Monday, January 2, 2017

When is it a project?


PRINCE2 is only suitable for use on projects, but how do we know if we have a project or if we have “business as usual” (BAU)?

“A project is a temporary organization that is created for the purpose of delivering one or more business products according to an agreed Business Case”. This is the PRINCE2 definition of a project. It is helpful, but the definition is not always sufficient to help you judge if you have a project or a collection of tasks. Below you find some additional help.

PRINCE2 Agile states that a project is a temporary situation, where a team is assembled to address a specific problem, opportunity or changes that is sufficiently difficult that it cannot be handled as “business as usual” (BAU). PRINCE2 Agile lists four characteristics of a project that differentiates it from BAU:
  • A project is temporary
  • A team is created
  • It is difficult
  • There is a degree of uncertainty.

Below is a table of the characteristics and some indicators to help judge if the task at hand should be organized as a project or “business as usual”. Before applying these indicators, you should make sure the scope and objectives are understood. If you don't understand the scope, you might misjudge the indicators.



Some cases are obvious, because there is no alternative. Arranging the Olympics for example. The host nation will have to set up a temporary team. There is no flexibility on time to implement a complex and difficult scope. A lot is at stake, and the risk appetite is low.

Other cases are not so obvious. Maintenance of a software product can be handled both as a project and as “business as usual” (BAU). If the team and funding is quite permanent, and commitment on scope and time to the user community is low, BAU is probably the best way to organize the work. If the team and budget is varying, depending om what scope is communicated to the market for a set release date, the best way to organize the work is a project.

There are communities preaching that projects are not necessary and should be avoided (#noprojects). The key assumption this community makes is that you can manage the environment to match the “BAU indicators”. Everything should be broken down to small tasks that can be done and released one by one, or at least often, with little or no planning and coordination.

The #noproject community is on to something. You should not establish projects in a situation where continuous releases based on prioritized value is possible. But, we also have to be realistic and pragmatic. If our business environment, organization or leadership is not ready to shape the environment towards the BAU indicators, or we have a product not possible to release in a continuous flow, we have to keep running projects. In many cases, there is no choice. Not even Allan Kelly would send a man to Mars based solely on the #noproject principles.

The #noproject community also makes some incorrect statements about project management – or at least about PRINCE2. The claim is that projects are measured on scope, time and quality – not benefits, and that scope is static. PRINCE2 is set up to focus on benefits and the business case. A PRINCE2 project scope can be changed whenever it makes business sense. Several times a day if needed. The #noproject community is also, at least the key spokesperson Allan Kelly is, communicating an incorrect PRINCE2 definition of a project.

So, yes there are circumstances where #noprojects is the best options. But, there are also many circumstances where project management should be the preferred approach. If you don't think so, you've probably been over exposed to a certain type of software development.

Copyright © PRINCE2How2 - How to implement PRINCE2 in your organization

1 comment: