Great Lessons in Project Management

David Pratt PMP

• Publisher: Berrett-Koehler Publishers
• Year: 2015
• Print ISBN: 9781567264722
• eBook ISBN: 9781567264739
• Edition: 1
• Topic: Business
• Subtopic: Bibles
• Index: Business

Learn from Other Projects to Avoid Pitfalls on Your Projects! Projects fail at an alarming rate, whether they are information technology, training, construction, or policy development projects. No matter the focus, each year we experience an abundance of challenged projects that either require super-human effort to resuscitate or die an untimely death. Great Lessons in Project Management is a treasure trove of lessons learned from troubled projects—and from projects that went well. This collection of stories describes the events surrounding a particular challenge a project manager faced or a tool that another used effectively. Project managers of all types of projects can draw on these stories to validate their own good practices and to avoid the pitfalls so many have encountered on their projects.

SCOPE MANAGEMENT

1

If You Can See It, We Can Build It

There’s a saying in project management that goes something like this: “If you can see it, we can build it. But if you can’t see it, we’re not going anywhere.” Never was this more evident than in the case of a project to replace a hunting and fishing license sales system for a large state agency.

The agency derived much of its $350 million annual revenue from the sale of hunting and fishing licenses to the public. Its old system was scheduled for retirement in six months, and the contractor who hosted the legacy software application was eager to shut down that system and move on to other ventures. Unfortunately, the project to replace the old software application was failing miserably.

A project management quality assurance (QA) consultant was called to the office of the state agency’s IT director and asked if anything could be done to save the failing project. As a result of a series of communications and technical misadventures on the parts of both the agency and the legacy system’s host, continuing the relationship with the old vendor beyond the remaining six months was not an option.

The agency was in dire straits. The system replacement project needed to be fixed, pronto, or the agency stood to lose a large piece of its annual budget and face the wrath of constituents who would not be able to get their hunting and fishing licenses on time.

The project manager for the “stuck” effort reported directly to the IT director. The IT director believed that the reporting arrangement was inappropriate, and that the project manager should be more closely aligned with the business unit that operated the system being replaced. The IT director recommended to management that an external QA consultant be retained to provide an objective review of the situation and make recommendations for remediation.

The QA consultant listened to the IT director’s story and concluded that the situation was, in fact, dire. When he asked to see the project’s charter, schedule, and other project artifacts, the IT director frowned and said, “I wish I could give them to you. They simply don’t exist. There’s a requirements list somewhere, but the vendor hasn’t acknowledged it and is ready to deliver the new system even though we have not agreed to what the new system will provide. We have no idea if the new system will meet our needs. Everyone is frustrated.”

The QA consultant next paid a visit to the project manager. He expressed as much frustration as the IT director, but put a different spin on the situation. The project manager thought the project’s goals and objectives were obvious: sell hunting and fishing licenses to the public and capture the revenue from those sales. He believed the vendor responsible for delivering the replacement system should, as presumed experts in the industry, know what the system needs to do to support the agency’s needs. The project manager felt a charter simply wasn’t needed for the project because the outcome was so obvious.

When the QA analyst posed specific questions about the solution the project might deliver—reporting requirements, accounting, how the new system would improve business for the agency, who was to be involved in defining those solutions—the project manager expressed a heightened level of frustration.

“The vendor should know those things,” he stated. “They signed up as experts in the industry, as well as expert software developers. Even if I did feel it was necessary to provide them with the detailed requirements for the project, I would not be able to do so. I don’t know who the stakeholders are who would help me with that. The business manager works with the vendor and handles all that.”

“What has the sponsor told you about the project situation?” the consultant asked.

“Sponsor? I don’t know who that person is,” the project manager replied. “I work for the IT director. I guess you’d say he is my sponsor, if anyone is.”

Undaunted, the QA consultant identified several members of the agency’s staff who were responsible for the system’s operation and visited them at their desks. When he asked them what they thought the new solution should look like, their responses differed markedly from the project manager’s description.

“We need a system that not only sells licenses to the public, but that also provides rich reporting of our sales areas so we can improve service to our customers,” one replied. Another added that the agency’s scientific staff and enforcement arm would benefit from the information the system gathered if it could identify where people were likely to fish and hunt as well as the species in which those purchasing the licenses were interested.

A system user from the agency’s finance and accounting office suggested that the greatest requirement for the new system is to record income and expenses in a way that integrates with the agency’s finance and accounting processes. “Without that capability,” she said, “the system will be practically worthless. We won’t know if we are financially afloat or sinking until it is too late.”

Armed with the information gleaned from the interviews, the QA analyst stopped by to meet the project sponsor—the person responsible for the agency’s licensing business. She had been with the agency for four months but had never met the project manager. She expressed her own goals for the project and system very clearly. “It’s simple,” she said. “I want the project done on time so we can collect money to keep this agency afloat. When the 12 months are up, our old system will be shut down. We’ve burned our bridges with the old system’s vendor and there’s no way they will keep it going beyond that date. This project must come in on time.”

The QA consultant leaned back in his chair. “Everyone in your organization shares that goal,” he said. “But they all have different views of what’s important for the new system to provide. There’s no consolidated vision, no consensus on the project’s focus or on what the agency needs the system to provide.” He went on to describe to the project sponsor the different views related to him by the IT director and the project manager.

The project sponsor sighed. “But I can see it so clearly,” she said.

“Maybe that’s the problem,” the QA consultant replied. “You can see it, but the rest of your team remains unaware of your vision. Without a consolidated, universally accepted vision, they are each naturally migrating toward what seems important to them. It’s like holding a compass in your hand while you’re standing in the wilderness in the dark. Lacking specific direction or orientation, you have 359 opportunities to get lost.”

The project sponsor grew thoughtful. “How do I fix this?” she asked. “We need this project done on time.”

“Let’s try an exercise,” the consultant suggested, powering up his laptop. He reiterated how simple yet important a project vision statement can be. A good vision statement, he explained, answers four questions:

1. What does the final solution look like?

2. Who will be affected by the new solution?

3. How will things be different once the solution has been implemented?

4. What value will the solution provide?

The sponsor responded quickly. “The first answer is obvious,” she said. “It’s an IT project, producing an information technology system to sell fishing and hunting licenses to the public.”

“Is that really all it is?” asked the consultant. The sponsor sat back in her chair, all ears.

“It’s a common mistake, particularly with IT and building projects,” the consultant continued. “Let me ask you a few questions: Will the sellers of those licenses need to be trained? Will agency staff need to be trained to use the information produced by the system? Will your organization’s business processes need to be modified to support the new system, or will the system be designed to support your existing business processes? Is your agency’s infrastructure adequate to support the new system?”

“I see what you mean,” the sponsor replied. “When you get right down to it, this project addresses all those things. It’s clearly more than an IT project.”

The consultant nodded. “IT projects generally work out that way. There’s no such thing as an IT project; there are only business projects with large IT components. Let’s get the answer to the first vision question nailed down.”

He followed up with a few questions about the first of the four essential elements of a good project vision statement:

1. What the solution will look like: The new system will be an off-the-shelf software package that supports selling fishing and hunting licenses to the public through retail outlets, which will retain a portion of the fees for handling. The solution will record sales and run them through the agency’s financial system; it will then provide data from those sales to support the scientific investigation of wildlife and fishery populations and trends. The system will provide management reports and access to data for use in decision-making processes at the agency and business unit levels. The sellers and agency staff will receive training to ensure that the system integrates effectively with existing business processes. To avoid the need to build a customized system, those processes may require modification to integrate the capabilities of the software package with the agency’s business needs.

The sponsor smiled. “That’s a much broader picture than I had in mind, but I see how it fits.”

They then turned to the second essential element of the vision statement: Who will be affected by the project’s solution? The consultant recorded the sponsor’s words as she talked and read back the following response:

2. Who will be affected by the project: The new system will impact the retail sellers, the agency’s business office, finance and accounting office, and staff scientists who use the data for their studies. The sales system will also directly impact the public buying the licenses and the agency’s enforcement staff.

The third element of the vision statement identified how things would be different once the agency implemented the solution. The project sponsor jumped right in with her view of her project:

3. How things will be different once the solution has been implemented: The new system will be easy for the retail sellers to set up and use, and it will include self-instruction so that agency staff remains focused on their work, freed from the current deluge of questions posed by the media and the public. Web-based, the system will interface wirelessly with the agency’s infrastructure, allowing set-up and support functions to be carried out with ease. Relevant data will be available in near real-time and the agency’s financial position will be apparent on a daily basis, with timely access to decision-making tools. Public access to eligibility and game records will be provided online, increasing ease of use and reducing calls to the business office staff.

The project sponsor then eagerly offered, “I know the answer to the last question, about the value the solution will provide to the organization.” The consultant typed as the sponsor spoke:

4. The value the solution will provide to the organization: The new solution will increase revenue flow, enhance access to information, reduce business office calls, and free up staff for other duties. It will create goodwill with retailers and the public, enhancing the agency’s reputation.

The consultant printed out two copies of their notes. As they read them together, the sponsor smiled. “I don’t think I ever realized the true scope of this project,” she said.

The consultant replied, “Imagine the difficulty your team faced in the absence of a clear vision statement. How could your project manager and project team meet your expectations without a clear description of what you expected from the project? If you, as the project sponsor, can visualize the solution clearly, your team will likely find a way to build it. Without understanding your vision, the team will be thrashing around without any true sense of direction.”

The consultant slid his copy across the desk. “Now, sign it. Your signature will let everyone in the agency know that you own this vision statement and that that they can count on what it says as they plan and execute the project over the next few months. You have a very short timeframe for delivery of the new system and all that goes with it. Your team needs all the help it can get from you.”

The sponsor scribbled her signature at the bottom of the page. “What now?” she asked.

“Take your vision statement to the project manager. I’m thinking he will be pleased to meet you and see this document,” the consultant replied.

The project manager received the vision statement with enthusiasm when the sponsor approached his desk with the QA consultant at her side. “Thanks,” he said after scanning the brief document. “It’s a relief to get this from you and to meet you. With this document, I can see clearly where we’re headed. I may have more questions for you later, but right now, I have a lot better idea about what it is you want from the project. I can work wi...

Table of contents

• Cover
• Title Page
• Copyright
• About the Author
• About the Contributors
• Contents
• Preface
• Acknowledgments
• Chapter 1 - SCOPE MANAGEMENT 1: If You Can See It, We Can Build It
• Chapter 2 - MANAGEMENT AND CONTROL 2: Can You Prove Your Project’s Status?
• Chapter 3 - PROJECT TEAM MANAGEMENT 3: Roles and Responsibilities Are Critical
• Chapter 4 - STAKEHOLDER MANAGEMENT 4: Consensus Is the Path to Success
• Chapter 5 - PROJECT INITIATION 5: Get Your Project Off to a Good Start
• Chapter 6 - COMMUNICATIONS MANAGEMENT 6: Don’t Let Tech-Speak Threaten Your Project
• Chapter 7 - QUALITY MANAGEMENT 7: Make Quality Your Priority
• Chapter 8 - TIME MANAGEMENT 8: Schedules Are Guides for Those Who Do the Work
• Chapter 9 - HUMAN RESOURCE MANAGEMENT 9: Build a Realistic Project Team
• Chapter 10 - COST MANAGEMENT 10: Never Lose Track of the Money
• Chapter 11 - PROJECT GOVERNANCE 11: Organizational Support Is a Key Success Factor
• Chapter 12 - PROJECT INITIATION 12: The Charter Is the First, Best Tool for Project Clarity
• Chapter 13 - PROCUREMENT MANAGEMENT 13: Take the Time Necessary to Ensure Project Success
• Chapter 14 - PROJECT PLANNING 14: Those Who Do, Should Plan
• Chapter 15 - RISK MANAGEMENT 15: Even the Best Planning Does Not Eliminate Risk
• Chapter 16 - RISK MANAGEMENT 16: Always Follow Up On Your Plans
• Chapter 17 - PROJECT EXECUTION 17: Sometimes the Napkin Approach Works
• Chapter 18 - HUMAN RESOURCE MANAGEMENT 18: Know Your Team
• Chapter 19 - PROJECT MANAGEMENT INTEGRATION 19: Solution Complexity Is Seldom the Issue
• Back Cover