Project Initiation: Where Project Management Often Fails
The Project Management Body of Knowledge
There are five major processes defined by the Project Management Institute’s document, the Project Management Body of Knowledge, or PMBOK®. These are Initiation, Planning, Execution, Monitoring and Controlling, and Closeout. It is at the Initiation stage of project management that the seeds of project management failure are often sown.
The reason for project management failure is simple—failure to properly define what the project is intended to accomplish. Anyone familiar with DMAIC understands that definition is crucial to project management success. However, Americans are educated to be problem solvers rather than problem definers, and this leads to a "ready-fire-aim" tendency in project management. A second component of project management failure is that we often assume that we know what the problem is, even though no analysis has been done. The result of this assumption may be that we develop the right solution to the wrong problem.
The Project Definition: A Key Issue for Successful Project Management
The mission of a project is to solve a problem, and again, we sometimes fall victim to the assumption that everyone understands the mission of the project. As an example of this, a project manager in a client company once called me and said that he had just completed a conference call with key members of his project team and had realized that they were not on the same page together. I told him that I was not surprised because this often happens in project management.
"I’m surprised," he replied. "We’ve been working on this project for nearly two months, and I thought we all agreed on the project definition, but we don’t."
We called a meeting of core team members and some of the major project stakeholders, and I began by suggesting that we clarify the project definition before going any further. Someone in the group protested that we need not waste time on that, as—he asserted—"we all know what the problem is."
I told him that he might be right, but I wanted to put a formal project definition statement on a flip chart page, so that we would have it as our anchor. He wasn’t happy with that, but I proceeded to ask the group to state the problem. Two hours later, we finally agreed on the problem definition!
The erroneous assumption that a group agrees on problem definition is so commonplace in project management that I am totally cynical about the claim that "we all agree." And, as I told this group, there is value in having the statement written out so everyone can ensure that they understand and agree with it. As you have heard, you pay now or you pay later, and it is always cheaper to pay up front rather than later. The time invested in ensuring shared understanding of the project definition is well worthwhile.
Mission and Vision in Project Management
Once the problem has been defined, the vision for the project outcome represents all of the conditions that will exist when the project has been satisfactorily completed. There may be performance requirements to be met, but there will also be sensory evidence—visual signs that the project objective has been achieved. An example is if you are going to design a product you begin with an image in mind of what it will look like when completed. Now assuming that the vision represents conditions that will exist when the project problem has been solved, your mission is then to achieve that vision.
The best way to ensure a shared understanding of mission and vision is to have the core project management team participate in developing them. Even if the mission is assigned, having the project team write it in their own words helps achieve a true understanding of what is intended. Another way to say this is that if members of your team can’t restate the mission satisfactorily, then they probably don’t really understand it.
Another Kind of Vision for Project Management
There is another kind of vision for project teams, which is one that defines how the team will function. This can be important when teams are composed of individuals for whom the project is not a primary job responsibility. The loyalty of such team members is often to their functional groups, rather than to the project. So discussing how everyone expects to work together, what the expectations are for project team members and how performance of individuals will be evaluated is very useful.
One way of getting at this is to have the project team generate a list of about 10 norms for member behavior, write them on a flip chart page and post them in the meeting room. Don’t impose these norms on the project team. You will gain greater buy-in if they generate the list themselves. In addition, the list can be revisited if need-be.
Project Management, in Conclusion
Projects often fail at the beginning, not later on. The way you launch your project can make or break it. Ensure that you have a shared understanding of what the project is intended to accomplish. Next you need to define project team member roles and responsibilities, which will be covered in our next column.