Project Pain Reliever

A Just-In-Time Handbook for Anyone Managing Projects

Dave Garrett

• Publisher: J. Ross Publishing
• Year: 2011
• Print ISBN: 9781604270396
• eBook ISBN: 9781604277234
• Edition: 1
• Topic: Business
• Subtopic: Project Management
• Index: Business

Much of the work performed in organizations around the world today is project oriented. Those responsible for leading the majority of these projects to successful results have varied educational backgrounds, knowledge, skill sets, and experiences gained over the course of their lives and careers that do not include the professional discipline known as project management. Most are managing projects as part of their role, not their profession. However, these accidental project managers frequently run into the same sort of issues and problems faced by those whose profession is project management, but they lack the education or training to properly address them. As a result, more projects run by accidental project managers fail than succeed.This handbook was developed specifically for those accidental project managers and for the relatively new project managers within the profession. It is uniquely organized in a manner designed to help these project managers quickly find specific solutions to the problems they are desperate to fix right now! The text is divided into two broad categories: the Art of Project Management and the Science of Project Management. Each part is divided into chapters to narrow the user's search by type of issue that project managers encounter, such as Planning and Managing Risks. These are then further divided by specific problems labeled as sub-chapters, such as "The company's project management process doesn't work for me" and "My project is too dependent on a few key people." Project Pain Reliever: A Just-In-Time Handbook for Anyone Managing Projects is essentially a plug-and-play answer to the accidental project manager's problems, and a valuable desk reference for all project managers.

PART B

Management—The Science
of Project Management

5

DEALING WITH CONSTRAINTS,
ASSUMPTIONS, AND SCOPE

5.1 We took on too much.

By Alexander Matthey

1. Problem

In the initial euphoria of being assigned the project management of an important corporate initiative, less experienced project managers nearly always overlook the precise perimeter of that assignment. A clear scope statement is often not established, reviewed, and compared within the timeline and for the budget provided.

Overlooking the preparation of a scope statement is certainly not intentional, but whatever the justification, failing to establish the precise scope remains detrimental to the organization from customer satisfaction, functionality delivery, budget overrun, and schedule delay points of view. The PM does not necessarily collect honors, either.

Are You Sure You Will Deliver It?

Tino was happy to receive a program management offer from a multinational telecommunications company. To be part of a world-wide program, in his area of double expertise and passion—telecom and program management—within a ten-minute drive from home was the right next step in his career.

The euphoria he had before starting rapidly subsided on the first day. A debriefing with his new boss revealed that the program was already behind schedule. Tino was expected to drive the implementation team over five continents to roll out an AirPort telecom infrastructure for 100 airport line connections from August to December, equaling 1500 connections by next July. In the past 18 months, only 35 had been done. Now, how did those numbers compare?

There was another challenge that Tino was facing: the detailed technical design was incomplete even though roll-out was underway. How much rework would be generated by this risk, which was almost certain to cause issues? “Hmmm,” Tino thought to himself. “Who will supervise the engineering team? Who will drive these experts to come out with a solution in 2-3 months, when in the last 18 months they could not do it themselves?”

He discovered four months later that the decentralized sales division, which was in charge of selling this solution, was losing commission revenue on numerous airline accounts by proposing this new solution. Right now, the hurdles were how to motivate over the phone 12 sales managers reporting to another VP and spread over five continents, and to plan scope-wise how to get them on board today.

Tino felt the pinch after two days. Isn’t it far beyond the capacity of himself and the eight regional representatives reporting in dotted line to him, to roll out this new world-wide AirPort telecom infrastructure solution in 150 airports and 1,500 terminal connections in 11 months?

A program with floating perimeters, and many dimensions for breaking down the work, had led to too many things to do! Tino had no idea where to start.

2. Warning Signs

•The stakeholders, who are the major impacted parties to the project, do not agree on what the project has to achieve or what the major deliverables are.

•No scope statement is yet produced for the project.

•If there is a scope statement, it is not aligned with the needs of the project stakeholders.

•There is no work breakdown structure (WBS) produced during early planning.

•The person footing the bill (the sponsor) does not give clear limits as to what needs to be achieved first or later, and for how much, in writing or orally.

•All targets are flexible; the only common point is that everybody talks in superlatives about the result of the projects once it is finished.

3. What will happen if I do nothing?

If you don’t recognize and address that you are taking on too much because of an unclear or ill-defined scope, then you will see an ever-increasing list of things to be accomplished (scope creep). This will result in dissatisfied stakeholders, who aren’t seeing the results that they expect, and unhappy resource owners who have provided members of your team and see those assignments getting longer and longer. Scope creep will leave you demoralized and feeling that you haven’t been able to achieve what was expected.

4. Solution

Even if not told so, you must clarify what needs to be done with the sponsor, customer, and any stakeholders. The earlier you do this, the better. You should proceed methodically, through iterations of meetings and analysis, which slowly build the complete and approved scope:

•Create a narrative description of what will be delivered—the scope statement— to define what the project will and will not deliver.

•Create a WBS to have a visual representation of what needs to be delivered with increasing levels of detail.

•Compare the actual project deliverables with the scope and WBS, and get stakeholder agreement that you have delivered all of the elements (and nothing else).

5. What should I do?

When you realize you took on too much scope, you need to quickly clarify what will be delivered, when, and for what cost. You need to ensure that you reset all stakeholders’ expectations. You need to get all major players (sponsor, customer, team, you) on the same page as quickly as possible.

Your starting point is your sponsor. He or she should be able to provide full details of what is expected of the project, when it must be delivered, and how much has been budgeted for the project’s execution.

5(a) Apply common sense

Remember that the problem with common sense is that it isn’t very common! So apply the principle expressed by the following Q&A, often used by trainers when talking about a huge quantity of work (scope) to be covered (delivered): Q: “How to eat an elephant?” A: “Piece by piece.” Apply common sense to break down the work into manageable pieces.

You need to combine your common sense with a solid knowledge of the project deliverables (from your project team) and a solid understanding of project management (which you bring), which allows you to identify the major project elements that can then be expanded into the full work breakdown structure. At this stage, you will include major project elements and perhaps major milestones, but identification of scope will immediately bring clarity to the project and provide something tangible for stakeholders to review and discuss.

5(b) Not yet started or at an early stage—apply one process

After detailed consultation with the sponsor or customer, and once you are in agreement, draft an easily understood description of what needs to be delivered in the scope statement. From this, develop the following (in this order):

•Detailed description of what needs to be done, broken out into packages in a top-down manner that gets progressively more detailed (WBS).

•Sequence the lowest level breakdowns of the WBS in a network of activities (network diagram).

•Estimate the time and cost of all necessary activities to determine the schedule and budget—the amount of time and money needed to do the identified work. This may be different from the timeline originally proposed by the sponsor and amount of money set aside for the project.

•Work with the sponsor and customer to refine the plan through various iterations until all aspects are approved.

•Once approved, refocus all your team members on what has been agreed to and manage their execution of the tasks.

5(c) Advanced stage—apply another process

If the project is further along, it doesn’t make sense to replan the entire initiative. Instead you want to focus on the work remaining. You can’t change work that’s already been completed, but you can work with the stakeholders to make sure that there is agreement on what elements need to be added to the already completed items in order to complete the project satisfactorily. If some scope creep items have already been completed, that reality has to be accepted, but you can prevent further scope creep from occurring.

You also need to work with the sponsor and customer to understand whether the budget or schedule is more important—are they prepared to spend more money to preserve the delivery date, or would they rather accept a delay in order to avoid a cost overrun. Once that is agreed upon, you need to:

•Repeat the process for developing the WBS and estimates, but focus only on the remaining required scope items

•Revise the existing schedule and budget to reflect the revised deliverables and their costs

•Refine the schedule and budget as necessary to account for the preference of preserving delivery date or cost

•Work with the sponsor and customer until the revised plan is approved

•Once agreed, re-focus all your team members on the revised work and ensure that no one is working on items removed from scope

The essential element in the list is the word focus. Use all other usual PM techniques, such as teambuilding, motivating, tracking against WBS, schedule, and budget (collectively called baselines) to achieve the newly clarified and fixed objectives.

5(d) Assistance—know when you need to ask

Managing scope creep can be a daunting activity, but you don’t have to do it alone. Don’t be afraid to ask for help from your project team and stakeholders, and from other areas of the organization, if available. As the project manager, you need to recognize scope creep and move to stop it, but that doesn’t mean that you have to do it alone.

5.2 Everything has changed. I need to reset goals and expectations.

By J. Chris White

1. Problem

The conditions that were present at the beginning of the project changed so drastically that the project doesn’t make sense anymore. You can’t simply incorporate a few changes and proceed; rather, this is a fundament...

Table of contents

• COVER
• TITLE
• COPYRIGHT
• CONTENTS
• DEDICATION
• PREFACE
• ACKNOWLEDGEMENTS
• CONTRIBUTORS
• ABOUT THE EDITOR
• WEB ADDED VALUE
• PART A LEADERSHIP—THE ART OF PROJECT MANAGEMENT
• PART B MANAGEMENT—THE SCIENCE OF PROJECT MANAGEMENT