Inspirandum

Inspirandum | where the project end date isn't clear

INSPIRING EXCELLENCE

Home | Contact Us | Site Map

The PRINCE2 project method says a project must have a clear start and end and that you must have a project plan from the front to the back of your project. But what if your project doesn’t have a clear end in view? Here are some simple guidelines on how to apply the method in these circumstances.

It is the case with some projects, and nearly all research projects, that you are not clear what the end of the project is going to be or even how long it is going to take. The PRINCE2 manual seems to suggest that you cannot apply PRINCE in such projects since it defines a project as having "A finite and defined life span". But don’t be put off by this. You can use the PRINCE2 method, and quite easily too.

The key to using PRINCE2 here is the staged approach of the method. Let’s look at the more extreme case of research projects first, then work back to look at projects where you are just uncertain as to what the end will be or exactly when it will occur.

Research projects usually have stages. The work is planned and resourced one stage at a time. You can think of this as rather like driving down a foggy road. You can’t see too far ahead, perhaps 100 metres. By the time you get to the end of the 100 metres, the fog has thinned out a bit and you can see a stretch of 150 metres. In the next stretch the fog has thickened again and you can only see 50 metres. So with research. You can see and plan the next ‘tranche’ of work, but you don’t know what is beyond. These are just standard project stages; it is just that you didn’t know in advance what the stages would be.

The difference between this sort of project and a more normal one is that there is no project plan showing the full duration of the project. There are usually only stage plans and they can’t be drawn up until near the end of the previous stage – but then that is a normal approach to stage planning anyway.

The impact on the Project Initiation Documentation

The Project Initiation Documentation, or PID, normally sets out the project plans and the Business Case for the whole project as well as other things. But these two things in particular are going to be different in a research project. The Project Plan has already been mentioned. If a project plan exists at all it is going to be very sketchy indeed. But the Business Case could be very different too. It is likely to be less well evidenced than a normal Business Case. In the case of a research project, it is hoped that it will deliver something worthwhile, but it is often a hope.

In most project types of course, a project Business Case is resting on something much more than hope. But in some fields of research, is is considered normal if one project in ten delivers something. It is anticipated that nine out of ten will come to nothing. In most projects, a 10% chance of success would not be sufficient to launch the project! While attention will be drawn in the Business Case to what is hoped the research will discover, things could be very different in reality. Projects are often about the unknown, but research projects are very much about the unknown. In terms of the standard contents of a business case with it’s justification, rather more attention is thrown onto the stage rather than the project. The commitment at the end of the Initiation Stage is very much about looking at the viability of ‘Stage 1’ and much less about committing to the whole project.

Impact on ESA - End Stage Assessment

If the decision at the end of the Initiation Stage is rather less significant than normal, the decision making at ESAs makes up for that by being more significant than normal. In a standard project it is necessary to check if the project is still viable, but usually it is and this is rather more of a confirmation. In a research project though, that decision is vitally important and the whole project is very seriously reconsidered in the light of what has happened in the stage. It will be asked if the research still looks promising, enough to warrant committing more funds and staff resource in a further stage. This will need rather more investigation and ESA preparation towards the end of each stage than is normal. Whereas the end of the Initiation Stage is often regarded as the major ‘go / no go’ decision, in a research project every stage boundary is a major ‘go / no go’ decision. In this way though, the staged approach of PRINCE2 fits perfectly as do the normal control mechanisms during stages, including reporting.

Projects with an unclear end

In the rather less dramatic project where you are simply not sure what the end of the project will be, there may also be a very important decision point further down the project and it may be difficult to plan the end of the project in detail when the Project Initiation Document (PID) is produced in the Initiation Stage. An example of this is a new computer system. Let’s suppose that the project is to look at requirements for the new system and then to look round the market to see if any software packages exist that will meet those requirements. If none is found that is sufficiently close to the requirements, the computer department will write a completely new system. If a suitable package is found, it will be modified to make it fit well, but clearly the amount of modification will then depend on how close the package is to the organisation’s requirements. That can’t be known until the package is identified.

When producing the project plan then, we can be very clear about the first part of the project to investigate requirements and research what packages are available. But the back end of the project is unclear both in terms of content and time. What might be done is to take an assumption of a likely path that a package will be found but that it will need some modification and the project plan can be based on that.

The PID must state clearly that the plan is based on that assumption. Only when the results of the survey of packages is know can the back end of the project be planned clearly so we can say in advance that there could be a major re-plan at the end of, say, Stage 3.

An alternative where the project breaks into two clear areas like this - the first part clear, the second part unclear - is to make two projects. The first project will then set out requirements and investigate packages, and the second will install the package or write a new system. However, as the staff will be the same and so will the Project Board, and as it is likely that a package will be found, it is often overkill to have two projects. It is much simpler to state the assumption and accept that there may be a major re-plan of the project at a known point – i.e.. the finding of a suitable package or not .

Even the PRINCE2 manual indicates that you cannot use the method on projects with no end date. As you have now read, that is not true so the method is even better than the manual suggests ... if you know how to use it.

▲

Web site © Inspirandum Ltd 2010
PRINCE2® is a registered Trade Mark of the Office of Government Commerce in the United Kingdom and other countries