What is Project Success?
What constitutes "Project Success" or what does "Project Success" look like? And from whose perspective and when?
There has been a lot of talk lately amongst project management folk about "success", not in any particular, just "success" unqualified! But given the participants, presumably we are talking here about projects, and from the project manager's perspective. Indeed, there is ongoing research into the subject.[1]
Of course there is the Standish Chaos report published in 1994, but still quoted, that reported a shocking 16 percent project success rate, another 53 percent of the projects were "challenged", and 31 percent failed outright. But that was over 20 years ago and in any case has been largely debunked as flawed analysis, or misleading definitions and conclusions.[2] In any case the reference was to Information Technology projects in particular.
Consider this, you are an employee project manager and you are called into the "Big Boss's" office. Well, he or she is not actually very big but because that person wields the power to hire and fire, they seem to be big. Big Boss says to you we want you to take charge of the ABC project to produce a new XYZ product.[3]
Right off the bat, there are four parties involved:
- Big Boss as project sponsor;
- You as project manager;
- Your team (if you are allowed any!); and
- The Users, Customers or Consumers, as recipients of the product.
So we could say that there will be at least four perspectives. "At least", because there will also be those marginally affected by the outcome, to say nothing of independent observers such as the media reporters and researchers like the authors of the Chaos report. But lets keep it simple, and stick just to the original four. What will each be looking for? Most likely:
- Big Boss: As much as possible (functionality), as soon as possible (time) and as cheap as possible (cost)
- You: Being a qualified but smart project manager you will be looking to estimate time and cost as high as possible to establish a baseline that gives the most freedom to deal with uncertainties (risks) and thereby at the end declare the project a success in terms of meeting cost and schedule.
- Your team: Things like challenge, network enjoyment, personal satisfaction, recognition and reward (process)
- Users, Customers or Consumers: Does it work, can I use it, will it make my life easier? (progress).
What do each of these expectations mean in terms of "success"? In general, in each case: "If I get what I want I'll be happy". But the reality so far as the project is concerned:
- Big Boss success: This attitude of squeeze will undoubtedly increase the probability of project failure.
- Your success: If you ask for too much your project may be taken away and given to someone else and your opportunity to declare success at all will be lost.
- Team success: If the objectives are not clear and worthwhile, or if the work is not well conducted and coordinated, teamwork could fall apart, grind to a halt, members will seek activity elsewhere and the quality of the product will either be poor or not produced at all.
- The Users, Customers or Consumers "success": If they see no direct personal benefit, they will simply not use the product whatever it may be. Or if use is mandatory, they will use it begrudgingly. Either way, the intended or expected benefits will not be earned, and the product will be declared unsuccessful and quietly abandoned.
But what about the real worldview of success? Here are some typical accolades that shed more light on what is really important in the final analysis:
- "It may be expensive but it was really worth it!"
- "It may have been late, but it was well worth waiting for!"
- "In the end we got what we asked for, and needed!"
- "It was late and over budget, but in the end it was hugely successful in terms of (popularity, profitability, impact, game changing, etc.)
- "It wasn't quite completed, but it did start on time!"
And of failure:
- At the end of the day (i.e. the project effort) all that we had left was the consequences (outcome, product waste, impact, or memory)
- At no time at the outset was there any serious attempt to agree on terms and definitions, details of the requirements, limits to the project's scope, the grade of quality required, the manner of deployment, and the benefits expected.
What can we learn?
By definition, every project is unique in one way or another. Therefore, each project should be set up in a way that is appropriate depending on:
- the objectives,
- type of project,
- the technology involved,
- the maturity of the organization sponsoring it,
- the availability of resources,
- the essential qualities,
- the urgency of the outcome,
- the available funding stream, and
- the likely risk level.
So there you have it. Take your pick!
1. Example: PM Perceptions of Project Failure or Success, survey by Ray C. Hickson, PMP, Doctoral Candidate, University of Phoenix, on line questionnaire, 6/20/14
2. Aidane, Samad, The "Chaos Report" Myth Busters, Guerrila Project Management, www.guerrillaprojectmanagement.com/the-chaos-report-myth-busters accessed 6/21/14
3. In Project Management Institute speak: "Unique product, service or result" — PMBOK® Guide Fifth Edition, Glossary, p553
|
