Among the five most common project management mistakes, inadequate definition and planning tops the list. Tom Mochal tells you how to avoid this pitfall.
This article was originally published on our sister site, TechRepublic.
Think back to the last time you worked on a project that was planned and executed perfectly. You met your expectations in terms of budget, deadline, and product quality. You also had a cordial and professional partnership with your clients. No problems at all.
If you’re lucky, you might actually be able to think of one project that might be a candidate—maybe even two.
Many projects do end successfully, while many others are outright disasters. However, usually projects end up in the gray area on the project success scale. It’s common to complete a project but be over your deadline or over your budget, or to have a dissatisfied client or a miserable team. To keep your projects from ending up in this gray area (or in the failure range), you must avoid making the single biggest project management mistake: inadequate project definition and planning.
Inadequate project definition and planning
If you've ever attended an end-of-project meeting on a project that had major problems, chances are good that one of the major themes you heard is “we should have spent more time planning.” Many project managers think that they need to jump right into the project by gathering business requirements. They think that if they do a good job with that, they're ready to run on the project. That is simply not true. In fact, you must complete a definition and planning process before you start gathering the business requirements.
Before the project work begins, you must make sure that the work is properly understood and agreed to by the project sponsor and key stakeholders. You need to work with the sponsor and stakeholders to ensure that there is a common perception of what the project will deliver, when it will be complete, what it will cost, who will do the work, how the work will be done, and what the benefits will be. The larger the project, the more important it is that this information be mapped out formally and explicitly. All projects should start with this type of upfront planning to prevent problems caused by differing viewpoints on the basic terms of the project.
The results of poor planning
Poor up-front definition and planning can cause serious problems in many areas later in the project, including:
Lack of business support
If you don't define the major characteristics of a project up front, it's very common to have differences in expectations among the major stakeholders. This is true even if you take all of your initial direction from the sponsor. As a project gets larger, even the sponsor may not have a complete picture of what needs to happen for the project to be successful. Other times, the sponsor has a vision, but there are other visions that may be better or more viable. These competing ideas end up surfacing later in the project, causing confusion and rework.
Usually a project needs to have a budget and deadline before the business requirements are completed. In many cases, if the definition and planning are not done ahead of time, the project team starts off with inadequate resources and time—and you don’t realize it until the project is already in progress. Many projects that could be successful are viewed as failures because they overshot their budgets and deadlines. This situation is often caused by the project manager committing to numbers that are too low, based on a lack of up-front planning.
Poor scope control
One of the major aspects of defining a project is defining the high-level scope. If you do not define and gain agreement on scope, you will find it very difficult to manage scope effectively throughout the project.
How to avoid the mistake
Spending the time up front on good definition and planning ends up taking much less time and effort than having to correct the problems while the project is underway. To avoid making this major project management mistake, focus on these two areas before going any further in the project:
Before the actual work of the project begins, make sure you have spent the time to define the project objectives, scope, assumptions, risks, budget, timeline, organization, and overall approach. You may think that you know all of this already. However, the purpose of this work is to ensure that there is a consensus between you, the project manager, the project sponsor, and all other stakeholders. Even if you and the sponsor are in agreement, other major stakeholders may have other ideas. Differences of opinion between the major stakeholders need to be resolved before the project starts—not while you're in the middle of it.
You should create an overall project work plan before the project starts. This helps you estimate the total project effort and duration. You also need to ensure that you have the detailed work mapped out over the next few months to ensure that the project resources are assigned correctly once the project actually begins.
In addition, it's very helpful to have an agreed-on set of project management procedures that are used to manage the project. These include how you will manage scope, issues, risks, communication, the work plan, etc. Again, the key is to define these all up front to better manage expectations. For instance, if you define and get agreement on the procedure for approving scope change requests, you should have a much easier time managing change once the project begins.
What if you are already into the project?
The best way to solve a problem is to prevent it before it happens. However, what if you don't have that option? Let’s say you're into a project, and you start to see some of the problem areas described above. For instance, you start to see stakeholders coming forward with different ideas for what the project should accomplish, but you are already well down the path with the prior vision.
If you’re having trouble with one or two aspects of the definition process, you may be able to resolve it with a mini-definition process. For instance, if you find that you cannot control scope because you did not define it to begin with, you can take the time to formally define and gain agreement on the scope. This involves going back to the sponsor and major stakeholders to gain the consensus and approval that you did not get earlier.
If you start to see differing visions as to what the project should achieve, you may need to actually complete the entire definition process while the project is in progress. This is very difficult and painful, but it can be done. You need to take a step back and define objectives, scope, roles, and risks. You might need to actually stop work on the project until this definition process is completed, although in many cases this pause won’t be practical.
As painful as it is to define the project while it is in progress, it’s still preferable to ignoring the problem. The first option may end up causing rework, resulting in additional cost and a later delivery date. However, ignoring the problem may end up making the entire solution irrelevant or obsolete as soon as it is delivered.