Recap: Face up to communication problems

Last month I pointed out that we have to deal with a lot more than language barriers with global projects. For example, in some cultures, speaking openly is not to be expected, in any setting. Furthermore, communication is often strongly augmented with non-verbal cues that simply don’t come across the telephone or email channels. The very method someone uses to communicate often carries an important message in and of itself — “reading between the lines” and picking up on the myriad of non-English, non-verbal hints is critical. It takes time and often a great deal of experience on an individual level.

Doing everything we can to remove ambiguity from project communications can be a huge help. One of the first things I generally want to take a close look at are the techniques and processes used to manage a project. Most of the time, they are not adequate for one reason: They weren’t designed to support a global, multi-cultural organization.

Tools do help

Let’s consider some of the common problems stemming from communications issues:

1. Assignments don’t get handled correctly
2. Nobody seems to know what’s going on
3. There is no single place to go to find out how well (or how poorly) things are going
4. Sometimes people don’t seem to be working effectively
5. Things that aren’t important get attention, while things that are, don’t

These are problems that almost every organization has dealt with at some stage in its life. The typical global project almost always faces them, and often, fails to address the root cause, and then keeps right on stumbling over the problem. Making a few strategic changes to your process, and your tool set, can help dramatically.

Use the right tool for the job

I’ve seen many organizations use email inappropriately. Email is easy to fall back on as the main communication avenue when everyone isn’t in the same office building. For example, I’ve seen engineers jump in response to a new product idea from the CEO. This leads to circumventing the project management effort, often misdirects the lead engineer, and easily puts a project off-track. After all, what’s an engineer going to do — tell the CEO to go through channels and keep working on today’s mundane task, or jump on a new, exciting idea straight from the top?

Equally damaging is responding to every customer “fire drill” that comes up. Email invariably leads to rapid-fire emergency drills, often at a very high cost. Customer service sends an email to engineering, and engineering jumps to respond — in the process, putting current tasks on hold and upsetting schedules (not to mention the engineers themselves).

Stop using email for project communications, requirements, design and, above all, assignment of work. Email is a fantastic communication tool — but it’s not the right job for communicating work items on a project. It has a poor audit trail, as you never know who did or did not read it, emailed tasks cannot be prioritized or captured in a work management system, and at the end of the day, they’re just unreliable.

Instead of trying to stay on top of a dynamic, changing organization with email, use an appropriate work management system. There’s great news here: In today’s market there are fantastic systems available to handle requirements management, task management, project planning, customer communications, resources and more. In fact, probably the most daunting challenge is simply getting enough information to make an informed decision and choose the right tool. Cost is always a concern, but make sure adequate due diligence goes into analysis of the tools. Picking the wrong product can easily create problems. For instance, some tools may work well with your project management process, whereas others may not fit smoothly. In this latter case, people end up working outside the system — and that usually means sending emails to each other.

Use the right estimation methods

Also critically important in a global project context is taking a long, hard look at the techniques you follow for project estimation. Make sure that your estimation methods take into account the complexities of a global team — this means accounting for inefficient communication and dramatically variant resource cost.

Be wary of estimation methods that focus only on the short term. “Burndown” estimates that provide visibility into the next thirty days are a leading source of project overrun and schedule slippage. An appropriately planned global project needs to communicate the goals of the project throughout the team. This includes setting very real objectives and milestones. If the milestones are variable and tend only to establish goals in the short term these become the only measures of success for the team — in other words, hitting the thirty day goal means success, because other yardsticks have not been established.

Wildly variant resource costs must also be accounted for. It’s one thing when every engineer gets paid more-or-less the same salary. When facing a dynamic, global team where costs can vary by a factor of ten, cost overruns become a very real threat. Simple estimation methods such as burndown estimates neglect these issues on two fronts. First, they don’t establish an adequate project baseline, and second, they don’t measure resource cost and progress against the baseline.

Make sure that the estimation methodology you use is adequate to the project at hand. Keep “burndown” estimates confined to projects that are either free of cost constraints, or at least operating on reasonably small budgets — so that cost overruns won’t hurt the organization.

Pay close attention to metrics — and metrics tools

Metrics tend to be a sore point with many teams. Mostly, at least in my experience, this comes from the assumption that measuring and keeping on top of project status requires a lot of work, and requires capturing a lot of data that nobody wants to capture. This is just plain wrong.

The fact is, almost every organization I’ve worked with is already capturing the data they need. It just isn’t being used right. The basic information needed to estimate tasks and monitor progress of the project as a whole is usually already in the system — it’s just a matter of getting at the data and building the right kind of reports. For example, most popular project management tools that tout themselves as being “agile” tend not to bundle reports for EVM metrics, baseline comparison, and project cost overruns. This is certainly the case with Atlassian’s JIRA, an excellent product that I’ve frequently put to use on large scale projects. Fortunately, the data recorded by systems such as JIRA gives us everything we need to perform more advanced metrics analysis. We know the original task goals, it’s planned schedule and it’s actual schedule, and can derive planned cost. That’s all we need.

Staying on top of the metrics and measuring against original project baselines translates into a very tangible return: You know your project health at any point in time. You know if you are slipping the schedule, if project cost is increasing, if too many changes are being made, or if too many defects are being discovered. If you can’t answer these questions you aren’t on top of your project.

Prioritize and balance dynamically

Finally a note about traditional, static project planning. Project plans are out of date before the ink is dry. Make sure that your project management process and your tools take this into account. Whatever tool you are using, it needs to generate the supporting project artifacts for you — not the other way around. In other words, if you find yourself wondering “how can I keep this Microsoft Project file in-sync with the project,” you’re looking at the wrong end of the equation. Instead, your project tools should be constantly in-sync with the actual state of the project — and if you’re favorite view of the project happens to be a Gantt chart, then your project tool should spit out an accurate one at the click of a button. Let the computer do the number crunching and formatting. You need to concentrate on managing the project, the people, and the global organization challenges that your team faces on a daily basis.

Creating a truly collaborative, communicating team cannot be accomplished with tools alone. While the tips I’ve offered above are sure to help, they won’t address all of the challenges a global project team faces — but they will give you a starting point.

Related posts:

1. Tackling the global project problem
2. Managing risk in global projects
3. Fix your boss (or, reduce risk to quality using a matrix approach)

Each project reveals something new, sometimes subtle, sometimes much more obvious. While writing Outsourcing in the BRIC: Being successful in global projects with Brazil, Russia, India and China, understanding each situation and turning it into a tangible, applicable lesson was often a complicated exercise.

In this article, the first of several, I’ll present a few of the lessons learned — not necessarily the most prevalent or the most important, but lessons that I think most teams will run into pretty quickly and could derail you from the start.

Face up to communication problems

By far the most common, most glaring misstep U.S. employers make in foreign markets is to assume that people, by and large, aren’t that much different. It’s a mistake I’ve seen in almost every situation, whether the global team is Russian, Indian, Asian, or South American.

In the U.S. we have become very insular, expecting behavior from our workforce that simply doesn’t exist in other cultures. For example, we take for granted that employees will be outspoken and even downright vocal about anything they aren’t happy with. “The squeaky wheel gets the oil,” as the saying goes. But as it turns out, that saying doesn’t apply to many cultures. In fact, the global project manager needs to recognize that in some cultures, speaking out is not to be expected, in any setting. This has come up with almost every outsourcing effort I’ve managed throughout Asia: People will contribute extensively or not at all, depending on the culture.

One strategy to begin overcoming this problem is to initiate collaboration up-front. This can be a particularly effective tool for establishing peer relationships early in the game. While speaking out is not a given, it’s almost universally true that people open up to their peers before opening up to managers. Initiate your project with a two-day collaborative session to drive interactivity. Be sure to stage the session appropriately. It has to be at one location, the entire team should be present, and the environment should be tailored to create effective, collaborative conversations. Remember, it’s more about building the team than about making real progress on the project.

Be sure to continue facilitating collaboration once the exercise is over. If you don’t work to break down barriers constantly, they’ll crop up again — probably the day after your exercise ends. Make sure the team has the right tools to establish effective communication. Try to arrange team schedules that facilitate frequent communication. Develop an on-going staff rotation plan to make sure the team is constantly getting “refreshed,” and working together on a regular basis.

Beware differences in business fundamentals

Just as varied as individuals are the business environments. Consider, for example, the complexity of developing a product in a foreign market, with most of the team speaking a foreign language, with common business knowledge rooted in a foreign business environment. Many of the assumptions that we take for granted are simply missing, or interpreted differently in other countries.

Often a good starting point is to look for regulatory and risk management profiles that will identify potential differences of understanding. Compliance requirements are often taken for granted in one market and completely missing in another (think of COPPA, the Children’s Online Privacy Protection Act, a U.S. law that dictates certain standards for any system storing information related to a minor). Many such standards, laws, and policies exist and are well documented — particularly in Western nations — but are never explicitly communicated to foreign teams where such laws do not exist.

Another common problem: People who understand the technical aspects of a project, but not the application of the product itself, often work “blind” to project quality goals. For example, I once worked with a client developing a legal work product in the United States, but most of the work was performed in India. None of the Indian team members had a solid business or legal background, and even if they had, it would have been based on Indian business law. As a result, most of the team had only a vague idea of what the product would be used for, and none of them understand the target customer.

Be ready to reset perceptions

Depending on your market, your product, and your overall goals, don’t be surprised if there are a few false starts. Engaging a global partner is not something that will succeed or fail in less than 90 days. Having a short-term perspective and focusing on the tactical, rather than the strategic, will doom the effort to failure. Because of the multitude of barriers — from culture, to language, to geography — expect to take time to develop a lasting, successful relationship.

Likewise, when developing a product in the global marketplace, don’t be surprised if it’s necessary to restart the project once your client or partner really begins to articulate what they need. If the project was initiated in the U.S., its inception was probably isolated, initially developed in a silo. Assumptions regarding foreign markets, realistic business objectives, and misconceptions about global performance are likely to be re-examined.

Monitoring a global project is clearly much more complicated than a domestic project or one that runs entirely out of a single building. Make sure the right key performance indicators are being measured, and stay on top of them. Keep a careful eye on communication throughout it all. Once the gaps have been closed and a collaborative environment built, successful, frequent communication will drive creativity and results from foreign markets — while failing to have good communication will create isolated, poorly performing teams. Even though you operate as a global business, try to remember what it felt like when everyone was in the same building, and keep that feeling alive as much as possible.

Related posts:

1. Tackling the global project problem, part 2
2. Managing risk in global projects
3. Successfully applying lessons learned

Every individual is different, and every situation is going to require a different response. Temper tantrums, sexist remarks, chronic lateness, information hoarding, playing favourites … people don’t always behave themselves at work. An adept manager needs to understand the individual nuances of the situation and act accordingly. You need finesse, insight into your team, an understanding of psychology, and often, incredible patience. Here are a few strategies that I always like to try.

1. Engage the malcontent

Quite often, the negative attitude comes from feelings of being disengaged from the team or the project. Perhaps the individual thinks he could do the job better; perhaps he isn’t working on what he wants to work on; or, just feels the project is heading in the wrong direction. Most often negativity stemming from these problems will surface in a team setting, such as passive aggressive behavior, grumbling, openly showing dislike for decisions. I like to engage this individual in finding a solution. Hand accountability to that individual and, in essence, give full reign to fix the problem. With accountability often comes responsibility — and the need to realize that decisions are not always quite as simple as they appear on the surface. Of course, sometimes the individual makes a mistake — but in this case, the lesson is still learned. They “get their way,” but also find out that “their way” wasn’t, afterall, the right way. Of course you’ve got to strive for a better outcome — assign responsibility, and then back them up. Make sure they’ve got resources and help in the decision making process. Hopefully it becomes a learning experience for everyone.

2. Reach consensus

Sometimes it’s not practical to let an individual run with their own ideas. Yet, still you have someone that feels “things” are heading in the wrong direction. I like to try to reach consensus or, failing that, at least agreement that we’ve made the right choices given what we know. One approach is to schedule a round table with the malcontent and his peers, perhaps 3-4 people. Discuss the problem, and try to reach agreement on direction. In the best case, his peers will sway his opinion. More often, the complexities, choices and decisions that have led to the current situation will be discussed — and the “black and white” situation fades in favor of many choices, and trying to make “the best one.” With a little luck, the malcontent employee walks out of the round table with two things: 1) a sense of having been engaged in the decision making process and 2) a new appreciation for the complexity at hand, and the decisions that have been made.

3. Make it clear that it’s a team effort

A one-on-one discussion goes a long way. Spend some time with the individual and really try to listen, and understand what the problem is. Come up with some mutual objectives — some things for the individual to work on (these might be soft skills, such as being less negative) as well as some things for you to work on (these will be things to help ameliorate the bad attitude, such as making sure his opinion is part of the decision process). Make sure it’s mutual, and show some real effort here — there’s tremendous value in demonstrating how much you value each individual’s contribution. Work with the individual to address the problems and find solutions.

4. If all else fails…

If you still have a problem employee on your hand after making a sincere effort to fix the problem, you’ve got to make it clear that continued negative behavior will not be tolerated. You also need to be prepared, so document the problems. Keep a record. After some time, it will become a matter of reprimanding and giving specific, required objectives. This is the worst case scenario and more often that not, the first step toward losing an employee. Sometimes it’s a “wake up call” to the individual, but often this kind of heavy-handed approach just feeds the negativity. Be prepared for either outcome.

Wayne McHale was a senior manufacturing executive when he heard reports that one of his branch offices was getting fed up with the arrogant, condescending attitude of a new manager. He decided to pay a personal visit to the office and put an end to the situation right away. “I made it absolutely clear that while we were delighted to have him on the team, certain behaviours could not be tolerated in a team environment,” says Mr. McHale. “He was taken aback, initially, because I think the behaviours were somewhat ingrained. He was a star and had been told for too long that he was wonderful.”

Whatever the case, make sure you have a good documented history. You can use it when talking about the problem with the employee, making sure you have concrete references to poor behavior. In the worst case situation, you can also use it to back up termination papers.

Above all else, don’t be an enabler

Some organizations actually nurture bad behaviour, according to Lew Bayer, president and CEO of Civility Experts Worldwide. For example, an all-star employee with a primadonna attitude may be tolerated because a manager decides it’s too costly or too much hassle to seek a replacement. Or perhaps certain rules may not apply to someone who has formed a friendship with a senior manager. In situations like this, it’s often the boss that’s the problem.

You can’t avoid dealing with workplace performance issues — it will come back to haunt you in the long term. Perhaps other employees will get fed up and quit. The problem employee might have a temper tantrum in front of a client. It’s hard to predict but one thing is almost certain: It’s going to happen at the worst time, when stress is high and a lot is on the line. Ignoring the issue won’t make it go away; it will just get worse.

Don’t wait until the problem becomes a problem for everyone. Be proactive, and recognize that the workplace is above all a place for professionalism. If your star performer is worth keeping, coaching can help. If your disaffected team member needs to feel involved, a few changes can make that happen. But, only if he’s open to the idea. If not, it may be time to take more direct action in order to preserve the integrity of your team.

Related posts:

1. When there’s a freeloader on your team
2. Team-based performance is key, but only works with team input
3. Managing with blinders on

Good employees are really hard to find — A solid worker isn’t just difficult to find, he or she is really difficult to find. And they’re the first ones to leave. The truth is that 10 percent of the world is competent – and you’re looking for that 10 percent in every hire.

It’s hard to do consistently. And that’s why organizations that do it with frequency have such strong reputations. If you want to build a business predicated largely on finding, getting and keeping quality employees to succeed, you should understand that premise will be your greatest risk. Finding a market and profitably selling to it (usually the greatest risks) will take a back seat. Better yet, pursue a business that needs some reasonable percentage of employees to be really good.

But if that news isn’t bad enough, consider the other side of the coin — if you don’t have really great employees filling your ranks, then what do you have?

Your bad employees rarely quit — For one thing, poor performers aren’t really all that motivated to look, as that might involve actual performance. For another, no one else is likely to recruit them. Your marginal and weak employees are with you for life unless you move proactively. In many years of running businesses, the only time this wasn’t true was during the dot-com bubble. At that time, every idiot could get a 15 percent to 20 percent raise here in Northern Virginia by changing jobs. And they did. Aside from that blessed time, weak employees are your most “loyal.”

Don makes a good point, among several others (his article is 8 things I wish I knew before starting a business): Having, and holding on to, great employees is very, very hard work.

It’s also quite possibly the one sure-fire factor that’s going to push your company toward success. Consider a few of the leaders in the technology industry, such as Apple and Google. Both have stringent hiring processes and focus on the quality of the hire first, and growth second.

Let’s put it another way: Does it make sense to focus on growth if what you are growing is mediocre (or worse)?

Related posts:

1. Hiring for the culture
2. It’s never a good time for training
3. Articulating the value of training

Let’s start at the beginning and reiterate this original statement from Schwaber and Beedle, the creators of Scrum:

Scrum is a management and control process that cuts through complexity to focus on building software that meets business needs. Scrum is superimposed on top of and wraps existing engineering practices, development methodologies, or standards.

Scrum is a process. One process, that must be taken and combined with other practices, methodologies and standards. A process does not, in and of itself, create a methodology and for this reason I say that “Scrum is not an agile methodology.” I might even go so far as to say “Scrum is not Agile,” but that’s misleading — because as a process, Scrum is compatible with and enhances agility, either taken as an “Agile methodology” or a general practice of being agile.

As Scrum has become more of a buzzword it runs into this dichotomy more often. I experience this frequently with my clients, where the dialogue goes something this this:

Me: “So, what methodologies do you follow?”

Client: “We use Scrum.”

At this point, I feel as if, say, I’d asked for a bowl of fruit and being given a bit of jam.

Me: “Yes, but that doesn’t answer my question since Scrum is a management process, not a methodology — do you use any development methodologies?”

This last is often poorly received. It’s at this point that I typically remind my client the reason I’m here is because they’re having trouble, and the reason is likely because of poor internal processes.

Methodology is a body of practices, procedures, and rules used by those who work in a discipline or engage in an inquiry. In the context of software and systems engineering, it specifically addresses how we manage the conceptualization, specification and delivery of the software. Scrum does not cover any of this. Scrum is just a management process that can be applied to pretty much any business situation.

A good methodology is going to provide a framework in which requirements capture and management is specified. Project parameters and management criteria, such as reporting structure, authority and responsibility, status management and progress management will be specified. Program assessment goals and objectives will be specified. Assessing organizational capability and planning growth or acquisition may be needed. How requirements are stated, what depth they must go to and what standards must be met, and how to manage change in requirements will be specified. Likewise, quality assurance processes will be set forth (for example, audits and controls will be put in place to ensure requirements meet agreed upon standards). Testing of the product will be standardized as well: What techniques will be used, what are the goals of the test program, and what will the output of the test program be? User acceptance standards should be specified and usability testing programs implemented. Transitional phase operations, often overlooked until “after we’re done,” need to be planned and prepared for — and then executed. Scheduling, resource planning and budget management are of course a key component of any well-run program. And through it all, meaningful measurement criteria must be established and communicated to stakeholders.

Scrum touches only the tip of the iceberg in regard to much of this. This is intentional: Since it’s designed to work compatibly with just about any methodology, Scrum explicitly avoids putting too many constraints in place. More than anything it’s intended to refine an existing methodology and process, improving its productivity through streamlining.

Of course, sometimes Scrum is all you need. A sufficiently senior team, comfortable with the problem domain, combined with a project of reasonable size and a business that’s willing to launch without a clear end-point can work. But more often than not, one of these four essential elements is missing. Perhaps the business isn’t comfortable with an undefined, vague end-point (they may want to know what the budget is, or have a hard launch date). Perhaps the team is new, hence the necessity for more structure and measurement. It’s a rare situation that we can dive into a project with no methodology, only the Scrum process, and come out the other side in a favorable position. Sometimes it will work, but it’s a gamble — and often a gamble that the business isn’t willing to bet on.

I’d like to stop hearing “we use Scrum” in response to the question “what’s your methodology?” It’s great to say, “Rational Unified Process with Scrum to streamline it” or perhaps “XP with a Scrum wrapper so we have better visibility,” but please don’t try to deliver software with “just Scrum.”

Related posts:

1. Making Scrum work: Common failings in adopting Scrum
2. Why Agile isn’t enough (and why it doesn’t work)
3. Common oversights in choosing methodology

Indeed, a good question: What would we do without the hero?

Let’s flash forward a little ways. The hero has grown tired of the project and leaves. Fears abound that the project is doomed; there’s no way the team will survive without him. Concerns run deep, until the hero tells us he’ll stay on-board as a part-time consultant. Of course, he’s pretty busy these days — but, well, he’ll give us a “preferred” rate and show up at least a few days each week. He’ll keep the project afloat, no worries… in between getting his new company off the ground, of course. The one we’re funding with expensive consulting dollars. Either that, or the hero feels the project isn’t challenging enough, and leaves to greener pastures and more exciting projects, still promising to provide part-time support to keep the project afloat.

Either situation is dismal. Both demonstrate a project and a team that’s being held hostage to the whims of the “hero.”

The truth of the matter is simply this: Heroes are bad for the team, bad for the project and bad for the company.

Heroes are motivated by making themselves indispensable to the project by becoming irreplaceable. Most often this takes the form of information hoarding. The hero understands quite well that the established culture supports his role only while he and he alone can solve the project’s problems. One of the most effective ways to make sure this happens is to keep critical information away from the team. He’s the only expert in a few critical areas, and refuses to share his knowledge because it would be inefficient or too difficult to convey to someone else.

This leads to situations where the hero is subtly motivated to make sure there are instances in which only he can save the project. By ensuring the hero is the only one with the answers, the only one who can solve the problem at hand, he becomes indispensable — and, also, a tremendous project risk. Not only is everyone on the team constantly put in second-place to the hero, they also suffer as a whole when the hero is at his best. In times when the hero “shines,” the team is struggling to overcome roadblocks they haven’t been prepared to deal with. The project falls into jeopardy because the team cannot focus on a solution as a whole. Instead, the team churns in vain trying to contribute to the solution that only the indispensable hero can tackle.

Consequently, team morale is often a casualty of the hero culture. The continued failure of the team to exceed project goals, instead running into roadblock after roadblock, is tiring. Compound this with the fact that only one person, the hero, is enough of an over-achiever to solve the problems of a seemingly over-ambitious project and the team begins to become demoralized. Nobody likes to come face to face with failure repeatedly. Doing so in an environment that doesn’t provide the tools to better oneself is futile, and the hero team leader is certainly not motivated to fix the situation. In point of fact, most heroes tend to be pretty lousy team mentors, as being a hero implies putting oneself above everyone else. This means that while the hero has holed up inventing the next great solution, the team is left to its own devices. This vacuum of leadership provides a poor environment for anyone interested in advancing their skills and career, let alone seeking out a workplace that provides opportunity to learn.

Environments that support the hero become detrimental to the team. With the team leader focused on fulfilling the role of hero, collaboration suffers. Without a truly open, collaborative, information-sharing environment projects function at low efficiency (or, in some cases, fail to function completely as information is silo’d and isolated). In contrast, a healthy team elevates everyone, sharing information and skills, making the hero obsolete and making the entire team indispensable. A collaborative team rapidly turns into a formidable force when its collective attention turns to any problem — such teams turn out productive results faster and more efficiently. Each individual’s growth becomes a focal point, and the positive experience and knowledge gained from such a working environment becomes a lesson that each team member can share. In an open, collaborative, delegating environment the team lead will mentor the team; constantly challenging each person to take on more responsibility and grow into new opportunities. The best team leads are not information hoarders but information sharers, almost trying to engineer themselves out of the equation by teaching everything they know. In fact, this kind of leadership becomes truly indispensable because so few people are able to teach, motivate, mentor and unify a group of people toward a single purpose effectively. It’s not the information hoarded in the team lead’s head that makes him invaluable, it’s his ability to create a hyper-productive team and get things done.

As a project leader it’s important to confront the hero mentality head-on, making it clear that a hero is known for what it is: A detriment and risk to the project. Heroes are a liability. They are a bottleneck to progress, introduce the risk of “hostage projects,” generally make poor mentors and leaders, and always create specific situations that are harmful or dangerous to the project.

Unfortunately, putting an end to hero culture is often not an easy task. Many workplaces that embody hero culture don’t understand the problem — they think everything is “just fine,” and look to the hero as a critical resource, someone that has saved the project or the company time and again. Especially in young or inexperienced organizations, the difference between a supportive environment and a destructive one is unclear. The hero continues to operate above and apart from the team, often disregarding what little authority or direction he disagrees with. Inexperienced team members don’t know they should have a team lead that is mentor, guide and teacher. Organizations can be set up in such a way that the hero figure is empowered beyond reasonable boundaries, as often happens when clear structure and accountability is not in place. Combined, these problems can create the environment where a hero-mentality, embodied in someone who is ill-suited to create unity, lead, and mentor, ends up holding the project hostage. Most often, the evidence will point to the root problem: The team will constantly run into problems only one person can solve; team members will disagree with the hero and often not achieve consensus; much of the team will be “out of the loop,” particularly where the hero is involved; overall, the team will operate either apart from the hero or as individuals, not a cohesive group. Perhaps most indicative: The hero has sole authority over the project, yet little accountability. This is common in so-called “flat” organizations. I tend to avoid organizations that strive to be “flat,” as it’s really just a way of saying “we don’t want to deal with the fact that someone has to be in charge.” The simple truth is that leaders and managers need to have the authority to implement policy. Good leaders and managers will find ways to do it without using their authority unless necessary.

The easiest way to fight hero culture is from a position of authority, such as the project sponsor or project manager role. Given the advantage of authority, the hero can be given a choice: Either become a collaborative leader, or face what amounts to demotion as a new leader steps in. Some heroes won’t be able to make the right decision and will end up leaving the project — but others will embrace the idea of transforming themselves into a positive influence. I’ve seen this happen in a few cases and can honestly say the results were extraordinary. It could be that your hero’s spirit is willing but he doesn’t recognize there’s a problem. Likewise, it could be that your hero is struggling to move into a management role and needs guidance himself. Sometimes you’ll find out the hero was thrust into a leadership role without wanting it, and will happily step aside.

Whether tackling the problem from a position of authority, or from the inside, there are a few strategies that will help to ease the process. Developing a collaborative environment is a first step at ending the hero culture. This means putting in place tools and processes to share information, including an open information environment. Get information out of everyone’s head and into a tool that facilitates group review and commentary, such as a wiki or document repository. This can begin by emphasizing brainstorming sessions, collaborative documentation and group exercises to design and implement solutions. Often group development can be a productive tool, as well (some environments, such as Extreme Programming, push pair programming as one example — I don’t believe pair programming should always be put in practice, but this is a good example of when it makes sense). Project deliverables should also be managed in an open, collaborative environment. Use a project or task tracking system that lets everyone see what’s going on, what’s being delivered and how it’s being done, and most important: Focus on shared responsibility and avoid having unique specialties in favor of collaboration.

The team should also push for opportunities to advance skills and individual knowledge. Avoid “information silos,” or individuals who hold all the answers to a specific problem. It’s healthy for teams to have more than one expert in an area. Not only does it reduce risk, it also affords a more collaborative environment where two or more people can openly discuss a solution and work together on implementation. Any time you hear “only one of us knows how to do that,” immediately think in terms of how you can turn one into two or three people.

Demand a leader that is a good mentor. If the team hero isn’t up to the job, find someone who is — and be vocal about wanting an environment that supports growth. A healthy work environment includes ample opportunity to take on more responsibility. Any project manager that hears you want the responsibility will start casting about for a means to give it to you — and that usually means making sure the team leader can advance his team.

Ultimately, your work environment is in your hands. If you’re aware of the problem, identify it and and surface it — but do so in a constructive way. Have ideas and solutions ready to solve the problem, and emphasize the value it will bring to the team or organization. Focus on the facts as much as possible, like productivity gains the team will experience when it has greater bandwidth, and how getting to market more rapidly (and probably with a better, more robust product) will boost return on investment.

Related posts:

1. Training versus development
2. Tackling the global project problem
3. Fix your boss (or, reduce risk to quality using a matrix approach)

“The problem is that, especially in a small shop, we:

a) Don’t have comparable projects that can be used to provide historical data, especially for partner projects that are often more one-off than core product development. I can say with some confidence how long it takes to add a new Struts 2 action and mapping – that part is easy, but what about the elements on the page? What about the logic?

b) Don’t have the infrastructure in place to really record time spent on any one task, and often find that if we did, it would be inaccurate because we wear so many hats, each hat being taken on and off randomly throughout the day/week.

c) Can’t afford just yet to spend a lot of time making exhaustive estimates, because that’s time that won’t be spent in construction and testing.”

This is probably the most common problem facing software teams today and, quite simply, the root cause of most project failures. Even projects that are regarded as ultimately successful suffer from this issue, as evidenced by frequent project overruns, software delays and adjusted delivery goals. And yet, we have the tools at hand to solve the problem: Function Point Analysis, Proxy-Based Estimating, Evidence-Based Scheduling, and similar tools offer the basic software estimation processes needed to accurately predict the overall cost of a project.

The problem is not with lack of process: It’s with lack of proper adoption. As Kirk points out, in his own situation a host of pressures prevent dedicating the necessary effort, time and resources to do the job right. Put bluntly, relatively unseasoned teams often lack the experience and wherewithal to set up the right processes and make the right investments. These “investments” typically translate into very real costs to the business, longer development schedules being among the most obvious. The pressure applied by a business to set a delivery date now, before enough data has been gathered, can be daunting. It often takes a combination of two things to successfully pull off software cost estimation: First, a team that has the ability to make accurate statements regarding a software project, and second, a business that is willing to listen to that team.

An experienced team

During my years performing project auditing I’ve noticed a trend throughout Silicon Valley, particularly among startup companies. This trend involves creating teams from remarkably bright individuals that have very little formal training or experience in software development. Other sectors, including large scale enterprise and the military, take a different approach: Assembling teams that have the senior leadership necessary to create an effective team. This means a formal understanding of development process as well as experience — because, quite simply, technical knowledge without experience generally results in missteps. Those experienced, senior dinosaurs are actually quite valuable in providing guidance and mentoring to the development team as a whole. But, again being quite blunt, these senior experts (SME’s or Subject Matter Experts) support their teams in a very effective way by providing the voice of experience and authority to the business. This is the bit about “standing up to the business,” and is critical when the business tries to step in and force decisions that just shouldn’t be made yet.

A listening business

Perhaps equally important as building a team with experienced, authoritative leadership is having a business that recognizes the value — and expertise — of its team. That has to extend to a willingness to listen to the team, and take the team’s recommendations at face value. I’ve personally walked away from more jobs than I’ve taken where it was apparent that the business believed in a purely “top down” management style, not giving the team the resources or time it needed to make the right decisions to deliver a quality software product.

Let’s make this concrete: What does “listening to the team” mean? More than anything it means listening to the needs of the team and addressing them. Kirk points out that they have a lack of expertise in software cost estimation: Hire a consultant to work with the team for three to six months to address this need. He points out a lack of infrastructure: Buy the right tools and give the team time to put them in place (they aren’t that expensive). Most appalling to me, he points out a lack of time to invest in estimation because that means the team isn’t coding: Give them the time to do their job right. The long term benefits will be realized ten-fold through accurate software estimation, greater reproducibility and improved software quality (you know how the software is always late or ships with too many bugs in it? This is the root cause).

Strategies for success

For projects that don’t have a body of work product to use for historical data, look outside the project. Unless the team consists of entirely junior programmers with no experience under their belt this won’t be hard to do (the formal nomenclature for this is wideband delphi, an easy-to-use and surprisingly accurate method for discovering historical data where none seemed to exist). The basic process is simple: A moderator and an estimation team with three to seven members is selected for two meetings run by the moderator. In the first meeting the estimation team creates a work breakdown structure (WBS) and discusses assumptions. After the meeting, each team member creates an effort estimate for each task. The second meeting is the estimation session, in which the team revises the estimates as a group and achieves consensus. I’ve had excellent success using this process as a basis for arriving at reasonably reliable estimates, but it’s important to add one more step: Make sure that the programmer that takes up the given task agrees with the estimate, and understands the task in full. Sometimes the group estimate will be more aggressive than an inexperienced programmer is willing to take on; likewise, sometimes an experienced programmer will know it can be done more quickly. Be conservative, and defer to the individual programmer when appropriate.

In regard to making time for the underlying effort in software cost estimation, one of the most common excuses I hear is “we don’t have the tools to record time, our team wouldn’t agree to it, and if we did, it would be inaccurate because we wear so many hats.” Frankly, this is just procrastination. First of all, read Joel Spolsky’s article on Evidence Based Scheduling. It’s an excellent introduction that clearly explains why wearing a lot of different hats, being distracted by unplanned tasks, and having a chaotic environment just doesn’t matter. A good system for measuring velocity is going to understand and accommodate those realities — in fact, the entire purpose for estimating velocity is because of all these unexpected, unplanned interruptions. If we had none, our estimates would be perfect, wouldn’t they? So, where does this excuse lead you but down the same, inevitable path: Lots of misunderstandings with the business, failed deliveries, slipped ship dates, poor software quality and an awful lot of late nights trying to get incomplete software out the door. Stop the addiction: Do the right thing and spend $200 on FogBugz or, if you want to go industrial choose my favorite, Atlassian JIRA (it’ll cost you a couple thousand dollars, but it’s probably the best investment your department will make, period). If you’re looking into JIRA, check out the Greenhopper plugin.

And finally, if you feel you just can’t take the time to estimate and manage your project, keep in mind this is the same as saying “we just can’t take the time to do it right — so we’ll hope for the best.” This is a classical problem for many Agile organizations that focus entirely on the short-term while sacrificing long-term strategy. It’s a situation that leads to a perpetual, self-feeding problem, and it gets worse not better. It’s time to break the pattern and make the decision to fix it.

Probably the most important piece of advice I offer team managers is simply this: “I don’t know” is OK. The worst thing you can do is commit too early. When the business challenges you for a timeline and presses for a hard and fast ship date, the best thing you can say is “I don’t know.” The natural follow on question is going to be “fine, what do you need to find the answer?” Stand firm and insist that you need the time, tools and resources to accurately estimate the job. Cite past performance — or past lack of performance, failed deliveries and customer service problems, if need be. Ask the business “do you want more of the same, or do you want to improve?” Ultimately, it’s up to you as the team lead, Scrum Master or project manager to make this happen.

Related posts:

1. Don’t ship broken software

Is this attitude regarding education part-and-parcel of the declining attitude toward education in the United States? More to the point, how will organizations continue to function if they curtail strategic learning initiatives? People don’t “just know” how to apply complicated concepts. They need training, particularly in areas such as software quality assurance, safety & reliability, validation & verification, and the basics of leadership, mentoring, and working as a team (including formal process education). And I haven’t even touched on morale issues, upward mobility and challenging our employees to aspire to improve their career path.

The fact of the matter is, in today’s economy we should be pressing for more education not less. This is called “recession proofing your organization.” Inevitable pressures to reduce staffing means fewer employees will need to do more, do it more effectively and take on new challenges they’ve never faced before. How about preparing them for it?

So, in an environment that doesn’t support training, how can organizations find educational funding?

Recognizing that training is not a wasted expense is probably number one. This needs to happen with management, but it doesn’t need to begin there. Training programs that are relevant to your work and beneficial to your employer are clear wins. Document the benefit of offering greater cross-functional capability within your team, of improving your efficiency, and reducing mistakes. Put together a training plan that demonstrates how the organization will benefit before you take a training request to your manager.

Consolidating training is also a huge win in most cases. For example, if you send five people to training courses around the country you’ll likely spend at least $15,000 (assuming the course costs $2,000 and then factoring in reasonable travel costs for each person). Consider bringing training on-site instead. Most programs that are available in public classes can also be delivered at your organization, and tailored to your specific needs. You get better, more relevant training and comparative costs are low. (An on-site workshop costs as little as $5,000-10,000 and becomes more cost-effective with more employees).

Use digital learning tools to reduce training costs as well. In particularly tight times, many web-based training programs exist. While not as effective as on-site, person-to-person training with an expert they can still provide a huge benefit to the student.

Focus on internal cost savings as well, and justify how the saved costs should at least in part be translated into better organization capability through training. For example, if you have more than one document repository (a problem many organizations suffer from) implement a single, consolidated document management system to improve efficiency and lower licensing costs.

One final idea that might find some traction: Audit your internal learning requirements and processes. Put together an analysis that demonstrates organization weaknesses and tie those weaknesses to actual issues the organization has experienced. Document the costs of handling those problems in retrospect and show how improved capability and efficiency would have avoided the problems—and will likely avoid future problems.

Related posts:

1. The case for certification
2. Articulating the value of training
3. Bad employees rarely quit and good ones are hard to find

1. Employers should not require certification.
2. Non-skill-based certification testing procedures have little value.
3. The Alliance is deeply concerned that uncertified, skilled workers will get locked out.

After considerable rumination I’m still feeling like the Alliance’s stated opinion here is fuzzy at best, misguided at worst.

I tend to agree that employers should not require certification for all things, but I disagree with the blanket statement that employers should never require certification. Wouldn’t you like to know that your management team is involved in current program management developments in the industry? Wouldn’t it be good to know that your Software Configuration Management lead didn’t pick up his knowledge entirely by the seat of his pants? Certification, just like earning a degree, demonstrates that a student has studied and understood specific subject matter. Particularly for team leaders this is valuable across the organization.

As for the value of different kinds of certification programs, I think this is a problem that will market correct. The market will tend to favor better certification programs. Certainly, I agree that skill-based certifications heavy on essay testing, problem solving and hands-on examination is the best way to go. But it’s neither here nor there. Education and certification is a good thing to support; if there are a few poor programs out there, they’ll eventually get weeded out.

On the Alliance’s next point, that skilled but uncertified workers might be “locked out,” I can’t help but feel the concern is misplaced. First of all, there are a number of industries where certification is required and sponsored by the employer as part of on-the-job training. But more to the point, I’m not at all concerned that the overly chaotic technology industry is on the verge of adopting uniform, required certification prerequisites. I can’t shake the feeling that the technology industry would benefit from looking harder at certification programs, much like the medical, scientific and even accounting industries do. Would you want an Uncertified Public Accountant working on your tax return, or a Certified one?

I’d love to see the Alliance restate their opinion, possibly stressing some of the benefits we could, as an industry and at the individual level, realize from good certification programs:

1. Keeping knowledge current. I don’t care how good a programmer you are. There is simply no way to stay on top of the best practices body of knowledge without looking to external sources. Picking up as much of that knowledge as possible through excellent training curriculum makes sense. The individual improves their skills; the organization motivates and energizes their employees and realizes benefits from best practices.
2. New discoveries in the field. There are new breakthroughs almost every day. The training and certification programs available today provide a venue for tapping into that knowledge, and in many cases the alumni associations create communities to share and develop ideas.
3. Demonstrating skill in established standards. Good certification testifies to two things, in my mind: First, that the individual is capable and competent enough in a field to pass an examination. That’s actually pretty darned valuable in the loosely defined technology field. Second, it tells me the individual cares about their continuing education and trying to be the best they can be in an area. Certification is optional. I’ve found that the people that get certified tend to be people that are more passionate, more enthusiastic, and want to be better at what they do.
4. Establishing a few standards. There are a lot of evolving standards in technology. Some are well established and many are brand-spanking-new. With this amount of technological turnover it’s hard to know what someone means when they say “I know Agile.” Having a common point of reference is not always a bad thing.
5. Assuring baseline knowledge in senior team. Without some common ground, how can we all talk about the same domain? By having at least the senior team go through with certification it helps bring all of the benefits of continuing education to the team using a common vernacular.

I’ve managed a lot of project teams over the past few decades. Almost every team that I’ve been asked to take direction of has had a wide range of skills, some barely adequate and some exceptional. Most of us have had similar experiences: Quality assurance groups where none of the staff have been formally trained in structured software testing, configuration management or even what quality assurance programs are all about, for instance.

I’m going to go out on a limb here and say we need certification. We need to know that the program manager knows how to manage across projects; that the quality assurance manager understands product life cycles; that the configuration team has a solid grounding in configuration identification and audits. It’s a natural evolution of this industry—an industry that is still very young, and showing it’s growing pains every time we look at it.

Related posts:

1. Is Scrum Master Certification Hurting Our Industry?
2. Finding strategic learning funds
3. What do you mean, SQA isn’t testing?

I respect goals more than most people — having founded or directed a number of innovative projects that’s probably a given. But I also respect a balanced strategy in developing those goals and the forethought to plan for changes.

I decided to take on a project reinventing a product that had over a decade of history behind it. Actually, I was more talked into taking the project by a friend and prior colleague. Over many months we went back and forth on the subject — but eventually I caved and decided to do it. In hindsight, my mistake was obvious. I had let my friend sway me, despite all the cynical bias I usually apply to potential projects.

When I started discussing taking the project on, the terms had already been set in stone. An early adopter client had signed up to foot most of the development cost, the project goals had been established, a target date was set and a contract signed. The project would be delivered for a fixed price. All of this was acceptable to senior management and even seemed reasonable at first. It was understood that the project dates and even the budget might not be “quite right,” but this was a long-term product. A little bit of overrun was to be expected.

As the project director I would be responsible for all technical execution. I would inherit the legacy system’s development team and have the ability to hire a couple of new people if need be. It was an attractive project, but riddled with potential problems. The irony is, I flagged all of these problems before taking the job — and I did it anyway. I was caught up in the persuasive, charismatic message the company President voiced — and two years later I’m reminding myself to keep those cynical biases near at hand.

“Remember that the worst reason to do it is for love.”

It’s important to love your work — in fact, personally I think it’s a requirement. It’s also important that you don’t do it solely for love. I’m a technologist through and through — and that makes my work dangerous. It’s easy to get wrapped up in the moment, to be one of those smart people defending bad ideas. What I need to be is a smart person defending a smart idea — an idea with all the right elements to evolve into a brilliant product, support a viable company, cross to the early majority market and achieve success.

Be objective in your analysis. Long ago someone gave me this advice: “Never invest in your own product.” In other words, if you can’t find other people that are willing to invest, you’d better challenge your assumptions. Maybe the idea isn’t well evolved.

“Look for the chasm.”

If you haven’t read Crossing The Chasm by Geoffrey A. Moore, it’s a worthy read, especially in the technology market. The company’s strategy was wrong. One of the most important aspects of product development is considering how the product will make it to market. That means developing a strategy around early adopters as well as the “early majority,” a group that represents the first half of your market research bell curve. The early majority is your cash cow. Make it into the early majority and you’ve got it made. The problem is getting there.

The root of the issue is crossing the perceived “chasm” from the early adopter to the majority. Early adopters are a rare breed of client. Typically they are actively seeking out new technology. They are often willing to take risks the majority avoids and may even fund development of early projects. Unfortunately, there are few early adopters — most companies can only attract a couple, if even that. And to make matters worse, early adopters make costly demands. Because of the concessions the early adopter makes — greater risks, higher costs, early funding to name a few — they demand greater returns. In a nutshell, they demand a custom project that meets their very specific — and yet often hard to define — requirements.

And there is the rub. If you are building a custom project tailored to the picky needs of your first — and perhaps only — customer, how can you evolve it into a product suitable to the majority? Such a product must be suitable to a wide audience “off the shelf,” robust, complete and easy to adopt. Custom solutions rarely meet these criteria.

To overcome the disparity between a hard to finish custom solution and a generic product of wide utility a company must budget time to “cross the chasm.” The transition from the custom, early adopter client to the early majority is often not an easy one. Products must be retooled, marketing messages revamped, new clients must enter into the pipeline (riding, hopefully, on the good recommendations of your first early adopter clientele). This is a critical time and often one that a company fails to plan for. The chasm was largely dismissed on the assumption that existing clients adopt the new product readily yet no transition plan from early adoption to majority adoption existed.

Even if the project goes without a hitch, there is necessarily a transition from the custom project to the generic product. This time must be budgeted, and funding must be allocated. Glossing over such a transition is a huge oversight — and probably the number one red flag for potential failure.

“Requirements are… required.”

Another concern surfaced very early in reviewing the project. The requirements that had been gathered were far from adequate. The entire work of requirements consisted of a tailored and very detailed request for proposals from the early adopter customer and the idea that the legacy software would serve as a blueprint.

These requirements, as an RFP, where actually very good, consisting of hundreds of pages of needs, desires and parameters from the customer. In many regards it was far more complete than most RFP’s — but it had very little to do with requirements per-se. The RFP was riddled with contradictions, incomplete statements and inaccuracies. The technical detail was simply not there but the business treated it like a finished set of requirements.

For example, round-trip integration between a 20-year-old Adabas court information system was summed up in a few sentences amounting to “there will be bidirectional communication with the court information system.” The effort was dismissed as trivial — yet the company ended up investing well over eight monthsof development time on this oversight alone.

“Don’t ignore unrealistic preconceptions.”

During my early discussions regarding this project a certain lack of grounding in the realities of software product development became clear. It’s important that the entire company is backing up a new project. That means aligning resources and setting goals in such a way that growth into a viable second-stage project is possible.

An early conversation I was a part of should have received more attention from me. “Once we finish the first release, we’ll be able to reduce staffing. Future versions of the product will require little or no additional development,” posited the company President. This attitude surfaced repeatedly, lending pressure to “finish” quality assurance efforts so that we would stop spending money on testing. My initial reaction was simply to dismiss these ideas, thinking that as feature requests, client demands and the realities of business growth became clear expectations would be corrected.

Unfortunately, pressures from the business alone are not enough to change deep-seeded misconceptions. This was a battle I ended up fighting repeatedly. Ultimately, the idea that the development effort should beshrinking rather than growing to accommodate a larger market contributed to the “chasm effect.”

“Avoid compromising on methodology.”

“We already have a contract, we know what we want to do, and really it’s OK if you go over budget. Let’s just get to work.” Sounds great doesn’t but? But it never really works that way. The realities of a business mean that your board of directors is watching the bottom line — unless you happen to work for Xerox Parc, stick to your methodology. Plan your project scope, development an lifecycle, and treat your business as “the customer.” Follow through on every aspect of iteration planning and delivery.

In retrospect I can say that a casual business attitude (such as evidenced by the statement above) is probably the most dangerous situation to get into. Customers will hold your feet to the fire. Investors want to see progress. Paying clients will demand quality and new features. But a seemingly casual business owner isn’t going to stay casual for long. Eventually the project schedule starts to matter. Follow your methodology, emphasize communication and frequent releases to keep the business in the loop, and don’t believe for an instant that it’s OK to take a shortcut. Inevitably, those shortcuts come back to bite you, quite often in the form of misunderstandings around schedules, features or capabilities.

“There is no substitute for a clear contract.”

Don’t buckle under pressure to get things rolling. I’d say at least half, if not more, of my projects have started with pressure to begin work with no contract in place. Clearly, starting work without a contract is in the client’s interest, or at least it seems to be. But what happens when the team is several months down the road and issues start to arise around responsibilities, client involvement, payment schedules and procedures to resolve these matters?

In the worst case you can end up with a poorly drafted contract that fails to lay out clear guidelines for all parties involvement. In this case, the contract was already in place — and unfortunately, none of these details were well incorporated. This can lead to poor client involvement, a very difficult situation with a demanding, early adopter client. Insist on a clear, well structured contract that makes it clear who is responsible for what activities. Incorporate these procedures into your methodology and risk mitigation strategies.

Technically, the project delivered some fantastic technology, but the cost on the team was high. Long hours and very hard work — and as of yet, no clear pay off as the company still struggles to get over the chasm and find a mainstream market. In the long run, I can’t help but think everyone would have been better served had I stuck to my guns. My instincts were to walk away from the project — and in so doing, provide a clear and concise message that the project could not succeed as it was set up.

Entrepreneurs, particularly those with a strong vested interest and long history with a product, can be terribly persuasive. Years of tuning the message and creating an infectiously exciting atmosphere makes them skilled at converting skeptics. Becoming excited about a product is wonderful, but don’t let the euphoria of the moment overshadow the concrete facts.

Related posts:

1. Common oversights in choosing methodology
2. Tackling the global project problem