All projects are required for a business reason, if there is no business reason for doing a project there should be no project. 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 organisations in the UK, have adopted PRINCE2 as the project management method and many 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 three 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 life cycle and not the organisations SDLC or SDLCs (some organisations use both waterfall and agile).
Project planning
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:
- What are the business objectives?
- What are the high-level business requirements?
- What is the business project organisation structure and how will the project be governed?
- What are the business benefits and how will the enablers for the business benefits be delivered?
- What is the business approach to resourcing the project?
- When will the enablers for the business benefits be delivered?
- What are the costs to the business and when will they be charged?
- What are the reporting requirements and frequency for the project?
- Who are the key stakeholders and how will they be managed?
- What is the business communications strategy / plan?
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:
- Project change management - engaging employees in the project to improve change adoption and, hence, earn the project return on investment (ROI) quicker;
- Operational impact - process and people;
- Communications - people;
- Training - people, process and technology;
- Finance - benefits and cost;
- Legal, risk and compliance - regulatory;
- Human resources - people;
- IT - technology;
- Sales and Marketing - benefits and cost
- Procurement - benefits and cost;
- Facilities - benefits and cost.
Each of these areas can be covered by either a workstream or a working group within the business project (see diagram, click the image to enlarge it):
Project governance
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 life cycle. This does not mean the business aspects do not need governing, just that the governance life cycle is different and has different considerations.
A business governance life cycle should consider:
- People (or change management aspects) - have the impacted employees been appropriately identified and engaged at the governance point? What is the ongoing engagement plan? Do the people have the expected breadth and depth of awareness of the change that the project is delivering?
- Process - has the impact on business processes been appropriately identified and described at the governance point, what is the ongoing plan for process change?
- Technology - has the impact on technology been appropriately identified and described at the governance point, what is the ongoing plan for technology change?
- Business case - is it still valid? Have the costs/benefits changed since the last governance point? What benefits have been claimed and have they been appropriately claimed? What is the on-going benefits realisation plan?
- Business risk - see next section.
Risks
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 risk 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 project risks need to be understandable and not in IT-speak. In simple terms the project sponsor needs to be advised in plain simple English:
- What is the risk?
- What needs to be done to mitigate the risk?
- What is the contingency plan if the risk materialises?
- Who owns the risk?
- How will the risk be monitored/tracked?
- How much will the mitigation activity cost?
- How much contingency budget do I (the project sponsor) need to maintain?
- Is there sufficient contingency budget to cover the high-probability risks?
- Have we assessed risk probability correctly?
It's time as COOs 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.
