During the ensuing discourse respondents from around the world posted not less than 18 different answers to this question.

Among the responses were answers such as “having poor stakeholder involvement,” “not enough project planning,” “poorly documented requirements,” “the budget being too small or poorly estimated,” and “the [project] goal is not consistent.” To be sure, many of these 18 answers are highly relevant to the success of a project — and yet, every single answer was wrong. None of the 18 responses identified the single, most common mistake of project managers.

In fact, each answer emphasizes the root of the problem: Too many project managers are focused on the day-to-day problems of the project and have lost sight of their overall strategy. They are thinking tactically, putting out fires, rather than strategically — making sure the fires never happen in the first place.

Take, for example, a few of the more common issues raised in this discussion:

1. Poor stakeholder involvement. Let’s assume for a minute that we have a solution to this problem — perhaps, for example, a project manager has correctly identified all the stakeholders, put together a great communication plan to keep the stakeholders informed, and succeeds in building a collaborative environment with the stakeholders “at the table” on a regular basis. If this solves the problem of stakeholder involvement, does it actually save most of the projects that go off the rails?
2. The budget was too small. Again, let’s assume that the right process was used to estimate the project from the start, and that the project manager uses a solid method for measuring performance, cost, and schedule (say, Performance Based Earned Value). Certainly, budget overrun is a common problem, but would this actually solve most project problems?
3. Poorly documented requirements. In my experience, every requirement is poorly documented to start with — so, let’s assume that the right approach is taken to turn poor requirements into great requirements. Quality assurance is involved early, a full-circle approach ties requirements to work product to acceptance, excellent change management is used, and stakeholders provide a final consensus. Will producing great requirements really save more projects than any other strategy?

The list, of course, goes on quite a long ways — and that’s the point. The list is long, and every single item raised is a valid concern for project managers. But with 18 different root causes on the table, could any one of them really make that much difference is the overall landscape?

These are all tactical solutions to specific project problems. So what’s the big picture? What is the one thing that would actually make the biggest difference, that would actually address many, perhaps even most of these 18 different issues?

Let’s take another look at KPMG’s survey of 252 organizations, and their subsequent findings. According to the study, inadequate project management implementation constitutes 32% of project failures, lack of communication constitutes 20%, and unfamiliarity with scope and complexity constitutes 17%. Taken together, 69% of project failures ultimately trace back to poorly implemented project management practices. What this means is simple: Project managers need to step back from the tactical, day-to-day fire fighting, and take a more strategic view. Adopting the right project management strategy will address most of the problems at hand.

How so? Let’s reconsider those first three project issues above.

1. Poor stakeholder involvement. A thorough project plan, adopted out of an appropriate project management methodology that is fit for the purpose, will place the right emphasis on stakeholder involvement. It will also provide the right tactical tools make sure stakeholders are involved, and appropriate measures should stakeholder involvement begin to fail.
2. Budget problems. A correctly selected project management methodology will put the right emphasis on budget analysis, and will provide the right tools to stay on top of the budget. The project manager may need to look outside his or her own skill set to manage to those requirements — but the methodology will establish the goals, the tools, and the metrics from which deviation triggers a red flag.
3. Poor requirements. The right project management plan will include appropriate methods, probably mandated as part of a technical requirements standard, for developing strong requirements. The plans will include adequate validation and verification of requirements — possibly through strong quality assurance measures. Again, all of these tactical solutions will become part of the project and solve the overarching problem.

So, the root cause of project failure — in fact, of 69% of project failures, according to KPMG’s study — is failing at the strategic level to identify and implement appropriate project management practices.

This means choosing the right standards and methodologies for the project. For instance, if tight quality and budget is a concern, more rigorous controls in this regard are needed. That probably means shunning simple methodologies such as lightweight, agile methods in favor of something that uses more ceremony and process (such as that defined in the PMBOK® and other classical project management approaches). It also means sticking to your guns and making sure the methodology is applied. Showing the methodology to the team and putting it on a bookshelf won’t cut it. Application is the key, and that means recognizing that the standards, practices, and procedures are there for a reason — don’t take shortcuts, because doing so means introducing risks to your project’s health.

Related posts:

1. Doing away with ineffective, broken risk management
2. Managing risk in global projects
3. Tackling the global project problem

1. Training focuses on the present — Development focuses on the future.
2. Training focuses on technique — Development focuses on talent.
3. Training adheres to standards — Development focuses on maximizing potential.
4. Training focuses on maintenance — Development focuses on growth.
5. Training focuses on the role — Development focuses on the person.
6. Training indoctrinates — Development educates.
7. Training maintains status quo — Development catalyzes innovation.
8. Training stifles culture — Development enriches culture.
9. Training encourages compliance — Development emphasizes performance.
10. Training focuses on efficiency — Development focuses on effectiveness.
11. Training focuses on problems — Development focuses on solutions.
12. Training focuses on reporting lines — Development expands influence.
13. Training is mechanical — Development is intellectual.
14. Training focuses on the knowns — Development explores the unknowns.
15. Training is finite — Development is infinite.

I couldn’t agree more. When it comes to leadership development, you can’t “train the leader.” Training on technical, procedural topics is of course highly effective, but leadership requires too much contextual differentiation, too much innovation, and frankly relies much more on innate skills that can only be developed over time, not absorbed from a short training course.

Related posts:

1. Tackling the global project problem
2. Why heroes are bad
3. Boomers at the exit gates

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

I think the most valuable asset a Software Tester can have is an attitude of gleeful problem discovery. Someone that loves to break systems, discover their imperfections, and explore their weaknesses makes a great tester. I haven’t met many people that really enjoy and excel at this, but it’s probably is an attribute that is common with Hackers as well.

It’s also wonderful to have a tester that really cares about the quality of the product. It’s absolutely essential for someone that wants to excel as a tester. That means having the patience and desire to work closely with the Quality Assurance group, to understand what a “good customer experience” means, and to really grasp things like quality of services, user experience, and customer needs.

Part of being a good tester means enjoying running down the rabbit hole. Where the hole leads is a mystery. Perhaps testing discovers problems stemming from poor UI design, SQL injection problems, performance issues caused by heavy loading, or playing the clueless user that always clicks the wrong thing and triggers a logic error.

The “how” of testing is another matter though. Yes, there are well understood principles and techniques, and often tools, for testing all of these things. I have found that in most cases, good testers tend to specialize. I don’t expect to find one person that can find the flaws in the user interface, perform load testing, and also look for SQL injection vulnerabilities. To get really good at all of these things, you need a team — some of those team members will focus on the back end, some on security, some on database systems, some on the front end. Finding someone that’s great at tackling a couple of those verticals is pretty rare. That said, every tester should have an adequate, at least shallow understanding of all of these areas. In order to properly localize a problem, you need to understand what could be causing it. But having other resources to bring in to help diagnose the specialty areas is critical.

Related posts:

1. Exposing the enterprise to risk: Who decides what not to test?
2. What do you mean, SQA isn’t testing?
3. Quality assurance as a way of life

Probably the most important factor to me is accessibility. Actually capturing lessons learned is relatively easy (as long as it’s embraced by project and team leadership). Problems, issues, ideas are still fresh in people’s minds so voicing them is not the problem. Management needs to recognize this and embrace the idea that some time needs to be invested in capturing lessons learned — and not just at the end of the project, but throughout its lifecycle. In my experience, this is pretty easy to achieve.

It’s returning to the information and using it in the future where most organizations fail to follow through. 

Having a system in place that makes sure the lessons learned knowledge base is consulted and used in the future is critical. My favorite approach is a well structured, collaborative, wiki-like system. For example, Atlassian’s Confluence has proven great in the past. It offers an open information repository that anyone can contribute to. It’s rich in terms of media integration, and it has version control and sufficient security to ensure that nothing gets lost. 

But most important, the system needs to provide a ready reference library. That means an excellent search capability and well thought out keyword or classification systems. Project managers and leads need to know they can consult the knowledge base, quickly find relevant lessons learned, and apply them to their current project. 

This also means capturing a lot of information. The tool is only useful if it really has a significant knowledge base. Lessons learned need to encompass the positive as well as the negative. Project performance statistics need to be in there. Specific development problems and solutions. Having a cross-reference to your support system or ticketing system is a great idea, because the team can look up generalities and then link directly to hands-on end results from past projects. 

Building the right kind of system is critical. Think about building a reference library. What does it take to feed the library, and what does it take to make it easy to access?

Related posts:

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

Organizations facing these environmental issues need to put a considerable investment into mitigating the associated risks. This is essentially why the “promise of outsourcing” has been toned down over the past decade: Gone is the illusion that you can get solid work for 25 cents on the dollar. “Real” outsourcing costs tend to range anywhere from 70 cents on the dollar to $1.20 on the dollar (yes, outsourcing can often lead to higher costs — but sometimes it’s not just about cost, but geographic presence, distribution, foreign market penetration, etc.)

Language barriers pose some of the most difficult issues to work around. Being unable to easily communicate means poor communication becomes a barrier to the entire team. This can lead to misunderstood requirements, misinterpretation of directions, even a complete disconnect on whether a team is in trouble or doing fine. Ideally, open communication, information radiators, and visibility are central to successful projects. Any barriers increase risk, and that means increasing efforts to compensate. Closely related to language barriers are cultural barriers. A pretty obvious example is the straightforward U.S. business culture in regard to the respectful and tradition-rich Japanese culture. Even seemingly similar cultures pose barriers; for example, East Indian cultures and U.S. cultures don’t easily connect until interpersonal barriers have time to break down.

Business environment and common bias also contributes to the risk of disparate teams, especially those separated by business culture. For example, consider a client developing a legal work product solution in the U.S. market while using East Indian resources. The lack of a common business foundation can easily lead to a complete disconnect regarding assumed business objectives (in other words, the legal system is very different in the U.S. versus India, which means a lack of common understanding regarding some pretty basic business goals).

All of these issues can be mitigated with appropriate practices. The necessary measures will vary from one project or organization to another — there are a lot of variables at work, and that means every project has to be treated uniquely. The common thread is communication. Breaking down these barriers by using process, technology and culture is critical. The disparate team needs to become one team, working as a unit — and that usually means a significant investment in tools, strong processes and team-building exercises. I strongly advocate rotating team members across the organization or project as one example. This helps across the board: It breaks down communication and culture barriers, helps team members get to know one another, lets distant teams experience local culture, and helps to build a collaborative “whole team.”

Related posts:

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

We all want to be Apple. We want to have their reputation, at any rate. A zealous customer base, fantastic products that seemingly flow out of design and into production without a hitch, and a virtually zero record of recalls or product delays.

But it’s the part about the customer that really grabs our attention. So the question is, how do they do it? If we put the right people in a room together will they just “get it,” and execute a flawless vision?

That’s likely a key part of it, at least in so far as it takes the right people to make the right decisions. But how do we execute our vision with such precision? And if we look at other successful companies, will we find some theme that’s in common with Apple? Absolutely. That common theme isn’t just one thing — But every single successful company has one common element in their strategy: A mechanism for avoiding undue risk.

Risk management has become mainstream. It’s no longer the domain of rocket scientists and actuaries. In fact, it’s become so mainstream that formal risk management practices are showing up everywhere we look. Most of the time, we’ll see the word Enterprise included in the definition — a way of letting us know “this is for the whole firm.” Enterprise Risk Management (ERM), Business Continuity Planning (BCP) and Governance and Risk Compliance (GRC) are just a few of the different names risk management flies its flag under.

Is More Attention A Good Thing?

But is all this sudden attention to risk management going in the right direction? To answer that, we need to look at the specifics of different risk management techniques.

For example, the Project Management Institute (PMI) and National Institute of Standards and Technology (NIST) have both put forward standards that devote significant space to the topic of risk management. The PMI standard of risk management (PMI-RMP®, or Risk Management Professional) includes some pretty extensive methods for identifying, quantifying and mitigating risk.

Much of the PMI-RMP standard can be considered a brief introduction to risk management. It doesn’t introduce quantitative analysis or provide any background of Judgement and Decision Making (JDM) theory. It does, however, provide a starting point, some kind of a baseline that we can use to at least make sure that our projects, programs and organizations are addressing risk management — at some level.

This is good, at least at first blush. But, unfortunately, when we dig deeper there could be a more subtle problem here: The practices advocated by PMI and NIST standards are, quite simply, apt to cause more harm than good.

Worse Than Nothing

There are decades of remarkable research in JDM and risk management theory. The research that has gone into this kind of theory has produced an invaluable treasure trove of tools, processes and techniques that we can leverage to learn how to accurately and effective assess risk across our organization.

This same research has also largely debunked “crackpot” risk management theory and poor decision making practices. For instance, Harvard Business Review led a study of over 200 popular management tools, like TQM, ERP and so on. Independent external reviews of the degree of implementation of each of these various tools was compared to stakeholder return on investment over a five year period. The resounding conclusion from this in-depth study, as reported by HBR, was that: “Our findings took us quite by surprise. Most of the management tools and techniques we studied had no direct causal relationship to superior business performance.”

But this shouldn’t be a surprise, at least not to anyone familiar with formal risk management and JDM theory. In research conducted over many decades, such as that of Brunswik, Kahneman, Hubbard and others, most of these recently introduced management practices have been exposed as ineffective and often even harmful.

Consider, for example, the principle method for quantifying risk in the PMI standard is a matrix-based weighted scoring system. This system advocates highly subjective risk assessment practices, such as relying on risk assessment almost entirely from subject matter experts. Studies have shown that even well trained experts — let alone the people that often serve as experts on review boards — tend to provide highly inconsistent and spotty assessment results. One study by Hubbard tested a group of experts in their ability to assess risk across a portfolio of projects. Unbeknownst to the participants, two of the assessed projects were identical — and, hence, we should expect identical risk assessment of the two projects. But that’s not what the study shows: Participants only agreed with their own risk assessment 22% of the time. The rest of the time, risk assessment varied widely, sometimes as much as 35% by the same individual.

Fixing It

Of all the professions that practice risk management, actuaries are the only ones that can claim a real profession. Actuaries, much like accountants, doctors and scientists, must demonstrate their ability to assess risk using scientifically proven methods. And, like other formal professions, an actuary puts her license on the line when certifying a Statement of Actuarial Opinion. As with doctors and lawyers, if she loses her license she can’t just get another job next door. The industry of risk managers, modelers and assessors outside of the insurance industry would be greatly served by this level of professional standards.

Likewise, organizations such as PMI and NIST should stop promulgating what amounts to crackpot risk management practices. Decades of extensive study have shown that the core principles of risk management integrated into the PMI and NIST standards simply do not work. Worse, in many cases these practices actually cause more harm than good. Scoring methods should be disposed of. Instead, standards should rely on existing bodies of proven risk management and JDM practices.

But in the meantime, attaining a greater awareness of the risks associated with bad risk management practice is our responsibility. Understanding what to look for in risk management, and consulting trained professionals that can employ statistical risk methods is a good starting point. At the very least, firms should consult with formally trained professionals — and look for empirical, statistics-based methods. Anyone proposing a weighted scoring system should be shown the door!

If you would like to learn more about risk management theory and practical methods of assessing and avoiding risk, see Hyrax International’s seminars on these topics. Attendees are welcome at public presentations. If you are interested in hosting a presentation at your firm, contact Hyrax International directly. Introductory seminars are offered at no cost.

Related posts:

1. Managing with blinders on
2. Managing risk in global projects
3. Fix your boss (or, reduce risk to quality using a matrix approach)

Having created a methodology that tightly integrates Scrum concepts, I tend to be a strong proponent of Scrum. But being a strong proponent doesn’t extend so far as to promote all the hype — I’m also a very strong believer in the value of formal education and the need for experience. After seeing the negative consequences of Scrum Master Certification, I’m hard pressed to see any benefits to it.

I’m not challenging the value of Scrum as a practice. I’m challenging the value of Scrum Master Certification. In fact, I’ll go so far as to suggest the certification program is hurting our industry by attributing competency where there often is none.

For example, the Scrum Alliance web site proclaims that Scrum gives you the tools you need to “manage complex projects.” This week I met someone that just joined an established technology company. She’s well spoken, bright, and just got her Scrum Master Certificate. She also just graduated college — and with both of those glowing credentials in-hand, landed her first job: As a Project Manager.

She has no experience. Yet, her employer has hired her to manage a group of people, executing a technical project, largely on the basis that her Scrum Master certification gives her that qualification.

What’s the value in a certification program if it inaccurately represents the capability of the people it certifies? Most Scrum Master certificates are earned after attending a two day seminar, sometimes with interactive exercises. There is no examination, although there is an “assessment” of about 25 questions — but without a pass-fail score, you get certified regardless of how poorly you do. There is no review of relevant experience. There are no requirements of past performance. You can get a Scrum Master Certificate without relevant professional experience or training.

Let’s compare this program with PMI’s PMP certification process. The PMP requires at least — even for an experienced project manager — years of experience and education, and weeks, if not months, of preparation:

1. The application requires detailed validation of years of project management experience, and even more experience and exposure to relevant work.
2. While PMI doesn’t audit every student they do audit, and experience must be vetted and verified.
3. The examination is 200 questions and typically requires weeks of study (most PMP preparatory courses are 13 weeks in duration, as an average).
4. The examination is administered in a secure environment, with no supporting materials. If you don’t know it, you won’t pass.

Even more stringent requirements exist for PMI’s Program Management credential: Included in the vetting process is a 360 degree review by 12 of your peers. As with the PMP certification process, if you fail any one part, you don’t get certified.

PMI requires that certified practitioners maintain their credentials with ongoing education annually. If you don’t demonstrate an effort to stay current, you lose your credential.

All of this earns you the right to put “PMP” (or “PgMP”) after your name. But if you don’t have the past experience (or if that’s too much trouble), you can drop in on a local Scrum Master course and walk out certified tomorrow. But certified to do what?

Scrum is not a project management methodology. It’s a process control structure that only works when combined with a methodology, such as PMP. It says so right on the first page of Ken Schwaber’s Scrum textbook. In that context, Scrum shines because it brings efficiency to a potentially bulky project management methodology. Scrum can be wonderfully useful, when used right.

So, here I sit, inwardly aghast as I meet Ms. Project Manager, with her freshly minted college degree, a Scrum Master Certificate, and no experience to her name, and I wonder: Is the Scrum Master certification program misleading an already beleaguered industry? According to KPMG and Standish, our success rate over the past 10 years was only 30%. Maybe this is part of the reason.

Does a two-day seminar and mandatory certification in a professional-sounding credential hurt, more than it helps?

Taking a seminar on Scrum is definitely a useful exercise. I think the Scrum Alliance needs to stop misrepresenting what Scrum certification really means to its practitioners, and the business world at large. I’d like to see Scrum professionals coming out of the seminar saying, “Wow! I sure learned what a long way I have to go before I’m ready to manage a project on my own!”

Related posts:

1. The case for certification
2. Making Scrum work: Common failings in adopting Scrum
3. Scrum is not an agile methodology