Reasons for structured project management

PRINCE2® is commonly described as a method based on best practices. A thorough analysis is made of problems that occur in real life project management. Structural solutions that cope with these problems are subsequently described in the method.

I must note that I think describing PRINCE2® as a method is too limited. I prefer to talk about a way of thinking, an integral approach. This is also the reason why I oppose against the way many organisations implement PRINCE2®: as templates or as a common language. This attitude takes the sting out of the approach and causes bureaucracy.

Why do projects fail?

Nearly every reason for failing projects is related to the justification of the project or in (somewhat fashionable) PRINCE2® terminology: the Business Case. I described a number of reasons below. All of them are probably very obvious and recognisable reasons. But sadly they also are daily practice.

Lack of justification and lack of concrete aims

During a visit to a major Dutch bank it became obvious that after implementing PRINCE2® they were aware of the need to justify their projects. The Business Case of every project needed to be made explicit. The result was that 30% of their proposals for projects was disapproved. An enormous saving that probably could be even bigger and that certainly can be reached in most organisations. Every organisation that I looked at from the inside, spends lots of time and money on projects that get started for political reasons or even for ridiculous reasons. This will show when writing an explicit Business Case. And because PRINCE2® insists on a clearly recognisable project owner who is responsible during the project for the Business Case (and should get in trouble in case of insufficient justification), this will decrease the chance of a bad start.

Before the project starts, PRINCE2® recognises a process in which the Business Case and the targets of the project are described. It is of great importance that the targets are also described (Project Brief) in terms of quality expectations and acceptance criteria. Quality in my view can be described in three simple statements:

  1. Promise what you will do (planning);
  2. Do what you promised (production);
  3. Show that you did what you promised (accountability, reporting).

A reaction is often that you have to be "pragmatic", so just go start working without clear targets. At the same time a planning is required! This planning is obviously based on nothing and the situation is even worse than working without a planning. The term "pragmatic" here is a synonym for amateurism...

When a project is underway, the environment changes and thereby also the Business Case and the targets of the project (and the planning). Annoying but unavoidable. This indicates that the Business Case can not be a "dead" document, but has to be updated and tested for validity. We all know projects that continue because a premature close would look like failure. But if there once was justification for a project and now not anymore, why would you still invest time and money?

No explicit project owner and project organisation

A lot of projects suffer form a substandard organisation. Usually there is a steering committee but the roles and responsibilities in this steering committee are often not formalised and it is also not determined who is ultimately accountable for the project. The result is that the project manager is made accountable. But if a project has a clear end and is unique (two important characteristics of a project), is it wise to hand the project manager so much responsibility? After all it is all about the creation of change that will be handed over to the permanent line organisation. This calls for a project owner with responsibilities who had a strong basis in the line organisation.

If during a workshop or training session for a bureaucratic organisation I ask a delegate who is the project owner, I am often told about a certain department. A serious fault: to make a project successful, it is important to have clearly defined accountability. So never a department, but a person as the project owner.

Another trap is working with the wrong project owner. Very often a strictly financial person is appointed. In a major company where I delivered a lot of training and consultancy, the controller was the sponsor of each project. Here we encounter two fundamental problems.

  1. When someone has no other interest in a project apart from a strictly financial one (cost), he or she will not act as the responsible person. A controller as project owner is fine, but only for projects where the controller can be held responsible for the end result and has an interest in the end result. This is the case in a financial project.
  2. The term sponsor is a very dangerous one. Who are the sponsors of Manchester United or Arsenal? Does the sponsor determine the team? Do the managers of these clubs, Sir Alex Ferguson and Arsene Wenger, allow the sponsors to determine their actions? This seems like semantics, but it is essential. Just because of this term a sponsor will not take the responsibility that is necessary to steer a project in a proper way. A project needs a person to take ownership of the project and of the Business Case. I strongly feel that the term sponsor should disappear out of projects.

As a variation on this theme you see a project owner that has hardly any or not enough power to operate. For each decision he or she needs to go through a extensive road to ask for authorisation to spend his or her budget. And often this discussion needs to be held with someone without sufficient interest in the project: usually with financial staff. This leads to an unworkable situation where the project gets paralysed and the focus is not on the end result but on the budget. In The Netherlands there was a parliamentary inquest about the problems concerning major infrastructural projects where you see the same principles. The Dutch Treasury Department has a major influence in discussions that go far beyond their competence.

In a substantial number of projects the supplier is seen as the project owner. In IT projects often the IT manager is seen as the project owner and responsible for the budget. But when the project is supposed to change the line organisation, it is only logical that also the steering and the responsibility for the budget is taken care of by the line management. After all they are the ones with the major interest in the project and they are the only ones determining the justification of the project.

In the PRINCE2® approach it is essential that three interests are represented in the steering committee (Project Board).

  1. One person responsible for the Business Case and therefore the owner of the project: de Executive.
  2. There also needs to be representation of those that will work with the result of the project (Senior User). Is the result workable? Can the expected added value be reached with the results of the project? This makes this role responsible for the end result of the project.
  3. It is also important that the supplier of the project can influence decisions (Senior Supplier). Is it possible for the supplier to deliver according to the constraints set by the project? The Senior Supplier is responsible in the Project Board for the quality of the end result.

Obviously these are roles that can be integrated or divided between several persons, as long as there is one explicit Executive. It is not the case that a Project Board should consist of a minimum of three persons. A small project can have a Project Board where only one or two persons handle all roles between them, while in a sizable project the roles of Senior User and Senior Supplier can be filled by several persons. Balance is obviously key. A Project Board consisting of a Executive, two Senior Users and nine Senior Suppliers can turn out to be unworkable. The suppliers can rule the project just because of their greater number of representatives. In some organisation there is a culture where meetings are held with great numbers of people. A large Project Board contains the risk that decisions are not taken when necessary and so paralysing the project.

A logical consequence of this all is that a project manager should not come from the organisation of the supplier.

Customer and supplier have opposite interests. Simplistically said the turnover of the supplier depends heavily on the cost of the project and that causes customer and supplier to have opposite Business Cases for the project. This gets the project manager, when from the organisation of the supplier, in trouble: what interest does he or she put first? The interest of the customer or the interest of the employer or the own manager?

Unfortunately most projects based on the traditional delivery model do not concern themselves very much with these fundamental, but also logical questions. Also consultancy firms that state their professional project management, hardly go into the importance of a good project organisation. Even the PMBOK disappoints on this subject. Recognising the importance of a good foundation for the organisation of a project is a first step towards more control and effectiveness.

Insufficient definition

Above I already talked about the importance of a proper justification, Business Case, for a project. Definition is of great importance. But also you often see that in a project there are several interests that are incompatible. An example is the roll-out of a new hardware configuration that is defined centrally in a major international company. On local level each national division had to put in effort under their own responsibility with the central department controlling. Under the mechanisms I described before such a project can not be handled. Locally there will not be a proper Business Case and therefore there won't be a proper local Executive. This is a project where locally staff do not see much added value but centrally there is a lot of value. This can be solved by looking at the total effort as a programme that steers the local projects. This causes taking away the justification and responsibility from the local line organisation for the local projects and it will strengthen the steering of the projects substantially.

Insufficient quality and quality assurance

In a lot of projects the supplier defines the quality. Tests are performed by their own experts under their own methods for testing. And that is where it usually goes wrong. The customer should be responsible for the end results and the supplier should agree to the requested quality. This makes the customer ultimately responsible for the tests (fit for purpose) and this makes the supplier responsible for proving the quality to the customer.

Tests often take place after development while before development there is hardly any or insufficient specification of the acceptance criteria. But logic says that when you don't specify at the start, it is impossible to test and to plan, making it impossible to promise what you will deliver. Under definition of quality mentioned above by definition you will not deliver quality. Unless at the start it is made explicit that the project contains high tolerances in terms of time, money and quality.

Quality is not something that can only be measured afterwards. Quality is determined by specification upfront.

Insufficient communication with the customer of the project

This ia a logical result of what i described under project organisation and quality. Projects are often determined and performed by specialists and not by the customer and their input. Working according to the principles of the Customer / Supplier environment increases the chance on a successful project significantly. The focus of a project moves from internally to the added value for the customer.

In many job adverts where is asked for a project manager, there is put emphasis on the term "customer focus". That this term is used and the quantity of adverts where this term is used, show that there is a major problem. Personally I find the term "customer focus" insufficient. A good project manager is "customer driven".

Working for a well-known consultancy firm I once received the complaint that I put insufficient effort into "managing the environment". My vision is that "managing the environment" was completely based on the application of the traditional delivery model. "Managing the environment" was essential for controlling crises because so many problems in the project needed to be presented in a nice way. I prefer preventing a crisis and do that through a different approach that also got me into many problems, but in these cases with my employer (the supplier...).

Emphasis on the supply, not on demand

After what I described above, there is not much news to mention here. Unfortunately a lot of projects are undertaken because it is a technically challenging project, not because the focus is on added value.

A number of years ago a major IT consultancy firm decided to implement a new CRM system. Unfortunately the responsibility was placed with a central support group and not with the Business that could have an interest in this solution. Business Case and project organisation were completely ignored and the project ended in failure. The system turned out to not work properly, not only technically but mainly functionally and was replaced after a short period of time. Not only an enormous amount of money and time were burned but the project also caused some victims: a number of innocent people were punished, as so often in these kind of projects that end in political chaos. The supplier of the software was not involved with the project, but some time after the project had started during a presentation they stated that there software was great for companies that worked with specific types of customers, but that their software was not suitable for a company that worked in IT consultancy. This IT firm implemented the software because of political, financial (good contract, cheap software) and mainly for technical reasons (it looked fancy). There was no proper Business Case and failure was predictable.

Usually a customer asks for a project manager with a lot of experience and knowledge of the technical environment and of the subject that the project has to deal with. Knowledge of the matter is handy without a doubt, but technical knowledge often seems to get in the way of controlling the project. The project manager seems to focus on the content of the project and no longer on controlling the processes. How often does a project fail because there is insufficient technical knowledge? Knowledge of the subject is also sufficiently present but often misused. The current practice has been proven itself for years: still the majority of projects are in trouble!. Why not try a different approach?

Insufficient planning and management of resources

When upfront targets, scope and required quality are not properly defined, the planning of the project will not be worth much. And that also creates uncertain planning of resources. This does not have to be a problem as long as the issue is made explicit and those responsible agree. Partly the principle of allowed tolerances is based on this.

When this problem occurs in several projects, the handing over of resources and taking them away again will take place on ad-hoc basis causing projects to run into even more problems. Obviously this problem can not be totally avoided, but there is improvement possible. With projects being planned better, planning of resources on a higher level will improve.

The ideas behind the Critical Chain theory will help improvement.

Fixed project

How many times do you see a request for a project manager delivering time project in time, budget and within the norms set for quality? This is impossible without periodical adjustment of these three aspects. A project is unique and will deliver something that has never been done in exactly the same way. The planning is a prediction of the future, maybe supported by experience from other projects. Unfortunately there are very few people that can predict the future exactly. In every project there will be issues that will disrupt the planning. When more time and money is necessary to correct, maybe concessions are made to quality to stay within planned time and budget.

Project management is all about controlling the aspects of time, money and quality (and some other aspects: risk). Explicit and timely decisions are important. That is why it is necessary to set tolerances: within what margins can the project manager act without escalation to the Project Board? When these principles are not used, the project manager will not on the door of the Project Board for every minor details or even worse, keep all problems to himself / herself result in major unpleasant surprises, often accompanied by negative politics.

Denial of risk

A well-known Dutch stand-up comedian once said something like: "An optimist is only a badly informed pessimist". Obviously a project manager should get the project going and should keep it going, but in many projects the "can do" mentality has gone too far. In these projects it is not done to mention risks and when it does happen the person is seen as negative. A great way to discourage that person and to make the project run into a catastrophe.

Every project has risks and risks should be controlled, not denied. Managing risk costs resources and it is not sexy to discuss and manage risks or think about measures to be taken when the problem occurs. But better safe than sorry.

I am convinced that during the Internet bubble and the Credit Crunch denial of risks almost became a way of living. In those days the standard reaction used to be: "don't act so negative, we make enough money and everything will be alright". The consequences for the IT industry and lately also for the financial sector are obvious...

The solution for all problems?

Does applying PRINCE2® solve all the problems I described here? Obviously not. Projects are unpredictable by nature. But applying the principles decreases the chance on failing projects and also causes falling projects not to prolong, but stopped when necessary preventing wasting time and money.

About the author

Specialist in effective change.

Accredited MSP™ and PRINCE2® trainer.

comments powered by Disqus