How Do You Measure Success?
From the Strategic Project Management Blog
by Ty Kiisel
Answering the question, "How do you measure IT project success?" shouldn't be that difficult, right? However, I think most of us would agree that pushing projects to completion on time and under budget should NOT be the only measure of whether or not a project is successful. Most seasoned project leaders will agree that any project, to be truly successful, must provide the business value it was intended to produce. Let me share a couple of other suggestions regarding what I believe projects need to be considered successful:
-
Success is about doing the right projects, not just doing them right. Delivering business value and satisfying customer needs is critical—and starts with the evaluation of which potential projects will meet those needs and provide that value. Hopefully, this has always been the case, but organizations are realizing that they have to do more than give lip service to meeting customer expectations and organizational goals. It must become a primary measurement of how we determine the success or failure of any IT project.
-
Project teams need to completely understand how "quality" is defined and how to build it into every project. Although everyone would agree that "quality" is very subjective, if everyone on the team doesn't have a thorough understanding of the cost of defects and rework, it doesn't matter what work management tool you use, it won't help. Edward Deming used to talk about how organizations must build quality into the product, it can't really be inspected in. Quality assurance needs to be a part of every process from start to finish. Smart organizations are looking at defects and their root causes through the project-life-cycle to develop methodologies that improve the quality of their final deliverables.
-
The final product needs to be stable, compatible, and easily maintainable. It's just too expensive for organizations to maintain software that's unreliable or incompatible with current systems. With staff and maintenance budgets at a premium, software that isn't will be abandoned for something that is.
The way organizations measure the success of project-based work is changing. Managers who leverage project management tools to meet the new objectives are able to better address business needs and ultimately increase their value within their organizations.
How do you measure project success?
Posted on: October 12, 2010 10:25 AM |
Permalink
Comments (5)
Please login or join to subscribe to this item
 | Association for Project Management |
In 2008 APM wrote a document called APM Insights which has a section on what is success in a project (
https://www.apm.org.uk/download.asp?fileID=1156). It summarised the key barriers to a successful project in terms of some questions that always need answering before the project is started:
• Do we understand what is meant by success for the project and who will ultimately decide whether it was successful?
• Do we understand the stakeholders interests in the project and how these might change over time?
• Do we understand the threats and opportunities of delivering a project?
• Do we understand the implications of any changes to the scope of a project?
• Is the social political and physical environment conducive to a successful project?
• How soon after delivery should the success of a project be judged?
There is a significant amount of literature about project failure available, and as a result there is no definitive answer to the question as to how much it costs in the UK.
Ty Kiisel
Manager Social Outreach| AtTask
Lehi, Ut, United States
Thanks for the contribution. This is a great addition to the post.
Dipanker Das
VP Program Management| Tavant Technologies
Bangalore, Karnataka, India
Great article and want to add my two cents:
>>>> Organizations have their own definition of success, and perhaps even different definitions for different types of projects (sometimes determined by your customers)
>>> Most of the time I found, different stakeholders define their own way to measure the success of the same project. It is highly unlikely that we can capture all the requirements (including emotional ones) in a SOW document. So regular assessment (thorough interviews/ dialogues/ feedbacks) of the perspective of the project in stakeholders mind is as important as measuring the elements defined in books (quality, cost, time, etc.). At many instances the customer has rated our organization very high on overall feedback (including quality) but, many times they are not happy with the project outcomes/deliverables (they are unhappy about the interim status). And interestingly the stakeholder remembers the latest feeling about the project at given point of time and so even at the end.
>>>> I think during the entire course one of the most important element that should be clear in the mind of Project Manager is that he has clearly defined and communicated - What is in it for me (WIIFM) for each stakeholder and keep communicating it all the time as the project progress towards end.
Ty Kiisel
Manager Social Outreach| AtTask
Lehi, Ut, United States
Dipanker,
Great additions to the post. Thanks for contributing and reading.
—Ty
Jed Simms
Executive Chairman| Capability Management
Melbourne, Vic, Australia
On time/on budget are measures of delivery efficiency; nothing else. We do not start projects to deliver something on time/budget.
Why this is a continuing issue is that we don't define in clear, specific, measurable terms our desired business outcomes/end states on projects. This is where the organization will end up - full business statements. These outcomes then deliver/enable the benefits and value to be realized. This then becomes the business' measures of success - did we deliver the desired business outcomes, the associated benefits and the available value? Yes or no?
The project should then be tasked with delivering a subset of the business outcomes - ie project outcomes. These too are defined as clear, specific, measurable business end states that can have benefits attached. (This notion that projects don't deliver outcomes must be stamped out!)
For example, a business outcome may be "We invoice all service calls within 24 hours" Do we or don't we? All service calls or only some? All within 24 hours or only some? All very measurable.
The project outcome was "We invoice all service calls within 5 days" Again measurable. No "how long after the project do we need to wait to measure - the project doesn't stop until we get to 5 days.
Many of the benefits to be delivered by the business outcome will in part or in full be delivered by the 5 days outcome - so the project should be seen to deliver these benefits as well. Again measurable.
If we start with the (business) end defined; make it clear, specific and measurable; 'success' becomes acheivement of the agreed outcomes, benefits and value. Simple.
Please Login/Register to leave a comment.
|
"When I have a kid, I wanna put him in one of those strollers for twins, then run around the mall looking frantic."
- Steven Wright
|
