How do we know if a project is successful? How do we measure success?

[kwalford]

My answer to this is below:

I view that there are two types of project success;

1. Achieving Project Success Criteria.
2. Delivering Business Benefits to the organisation.

Achieving Project Success Criteria (PSC):

How do I know I've done a great job?

This type of success is measure by the Project Success Criteria. Derlivering a Project to the Project Success Criteria (PSC) will show that the PMT has delivered the project successfully. For example, project being delivered & completed before 1st June 2013. PSC's are measured at the end of the project and used to gauge the projects overal success. The criterion must be concise and measurable; agreed and stated by the sponsor early on in the project.

Delivering Business Benefits to the organisation:

How much have the project benefits improved the business's strategy?

Project is also a success when it delivers tangible benefits into the customer organisation, which are closely aligned with the corporate strategy. The PM needs to work with the customer to understand the business need and ensure that the project will add tangible benefit to the business need defined by the sponsor. Example, if the new CRM product reduced product lead time by 25% when compared to the current 10 working days. The project could be completed to the defined PSC's, but if it does not deliver tangible business benefit then the projects success is questionable. Improving (or adding) business benefit is the purpose of a project.

On a different note, if the project delivers all the deliverables, to the defined product acceptance criteria, but the project does NOT meet the PSC's, then is the project classed a failure? Even though the project delivered all the products to the required quality level.

[dhaughey]

Hi Kit,

Interesting post. For me the most important part of project success is the delivery of business benefits. There are plenty of examples of projects delivering against time, cost and quality that never realised their envisaged benefit or result.

Benefits Realisation is a much neglected part of project management, perhaps because it comes after the project has finished and the PM and team have moved on.

I recommend having a 'Benefits Realisation' phase in the project. I use it to embed new business processes and make sure any supporting IT systems get established and deliver real business value. I've seen many good projects fall on stony ground because they weren't properly embedded in the business.

Be careful if you believe any of these to be true:

1. A project is over once the delivery and implementation is complete.
2. Benefits automatically drop out of a project without any effort.
3. Benefits can be obtained without change.

"How do I know I've done a great job?"

My developers think they have done a great job when they solve a difficult technical problem and complete their work packages. As PM, I think I've done a great job when the customer is getting the benefits they expect. I have a stake in the business, so successful delivery without benefits does nothing to improve the share price and make me richer.

"How much have the project benefits improved the business's strategy?"

I think you should ask how the project contributes to the corporate strategy up front. If it doesn't, or you can't articulate it clearly, then perhaps investing in the project is wrong. If you only ask about benefits in isolation to strategy, then you are at risk of delivering something that doesn't take the business in the direction set by its leadership.

Benefits Realisation is a fascinating area and as I said, much neglected.

Duncan

[kwalford]

Hi Duncan,

Thanks, it is interesting to see others views on this. By my own admission, I haven't led many complex projects and it is insightful to see what other PM's think on this matter.

With the Benefits Realization phase, do you normally include this in the project plan? Do you cost in the time/resources required for this additional phase into the project? I am interested to see how you apply this extra phase in practice. Prince2 teaches that it is the organisations role (Executive) to ensure the benefits are realized. But, this clearly is reliant on someone else and you as the PM would be leaving this all in the hands of someone else; meaning you have little control.

Your point 3 (Benefits can be obtained without change) - Like you say, this isn't true so I suppose you (or someone with the allocated responsibility) needs to ensure that the correct change actually takes place. I think this is a powerful point.

Also, on reflection I suppose a better worded question would be, 'How have the project benefits improved the business's goals (strategy)?"

Many thanks,
Kit.

[dhaughey]

Hi Kit,

I do think you should build benefits realisation in to your plans as a last phase, however you may get push back. Many people agree it's a good thing to do, but in reality forget about it once the next project arrives to take their attention.

I've done both formal and informal benefits realisation. Informal where I've 'stolen' time to help the customer gain the benefits by working directly with them and guiding them through the process.

Another thing you can do is write a section in your initiation document about how you will realise the project benefits. This helps focus people on what needs to happen over and above a successful project delivery.

The trick is to get the stakeholders to see it as an essential part of the project. Failing that, use your own initiative to drive out the benefits. This usually involves extra unpaid hours.

I've had a couple of projects, that although successful from a time, cost and quality point of view, withered and died because the key stakeholder (Executive in PRINCE2 terms) didn't drive out the benefits and now they are forgotten and gathering dust. As PM it's not a nice feeling and they get mentioned occasionally. Best avoided if possible.

Make sense?

Duncan

[kwalford]

Perfect sense, thank you.

Like you say, as the PM you have to be prepared to go the extra mile and sacrifice your own time if you are unable to officially plan in a Benefits Realization phase into the project plan.

Having a understanding of the Business's current processes will aid in ensuring the Benefits are embedded effectively after the project is closed.

Every day is a school day :)

[begeland]

The detailed answers and discussion that is happening in reference to this question is great. My own short answer on this is three criteria:

1. On time delivery (within a given +/- range)
2. On budget delivery (again, within a given +/- range, but 10% is usually acceptable for success)
3. Customer satisfaction. This one is a bit more subjective. #1 & 2 above may come into play for determining #3, but other factors obviously affect customer satisfaction as well. This will likely become more known during lessons learned sessions, at deployment time, or a final customer survey at the end of the engagement...though it's usually fairly obvious much earlier in the project. But going back to the business benefits realization...yes, if the business can't really use the end solution (ie - the solution doesn't deliver what the customer's end users really want and need) then it can't be considered a success. But again, that will leave a customer dissatisfied so this rather simplified answer I'm giving still applies.

Brad

[kwalford]

To further my original post I think that project success can be classed as Project Management Team success (meeting success criteria) and Project success (project deliverables delivering business benefit back to the organisation).

Sorry, I just wanted to add to this thread as I was thinking about this again too.

[MarcAllen]

If the project meets the desired results with ease then it is successful...you can get more fruitful and bad results which can determine the success rate.