Whose success is it?

In my “enemies within” blog, we looked at how senior management often gets the project performance they deserve. In that blog I  explored the important role of the programme and project sponsor in making sure that an organisation’s programmes and projects succeed. But what does “success” mean? Success is often interpreted through the differing eyes and motivation of stakeholders.

Successful project management ensures the delivery of a specified scope, on time and to budget (what PMI refers to as the triple constraint). It is related to how efficiently a project is managed. This should be assessed during the project closure review, documented in a project closure report and measured by timeliness of delivery milestones, adherence to budgets and quality. This is commonly associated with the role of the project manager.

A successful project delivers the outcomes and realises the business benefits it was set up to achieve as stated in a business case. It is related to the effectiveness of the project in meeting the objectives set. The post implementation review (post-project review) assesses this. Measures of success here must be indicative of the business objectives being achieved. This review therefore has to happen some time after the output of the project has been put into use and outcomes are assessable. It is more associated with the role of the sponsoring body and the project sponsor.

A successful organisation drives towards its strategic objectives while fulfilling expectations of shareholders, managers, employees and other stakeholders. Measures for this are at a corporate level and should be financial and non-financial, such as a balanced score card. This is associated with the role of the chief executive and board.

A project which has been successfully ‘project managed’, however, might actually deliver little of value to the organisation. Further, a ‘successful project’ might not further the strategic objectives of the organisation, as its objectives could be out of alignment to that of the organisation. A failing company can be full of ‘successful project management’ and ‘successful projects’ all driving in different directions.

Further reading: you will find my book, The Project Workout (5ed), advocates this approach, which I call business-driven or benefits-led project management. It is also the approach taken in ISO 21502:2020, BS6079:2019, PRINCE2:2017 and the UK government’s GovS 002 Project delivery.


Whatever you do must help you move towards your strategic objective. Otherwise there's no point.

Whatever you do must help you move towards your strategic objective. Otherwise there’s no point.

A cautionary tale on business cases

Some years ago, a major communications company was expanding its network to gain access to potential customers. They prided themselves on having a good handle on cost management, especially capex. Each department knew exactly how much they could spend each year and it was tracked weekly. They held weekly Capital Approval Board meetings to control the release of the funds.

The business case
So, along came the project team and asked for a lot of money to buy a telecoms switch to handle the traffic from their five million additional potential customers. The revenue projections were good and return enormous . . . and the wise men on the Capital Approval Board approved the project.

The following week, another project team came along and said, “You know that lovely new switch you approved? It doesn’t like getting wet, so here is a submission to construct the building around it to keep it dry”. The revenue figure was the same as before as, without this building, the switch wouldn’t work and no customer revenue would flow . . . and the wise men on the Capital Approval Board approved the project.

A week later, another team arrived. “You know that lovely building and switch? Well, it won’t work without electricity, so here is the submission for the uninterrupted power supply electrical systems for it . . . and the wise men on the Capital Approval Board approved the project.

Yet another week or two later, yet another team arrived. “You know that switch, and powered building you approved? Well, switches don’t like getting hot, so we need you to approve the air conditioning system which is needed to keep it cool.  If you don’t, you won’t get any revenue . . . . the wise men on the Capital Approval Board were getting a little annoyed, but approved it as they really wanted all that lovely revenue.

The final straw came a month later. “You know that lovely switch in its cool, dry environment with lots of power? Well, it’s useless unless it is connected to the core network; the calls and data will have nowhere to go. If you really want the revenue (which we have attributed to this project’s business case), you have to approve this business case as well. The CEO (who chaired the Capital Approval Board that day) exploded.

True business led project management
The result was that from then on, projects were not bounded by departmental budgets (opex or capex) but by the work needed to get the revenue or other benefit. Projects became bigger as they included all the work needed, across any departments needed, and only ONE business case was developed to cover the lot. There were also far fewer projects, making it easier to see what was going on and the multiple counting of revenue and benefits decreased dramatically. Individual departments contributing to a project could no longer veto or reprioritise the “portion” as they no longer owned the project.

Look in the mirror – what do you see?
This blog is based on a true story from the 1990s, but even now, I see companies which fall into the trap mentioned above. Are all your projects “complete”? Do they include all the work needed to achieve the benefits? Or has the project been “salami sliced” into smaller “enabling projects”, each of which, in isolation, contributes nothing and just consumes resources?