February 19, 2009 | Author: PM Hut | Filed under: Project Milestones
Project Signoff Points
By Literal Thinking
Any size or type of project will have identified deliverables that need to be completed and signed off at key points during a project’s lifecycle. The signoff signifies completeness, or at least business acceptance of the deliverable.
Most large scale projects will have a long list of deliverables that need to be completed for the duration of the project. Some of these need to be completed very early in the project (e.g. a project charter), some not until the project is completed (e.g. a post project review). Often, the number of phases a project will have is dictated by the number of deliverables required, and when these are required to be completed.
While some complex and well-run projects may identify specific signoff points or dates for each and every defined deliverable, most projects we encounter and have been a part of adopt a more general approach of having the signoff points coincide with the end of a particular phase of the project. The great advantage of this approach is it simplifies the monitoring requirement for deliverable signoffs from a project management perspective. Its one significant disadvantage is it can lead the project managers to slacken their grip on deliverable scopes and timelines.
The end of individual phases in a project also typically serves as checkpoints. Checkpoints are often where formal reassessments of projects take place, where a check is done to see whether the project still serves the business case for which it was launched; this check determines whether a project proceeds to the next phase or is terminated or re-scoped. Checkpoints are also often where partial payments are made to third parties that may be involved in project delivery; that is, a consulting organization helping in the delivery of a project gets partial payment for its full consulting fee during the completion of every phase of the project they are helping with.
Coinciding delivery signoffs with phase signoffs and/or checkpoints helps simplify the monitoring tasks of project managers. But it also puts a significant burden on them to juggle two often conflicting items in a project: the pressure to deliver on time, and the pressure to deliver on scope. Quite often, it is the pressure to deliver on time that takes precedence. And this inevitably means striking a compromise around scope delivery.
Some of the tactics project managers utilize to “force” deliverable signoffs just so they can meet their time requirements include:
Conditional signoffs. This is when deliverables are signed off on specific conditions that will need to be met in the succeeding phases of the project. There are some deliverables that will naturally require conditional signoffs. In an IT project environment, functional specifications for custom developments are often written early on in a project’s blueprint phase when only key functional personnel are involved. During the build phase, when developers start joining the project, it may be found that some of the functional specifications are “technically impossible” to implement. To ensure that there is scope for functional specification adjustments, these are only conditionally signed off at the end of blueprint.
Acceptable variance signoffs. This is when a deliverable is signed off even when it has not completely satisfied the original requirement but is delivered within an acceptable variance of the original scope. Going back to our conditional signoff example for custom development requirements, it may be found during the build phase of the project that some functional requirements originally identified during blueprint cannot be accommodated. An acceptable variance signoff for a custom development can be made if it addresses the key business requirements, and even when some of the nice to have bells and whistles are not delivered.
Postponed signoffs. This is when the signoff of a particular deliverable is postponed or moved to the next project phase or checkpoint. Unless a deliverable is mistakenly identified as a requirement earlier than it should be – which itself is unacceptable – we strongly believe that there is no reason for signoff postponements. Deliverables are often required at a particular point because serious consequences can happen if their deadlines are not met. For example, the statement of work is a requirement at project initiation; a fourth draft of the statement of work should not be floating around for signoff during a project’s build phase.
Arm twisting. This tactic is not as sinister as it looks, but it is essentially as it is written. The signoff parties for most deliverables are often subject matter and business process experts (SMEs/BPEXs), not the project managers. Project managers use the arm twisting tactic by imposing unreasonable deadlines and scrutiny on the SMEs and BPEXs that they often feel like they are left with no choice but to signoff, even when signoff processes have not been duly followed. Of the signoff tactics used, this is the riskiest, as this can mean that deliverables are signed off even when the business requirements are not met.
Literal Thinking is a blog that aims to present real stories of workplace follies. While we may occasionally post some interesting high profile cases of corporate missteps and failures that we find in the news, our focus is more on typical working day experiences of typical working people.
Our goal is not to name and shame, but to share stories and experiences in the hope that the reader is able to take away some valuable, practical learning that they can apply in their own workplaces. So they can go to where others have previously gone to and failed, and succeed.