Project tollgates
I'm doing some work at the moment on project tollgates. We use the DSDM Atern Framework for delivering our projects, and in a recent all day workshop one of the concerns that came up was the handover from the sales team to the delivery team. Not a major concern - I've seen some teams where the gap between what was sold and the reality of what can be done has been monstrous. Here, fortunately, not the case.
However, this seems to be a recurring question. What has the salesman agreed?
My approach to a project delivery methodology has always been that the first phase of a delivery project is fundamentally to address that - the delivery team need to take ownership of the project, and make their own commitments to what can and cannot be done and by when. Call it Inception, Foundations, Blueprint - the effect is still the same. Not the best way to present it to a customer, but actually, a customer should be able to see the value of this first phase also - it aligns everyone's expectations and paints a much clearer picture of what is needed to be done, by whom and when (and, maybe, even a bit of how).
I digress. The fact still remains that this first phase (I'll use Foundations) needs to be based on what has come before (I'll use Feasibility).
Checklists seems to be the way forwards. It's common for IT Managers to ask why there's no checklist for how to pass from A to B. We sit on planes, watch the pilots do the pre-flight checklists (yes, they do commonly still leave the cockpit door open!), and think, that's what I need to make sure my project gets off the ground correctly also.
I think this is combined with Tollgates. A Project Delivery Method needs to define discrete phases to pass through. It needs to define the Tollgates (which would usually align with phase boundaries, but there might be some inside the phases also). Then we need to write checklists on what needs to happen to pass the tollgate - and record the outcome. If we choose to pass a tollgate without all the checks passed, then we will have a record of why we did that, and who was involved in the decision to do so.
Thus a checklist can ensure that the delivery team understand everything that the pre-sales team has committed to; and provide a smooth passing through the Tollgate from Feasibility to Foundations.
I came into this from reading an interesting article by Patrick Gray called The Power of the Tollgate, where he expresses that tollgates are powerfull because they are pre-defined, and provide the power to pause.
However, this seems to be a recurring question. What has the salesman agreed?
My approach to a project delivery methodology has always been that the first phase of a delivery project is fundamentally to address that - the delivery team need to take ownership of the project, and make their own commitments to what can and cannot be done and by when. Call it Inception, Foundations, Blueprint - the effect is still the same. Not the best way to present it to a customer, but actually, a customer should be able to see the value of this first phase also - it aligns everyone's expectations and paints a much clearer picture of what is needed to be done, by whom and when (and, maybe, even a bit of how).
I digress. The fact still remains that this first phase (I'll use Foundations) needs to be based on what has come before (I'll use Feasibility).
Checklists seems to be the way forwards. It's common for IT Managers to ask why there's no checklist for how to pass from A to B. We sit on planes, watch the pilots do the pre-flight checklists (yes, they do commonly still leave the cockpit door open!), and think, that's what I need to make sure my project gets off the ground correctly also.
I think this is combined with Tollgates. A Project Delivery Method needs to define discrete phases to pass through. It needs to define the Tollgates (which would usually align with phase boundaries, but there might be some inside the phases also). Then we need to write checklists on what needs to happen to pass the tollgate - and record the outcome. If we choose to pass a tollgate without all the checks passed, then we will have a record of why we did that, and who was involved in the decision to do so.
Thus a checklist can ensure that the delivery team understand everything that the pre-sales team has committed to; and provide a smooth passing through the Tollgate from Feasibility to Foundations.
I came into this from reading an interesting article by Patrick Gray called The Power of the Tollgate, where he expresses that tollgates are powerfull because they are pre-defined, and provide the power to pause.
Comments
Post a Comment