Literal Thinking

Real stories of workplace follies

The perennial time and scope dilemma, part 1

Posted by A Friend on 19 February 2009

Dilemma In our last post, we introduced a fairly familiar project scenario where signoff points for scope and time overlap. This typically happens when deliverable (scope) signoffs are crammed into one time block, often also coinciding with the end of a particular phase (time) of a project. In some projects that we have seen and been involved in, this simplified approach had led to project managers choosing to either compromise on scope or on time (sometimes both), just to make the signoff point. We call this the perennial time and scope dilemma.

To illustrate this time and scope tension, we will walk you through some of the key sign-off decisions made in each major phase of a global IT outsourcing project by a large consumer goods manufacturer (hereafter we shall refer to as the client). The project was undertaken with support from a consulting partner (hereafter referred to as the vendor) that was also going to be the outsourcing organization after project completion. This is the first of a two-part series.

Business Blueprint

The business blueprint document, arguably the single most important document in any IT transformation project, was signed off unconditionally with major sections of it indicated as “to be completed”. The vendor used strong arm tactics to force the client to sign off, arguing that the blueprint completion delay was singularly due to the client not being able to provide the required resources for on-time delivery. For the client, it was a matter of signing off on an incomplete blueprint, or paying a hefty delay cost.

The client cascaded the strong arm tactic down to its internal subject matter experts (SMEs). The SMEs were forced to sign off on the data migration design and plan without being given the opportunity to seriously assess project implications to both their retiring and retained systems and processes; or scrutinize two 150-page documents and four complex workbooks, which were to be used as primary tools for transferring data.

All custom development functional specifications were conditionally signed off, contingent on missing blueprint information being provided in the next phase of the project and proper assessment of proposed technical solutions. It was correct to conditionally sign off these deliverables, but their dependence on a completed blueprint document, when it was already unconditionally signed off, was a big risk.

The sign off requirement for a go live checklist was postponed as it was deemed unnecessary at such an early phase of the project. The project would eventually go live without a formal checklist being signed off.

Solution Build

It quickly became clear to both client and vendor that the business blueprint documentation did not contain adequate information to allow the vendor to build a complete enterprise solution. The vendor tried to push the client to raise change requests; while the client pushed back, arguing that while the business blueprint documentation may not have been completed, the enterprise solution requirements had always been clear.

Client and vendor met halfway, but a lot of effort was wasted on just scope renegotiations. The checkpoint was reached, and the enterprise solution was not yet completely built. To ensure the project continues on schedule, both client and vendor project managers agreed to conditionally sign off on the enterprise solution, with the proviso that incomplete components will be progressively delivered in the next phase.

The conditional signoff of the enterprise solution had a trickle down effect on the rest of the deliverables. For example, the data migration processes and most of the custom development requirements were reliant on the enterprise solution being completed, so these were also conditionally signed off.

Part of the conditional signoff of some custom development deliverables was also due to the lack of time to complete the developments. The original project schedule was made based on a number of assumptions, one of which was the number of custom development requirements. These requirements were significantly underestimated, but the broader scope did not deter both client and vendor project managers from sticking with an ambitious delivery schedule.

Finally, some other requirements like super user training and cutover planning just could not be delivered with a half baked enterprise solution, so signoff for these were postponed to the next phase. Not surprisingly, these were not looked at again until late in the project.

Integration Testing

Integration testing is all about making sure that the to-be-implemented enterprise solution can replace retiring system functionality, including integration with mission critical retained systems and processes. With an incomplete enterprise solution, integration testing for this project was a shambles. In fact, proper integration testing processes were totally ignored, and activities during this phase were more to ensure that systems and processes were ready for user acceptance and parallel testing (the next phase).

Full end-to-end data migration testing was a mess. The client did not have enough time to analyze their source system requirements; while the vendor was still in the middle of building the solutions during data migration testing, so the target system requirements were also not yet properly defined. The whole data migration team struggled to get data loaded properly, and virtually every step of data migration had errors. In the end, the goal changed from end-to-end data migration testing to just making sure that data is loaded into the user acceptance and parallel test systems. There was no proper data validation process, and strong arm tactics were used to force the data migration SMEs to sign off on data migration testing.

A lot of the custom developments, most especially interfaces to mission critical systems, could also not be tested properly. This was due to the incomplete configuration of the enterprise solution, the lack of meaningful data to test against, and the still ongoing development activities. Without much headway and with the project still chasing its time requirements, a lot more of the custom developments were conditionally signed off, contingent on these passing user acceptance and parallel testing.

Our case discussion will continue in our next post, where we will present some of the signoff disasters in user acceptance testing, parallel testing, end to end testing, and go live cutover; as tension between delivering on time and on scope mounted.

Advertisements

One Response to “The perennial time and scope dilemma, part 1”

  1. […] The perennial time and scope dilemma, part 1 […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: