Project or Process, that is the question

2016-10-06

I ran across a customer the other day who had employed an MSP consultant to develop an MS Project template to support project planning according to PMI methodology.
The templates WBS structure was defined as a series of phases taken from the PM Book top-level processes, like Initiation, Planning, Execution, Monitoring etc. Below these processes the administrative processes and deliverables of PMBook were incorporated. The consultant had even added classifications for PMBook Knowledge area and Deliverables. So far – so good.
Recapitulating over the years, many project schedules, regardless of tools used, focus on the process of PM deliveries like repeated tasks for team meetings, stakeholder meetings, delivery of ”formal” project documentation, monitoring work done by the schedulers or PMs etc.
But – is this a *project schedule*?
In my world no, and below I will elaborate on why we need to differentiate carefully between the PM Processes and the Project Delivery Schedule.
OK, back to the customer. The project managers, newly trained in PMBook were​ really happy with their project schedules. ”It contains all I learned at the class” one PM stated. ”Now I will be able to show my stakeholders exactly what needs to be delivered in my project” another PM stated. The PMO manager said ”Finally we can streamline our project plans for me to gain oversight and control of the projects’ status reports”.
I guess you all know where the ball is rolling.
”Where can I see the development deliverables in the schedule and their forecasted delivery date?” I asked the PM crowd. Silence.
”Can you show me in the Schedules how we will fulfill the scope according to contract with the customer?” Silence.
”What projects are in danger of delays and liability payments in the portfolio?”. ”We know when we see the status reports”, the PMO manager muttered.
So, the deliveries of the projects were unaccounted for. Hidden behind a forest of minute PM admin tasks. Forgotten? Yes. Misunderstood? Yes.
No shadow should fall on the newly trained PM or the PMO manager. They acted as they where supposed to. Took their newly won knowledge and wrapped it in the best effort they could think of.
The shadow needs to fall on us who have been training these crews. Us who know how important sound processes for Project Delivery are, us who have failed to clearly show the difference between a *delivery process* and a *delivery schedule*.
Why does this happen? Because the PM community is inherently built on (rightly) hammering in the need for strict procedures, administrative planning and control. A PM leaving an ordinary PMI training will actually have one of the best foundations for running the PM processes that will help lead to success!
But, home alone in front of the full inbox, with endless to-do lists from component or scrum teams, another stakeholder request for a project report in a new format, etc, etc… I, as a PM, might (wrongly) feel that the *process* IS the *project!!!
So, what is the advice to the PMs in this case? You need to ask yourself:
1. Why do we have a project schedule?
2. Who is the stakeholder of the schedule information?
3. What tasks are adding value to the delivery of the project?
4. Is there a clear and constructive hand-over level to subPMs, contractors that is actionable and possible to track but still gives enough leeway for each delivery team to be successful?
4. How and where do we make sure that we follow the best-practices processes for PMs?
A Project Schedule should describe the project deliverables from an end-result perspective.
So, if your project’s value is calculated based on the PMBook suite of documentation and administrative​ tasks, please continue to deliver admin-value. If I were the stakeholder, you would not survive the next status meeting.
If your project success and value is measured on delivery of customer value through products and services: schedule for your end products. Maybe include Level of Effort tasks for your PM Process work items. Use Visual Planning for your PM team to make sure you are aligned with the process.
To improve your understanding in this area, study the PMI books around WBS and scheduling best practices. Or join, for example, the Forecast Scheduling Group on LinkedIN. Or look into how PRINCE2 reasons around scheduling for product delivery.

Email a link