I spent a lot of time this week dealing with project management and work planning issues, and as I worked with a variety of people, it became clear that even if they understood the planning process, there was often a breakdown regarding what a successful project looked like.
Let me give you some examples of what I mean. For some managers, the answer to how success is defined for an IT project is to be on time, on budget, with zero defects. Sounds good doesn’t it? Or others might say, fulfilling the goals and objectives in the project plan. That sounds good too and may or may not be accurate depending on the quality of the project plan. In both of these examples, the definition is too vague. Success means different things to different people, and unless you are very explicit in the definition of success at the start of a project, you may end up in trouble further down the road.
Let’s take the development and implementation of a new warehousing system. What does success look like from the perspective of all the players involved? From a finance perspective, success may mean that operating costs are reduced by 5 percent, the project doesn’t exceed $300,000, and the payback time in savings is less than 10 years. From an operations perspective, success may mean that delivery errors are reduced by x amount, that time to find and ship an item is reduced by y amount, that the system can be learned in less than one week of training, that system implementation will not interrupt operations, etc. From an IT perspective, success may mean that the system can be purchased rather than developed, consume less than three FTEs (full-time equivalent) for six months, is on time, etc.
Many of the success factors above may very well be included in the project’s justification and is typically submitted to an executive or a governing body, for approval. But after approval those factors seem to disappear as the project plan often starts to focus on the more nitty-gritty pieces of getting the project done. This is a huge mistake. Well defined (and agreed upon) success criteria need to inform every decision made during a project and any changes in the project need to be weighed against the original success factors—in particular, the HIGH level success factors that often get forgotten in project planning.
Defining success sounds easy, yet it is actually quite difficult because of subjective language. My previous sentence is a perfect example. What is easy? Easy to you may be difficult for others. Yet we see ease-of-use as a software or hardware descriptor all the time. Getting the right people in the room to determine success factors to a degree of specificity that is measurable is a monumental task and any project plan that makes short shrift of project initiation and planning processes is a candidate for failure.
Defining success, though, does not end at the start of the project but continues at every juncture at which a goal or objective is created and each time a decision is made. This is really hard to do and takes a huge amount of discipline as it is so tempting to assume that people know what you mean and that they define success of the project, goals, objectives and tasks in the same way. I know I am guilty of assuming that something is clear, when in fact it is not clear at all; it just happens to be so in my mind because I am familiar with the subject. This is why it is so important to have people who are not familiar with your projects to be involved from inception and through review, approval, and completion. They are your check points to make sure that what you are putting together is understandable to anyone off the street. If someone is bamboozled by your project, then it needs to be tightened up further.
In summary, clarity, conciseness, measurability, and a consciousness of all the definitions of success through the phases of your project will not only help you achieve success for a particular project, but also will move you down the road to being successful in all your efforts.