The seven keys to successful projects?

A common cause of project failure is a lack of executive commitment and sponsorship. So how do you communicate the challenges that a large project is facing at the boardroom level?

Over the course of my career I’ve witnessed several different approaches to this problem. In my opinion the framework that has proved most effective is one that was developed by PwC, called the The Seven Keys to Success. I’ve seen it used, on many different occasions, to communicate difficult messages to senior managers up to and including board members.

The Seven Keys To Success are applicable to any kind of project that you can imagine. It works by assessing the project across seven different critical success factors that resonate with executives and by focusing on the action that you wish them to take:


IBM used to have a whitepaper available for download that provided an introduction to the Seven Keys. Unfortunately they seem to have removed it from their website. However a quick Google for the author (Bill Smillie) along with the article’s title (The Seven Keys To Success) quickly turns up various copies on the Web!

It’s the benefits stupid

Recently I was looking back over some work that I did on Agile methodologies whilst working for IBM.

One of the key tenets of all Agile delivery is to deliver early and deliver often. Whatever you think about using Agile to deliver IT projects in complex organisations it is worth understanding one of the key rationales for this mantra.

Imagine this common scenario in a project steering committee. A stakeholder has submitted a change request for the project. The project team have rapidly turned around an impact assessment which indicates that it will mean delaying the go-live by 2 months to allow for the new functionality to be developed and tested.

How should the committee decide what to do? A common response to this will be to look at the additional delivery costs that this two month delay will be incur. If funding can be found to cover this then the change request is approved.

However what this has ignored is the cost of delaying any realisation of benefits by an additional two months. A sign of a healthy project with a robust benefits case is that less focus is placed on the cost of delivering the project and more emphasis is placed on when the solution will be delivered.

The graph below shows why this focus on timescales is important to the organisation as a whole. It shows two different ways of delivering the same project with the same benefits case. Approach A goes live earlier than approach B but costs significantly more to deliver. However, you can see that it still breaks even earlier than approach B because it started realising benefits earlier.

A graph showing Net Cash Flow Against Time for two different project schedules

Agile delivery takes this concept to the next level by “timeboxing” releases of a project. This means that the project team commit to go-live on a particular date. In return other stakeholders commit to the principle that, if necessary, scope will be pushed from that release into subsequent releases in order to hit this date [1]. Doing this ensures that the organisation can start realising some benefit from its investment as soon as possible.

Even if you aren’t working on an Agile project, the next time you’re next asked to look at a change to a project’s timescales have a think about what the impact of delaying the benefits realisation might be.

[1] There is a limit to how far the timeboxing principle can be taken due to something I tend to refer to as the minimum viable release. This reflects the fact that there is an irreducible minimum set of functionality beyond which any further reduction in functionality will result in a solution that does not provide any worthwhile benefit. This irreducible minimum functionality defines the minimum viable release but you often find it is much smaller than you might initially imagine.