Is the PID dead?
Phil Jacklin
I lead medium-realisation high-potential teams, profitably, through transformational change and ideally periods of significant growth
I was catching up with a colleague I hadn’t seen for a good ten years and he was lamenting the fact that Project Managers have stopped planning. Specifically, he yearned for a Project Initiation Document at the start of a project.
That got me thinking. I can't remember the last time I saw a Project Initiation Document. It must be a decade.
Do PIDs still exist?
Straight from the PRINCE2 website:
“The purpose of the Project Initiation Documentation (PID) is to define the project in detail so it can be used by the Project Board to assess the project and see how it performed. The Project Initiation Documentation gives the direction and scope (Project Plan) of the project and along with the Stage Plan?forms the ‘contract’ between the Project Manager and the Project Board.”
OK, so it looks like they still exist.
So why is no one writing PIDs any more?
The phrase that doesn’t sit well with me, and may offer some insights as to where all the PIDs went, is “define the project in detail”. The detail is the issue. I see nothing wrong in defining the project before it is started, creating a baseline, roles & responsibilities, defining the major scope items and a level of understanding on the outcomes the project is responsible for. But in detail?
There is no doubt that back in the PRINCE2 heyday, PIDs slowed things down a little at the start. To produce what was often a 30 page plus document took some time. To get agreement on it could sometimes take even longer.
领英推荐
In our strive for improving productivity, we have eliminated many of those long steps in preference for “just getting going”.
Has the pendulum swung too far the other way?
Certainly there are occasions where the pendulum has swung too far. I recall in recent history being asked to sign a contract to deliver a project, where the deliverables section of the contract was entirely empty. My refusal to sign it got me branded as someone who was slowing down the project. No one was clear what I was slowing down, because the deliverables hadn’t been defined, but there was outrage that I was slowing things down.
Motion is not the same as action.
What replaces (the good parts of) the PID?
I don’t want to see a return to the PID. For a start, I really didn’t like writing them. But I do advocate for a little more pause, a little more thought and a little more planning before we hurl headlong down a particular route.
I still believe there is value in knowing the outcomes, having a level of agreement on the big scope items, knowing who is doing what. Sure, it can all change. The production of it should be light. But it should still be done.
A project rarely delivers well without starting strong. Let’s not throw the planning out with the PID.
Global Transformation Director at Oxford University Press
3 周I remember taking over a programme at a client and inheriting a 92 page as yet unfinished PID in its double digit version 9 months post programme start. After my first week of stakeholder reviews it was clear that no one had read beyond page 1. So I completely agree that the "in detail" bit is the killer. An anchor to the core business requirement/ problem statement, goals, business case and guardrails is still critical (whatever you call the document) but my rule of thumb now is ideally no more than 3 pages and with links to the active elements of the project / programme where the real works evolves and adapts as it engages with reality - rather than someone's imagined reality from the halcyon days before the initiative started.
IT & Business Consultancy Project Manager
1 个月A PID on steroids
Project & Programme Manager
1 个月The problem with PIDs is the name and the legacy. Conceptually, it's still a good idea on a lot of projects. But a small amount of time spent framing "so what are we all trying to do here?" still goes a long way I think. Just don't call it a PID, don't spend 20% of the expected project life cycle developing it, don't make it the size of a phone book, and don't fill 90% of it with boilerplate text that is irrelevant and ignored.
Senior Project Manager
1 个月If you don't put some effort into defining the benefits and outcomes you want from the piece of work, how will you ever know whether you have succeeded? If you don't have some kind of high-level investment case, how will the executive boards triage all the requests for funding to find those most worthy of the money? I agree with Bernard documents can become bloated with duplicate content. I have also seen stakeholders request detailed cost benefit analysis of the solution in the Investment Documents before you have stated the options analysis. I do think there is a belief amongst executive stakeholders that projects not in delivery phase are not making progress. See my previous post about governance.
Transformation Programme Director IBA
1 个月Great perspective thanks Phil Jacklin I still use a wagile approach. We have project brief and business cases, linked to resources plans. We have firm project initiation but it's scalable from very lite, to full fat. We also still employ stage gate and assurance review to avoid the zombie project. Clearly in delivering We adopt agile ceremonies and rapid iterations whilst having a clear view on what the end goal is. So I agree we cannot define the exact detail but these should be living documents that are reviewed during the life cycle