Certification programs are more about demonstrating your competency than about learning how to manage. Consider this: PMP and IPMA certification takes you through a process guide and an examination that you can easily enough prepare for in a few weeks. The process guide itself is a valuable reference, a great way to organize all the possible areas of knowledge in a project — but it’s just that. A process guide is largely a checklist, giving you a tool to make sure all the right pieces of a project are in motion.

The other part of the certification process is the exercise of documenting your experience, as a project manager, and having the certifying organization vet your experience (although the vetting process is often cursory). It’s supposed to show the world that you have a certain level of project management competence. It is explicitly not going to teach you that competency. The real theory behind PMP certification is that by achieving it, you have demonstrated relevant competency as a project management professional. There’s a good bit of debate regarding the value of this certification: How well does the PMI do in vetting experience? Is there any qualitative distinction in the evaluation? I’ve seen a few terrible managers get their PMP by documenting their management of projects that were miserable failures.

For the most part, deciding whether a candidate’s PMP or IPMA certification (or lack thereof) is valuable lies with the employer. For the individual, I always recommend learning the bodies of knowledge, so long as you are fully aware of what you’re getting. Here are a few of the things that either program won’t prepare you for:

1. Project management is more about management, and less about process. Most of the certification programs out there tend to emphasize the latter, the process, and spend little time on the “soft and fuzzy” bits: People. The fact is, this is where you’ll succeed or fail. It often comes down to how good you are at picking up on subtle (and not so subtle) cues between team members, sponsors, and stakeholders. There is no certification program in the world that will teach you how to be a great manager — that requires experience, more than anything else (but if you have a degree from a top management school it’s bound to help).
2. The rosy project you just inherited is actually completely out of touch with reality. More often than not businesses will commit to a project that can’t be met (often establishing budgets and schedules in the process). Studies by Standish and KPMG bear this out, pointing at 70% of projects failing to meet cost, schedule, and quality goals.
3. Identifying all the right pieces of a project is just the beginning. For example, knowing who the stakeholders are (an important step in the PMBOK) is the easy part. You’ll spend far more time motivating them, coordinating their schedules, dealing with stakeholders that want your project to fail (or just don’t care about it), responding to impossible demands, and figuring out what everyone’s secret agenda is all about.
4. You’ll need to be good at managing other people’s anger and frustration. Part of being a strong manager is knowing how to evaluate the project dynamics, and then make the right decision. Most of the time, you won’t find a rosy world where everyone agrees about what has to be done. You’ll be stepping inside someone else’s world, and messing with it. You’ll have to tell people to do things they don’t agree with, or don’t want to do. You’ll have to step in and change everything, and people don’t like change.
5. Your certification didn’t warn you about some of the important bits. There is no such thing as a comprehensive process guide or methodology that gives you all the answers. Some guides are really good in some areas, and horrible in others. The PMBOK, for example, spends precious little time talking about quality assurance and risk management — so little, in fact, that without turning elsewhere you won’t have any idea what these two things are, how important they are, or what to do about them.
6. You are actually not ready to manage a large scale project simply because you’ve earned your PMP/IPMA/PRINCE2 certification. These certification programs document your past experience, and your basic knowledge of the relevant process guides. Unfortunately, splashy advertising sells certification, so I’m sure we’ll keep seeing claims such as “everything you need to manage complex projects!” It’s a lie.

Deciding whether obtaining a certification is worthwhile or not is a personal decision. I definitely recommend learning the reference material — and after all, if you learn the PMBOK, it’s not much more work to get a PMP certification. Just be honest with yourself about what it means. Being a good project manager means having the experience to guide an organization toward success, not just recite the process guide. I always recommend starting small and finding out what your personal aptitude for management is.

Your key to success as a project manager is going to hinge on your ability to listen to others, learn from others, and always be open and ready to support your team. You’ll need to turn to other people and other sources of information. Be humble, never let obstacles derail you, and make sure your team knows they can rely on you for support. These are the things you don’t find in the process guides.

Related posts:

1. The good (and bad) about Project Management School
2. Is Scrum Master Certification Hurting Our Industry?
3. Managing with blinders on

There’s a host of information you won’t get in school (not even from a top tier management school, let alone a certification program you can cram for in less than two weeks). And that leads me to the value of the certification itself. Here I’ll generally weigh in saying “it’s up to you.” If you feel going through the certification process will be a helpful learning experience, then by all means do it. On the other hand, getting the certification will neither teach you to be a good project manager, nor will it have a great impact on your career.

It’s important to realize that the Project Management Institute (or PMI) is not a standards body. PMI is a for-profit company that sells several products, and those products are all essentially based in the PMBOK (for example, you can seek certification as a Project Management Professional, or PMP, through PMI’s certification process). This imposes a couple of limitations on the concept of the PMBOK being a robust standard:

1. Successful standards bodies are international in nature, and the best of them are completely unbiased — something that usually requires forming a body that is not motivated by profit attached to its own products. PMI is, ultimately, concerned with corporate profitability, and this has led to some debate regarding whether the PMBOK has evolved first-and-foremost as a leading project management standard or as a product that PMI can easily sell.
2. PMI tends to be very insular in its thinking. By this I mean that it does not extensively rely on third party standards — quite the opposite, in fact. The PMBOK is almost exclusively a self-contained work. It does not reference the 50 years of decision management theory that constitute strong risk management practices. Nor does it reference other standards, such as the ISO’s work on quality management. This, naturally, tends to keep people more involved in the PMI’s products, as opposed to moving into other standards.
3. The PMBOK standard is unquestionably a solid reference volume with extensive project management knowledge — however, it also has startling weaknesses. For example, it’s coverage of risk management and quality management is largely negligent, and it’s strong focus on technical knowledge completely ignores the human factors addressed by methods such as Kanban.

The PMI’s Project Management Body of Knowledge (PMBOK) represents a strong reference guide, and one that I turn to when appropriate as a process guide — but its very strength as a reference text also makes it a poor companion for someone looking for a comprehensive project management methodology. It lacks the practical, hands-on information needed to apply much of the knowledge it presents.

That tends to mean that novice project managers turn to the PMBOK far too often, hoping that it will solve management problems (it won’t). Experienced project managers recognize that it’s a process guide, and nothing more — which means it’s a provides a great checklist to make sure all the right pieces are being executed, but it does little to tell you how to execute those pieces. That comes from experience. The experience of managing people, learning how teams work together (and often don’t work together), how to motivate and communicate, and how to see problems coming before they hit you.

The bottom line is simply this: No school, and especially not one offering a short certification program, can teach you to be a good manager. That’s what project management is all about — it’s not the technical process, more often than not, but the personal factors and the management skills that make or break a project. So yes, get familiar with all the standards, bodies of knowledge, and process guides you can. Learn what you can from each, and use that knowledge as a reference when deciding how your project will be run. But don’t ever assume that this encyclopedia of knowledge has taught you how to manage successfully. That’s going to take management training and experience — more the latter than the former, in my opinion. A lot of it, most likely.

Related posts:

1. What you won’t get out of your certification
2. Managing with blinders on
3. Doing away with ineffective, broken risk management

Related posts:

1. Scrum versus Kanban
2. First, care. Care intensely.

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. The good (and bad) about Project Management School
2. What you won’t get out of your certification
3. Doing away with ineffective, broken risk management

Related posts:

1. How big is cloud computing, really?
2. 2011 Business and Technology Trends Seminar

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. Why heroes are bad
2. Tackling the global project problem
3. Boomers at the exit gates

No related posts.

No related posts.

No related posts.

Related posts:

1. Dealing with negativity in the team
2. When there’s a freeloader on your team
3. Tackling the global project problem