The Battle Between Process and Progress
This is a contribution by Chris Hammond from smartitpm.com.
As Project Managers, we’re all familiar with process.
In fact, sometimes it can feel as if a project manager’s world is but a never-ending universe of interlocking processes and procedures.
But what happens when the need to follow organisational process inevitably conflicts with making project progress?
After all, project managers are not process monkeys.
We are not process workers, production line operations – or trained gerbils.
We exist to deliver outcomes.
On schedule, on budget and to specification.
So let’s delve into the quandary of “process vs progress” and what you can do about it on your projects.
Why Do Processes Exist In The First Place?
When it comes to processes, we really need to sit back and take in the grander perspective.
Why do organisations have processes in the first place?
Broadly speaking, processes exist to serve one of the following 3 masters:
- Control of Safety or Business critical tasks
i.e. aeroplane component design, or changes to core banking infrastructure - Quality Assurance
i.e. document review, software testing and release - To Facilitate Progress
i.e. project delivery frameworks
That’s right, the majority of processes actually exist to facilitate progress.
At least in theory.
Let’s assume a company is a commercial entity. It exists to make money. The company grows and goes about its work, being conducted now by many people. It needs processes. The processes mean the company can go about its objectives more smoothly, efficiently and with more predictable outcomes.
But ultimately, all processes serve (or should serve) a business need.
Temporary projects are also created to fulfil business needs.
And so there can be conflict.
Now this is all going to vary depending on the maturity and scale of the organisation you work for.
Some smaller companies have barely a process to hang their hats on.
Large enterprise organisations, however, can often seem like a labyrinth of strictly enforced processes – beset on all sides by senior managers, viciously guarding their process territory.
What often happens – particularly in larger companies, or organisations without good maturity levels – is that processes get divorced from the reasons they were created in the first place.
It is not uncommon for the project manager to find herself facing a poorly conceived, out-of-date, or immature process.
And it is certainly not uncommon that such a process could stand in the way of making progress.
The Main Event: Process vs. Progress
In the red corner: fighting out of operational business needs, repeatability and predictability:
- 32 wins, 2 losses – the reigning, undisputed champion of the world – Process!
In the blue corner: fighting out of project business benefits, delivery and flexibility:
- 25 wins, 0 losses, the challenger – Progress!
There comes a time in every project manager’s career when they will need to step into the ring and fight against process.
After all, if following a process impacts your schedule, budget or scope, this is a major decision and passes out of your hands.
Your project stakeholders will judge the winner of the fight.
And your job as project manager is to enable them to make that decision.
The decision between:
- Option 1: Delivering the project: as intended, conceived and baselined.
- Option 2: Following the process and delaying the project or increasing the budget.
I know what you’re going to say.
Some project managers will shout from the rooftops: your baseline schedule should have incorporated the timeline requirements of following all organisation processes!
But back in reality: the real world doesn’t always work like that.
Project schedules aren’t always created in that level of detail.
And what’s more – especially in complex organisations – new processes will be introduced, or existing processes changed, whilst your project is already in-flight!
The judges of the fight must make their decision based on clear information – business impacts and risks.
A Real Life Technique to Use on Your Projects
So, as a project manager, you need to gather this information:
- Why does the process exist in the first place?
- What underlying business need does the process serve?
- What is the impact to your project budget, scope and schedule if the process is followed?
- What variation to the process does your project propose, in order to sustain its current delivery?
- What is the additional business risk and business impact, of the proposed process variation?
Crack open your copy of MS PowerPoint and create a quick 1-page slide. Provide your stakeholders with Option 1 and Option 2 – with associated impacts and risks.
Let’s look at one quick example.
Sara is delivering a 3-month project to upgrade some core banking infrastructure.
Halfway through her project, the
Sara creates a quick PowerPoint saying:
Option 1:
Accept 2 week delay to the baseline schedule.
Impact: project business benefits ($250k ROI p/a) delayed by 2 weeks.
This is a direct loss of $9.6k of operational savings.
Option 2:
Retain the planned lead time of 1 week.
Stakeholders to approve process exemption from 3 week lead time.
Risk: additional risk to operational stability of banking infrastructure, as the upgrade will take place outside of
Risk Mitigation: project will facilitate a technical risk assessment and approval from all SMEs and operational groups, for the upgrade to be deployed with 1 week lead time.
Sara emails her deck to the GM and adds the item to the agenda for her next steering committee.
As expected, when presented with the facts (and particularly the financial impact) the stakeholders approve Option 2.
A victory for Progress!
So there you have it. A brief summary of the battle between “Process vs. Progress”.
About the Author: Chris Hammond was an IT project manager for 12 years, moving from a project admin role to a project director role in that time.
