Despite the protestations of PRINCE practitioners and other advocates of project “management” methodologies project management is not all about process. What really separates effective project management from the rest is decision making at all levels of the governance structure.

When a Decision Needs Taking, Take it

In my first job after leaving Durham University I was often left in charge of an entrepreneurial small business. This was in the days before e-mail, mobile phones and even fax machines were something of a novelty; we still used a telex service for urgent overseas correspondence! When the owner went away on his occasional overseas business trips his instructions were very clear: “… if a decision really needs taking then you must make it, take using the best of your knowledge and ability. If you do that in good faith there will be no blame if it turns out wrong; I will sort it out, few decisions are irrecoverable”.

He meant it and lived by it, as I have ever since. The point was that delaying a decision is usually worse than not taking the necessary, even if painful, action. Politicians on both sides of the Atlantic would do well to learn that lesson as they tinker with sticking plasters for the financial crises. The politicians are learning what many project managers have discovered, the consequences of indecision just keep mounting up and make the eventual decision even more difficult.

The lesson is that if a decision needs taking then it should be taken with the best information available. A timely and good enough decision is far better than a perfect but too late decision. The only perfect understanding is with hindsight “what we should have done is…”. A bureaucratic approach to project management is often engendered by project methodologies which hinder speedy and effective decision making. Waiting for more information leads to the old cliché “paralysis by analysis” – an appearance of activity whilst the problem continues to grow.

The over-large project board discussed in a previous Thoughts — Project Governance, Less is More was brought about, in part at least, by confusing the different roles of key stakeholders. A common problem on large projects is to give equal authority to advisers and decision-makers.

Do not Confuse Advice with Authority

On large projects with many, diverse, user groups there is a need to consult widely with many subject matter experts to ensure that there are no gaps in the project requirements and all needs have been understood. Once understood not all the stated needs may be accepted into the scope of the project board. That is the responsibility of the project owner and a small, selected team authorised to define the scope and budget for the project. That group, essentially the project board, will be accountable for delivering the project scope once the budget holder’s senior management team has approved the project details. For large or strategic projects, it will often require board or executive management team approval.

Many user groups will believe that they have a say in making the decision as to what should be in scope. In reality, they need consulting and their needs considered alongside those of many other interested parties. However, there will need to be a decision that balances conflicting requirements between groups. As a result, such subject matter experts can only advise as they have vested interests and may not have the full strategic picture. To facilitate those discussions a committee of senior users may be appropriate to explore the wider picture and ensure that it is complete even if issues of scope remain unresolved.

It may even be a hierarchy of committees so that individual communities of users can agree their needs and have them represented in a wider forum that advises the decision making body on the desired scope and priorities. That senior advisory body should usually be chaired by the senior user from the project board so that he or she is conversant with the advice and can represent in a separate decision making body.

Much is made of the need for responsibility and accountability on projects. However, there are limits on how widely they can be distributed. On many projects, large ones especially, there is a confusion between project responsibility and stakeholder management.

On one very large project I know of the senior responsible owner was concerned about making stakeholders accountable. As a result he insisted on them being on the Project Board and party to the project decision making. The result was the largest project board with which I have ever worked; there were around 24 people on that board. His thinking was that all members would then be equally accountable; unfortunately, he misunderstood the dynamics of groups.

The Abilene Paradox

The result was that no one, no one was actually accountable. Jerry Harvey, the American psychologist, noticed that groups often take decisions that are at odds with decisions they would take as individuals. Even to the extent that as a group they would take decisions they would personally regard as perverse. Harvey noted that the groups takes strange decisions because individuals know they can avoid personal responsibility for the groups actions. He called this behaviour the “Abilene Paradox”; he compared it to a family that chose to go to Abilene for a vacation even though individually no one had any desire to do so and knowing the journey would be unpleasant.

The other problem with such a large project board was that it became a talking shop and was slow to take decisions at all. With over twenty people travelling from all over the country it was also inordinately expensive so it was hardly surprising that the project was on its fifth project director and running over a year late. It was eventually delivered after a further replanning and with a reduced scope.

For the sake of consistency, we need to understand what we mean by a project. Project managers who have been involved with projects for a while usually have a clear view. Although the definition of a project may seem obvious to experienced projects managers it is often not so clear to new project managers or managers with only business as usual or operational experience.

Projects are Limited Life, Standalone and Complete Pieces of Work

Many definitions of a project are written in rather worthy and pretentious terms. For all practical purposes a project has clear set of characteristics, projects:

• are complete standalone pieces of work,
• are temporary, resources and organisation are provided only for the duration of the project,
• have clearly defined objectives with specific goals and outcomes. Often these in the form of business benefits that may be compared with an operational baseline taken before the project starts; or at least at a very early stage of the project.
• do not have any continuing operational or business as usual existence. Once complete the project hands over the outcome of the project, building, organisation, computer system or whatever to business as usual management to operate.
• often has a predefined timetable; it can either be predefined as part of the project scope or it may result from the planning as the time needed to deliver the agreed scope with the resources available.
• operate within a set of constraints which usually include:
  • predetermined scope
  • budget and resources
  • timetable
  • quality measures
  • outcomes
  • benefits

A project may be a one-off or it may be part of a series of linked projects or programme of work to deliver strategic outcomes. In such cases, the allocation of resources and project organisation may not appear temporary. Good project discipline requires formal closure of a project when it has delivered its objectives (or abandoned for whatever reason); then a new project properly initiated with its own clear scope and constraints.