In many organisations, the project management capability resides within the IT Function. Having the project management capability in the IT function is like ‘the tail wagging the dog’. This anomaly should be addressed.
Project Management Capability
It may be a case that many projects have a large IT component but this does not mean it is an IT project, it is a business project with a large IT component! The project management function should reside within the business and the natural place for this is within Business Operations.
This provides the project management function (and project managers) with the exposure and breadth of business relationships and clear sight of the business impact from three dimensions people, process and technology. It is very rare for projects to impact only one of these dimensions.
Justifying a project:
For all projects a business case should be produced, whilst some projects may be required for regulatory, operational risk or cultural change reasons these are business projects and have a business justification.
The business case is a collaborative document brought together by the business lead (or business project manager) with input from all of the business areas impacted to ensure that a holistic business case considering costs, benefits and risks from each business area are considered. IT is one area of the business.
PRINCE2 and Gated Governance
Many organisation’s in the UK, have adopted PRINCE2 as the project management method and many organisation’s have embedded a gated-governance framework based on a software delivery lifecycle (SDLC), whether it’s waterfall or Agile, into its project management method.
This has resulted in a misconception that PRINCE2 is tied to the gated-governance framework and the SDLC gates. This is incorrect. PRINCE2 is a business project management method and only specifies 3 governance gates ‘Starting Up a Project’, ‘Initiating a Project’ and ‘Closing a Project’.
Of course, between ‘Initiating a Project’ and ‘Closing a Project’ other stages are allowed and the ‘Managing Stage Boundaries’ construct allows for that, however, these stages should be aligned to a business project lifecycle and not the organisations SDLC or SDLCs (some organisations use both waterfall and Agile).
The project plan (and I don’t mean the project schedule or Gantt Chart) is a business document and hence should be written from a business perspective and should broadly contain the following:
Organisation Structure of a Business Project
For each project, subject matter experts will be required to address each particular perspective or business area, for example:
Each of these areas can be covered by either a workstream or a working group within the Business Project (see diagram):
An appropriate governance framework should be defined within the organisation for a business project. The IT Workstream should be governed against the SDLC and not the Business Project. The business aspects to the project do not fit a SDLC lifecycle. This does not mean the business aspects do not need governing, just that the governance lifecycle is different and has different considerations.
A business governance lifecycle should consider:
Risks should be documented in a form that is meaningful to the business. Often Risk logs are filled with technical risks, whilst there may be a significant IT risks within a project the language used to describe these should be in a form that is understandable and meaningful to the business. For the Project Sponsor to make informed decisions the projects risks need to be understandable and not in IT speak. In simple terms the project sponsor needs to be advised in plain simple English:
It’s time as COO’s to change the landscape and put the project management capability where it belongs, in the business and utilise the Subject Matter Expertise of the individual departments in the most efficient and effective way. We are here to help.