In the ideal world, as project deliverables are produced, the necessary support and governance pieces required to effectively transition them to an operational state are ready so that the project team can move on to the next set of deliverables and the functional owners are comfortable being able to use these deliverables. A lot has been written about resolving the common issue of a project team poorly handing over deliverables but a tougher challenge exists on those projects where scope is delivered in a phased fashion over a long duration and future deliverables are based or tightly linked to earlier ones.
In this situation, how does one define what transition or a warranty period means? On one hand, the project team has completed the work on the early deliverables and would have the reasonable expectation that the operational support team should be able to own the ongoing care and feeding for these. On the other hand, if the functional owners are changing the intended use or nature of the delvierables due to gaps or other causes, such activity should involve the project team as it may either impact the quality of future deliverables, or might present an opportunity for the project team to come up with a more elegant product in a future “release”.
This situation is well understood on agile projects – the role of the product owner is to incorporate feedback on released deliverables into the product backlog for prioritization purposes.
But what can one do on traditional projects?
Establishing some rules of engagement for operational handover up front can help – one approach is to define timelines and procedures for two distinct phases of post-handover support:
- Pilot period: Over this time period, all defects and desired modifications will be fielded by the project team.
- Warranty period: This starts once the pilot period ends, and details specific situations or criteria that merit the project team’s involvement. For service request consistency, the first point of contact should always be the operational support team (e.g. a level one help desk analyst), but the request should then be forwarded to a specific, designated project team member for review & assessment. Each request can be handled in one of three ways:
- It is incorporated into the design of a subsequent deliverable (following appropriate project change management practices)
- It can be considered as out of scope for the project, but of low risk or impact to future deliverables, hence the functional owners can modify its usage as they choose. This approach is analogous to a normal product warranty exclusion.
- It is considered out of scope for the project, but of measurable impact to future deliverables, and the functional owners should not pursue it. This response is similar to clauses in a normal product warranty that specify what behaviors will void warranty coverage.
As with most project management challenges, a little planning can go a long way and defining standard practices for handing over deliverables on phased projects will avoid the inevitable tug-of-war between the “Hotel California” and “toss it over the wall” syndromes.