CASE STUDYScope Management,Stakeholder Engagement,Government26 October 2004

PMI Global CongressNorth America

Wagner, Ellen

How to cite this article:

Wagner, E. (2004). Against all odds, a case study on scope and stakeholder management (....and then some)PMI Global CongressNorth America.

Abstract

The objective of this project was to develop a document imaging system that would support the government's requirement to process information requests. This imaging project was based on a similar one; one that was operational at a different federal agency and used to demonstrate to the buyer what the contractor and emerging technology could do. As in the original project, the new system was to be delivered in approximately 18-24 months. However, unlike the first contract, this project was Firm Fixed Price (FFP) and not Time and Materials (T&M).

The circumstances, issues, and actions of individuals on the buyer and seller teams are detailed. The buyers originated from three different sister organizations: users of the new system, contracts, and the user liaisons that were more technically savvy and interfaced with contracts on the user's behalf. There were three sellers involved in a traditional, tiered contractual arrangement. The prime contractor was new to the relationship while the systems integrator and product developer worked together on the original system. All in all, seven unique roles on the buyer's team and five from the seller's will be explored.

Pertinent facts tying the project details with theGuide to the Project Management Body of Knowledge(PMBOKGuide)knowledge areas are described, providing the basis of which to analyze and discuss this case. For example, what would you do in any one of the following situations?

• One of the first system deliverables, a Concept of Operations, was rejected because it did not follow the existing process. This contract was won, in part, based on showcasing a similar workflow that was operational at a different federal agency.
• About 50 user representatives existed, they couldn't agree on their needs, and senior management didn't provide any guidance or leadership.
• Although the system requirements were documented, they were only gleaned during the proposal phase and not thought to be contractually binding. However, they were. What was supposed to be an 18-month project became a 4-year effort.

This case study focuses on scope, stakeholder and procurement management, highlights risk management (or the absence of it), and addresses all of thePMBOK Guideknowledge areas including professional responsibility.

Project Introduction

Like the original, this document imaging project was based on a commercially available product that was enhanced with customized software features. The process workflow begins with preparing documents, scanning and indexing them, redacting sensitive information to protect it from release, and distributing an image of the remaining information to the public. Its implementation would be staged in three phases, building more capability and adding more users in each phase. The first phase would provide limited operational capability within 6 months to approximately 150 users in the beginning of the workflow. The middle phase would provide automated redaction capabilities to an additional 250 users. Finally, approximately 100 users involved with the release and adjudication process would be added into the fold. The total length of time was anticipated to be approximately 18-24 months.

This was a ten million dollar project and included a new ATM backbone, new client server hardware, commercial software for 500 users, custom software, and professional services. As noted in the buyer's proposal, a potential move did occur. Approximately 250 users, those in the middle of the workflow, were relocated to a new facility a few city blocks away. In addition to the surmised logistical challenges, secure network connections were also required.

Project Stakeholders

Seven unique roles on the buyer's team and five on the seller's team will be revealed as we consider each of the three case studies.

Buyer's Stakeholders

The buyers originated from three different sister organizations within one federal agency and included management and users of the new system, liaisons that interfaced with the users and the contracting organization, and the contracting officer. (Exhibit 1)

Exhibit 1: Buyer's Stakeholders

The six key individuals and one role are detailed below:

1. Project Sponsor:A department executive; he was the 4^th-line manager of the users of the system.
2. Senior Manager:Promoted to this position 6 months into the project; team leads reported to directly to him. Although he regularly met and had a good rapport with his team, he often deferred making decisions.
3. Process Lead:Received a tour and demonstration of the original system. She is offered and accepts more responsibility and authority over time.
4. Users:Users and team leads of the new imaging system, some of whom received guided tours and demonstrations of the original system. Initially there were 50 user representatives representing 500 users. Eventually the number of representatives shrank until it reached a manageable size of about 10 people.
5. Project Liaison:Acted as the good cop in a good cop/bad cop scenario with the Contracting Officer's Representative (COR). She received a tour and demonstration of the original system and worked well with the Process Lead.
6. COR:Acted as the bad cop in a good cop/bad cop scenario with the Project Liaison. She retired from the government approximately 18 months into the project.
7. Contracting Officer(CO): He would only speak privately to the COR during meetings and wouldn't look you in the eyes during conversations.

Seller's Stakeholders

The sellers were government contractors who managed, developed, integrated, and ultimately transferred the system to the buyers. The sellers were employees of three different companies; a prime contractor, a systems integrator, and the product developer. The systems integrator and product developer had worked together on multiple projects, including the showcased one, and were collocated at the product developer's site. During the project kickoff meeting, members of the original showcased project team were intentionally placed on this team to facilitate its success. The prime contractor was selected, in part, because it had an existing GSA contract. (Exhibit 2)

Exhibit 2: Seller's Stakeholders

Five key roles, representing seven unique individuals and two groups, are detailed below:

1. Senior management:Includes management from the systems integrator and the product developer - in a two-tiered hierarchy. The prime contractor's senior management did not have a sustained presence.
   • Systems Integrator VP:Involved in the proposal phase, a quick turnaround effort based on available fiscal year funding. When notified of serious project risks and issues, he took no action for over a year.
   • Product Developer VP:One of the founders of the company that developed and marketed the commercial, document-imaging product. He initially glossed over serious project issues but became more involved in their resolution as the project progressed. Unfortunately, in becoming more involved in the resolution of issues, he often provided additional software features to appease the client (often called goldplating).
2. Project Managers:One for each of the three companies, the prime contractor, the systems integrator and the product developer.
   • Prime Contractor PM: Added to the team about 6 months after the project started and although he had weak leadership skills, he stayed for 12 months.
   • System Integrator PM: PM from the original, operational system who was presented the opportunity the day before the kickoff meeting. She managed the project, leading the prime and the product developer, for the first 18 months.
   • Product Developer PM: Although an inexperienced project manager, he was well versed with the commercial product and provided technical guidance to the developers for ~ 12 months.
3. System integrators: 12 people for systems engineering, system administration, system verification and training. The system integrators often acted as a liaison between the users of the new system and the developers.
4. Software Developers:10 software developers who knew the product and how to best customize it to meet the buyer's needs.
5. Contract Executives:Executives from the prime contractor and the system integrator. The system integrator's VP of Contracts was involved since the project kickoff meeting while the prime's contracting officer and executive became involved after the project was underway. The prime became more involved when contract deliverables weren't accepted and payment terms renegotiated.

Managerial and technical lead personnel changes occurred for the buyer and the seller over the course of the project.

The following three case studies are directly relevant to scope, stakeholder and procurement management. As you read these studies keep in mind your education and experiences and what you would do or have done differently.

Case Study 1: The rejected Concept of Operations

One of the first system deliverables, a Concept of Operations (CONOP), was rejected because it did not follow the buyer's existing process. The system integrator's PM suspected the users wanted the existing process automated so she requested two versions of the CONOP, one that presented an alternative, a streamlined process workflow, and one that automated the existing process. This re-engineered workflow in the first CONOP was based on the operational showcased system and was delivered first. It was ultimately rejected. While the buyer claimed they wanted to reduce cycle times, they were resistant to changing their existing business processes. In fact, when all was said and done, they simply automated them.

The CONOP was the first document deliverable, due within the first three months of the project. After its initial rejection the system integrator's PM met with the project sponsor and senior manager, requesting reconsideration. Likewise management asked the users to reconsider and within a few weeks, the users again rejected it. The buyer's management stood by their users, ultimately setting the precedent for the rest of project.

Rejecting the CONOP was a critical turning point.The streamlined workflow was the basis for the proposed time, scope, and cost estimate.Although the PM knew in her gut that this was a serious turn of events, she wasn't able to articulate the impact of this decision and her disappointment at the time.

Risk management could have provided insight into the project issues.

• How might the project have changed if the rejection of the CONOP had been identified as a potential risk?

Case Study 2: Who's making the decisions?

Are the users empowered or running amuck?

This document imaging project involved a very large user community who received little guidance from their management. When the various users groups couldn't agree on functional requirements, senior management provided little if any direction. Users were permitted to review key project deliverables such as the CONOP and the design document and recommend changes without a process that provided a check and balance; change recommendations were blindly passed through to the seller as the users learned what was available and determined what they wanted.

The sellers initially vetted requirements with the users through capability demonstrations and later via incremental demonstrations of recent developments or progress. Although design reviews were held on the first project, they were not held during this project. In fact the design document was in a continuous revision cycle of its own. Vetting requirements and system design with the users or their representatives was time consuming and costly as it often led to gold plating and frustrated the software developers as changes were reintroduced.

The pendulum swings back

Initially, as in many projects that require a champion to pioneer change, the buyers and sellers presented a unified message to aid the users in their transition. The system integrator's project manager presented to the sponsor and management monthly and to the users quarterly. That was until the sellers were prevented from meeting with the project sponsor. The COR and CO reviewed the seller's presentation in advance and once issues were noted, the sellers were prevented from presenting the project status. The buyer's senior managers became transparent. As the project atmosphere changed and client relations became strained the pendulum swung in the other direction. Now instead of the users running the show, the CO ran it.

Additionally, from the seller's point of view, when the system integrator's PM notified her senior management, on multiple occasions, of serious project issues, they took no action for nearly a year. In fact, she was prevented from providing a realistic schedule estimate to the Systems Integrator's CEO during monthly project reviews because the completion date was so far from the original estimate.

Stakeholders must accept their roles and responsibilities.

• What if the prime contractor had been in control from the beginning?
• What if the buyer's management had made the tough decisions instead of defaulting to the users?
• What if the buyer's and the seller's management had listened and resolved issues?

Case Study 3: Is that a requirement?

As in the original imaging project, this project's software development model used an iterative approach where capabilities are added into successive software releases and buyer input was encouraged to refine the user interface and workflow process. However, unlike the original project, there were many document deliverables developed in parallel with the application and an exhaustive set of requirements.

The buyer routinely rejected document deliverables, requesting minor changes. A reconstructed timeline showed that feedback was often late, sometimes as late as a month after the document's last delivery. Additionally, after the original changes were incorporated and the document redelivered, further modifications were requested on the original text as each functional user group provided their input. There were no checks and balances; change recommendations were blindly passed through to the seller as the users learned what was available and determined what they wanted.

All the while, the prime's and the buyer's contract officers renegotiated the terms of the contract to base payment on specific system and documentation deliverables rather than on project phases. As users perpetuated the change review cycle, deliverables were not approved, catching the eye of the prime's contract executive.

A detailed system requirements document existed, based on the buyer's previous attempt for a similar system. Although the system requirements were documented, they were only gleaned during the proposal phase and not thought to be contractually binding. However, they were. The buyer and prime contractor had included the original system requirements in the contract; this was confirmed by the system integrator well into the project (~ nine months). All while the seller vetted requirements with the users during meetings and capability demonstrations!

The capabilities defined in the requirements were out of date, from a technological and user interface point of view. For example, since the original requirements document was written (affectionately known as the 3" binder) graphical user interfaces and point and click applications had become the norm. Accepting that a picture is worth a thousand words, requirements should identify what needs to be done, not how. In addition, the original requirements document did not address the ATM network, the connectivity required by the additional site, or the installation of the new servers, workstations, and scanners.

While the commercial software licenses were delivered in the third month and the seller recognized the resulting revenue, only limited operational capabilities existed for those users in the beginning of the workflow after the first six months. Work-arounds were in place, the system delivery was behind schedule and the buyer was losing confidence in the seller's ability to deliver. In addition, about nine months into the project, the developers, frustrated over incessant changes and what they perceived as an antiquated system, implemented a solution requested by the users - although they knew it wouldn't work.

Already concerned, the buyer continued to hold steadfast, taking the stance that everything was a requirement. Therefore, there were no change requests so the prime's proposed engineering changes were rejected. Only through regular software demonstrations were the buyers able to regain their confidence. And during these demonstrations, all the stakeholders were focused on and managed to the requirements.

Should development have stopped to re-plan?

• Early in the project, before the prime's PM joined the team, the prime suggested that everyone stop working to re-baseline the project. Perhaps this wasn't considered seriously enough because it is difficult for small companies, like the systems integrator and product developer, to stop work as it usually results in re-planning and shifting workload and personnel off of and back onto the project team.
• Later, it was confirmed by the prime's contract executive that the team had to "keep working the project", although it was permissible to significantly reduce the number of staff.

Project Summary

What started out as an 18 - 24 month project lasted nearly four years; however, the requirements for the last phase were mutually agreed upon. While the prime contractor, systems integrator, and product developer had prepared for legal action, all parties ultimately agreed on a settlement. The buyers and the sellers were able to move forward through the problems, ultimately resolving them together. Not only are the users trained and the document imaging system operational, the client is satisfied and the sellers are asked to continue providing their services.

There were many lessons learned, not the least of which is to manage the project as the contract would dictate. In other words, what began as a "T&M managed" contract ultimately was managed as a FFP contract with a serious emphasis on managing requirements - as it should have been from the beginning. Project managers and company contracts organizations must collaborate and be keenly aware of what is in the contract, what is legally binding. Key company and project team members must know whether referenced system requirements are merely guidelines or hard fast requirements.

There is no substitute for following sound system engineering principles and practices. Systems engineering processes support scope management by managing requirements, system design, and changes. Not only would formal requirements and design reviews have provided a baseline or reference point from which to move forward, they would have enabled communications between the project stakeholders. Once a baseline was established, an institutionalized change management system would have enabled the monitoring and tracking of defects and enhancements and prevented (or at least minimized) gold plating. Risk management could have provided insight into the project as well as a forum for communicating issues and risks amongst all the stakeholders - without the ramifications of any one person being the bearer of bad news. The project circumstances may have been significantly different if the rejection of the CONOP had been identified as a potential risk.

Lastly, all stakeholders must accept their roles and responsibilities. The prime contractor could have been held accountable for their lead role rather than allowing others to step in and fill a void. Management is often responsible for making the tough calls and had the buyer's management done that, rather than continuing to defer to the users, the government may have made more substantial gains from an efficiency and technological point of view. It is often harder to stop, reassess the situation, and change direction as necessary than to continue along the path of least resistance. But often that is exactly what needs to be done, from an organizational and project point of view.

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.

2004, Ellen Wagner Originally published as a part of 2004 PMI Global Congress Proceedings - Anaheim, California

From The above Case Study Answer the following questions including solutions, Recommendations and conclusion

• Discuss the importance of scope management as stated in the case in your own words.
• What would have the case organization done better to ensure proper scope management?
• Have the stakeholders been engaged (yes/No)? Support your argument from the case.