It's an all too common scenario. Projects are launched to great fanfare, teams are formed, benefits promised, milestones set, T-shirts and tchotchkes handed out. People get excited about all the great things the project is going to deliver, and start making plans for how the benefits will make their jobs better. Problem is, most projects also start out with unrealistic expectations for when the project will be finished. These expectations, if not properly managed and communicated, will come back to bedevil the project manager as delays in locking down scope, writing business requirements, and finalizing design specifications conspire to push delivery dates further and further out.
Unless, that is, you take steps to control your projects from start to finish, and dampen the whipsaw effect that early delays can have on downstream deliverables. On a fixed schedule project, every week wasted during the scope and requirements phases will be directly subtracted from the construction and testing phases, or will require that extra time be tacked onto the end of the project. You don't have to be Cassandra to foresee that, when things come down to the wire, the fact that scope or requirements were late will likely be forgotten, and you as project manager will be held accountable for failing to deliver on time.
This paper focuses on the most basic of project management disciplines—schedule and resource planning—and introduces a simple set of tools to help identify when projects are likely to become problematic. There is nothing new here; in fact, project managers may initially consider it a pointless exercise. Yet this pointless, trivial, nitty-gritty exercise has done more to bring project portfolios under control than virtually any other improvement effort the author has employed at various organizations with which he has worked. By forcing teams to respect the fundamentals—to plan, communicate, and iterate their schedules until all stakeholders are on board—project managers will have a far greater likelihood of successfully executing their duties and delivering a triumphant project.
Scope Creep and Late Requirements
There are many reasons why projects come in late—construction delays, quality issues, key person availability, unexpected complexity, and other unanticipated events. Yet two of the most common, and most controllable, are scope creep and late requirements. Delays introduced here, in the early phases of the project, will be magnified in later phases when resources are piled on in an attempt to make up for lost time.
Even when project managers have added padding to the schedule (any PMP® worth his or her certification knows to plan for unexpected delays), the worst place to squander this buffer is at the beginning, when expectations are most flexible and easy to adjust. The team always ends up regretting it later.
“Youth is wasted on the young.” – George Bernard Shaw
Knowing this, why do managers, time and again, let projects get into these situations? Why do projects have such difficulty getting scope and requirements under control? Three common weaknesses:
- Failure to set clear delivery expectations (milestones) up front
- Failure to understand resource interdependencies with other projects
- Failure to respect milestones and address issues quickly
As project manager, you must identify and baseline your key milestones as quickly as possible, and then build a detailed plan around these milestones, adjusting scope and spending as needed to make sure they can be met. Unfortunately, this puts you in a Catch-22 situation, having to plan the work effort and activities necessary to get the project delivered on time, but with little knowledge of what you will be delivering.
Put another way, if you don't have clear delivery dates for each of the project phases, you will have a hard time instilling a sense of urgency in the early phases (i.e., defining scope and requirements), and will once again be at the mercy of late requirements and compressed construction schedules later on.
Setting Clear Delivery Expectations Up Front
While many projects start out with little more than vague requirements and a back-of-the-envelope budget, they do typically start out with expectations for when the project needs to be done. Therefore, the most important issue to resolve up front is delivery expectations, or target completion date. It is critical that you get answers to a few questions at the very beginning of the project:
- What is the expected completion date? How critical or flexible is that date (and why)?
- What is the target budget? How flexible is that number?
- What final product is expected? Can it be delivered in phases?
- What resources are needed on the project? For what roles and what time commitments? What are these resources currently working on and when will they become available?
- Who are the stakeholders and what are their relative priorities regarding this project versus others?
- What similar projects to deliver similar functionality have been done in the past? If no precedent exists, what other benchmarks could be used?
Project managers will often complain that they are being pushed to lay out a plan before scope is even understood. A fair concern, to be sure, but somebody has to take responsibility for putting the first stake in the ground and rallying the troops, or the project will be doomed before it ever gets off the drawing board. If not the project manager who takes this leadership role, then who will?
In reality, setting a few concrete deliverables early on is not as difficult or vague as one might think. You just need to take advantage of the iterative and evolving nature of the project by building “level estimates.” For example:
- Level 0: Concept and strategy
- Level 1: Scope defined
- Level 2: Requirements complete
- Level 3: Design complete
With only three pieces of data—target completion date, target business requirements delivery date, and estimated phase duration— you can create a Level 1 estimate almost as soon as the project has been given the “green light,” and bring that much-needed sense of urgency.
Deadline-Driven Project Estimation
A crude, yet powerful, tool for structuring your Level 1 estimate is the Working Backward/Working Forward model. With the “working backward” portion, you lock in the target completion date and subtract from it the expected length of each phase, working backward until you arrive at two critical dates—end of Scope phase, and end of Requirements phase. With the “working forward” model, you lock in target dates for scope and/or requirements and use the same phase duration data to add their lengths to the overall elapsed time, working forward until you arrive at the date on which the project can (reasonably) be completed.
This model presents, in stark detail, the dates that scope and requirements must be completed if the project is to stay on track for the target completion date. Often you will find that, by the time you run the “working backward” model, the calculated dates for scope and requirements will have passed already, and the Level 0 estimate that was used to get the project approved will no longer be achievable in its current form.
With the modeled schedule in hand, initiate discussions with each of your delivery partners so you can understand their expectations of scope and schedule. Make sure these discussions focus on the assumptions behind the plan, rather than the exact dates. For example:
- What you assume to be scope for the project, at least in broad categories of functionality and features
- How you came up with the durations for each phase
- How many people you believe will be needed, based on estimates of scope and budget
- What analogous project(s) you are using, and why you believe it is similar to the current project
Once everyone is on the same page regarding assumptions, you can then begin discussing ways to accelerate work and improve your chances of hitting the targets.
- How to shorten the duration of each phase? (If nothing else, it will force people to come clean about where they have padding.)
- Where can phases be overlapped to shorten the total elapsed time between them?
- Where can resources be added?
- Where can scope be reduced, combined, or rescheduled for later delivery?
Be prepared to adjust the assumptions as many times as necessary to get buy-in, because once you have agreement on the assumptions, then the rest is just addition and multiplication to arrive at the milestones.
“Plans are useless; planning is essential.” – Dwight D. Eisenhower
Granted this analysis will tell you little about the detailed work activities needed to flesh out a full schedule. And the dates are sure to change over time, as expectations become clearer. However, by putting a few early markers in the ground, you will have a mechanism for escalating scope and requirements problems you encounter, and kicking-off dialog with your partners before too much delay has passed.
Understanding Resource Interdependencies
Your Level 1 estimates need to include a staffing plan as well. This should be a high-level resource plan that identifies how many people, by role and by phase, are required to hit the dates set forth in the Working Backward/Working Forward model. Again, you want to use learnings from similar projects to get a ballpark estimate of your staffing needs and skill sets.
This would also be a good time to start choosing the people by name that you want working on the project. As every organization has its “must have” resources who get pulled onto too many projects, the earlier you can lock in their commitment, or seek alternative arrangements, the better your chance of not falling victim to “key person” dependencies.
For each week in the schedule, identify the dates that each person (or role) must be available and working on the project. Be sure to enter these availability commitments into your project staffing system (if you have one), to stake your claim and to identify when they have been committed to more work than they can handle.
You will find that many of your resource needs are fungible enough to swap out for similarly skilled employees or consultants. However, for that handful of critical people upon which your success will hang (such as lead architect, quality engineer, designer, subject matter expert, purchaser), you must be super-vigilant that they are being made available when they should be, and are not being overused by other managers. Even a one- or two-week slippage on their contribution versus their committed hours could submarine your project.
Respecting Milestones and Addressing Issues Quickly
Getting the team to respect milestones and address issues quickly requires a baseline against which you can monitor progress. For a starting set of measurable deliverables, you can use the Level 1 estimate from the Working Backward/Working Forward model. Though this handful of dates is clearly insufficient to guide the team's day-today efforts, just having a few early deadlines looming over the project will force people to begin fleshing out their plans or risk missing their milestones.
The Due versus Done metric is simple and effective. For each task, use target start, target finish, and % complete data from the project schedule to identify tasks that are due each week, and highlight all that are past due but not yet 100% complete, or that have an average completion rate less than the percentage of tasks that should be done so far.
Any tasks that are late should result in a discussion with those folks who are responsible for their completion:
- What is preventing you from marking the task 100% complete?
- What information do you need from others to complete the task? What is preventing them from completing their portion of the work?
- When will the task be done for real?
Likewise, you must keep track of each resource, week after week, to make sure they are giving their committed amount of time to the project. If you have a time-tracking system, use that data to reality check overall staffing levels against your own project plan and identify where committed resources differ from actual, or where they differ from the amount you need to hit the delivery dates.
As trivial as this exercise may seem, too many teams will still fail to take the early deadlines seriously and hold folks accountable for their commitments. Why? Because calling a client or team member “on the carpet” when his or her deadlines slip is a difficult responsibility, especially for managers in a service organization (such as IT, consulting firm, general contractor) who risk upsetting their customer (for example, business user, client manager, property owner) by pushing them to make decisions they're not ready to make.
However, not to do so would be doing your customer or sponsor an even greater disservice. They've committed time and money to the project, they expect to get results for their investment, and they want to know that you are doing all you can to deliver. If you don't escalate risks and get the necessary people involved, your sponsors won't be able to help you because they won't know that the project is in trouble.
“Pay Me Now or Pay Me Later” – FRAM Oil Filter commercial
Remember, every week squandered early in the project will come back to haunt the team when later deliverables begin to tighten. By putting issues on the table sooner rather than later, and forcing a conversation around missed deliverables and resource commitments, you stand a much better chance of getting your partners to work with you on identifying alternatives, such as:
- Reducing or changing scope
- Re-sequencing deliverables
- Adding more budget to accelerate certain phases
- Putting pressure on peer organizations to free up resources or get approvals.
Beware the Politics of Escalation
The best schedules and resource plans in the world won't mean anything if the team doesn't deliver. As project manager, you are responsible for overseeing progress and for making sure people either:
- Get others to deliver, or
- Escalate to those who can help them deliver.
Unfortunately, this third point—the “obligation to escalate”—is not ingrained in many company cultures. Quite the opposite: those who are willing to put issues on the table are branded as “a bull in a china shop” or “not a team player” or “difficult to work with.” Not a nice designation to be given, but for ambitious managers who take pride in their ability to manage complex projects, a far better reputation than being thought incompetent or ineffective. Over the long haul, your career advancement will be determined more by your successes than by your niceness, and the willingness to suffer short-term slings and arrows of organizational politics while getting to the right answer will be a key success factor for many managers.
That being said, you must also respect the politics of the situation you are in, and be ready to deal with roadblocks on a factual and professional basis. After all, what is the source of many roadblocks but a disagreement of opinion as to what is the right way to proceed?
“How often [it] happens, even between the best of friends. Each believes that what he has to say is much more important than anything the other might have to contribute” – Albus Dumbledore
The more you can get issues on the table and steer the discussion toward the facts at hand (and the assumptions behind them), the better your chances that they will be resolved quickly.
To an experienced project manager, the advice and tools outlined in this paper may seem trivial or pedantic. Many managers with whom the author has worked have resisted such tools as being overly bureaucratic. What these managers failed to grasp, at least initially, was that the tools were not introduced to help them manage their projects better, but to help bring visibility to their stakeholders when certain activities or resources are at risk of missing on their commitments. Even well-trained managers need help to step back from the details and engage their management hierarchy when issues come up.
Having such discussions may be uncomfortable for the folks involved, but having them after the toothpaste is already out of the tube is far more costly and damaging to the project, team, and reputation of the manager. These tools serve as a simple way of highlighting two of the most common “gotchas”—delays in locking down scope and requirements, and delays in freeing up critical resources—that can make or break a project.
Don't be a victim of late requirements. Don't get held up by “key person” dependencies. Don't be left holding the bag at the end of the project, when your buffer has been exhausted and your client is screaming at you for being behind schedule. By then, they will surely have forgotten that it was their inability to lock down scope and requirements months earlier that put the project in its current situation.
Instead, take control of your projects early in the process with a few simple exercises, and you will greatly increase your chances of finishing them successfully.