Literal Thinking

Real stories of workplace follies

Archive for the ‘Project Management’ Category

Scope creep of a different kind

Posted by A Friend on 17 April 2009

No End in Sight Scope creep is often the bane of every project manager’s existence. High on project managers’ hate lists are the project sponsors, business process owners, and end users who seem to think that there is no time limit to the introduction of new requirements. This, while at the same time querying why the project takes so long to finish and costs so much to complete.

However, there are some project managers who not only tolerate, but sometimes even spearhead and encourage, scope creep. This typically happens when a project manager also wears the account management or business development hat. So while their project management side may want to complete the project on time, scope, and budget; their account management or business development side aims for more revenue and continuous work.

Take the case of Simon, who was enterprise applications manager of a large multinational firm. The company was implementing a customer relationship management (CRM) system that was to be rolled out globally, and Simon was leading the pilot implementation. The pilot had a fairly generic scope, the aim being was to deliver the solution to all locations and customizations done at country level.

This was good enough as a starting point, but Simon kept introducing module after module of additional requirements that extended project timelines and bloated project budgets. Simon argued that the scope creep was necessary to ensure the quality of the finished product. In truth, Simon only wanted to ensure that his department’s budget and personnel are maintained, if not increased.

Simon’s initial attempts to expand the pilot’s functionality easily passed the change request process. But the module expansions not only extended timeline and budget requirements, these also introduced various layers of complexity that likewise introduced additional deployment risks that required mitigation. And often, Simon’s risk mitigating action was the introduction of yet more components to the pilot module.

The scope creeping exercise eventually got out of hand, as what was supposed to be a six to twelve month pilot project had entered its third year with no clear end in sight. Alarmingly, Simon was still introducing additional, “risk mitigating” requirements. Not only that, he grew to become more and more adamant and insistent on these change requests. Ultimately, management decided that the only way for the project to be completed was if Simon was let go.

Simon was quite well known in the industry, so he did not find it difficult to find a new job after his dismissal. His next assignment was as a contract project manager with a national electricity distributor. The company was looking at building its own custom CRM solution, as most of the products offered in the market looked too expensive and complex for its requirements.

Even before Simon joined, the project had already been budgeted and scoped, with the charter and statement of work already approved. Simon arrived at the commencement of business blueprint, and his initial task, aside from slowly taking over the management of the project, was to facilitate the workshops with subject matter experts (SMEs) and key users.

A mere four weeks after joining the project, Simon started questioning the project’s scope and pointing out what to him were big gaps between the proposed solution and the business’s requirements. His points were initially taken on board, and he was given significant leeway in re-scoping the project.

But then, two months later, Simon was still documenting requirements and conducting workshops, with no clear end in sight. This frustrated the project sponsor, as it became apparent that Simon was not only allowing the SMEs to introduce additional requirements, he was actually encouraging them to, without regard to the limited resources allocated to the project. Another month of yet more workshops later, Simon was advised that his services were no longer required.

On the surface, project managers like Simon either hold scope restrictions in contempt, or have a high level of customer orientation; it’s likely that neither of these is true. Rather, it’s more plausible that the likes of Simon just want to ensure their indispensability by continuously churning out work requirements. As with Simon’s case, this can sometimes backfire badly and can lead to them being dismissed rather quickly.


Posted in Case Studies, Project Management | Tagged: | 1 Comment »

The perennial time and scope dilemma, part 2

Posted by A Friend on 24 February 2009

In a Pickle In our last post, we began presenting a case that illustrated the time and scope tension project managers often face. This tension can be especially heightened when signoff points for scope deliverables and phase completion are crammed together in one small time block, usually coinciding with the end of a particular project phase. This is the second part of the case, where we look at some of the major signoff decisions made, and the consequences of such and earlier decisions, at the latter stages of the project.

User Acceptance Testing

User acceptance testing (UAT) started with a big conundrum: who should do the testing? One train of thought was it should be the client’s key users, as they were the ones who knew the existing system and process requirements and should be doing the tests to ensure that the to-be solution met all of these requirements. Another view was it should be the vendor’s key outsourcing users, as they were going to be the ones using the system on a day to day basis, post-implementation. In the end, members of the vendor’s implementation team did the testing, the very people responsible for building the solution. It was a glorified unit test, and a farcical user acceptance test activity.

This was an unexpected requirement for the implementation team, so they were naturally not prepared and had not planned for it. UAT test scripts, which should have been completed and signed off in an earlier phase of the project were haphazardly done, often recycled from previous projects that had little relevance to the current one.

The project managers then decided that because of time and resource constraints, UAT was only going to be executed against core system functionality and maintained at a very high level; and all custom development testing was postponed to the next project phase. But even with this minimal requirement, it quickly became apparent that proper testing was going to be an arduous process, mainly because of the low quality of data loaded during integration testing and the still incomplete enterprise solution. So despite the significantly reduced scope, UAT could not be completed on time.

To ensure that the project remained on track, both client and vendor project managers decided to start parallel testing while UAT was still going on. UAT and parallel testing thus ended up running in parallel.

Parallel Testing

To make sure that the to-be solution met the client’s system and process requirements, the project simulated a parallel run over two months’ worth of transaction data. Parallel testing started at a later stage of the project, so the data migration team had more time to ensure that the quality of data loaded for parallel testing was of a much higher quality. But the good news ended there.

Virtually every process in parallel testing ended in error and data between the legacy and the new system just could not be reconciled. Various factors contributed to these errors: poor data quality coming from the source systems, incomplete configuration of the enterprise solution, and highlighted missing functionality in the to-be system.

The premature and forced deliverable signoffs done during the initial stages of the project was finally taking a heavy toll and putting tremendous pressure on the project team. Despite this, a very tight deadline for parallel testing completion was still followed, and strong arm tactics continued to be used by the project managers to ensure signoff. The parallel testing team was forced to manipulate data and introduce quick system configuration solutions just so parallel testing could be green-lighted on time.

The problems with the core solution encountered during parallel testing and the required efforts to address these also meant that signoffs of some solution components and functionality, and of various custom developments, were yet again postponed to the next phase of the project.

End to End Testing

End to end testing was identified as a key phase to be completed during project initiation to see whether the enterprise solution and the outsourcing organization could cope with the client’s end to end business process and service delivery requirements. Incredibly, some solution components, various custom developments, and UAT and parallel testing, were not yet completed before end to end testing was to start.

The end to end testing process itself was chaotic. There were yet again no test scripts written; and while the project had members who were experts in their individual work components, it had no identified business process experts. The project team did not have a clear understanding of an end to end business process to test, and no expert to look to for guidance.

Faced with time constraints and the lack of expert advise, both client and vendor project managers, not for the first time, decided to only take a helicopter view of the entire business process chain for end to end testing. And once more, even with this reduced scope, the to-be solution was found wanting.

Last-minute change requests to address process gaps were quickly approved, half-thought of solutions were developed and signed off, and an alarming level of testing variance against benchmarks was accepted and approved. All this was done for the singular purpose of meeting the project’s time requirements.

Go Live Cutover

The project reached go-live cutover without a cutover plan, with both client and vendor project managers still swamped with issues to close out: some custom developments were still not properly tested, let alone signed off; acceptance of testing variances were still being debated; and more change requests were being considered.

The big volume of issues still outstanding forced both client and vendor to bring in two additional project managers, with the sole brief of working together to take the project to go-live cutover. These two “cutover managers” had no experience in the project yet were given free reign to map out the go-live cutover plan.

A mad rush of signoffs and completions occurred in the last two weeks before going live. Changes to system configuration, with minimal testing, were introduced very late in the project because of even later solution gap identification. Critical custom developments with barely there testing were finally signed off, with some developments just getting completed during the last weekend before go live.

Data migration took two weeks to complete, with the data migration team losing count of the delta loads done. No one could swear on the integrity of data loaded into the new production system, and everyone crossed their fingers when go live cutover was signed off – on time.

– o –

We are deliberately stopping the case discussion at just before go live to let you, the reader, imagine how go live – and the immediate post go live – activities went. What is most amazing is this project was actually delivered on time and on budget; and with some creativity, it can even be reported to have been on scope.

Posted in Case Studies, Project Management | Tagged: , | 2 Comments »

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.

Posted in Case Studies, Project Management | Tagged: , | 1 Comment »

Of project signoff points

Posted by A Friend on 14 February 2009

Project Signoff Board 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.

This post was originally meant to only be a one or two paragraph introduction to a project management case where an overemphasis on “on time completion” put significant risks to the project as it struggled to meet its scope requirements. It developed into a post of its own as we feel it important to establish some background around the tension between delivering on time and on scope. We will present the case in our next post.

Posted in Project Management | Tagged: , | 6 Comments »