CHAPTER 5

Project Management Execution

Successful projects produce measurable value to the customer by delivering capabilities needed to fulfill a mission or strategy of the business or organization. These capabilities are assessed through their Measures of Effectiveness. During the execution of the project, process provides guidance for the principles and practices needed for success. In this chapter, we will execute three simplified, hypothetical, but real-world projects to see how to apply the principles, practices, and processes across each project: (1) a simple project using commercial off-the-shelf products, integrated into a system; (2) a tailored project from components, installed in a customer framework; and (3) an enterprise system integration project:

1. A Personal Unmanned Aerial Vehicle (UAV). Using commercial off-the-shelf parts, the Internet community, and some mechanical, electrical, and software skills, a UAV capable of flying around a park, following a person on a bike, and taking video can be assembled for under $1,000.

2. A Kitchen Remodel. For a fifteen-year-old house that currently has a “builder grade” kitchen: Using a kitchen designer and a general contractor, we want to replace the old kitchen with new “everything,” while minimizing the structural impact on the home. A typical kitchen remodel, with top-shelf built-in appliances, and name-brand gas range and oven, really nice countertops (granite), hardwood floors, a wine bar, a coffee bar, and really cool light runs around $60,000. So this is a nontrivial investment for most homeowners. Managing this project is important to your pocketbook as well as to marital relations.

3. A Health Insurance Provider ERP System. A collection of legacy IT applications will be consolidated in the commercial offthe-shelf product by migrating existing providers and clients to the new system, while maintaining the operation of the legacy system. An “off-the-shelf” claims processing system, with integration of legacy systems, a moderate amount of customization, migration of all the legacy records, training, rollout, and go live will run about $100 million for a large insurance firm with several billion in revenue. This is a serious project, one that “bets the company” on its success. Proper management is a critical success factor for all involved.

Each project will apply the Five Immutable Practices, guided by the Five Immutable Principles, using the Five Processes. We will use them to develop the results for each of these projects. Each principle, practice, and process is presented for each project so you can see how each is applied to the project and how the three elements work together to create a successful result. Each project will offer a complete solution, with an end-to-end outcome. For comparison, figures at the end of the chapter will connect the dots between each of the principles, practices, and processes across each project. But for now, let’s focus on one project at a time.

Before we start, let’s look at Figure 5.1, which connects the principles, practices, and processes and see how they can be tailored to fit the domain, paradigm, and needs of the three sample projects.

In Chapters 2, 3, and 4, the principles, practices, and processes were presented as lists of elements with their outcomes. In this chapter, we will describe the three projects using a “storytelling” approach. This is a powerful concept used in many domains, under different names. On large government programs, the Concept of Operations (ConOps) tells the story of the characteristics of a proposed system from the point of view of an individual who will use that system. Its purpose is to communicate the quantitative and qualitative characteristics of the system to all stakeholders. These capabilities describe what the stakeholders can do with the outcomes of the project to improve their business or fulfill a mission.

FIGURE 5.1 Relationships among the Five Principles, Practices, and Processes.

In software projects, use cases and scenarios tell the story of the series of steps to be performed by the system and the participants to accomplish some outcome. Without this description of the capabilities, the customer has no way of knowing if the technical and operational aspects of the project will be of any value. In the end, without a clear and concise narrative or graphical description of what capabilities will be delivered and how these capabilities provide value, no one on the project knows what “done” looks like.

In our kitchen remodel project, use case and scenarios would not be particularly useful. Neither would a Concept of Operation. In this case, the interactions between the “equipment” and the user provide the best description of what capabilities are needed. The “user” is the cook, the outcome is food and beverages, and the guests of the dinner party are the consumers of those products. This is an experience-based statement of the needed capabilities, rather than a technical or operational description. The UAV and ERP project have more of a technical and operational approach, since they are both heavily dependent on technical performance for their success.

So let’s get started by telling the story of our first project, the personal UAV.

Personal Unmanned Aerial Vehicle

A recent newspaper article told a story about a film company using an unmanned aerial vehicle (UAV) to photograph our downtown pedestrian mall for advertising. This story also described farmers using UAVs for cattle tracking, crop surveillance, and spot spraying. UAVs are used for inspections of chimneys and roofs, cooling towers, power lines, and wind turbine blades, as well as for construction progress photography, preconstruction surveys, wildlife filming, and sports coverage. These machines can be purchased or assembled from parts. This sample project calls for assembling a UAV from parts. It will be used for making videos of our cycle club members riding their mountain bikes on local trails. The FAA does not allow personal UAVs to fly higher than 400 feet above ground level (AGL), and they must stay in sight of the operator, so we’ll establish that as a “hard” requirement. Our UAV will be autonomous while following us, so technically we are the “operator” with an abort and land immediately switch.

“Done,” Capabilities, and Organization

We want a small helicopter UAV that can take high-definition (HD) video of us riding our mountain bikes, follow us on the trails after being launched, and fly for an hour and land safely. Once on the ground, we want to upload the video to our laptop so we can see and post our beautiful ride and amazing single-track cycling skills on the web for all to see. We could buy a $250 device that can do some simple things, but it will be more fun to build one from scratch using our hardware, software, mechanical engineering, and project management skills.

Because this is going to be a personal project, organizing it is simple. A small group—maybe two or three—of qualified people will be on the team. We will pool our money with a target budget of $750 for a fully functioning UAV with all the features we could ever want. Our skills need to be focused on the assembly and configuration rather than design and development, since all the parts can be purchased from standard sources.

The project will be “done” in stages:

1. Identify suitable components that can be assembled into a functional UAV. This includes the airframe, propulsion system, power system, flight software, ground control software, camera, GPS (Global Positioning System) needed for guidance, and the remote control hardware and software for flying the UAV.

2. Assemble these parts into a workable UAV and confirm they all work together reliably and provide all the capabilities as advertised by their suppliers.

3. Learn to fly under manual control in the park, without crashing too often. These flights will use the stability control, so once the UAV has been assembled, trimmed to fly straight and level and can follow the commands from ground control, the “pilot” should be able to control the UAV with ease. The stability control software and hardware allows the pilot to concentrate on moving the UAV around the park without worrying about wind gusts upsetting the aircraft.

4. Add the camera and the GPS navigation module and we’re ready to try autonomous flights in the park. Program the autonomous software to fly around the perimeter of the park and come back and land in front of us. This mode works using the GPS to sense where the UAV is in both altitude and position over the ground, just like the GPS mapping capability in a car or your smart phone.

5. Learn to define the track for the desired route in order to add “locator beacon” hardware and software so the UAV can follow a moving object on the ground.

6. Have the UAV follow us around the perimeter of the park for more testing and integration.

7. Add some simple command signals to “land,” “hold position,” “come home,” and try out the UAV outside the park.

These capabilities need to fit inside a $1,000 budget. Our “team” needs to agree who rides the bike with the locator beacon, who controls the launch and monitoring of the UAV, who takes notes on what went wrong, and as a team how we are going to take steps to improve the outcomes. We are all engineers either by profession or experience, so working in a team comes naturally.

Since there are working examples of commercial UAVs for farmers, power companies, and other uses, we know it can be done. We just have to stick with the project long enough to make ours work as well. This means we need to seek the guidance of others so we don’t have to discover all the problems by ourselves. Radio controller airplane clubs are the place to start. People with experience in the UAV hardware and software are another. And they can be found on the web in forums for UAVs.

Getting to “Done”—Requirements, Planning, Scheduling, and Budgeting

For our mountain biking needs, an autonomous video-equipped UAV is a well-defined project with clear and concise capabilities, requirements, and an easily developed schedule and budget. Why? Because there are numerous examples of these types of machines commercially available. They range in price from $1,000 to tens of thousands of dollars. All we have to do is look at the capabilities, configurations, and lists of features and decide what we want in our UAV.

Nevertheless, there are several incremental approaches here. The first is to film “downhill” riding. This is a short course, where the rider follows a path down a steep mountainside, with jumps, turns, and more jumps. The dimensions of the course are fixed and can be entered into the UAV’s GPS navigation software. The UAV would “hover” over a spot, detect a rider coming, and follow that rider down the hill. The trail-following UAV needs more sensors to know the trail, follow the rider, and avoid obstacles, like trees, that might be in the way.

So let’s start our list of technical requirements and develop a plan to deliver them:

First is the ability to launch the UAV and have it follow us autonomously. Out on the trail, there is no room for a “pilot” to start the flight launch process. We ride narrow tracks (single track) in the mountains, so the UAV has to be able to know where we are, follow us as we ride, and land safely when we reach our destination. This capability will have to be developed incrementally, so the technical features can be added incrementally as well.

The first technical requirement is to develop a platform that can be flown under remote control, like any other remotely controlled model airplane. Stability control is the key to this. Flying a helicopter UAV without built-in stability control results in a very short-lived vehicle, because it will crash often. Once stability control is installed, the UAV moves from being a backyard toy to a platform for doing real work.

The UAV has to have an HD video camera with enough storage to hold enough imagery to make the result interesting—at least fifteen minutes of riding.

Because the UAV is battery powered, it must be capable of flying, videoing, navigating, and landing for a reasonable amount of time on a single battery charge—twenty to thirty minutes.

Navigation and tracking also need to be sensor driven. A locator beacon is one option. Another is map following. Most mountain bike trails are available from popular mapping sites, complete with elevation charts and details of the trail.

Resources, Performance Measurement, and Cost Accounting

Our UAV project’s resources consist of suppliers and the tools needed to assemble and test the result. This is a small project that integrates high-technology components, guided by the assembly instructions. The primary resource is the “customer support” technicians for the purchased components. This is a selection criterion for some components. The Internet is the first place to look, not just for the components but also for the ratings of the customer support of each supplier. This concept can be extended to almost any “off-the-shelf” procurement. In the end, customer service is likely to be the most important “product” that is purchased in mature product domains.

The budget for our UAV is straightforward and connected directly to the capabilities. The more we pay for something, the more likely it is that “something” will have better performance. So our cost accounting starts with an upper limit on the budget, and an allocation of that budget to the needed capabilities.

We need:

An airframe that holds the propulsion system and the power source. Can’t fly without propulsion and power.

The first-tier flight controls. These include the remote-control system, which gives directional and lift commands to the UAV. With the airframe, propulsion, power, and remote control, we can start to learn how to fly before spending any more money.

We quickly learn that flying the UAV in the park under manual control is much harder than it looks, so our next purchase is a flight stability system. This includes some sensors, some more software for our “central computer,” and a few calibration and checkout processes. With our stabilization system installed, the UAV is much more controllable. It is a “fly-by-wire” machine now. We are flying the computer and the computer is flying the UAV, just like all other modern aircraft.

Next is a navigation module that uses GPS to find the path to fly. This module can be uploaded with a flight plan, follow that flight plan, and return to the landing zone. Now we are getting closer to the autonomous vehicle that can follow us around the park.

With that module integrated and tested, we now need a video feed so we can send back live pictures from the UAV flying around the park.

Impediments, Execution, and Performance Analysis

This project is about the assembly of commercial off-the-shelf components. The primary impediment to progress is the advanced understanding needed to select and integrate the components for the UAV. These impediments can be addressed straightforwardly—by reading the directions. This assumes we are qualified in this area, but that is behind us. We are hardware and software engineers with experience in integrating off-the-shelf components. This, of course, does not eliminate the impediments, but it does provide us with skills to deal with them. This is a critical understanding: If we are to manage a project, we should know something about the technology and how it is put to work to deliver a capability.

With our schedule for delivering the capabilities, we can identify the sequence of purchases, assembly, testing, and first operations.

Measuring Progress, Managing Risk, and Revising Our Plan

Progress measurement is straightforward. We buy parts from the web, assemble them following the instructions, run all the tests, and try out the assembled system in the park. Progress is measured by working capabilities—simple flying, stability control flying, flying a route, flying with a video feed along the route, following the rider with the “locator” while videoing the ride.

The primary risks involve the improper assembly of the parts, failure to read the instructions, and our low skill in actually flying the UAV. These risks can all be addressed through “learning.” These are reducible risks, with information we can find from a variety of sources. This information reduces uncertainty and the resulting risk. This information is usually free, which is not true for our next two projects.

Wrap-Up of the Personal UAV Project

The story of our UAV was simple: We want to build and fly a machine that can follow us on the trail, take videos so we can see what happened, do this for thirty minutes or so, all using off-the-shelf hardware and software. The skills of our team include software development, mechanical engineering, electrical engineering, and the ability to read instructions and debug the machine after we don’t follow the instructions.

The plan is simple; follow the instructions. Timing is simple; we have evenings and weekends to work on our project, no real deadline. This is a “hobby” project, but it does require organizing, planning, funding, and actual “touch labor” to get the UAV to work. There are no real impediments beyond our own capabilities. Since our team members all have “day jobs” performing the needed skills, there is little doubt we can get the UAV to work. Not learning to fly the UAV before we break it is the primary risk, but once the stabilization and autopilot hardware and software are installed, that risk goes down.

Kitchen Remodel

Our current kitchen is going on fifteen years old. It was a “builder’s quality” kitchen with builder appliances, a standard layout, and tract-home feel. We wanted an upgrade that made use of modern appliances, had a better layout within the framing structure of the home, and provided capabilities not found in the current design. At the start of the project, appliances were available that had much higher efficiency ratings. The prices for restaurant-quality cooking appliances were coming down, and the style of modern kitchens was moving from “cooking-centric” to “entertaining-centric” layouts, where the kitchen is the focus of the party, not the dining area.

What Does “Done” Look Like?

The answer is simple:

The old kitchen is gone and the new kitchen with new “everything” is installed without collateral damage to any other part of the house.

This is all done close to our planned budget and planned time frame.

What this really means is that once we decide on what the kitchen will look like, there will be no surprises, it will all be done according to plan, and the “stakeholder” will be happy.

“Done,” Capabilities, and Organizing the Kitchen Project

When spending your own money, one good question to ask is, “Why are we doing things?” Once we decided to move forward with the remodel project, these capabilities were the focus of our efforts:

Space, access, and flow to host dinner parties for twelve couples, members of our supper club.

Appliances that exceed the energy savings guidelines of modern kitchens.

The ability to cook three main courses at the same time in the same room for large dinner parties.

Increased storage for cooking utensils and serving dishes.

With these capabilities, the next step is to organize to get the kitchen done. This begins with:

Engaging a kitchen designer to help us select cabinet styles, colors, and layout.

Engaging a general contractor (GC) to provide all the work except the installation of cabinets and appliances. There will be demolition work as well as installation, so coordinating all the subcontractors, including the kitchen designer, is needed to ensure that everyone knows the proper roles and responsibilities, has availability to work on this project, has the same quality standards, has all the licenses and permits needed to work on site, and agrees on the business arrangements. The GC is the single point of contact for this project. Financially, the GC might not be the only direct pay resource, but the GC is in charge of how the work is planned and executed.

The kitchen remodel organization is straightforward:

A general contractor is going to do the heavy lifting for the construction.

A few subcontractors are involved, including a cabinet designer, appliance supplier, and countertop supplier.

The trades, such as electrical, plumbing, and flooring, are provided through the general contractor, are managed by the GC, and provide their services in a transparent manner.

Last, there are the stakeholders. In this case, there is only one stakeholder—the “monarch” of our kitchen.

Getting to “Done”—Requirements, Planning, Scheduling, and Budgeting

The kitchen remodel is a straightforward project, ignoring for the moment any unforeseen complications. It is assumed that we will not rearrange any of the structural aspects of the kitchen in this project, which means we will leave the structural walls where they are, leave the plumbing for the most part where it is, move utility electrical around to be more convenient, and upgrade the appliance electrical to better fit the modern code. The requirements for the contents of the kitchen and the planning and scheduling start with the following:

Picking out cabinets, appliances, countertops, backsplash, flooring, plumbing fixtures, and a bunch of detailed “gadgets.”

Deciding when we need the final kitchen and working backward six to eight weeks. The work starts with the demolition of the existing kitchen, so we need to also decide where to cook in the meantime.

Starting with the cabinets, because they are the “signature” of the kitchen. This means engaging a cabinet designer once we’ve seen sample kitchens we liked and have narrowed down the style and general color and finish.

Resources, Performance Measurement, and Cost Accounting

Now we’re getting to the hard part, at least for this project. There is a budget for the kitchen. There is some margin in the budget, but there is a “not to exceed” cost. Resources may be a problem, because special skills—cabinet installers—may be hard to come by. General tradesmen are usually available. Countertop tradesmen are usually more specialized, and we wanted some unique features, so the general contractor was assigned the task of using his best people for that. Appliance consultants are provided by the appliance vendors, so that’s simple; the same holds for lighting and plumbing fixtures. The resource plan is straightforward again:

Cabinet shop has designers.

Plumbing fixture shop has designers that can connect with the cabinets for color and style.

Appliance store offers options for every appliance—range, oven, microwave, refrigerator, freezer, and the ever-critical wine cooler. It was decided up front to have a separate built-in refrigerator/freezer.

Performance measures of the kitchen crew start with the planned completion date and the incremental completion of the components of the kitchen. “Demo’ing” the existing kitchen must be done first. The schedule for that drives the rest of the job. The budget for all the work was worked out in advance, with margin for both cost and schedule. This is usually a “not to exceed” type budget. The costs of materials, appliances, and other tangible items are easy to determine. The surprises found during the work are not. For that, we’ll need budget margin within our “not to exceed” number to cover these overages.

Impediments, Execution, and Performance Analysis

Impediments to progress are, for the most part, easily identified. No permits are needed because there are no structural changes. Lead times for appliances are reasonable. Lighting and plumbing fixtures are in stock. Prices are established within tolerance ranges, so the budget looks credible. Labor estimates are credible, since each craft has done kitchens like this before.

What is unknown is what is behind the wallboard in the current kitchen. This is a semi-custom house, built at the height of the building boom, by crews that came and went without a lot of continuity. So when the wallboard is ripped off, we’ll see what’s underneath and how much impact that will have on cost and schedule. On the actual project, it turned out that the floor joists for the upper floor were going the wrong way, so the vent for the range hood had to be specially built, because it had to run through four joists to reach to the outside wall. The wall behind the range was not to code—too narrow—and the gas line and oven back intruded into the wall. Also, the existing pantry had a return duct intruding into the space that had to be modified so the cabinets that replaced the pantry and the separate built-in freezer would fit flush with the cabinet depth.

Could these impediments have been known before we started? Probably not. You have to rip off the wallboard to see these code violations. The same was true of some electrical code violations that required repair.

Measuring Progress, Managing Risk, and Revising Our Plan

So we have a plan, a budget, and a firm idea of what the final kitchen will look like. We are convinced it will provide the needed capabilities when done, so let’s go to work. Use the planned sequence of work—empty the current kitchen, remove the appliances, demolish the cabinets, rip the wallboard off—but first close off the kitchen with plastic to protect the rest of the house from the huge mess the work will create.

With the cabinet plan, measure precisely the fit of the upper and lower cabinets along the wall. Measure twice, even three times, because once the cabinets are ordered we’re committed. The same is true for the built-in appliances. These are counter depth, ordered from the dealer, but built in Germany. The sizes are standard, but the door fronts—so they look like cabinets—are custom-made by the cabinet shop. Electrical and plumbing layouts for the refrigerator and freezer have to be defined—once they are installed there is no “uninstalling” or moving them. They are “built-ins,” and that means permanent built-ins! Wine refrigerator is easier, because it can slide out from under its countertop.

Countertops are another sensitive topic. There are hundreds of choices of stone: granite for the perimeter countertops, something more unusual for the island. Cost for granite is controlled by the volume of stone in the quarry: the more stone in the ground, the lower the price. It is a pure commodity pricing strategy. So find something that fits the design but is low cost, and spend the rest on a smaller piece, but more expensive. So find the right combination of “common” and “unique,” engage the firm that will finish and install the countertops, and schedule the workers to come once the lower cabinets are installed.

Demolition is simple, just like on TV. Get a sledgehammer, swing away, don’t hurt yourself. Try not to ding the hardwood floor even though it has to be refinished. Electrical boxes can be relocated now, new wiring pulled, drains and water feeds moved to the right places, and “ugly” pieces of the room cleaned up.

Wrap-Up of the Kitchen Project

The complexity of the kitchen project is more than the UAV, but still low compared to the next project. No structural changes, no major electrical or plumbing other than cleanup, semi-custom cabinets, picked out of a catalog, appliances picked out of a catalog as well, everything else “store-bought.” Work processes are serial—rip stuff out, fix what needs to be fixed after stuff has been ripped out, install new stuff, hook it up, test it out, clean up the mess. The principles, practices, and processes for managing a kitchen rebuild type of project are straightforward:

Develop an overall “look and feel” of the kitchen, the style of the cabinets, colors, and trim. Decide on the appliances and other fixtures. Confirm the layout and capacities of the equipment that can be the foundation of a moderate-sized dinner party, and the primary stakeholder will be happy in the long term with all the choices.

Select the right contractors, who can work with each other, understand the goal of the kitchen, and are available for work.

Prepare for any delays once the walls are exposed, and have solutions, including workarounds, to keep the project moving.

Plan progress measures in “big chunks.” Kitchen emptied, wallboard removed, electrical and plumbing corrected, wallboard back, cabinets installed, appliances installed, countertops installed, all finish work complete.

Health Insurance Provider Network Application Migration

We’re on the third of our three sample projects showing how to tailor the principles, practices, and processes of Performance-Based Project Management. This project is an Enterprise Resource Planning (ERP) project; in this case, an IT effort that starts with a collection of legacy applications that form the basis for enrolling healthcare providers in an insurance network. If we look back to Figure 2.2, we can see the “enrollment” process is needed early on as part of a larger conversion effort. The new system will ultimately replace the collection of legacy systems, but during the transition period, normal business operations will be conducted using these legacy systems. The project allows physicians and hospitals to “enroll” as healthcare providers using the insurance company’s benefit plan. Patients cannot be “provided” healthcare without the “providers” knowing that they are covered.

The focus of the project is not on the technology, but on the operational processes needed to deliver the project. The technology will be provided by a commercial off-the-shelf (COTS) product. Data migration, workflow processes, management training, customer training, and data integrity validation are all part of the migration process.

“Done,” Capabilities, and Organizing the ERP Project

Done for this project is easy to define. The legacy systems are replaced with a single integrated enterprise system capable of enrolled providers for 15 percent less than the legacy systems. It’s really that simple, even for a large enterprise IT project. To begin, write a few simple, measurable, clear, and concise statements describing what this will look like:

Replace legacy systems with an integrated system for provider enrollment.

Reduce transaction costs by 15 percent for end-to-end activities—from provider identification to provider payment.

Transfer data from all legacy systems to a single integrated database, while scrubbing providers’ network content to ensure that no provider is misplaced and all data are verified against all past transactions and providers.

Deploy web-based provider enrollment interface with the same baseline functionality, at the very least, as the heavier interface offered.

Deploy portable device interfaces for iOS- and Android-based tablets with the same functionality as the legacy system.

The core activity of this project is to determine the cost to stay on schedule as well as to verify that the delivered capabilities provide the planned value to the enterprise. So let’s start with confirming what “done” looks like and develop a plan, schedule, and budget to reach “done.”

With the legacy systems in place, the organization of the project is based on employing existing staff, processes, and technology. Our goal is to transition the existing technology to a new technology using the current staff. This requires subject-matter experts currently in place to guide the transition. Leaders of each business process are accountable for the activities needed to successfully make this transition.

Getting to “Done”—Requirements, Planning, Scheduling, and Budgeting

The description of “done” requires seamless transition from the legacy systems to the new system, starting with the provider network enrollment processes. This capability allows the business to start saving money while maintaining the same customer-facing interface. The challenge is to develop a clear and concise plan, schedule, and budget for getting to the provider network capabilities. This means we don’t need the full set of capabilities illustrated in Figure 2.2; rather, we can deploy these capabilities incrementally, allowing the business to take advantage of the capabilities as they emerge to deliver value from their investment. This does not mean the work is not done in sequence; it is. This is the planned delivery of incremental value to the customer that is the basis of all agile development processes. This notion of incremental delivery using Agile works in a variety of domains, not just software. Lean construction is one example popular today.¹

To develop a plan, schedule, and budget, we need to know what business capabilities are needed and how they will be implemented using the technical and operational requirements. The requirements are for technology and processes based on the technology that fulfills the capabilities. We begin by stating the capabilities in the form of scenarios or use cases, just like our other two projects:

Enroll providers in the new system using the same work processes as the legacy systems did.

Migrate all legacy providers into the new system with 100 percent transparency, meaning no provider will know there is a new system.

Once the new system is active, reduce the cost of enrolling a new provider by 15 percent compared to the legacy systems. This 15 percent reduction will come from lower customer support costs, transaction processing costs, error correction costs, and other operational costs associated with capturing, maintaining, and supporting the provider network.

Resources, Performance Measurement, and Cost Accounting

The acquisition and deployment of the technology can be handled by a systems integrator. The primary resources for this project are the subject-matter experts needed to ensure that the capabilities of the new system match those of the legacy system. This means the internal users of the system, those who operate the provider network management system, are the ones guiding the transition from legacy to new. These resources, of course, have “day jobs,” which means their normal operational roles in the insurance company must still be accomplished. Therefore, resource planning must address the utilization of the operational staff and their reduced availability for normal work. This might mean backfilling staff, possibly outsourcing many of the day-to-day functions to staff augmentation firms, and so on. Without these subject-matter experts, the new system will represent what the vendor thinks the system should do—or worse, what the system is capable of doing in the absence of any external guidance.

With the staff in place to guide the deployment of the new system, the measures of performance are straightforward. “The system works like the legacy system.” This means the processes, data, and outcomes of the new system are substantially the same as those of the legacy system. If the new system does not work like the legacy system, then that behavior must be benign. This approach to resource management is similar to operations management. The system being managed has to be operational in the end. So the resources must be capable of recognizing what operational means. These resources become the “owners” of the final system and, as such, become the “acceptors” of the capabilities of the final system.

Impediments, Execution, and Performance Analysis

The vendor doing the systems integration work now has the resources that can describe what “done” looks like. This removes many of the impediments to progress, as there is little room for interpretation of what to do or how to do it. The primary impediment is the availability of these resources.

With the subject-matter experts on the same team as the system integrators, measuring progress to plan means starting with the plan for deployment of the existing capabilities using the new system. This is done with the “make-a-list” methodology. We need a list of the current capabilities, evidence of what they do to the various elements involved in this activity, and the underlying processes used to produce each element. This starts with an as-is process flow for the legacy system and is a “build to” specification for the new system. The as-is process flow shows the people, processes, and tools used to perform the work of enrolling providers in the insurance network. An example of the as-is approach is shown in Figure 5.2.

FIGURE 5.2 As-is process flow in a provider network enrollment.

Measuring Progress, Managing Risk, and Revising Our Plan

Using an as-is process flow such as the one illustrated in Figure 5.2, we can define how to measure progress. Each of the work activities must be in place for the provider network to have the capability of enrolling new providers. A schedule of when those capabilities will be available for verification can then be built by the system integrator. For each of the boxes in Figure 5.2 (and these are notional boxes), the subject-matter experts can show in detail what is now being done on the legacy system and verify that the new system is doing the same thing. This is a side-by-side comparison.

The risks associated with this approach lie in the ability of the current subject-matter experts to recognize that the new system is performing its job as the legacy system does and that they can convey any differences to the system integrator. This is a challenge because the subject-matter experts may or may not be able to communicate the technical details of what they only know as “operational” aspects of the system. This risk can be addressed through an interpreter, meaning someone who knows the new system, can learn the legacy system’s operational aspects, and can work alongside the subject-matter experts to translate between the two systems.

Wrap-Up of the Health Insurance ERP Project

Modern enterprise IT projects usually start with a legacy system of some sort moving to an upgrade or replacement. Development of an IT solution “from scratch” is rare these days. Managing a transition project requires a careful approach to ensure that the result meets the business need, since the new system is usually based on a commercial off-the-shelf product. Customization of this product rarely returns value. Ensuring that the baseline capabilities of the COTS product meet the needs of the organization starts with the subject-matter experts defining the as-is processes and data. With this information, we can define the steps needed to replicate these processes and data in the new system as a baseline for the business operations.

Only then should new features be added. Making the transition to a new system, maintaining the continuity with existing users and adding new features creates unnecessary risk. A step-wise transition process ensures that the integrity of the legacy system is established before making it better. The new system can act as a platform for “making it better.”

Looking Back

We took a deep dive in this chapter into the practices needed for success and applied them to three notional projects here. The following checklist can be applied to any project. We begin with the principles:

Define what “done” looks like through storytelling.

Show how we are going to get to “done” on time and on budget.

Confirm that we have enough resources to reach “done.”

Identify any impediments that might be encountered along the way to “done,” and specify how you are going to handle them.

Determine how you are going to measure physical percent complete to ensure that progress is being made to plan.

Figure 5.3 illustrates how these principles were used on each of our three sample projects.

Next, we need to apply the Five Practices to the project:

Identify the needed capabilities by listing what outcomes are required to implement your “story.” What does the customer want the results of the project to do? These are the capabilities. The capabilities to process transactions at a lower cost is a capability. The ability to follow the rider on the trail is a capability. The ability to entertain thirty guests is a capability. These are the “reasons” for the project.

Identify the baseline requirements using the technical and operational terms found on the project. These used to be called “feeds and speeds” in the mechanical world. Now with software intensive projects, except for the kitchen remodel, we need other words. Each technical and operational requirement must be traceable to a needed capability. Capabilities without requirements to fulfill them are widows. Requirements without a reason for being there are orphans. Technical and operational requirements are fulfilled by products and services. Transaction speed and cost, square footage for sitting and standing space, bandwidth and tracking signals are all technical or operational requirements.

FIGURE 5.3 Five Principles of project success for unmanned aerial vehicle, kitchen remodel, and health insurance provider projects.

Develop the Performance Measurement Baseline by agreeing on the duration, roles, budget, outcomes, and how progress is going to be measured. “Plan the work and work the plan” is the overused phrase. But this is exactly what the PMB does for us. Without a plan we can’t see where we are going and we can’t recognize done when we get there.

Execute the Performance Measurement Baseline by following the plan. Perform the work in the planned order, try to stay on budget, use the planned people for the planned work, and measure progress with tangible outcomes, not effort and cost.

Perform Continuous Risk Management on all the work activities in the Performance Measurement Baseline.

Figure 5.4 illustrates how these practices were used on each of our three sample projects.

With the principles and practices in place, we need a governance process framework for managing the project:

Organize the work and the resources performing the work by stating up front who is needed and when they are needed.

Plan, schedule, and budget the work with simple or complex tools suited to the project. Write it down. Even sticky notes on the wall of the garage can be used for plans, schedules, and budgeting. Larger projects require larger tools—that’s the only difference.

FIGURE 5.4 Five Practices of project success for unmanned aerial vehicle, kitchen remodel, and health insurance provider projects.

Account for all the costs in performing the work by keeping track of the budget and the expenditures. It’s that simple. Again, it is only a matter of scale. But this accounting process is not a measure of progress. It is only a measure of money planned and money spent.

Analyze the performance of the work. That old phrase, “If you don’t know where you’re going, any path will take you there,” is not true. If you don’t know where you are going, you are lost. Measure progress with tangible evidence of the outcomes on the planned date for the planned budget.

Make any needed revisions to the plans, budgets, or schedules for the work.

Figure 5.5 illustrates how these processes were used on each of our three sample projects.

Some General Observations

Project success, of course, starts with knowing what “done” looks like, how to get to “done,” and the impediments along the way to “done.” This last piece is critical. For each of our sample projects, the impediments can be discovered through the effort of others. There is no reason to do it alone or from scratch. Instead, find similar projects, and learn from them; try to understand the reasons for their success or failure.

The same is true for the requirements, plans, schedules, and budgets. Rarely is a project the first of its kind. Look around to see if there are similar projects. Search out the people who worked on those projects or any documentation from those projects in order to learn from them. This is one purpose of project management forums and the Project Management Institute (PMI) chapters. Sharing knowledge and experience is what project managers should do. This is a risk-reduction process. Learn from the mistakes and successes of others and pass that information on to others.

FIGURE 5.5 Five Processes of project success for unmanned aerial vehicle, kitchen remodel, and health insurance provider projects.

What’s Ahead?

With the principles, practices, and processes developed and applied to three sample projects, with a deep dive into the practices, we are now ready to look at the artifacts that are produced by Performance-Based Project Management. These artifacts start with the Statement of Work, which describes the items to be delivered. This can be a simple list of things the project will do, like those developed for the UAV project. Or this can be a more formal document in the form of specifications for operational and technical capabilities.

For any project to have a chance of success we need a plan and a schedule. The schedule shows us the path to reach “done,” what work needs to be performed along the way, who is doing this work, and how much it is going to cost. Building this resource-loaded, budgeted schedule sounds like a lot of work, but without it we do not have visibility into the resource and funding risks associated with the project. Since we are spending other people’s money, this is an important attribute for the success of our work. Once we have identified the risks, we need a Risk Management Plan, a Risk Register, and a connection to the schedule for handling these risks.