ALL PROJECT MANAGERS MUST NEGOTIATING REALISTIC PROJECT schedules and budgets, but how do we do it when faced with the need to meet externally set targets that may be based on legal requirements, market pressures, or client whim?
Tight Deadlines and Budgets. Confusing impossible deadlines and budgets with aggressive project planning and performance may be one of the most costly errors in business. Deadlines set without regard to how much time it actually takes to perform the work, given available resources and conditions, are targets, not schedules. The deadline is a target, even when it is driven by market forces and legal requirements. Schedules are based on an analysis of the work to be done, the resources available to do it, the tools and methods to be used, and the environment. Budgets are based on these same parameters.
Aggressive schedules are fine, if they are realistic. If they're unrealistic, they won't be met, or, worse, they'll be met by delivering a product that fails to meet business objectives. Project performers will do their best to do the impossible. They'll probably eliminate planning, short-circuit requirements definition and design, bypass quality reviews, and whiz through testing. They'll eliminate documentation. All to meet the deadline and make the budget.
The Case of the Tight Target. Jack Parker left Joe LaPorta's office thinking, “Here we go again, another project that's never going to get done right.” Joe, the director of software engineering at Dynamic Systems Inc., has informed Jack, one of his lead developers, that Sales has just landed a big contract, which includes a major software component that must be delivered within four months. Joe isn't sure just what is required, but he is confident that Jack and his crew can make whatever needs to happen, happen.
George Pitagorsky, PMP, specializes in project management and process improvement. He is the director of Product Development and Information Technology Services for the International Institute for Learning, and has an independent consulting practice based in New York City. He has authored many articles and courses on project management, interpersonal communications, problem solving, and process improvement.
Jack's developers are up to their eyeballs working on several high-priority projects, all of which have tight deadlines. Everyone is working overtime on a regular basis, and the staff is grumbling about being forced to put out poor-quality products. Postdelivery rework and customer complaints are becoming standard operating procedure. Staff turnover is on the rise. Late delivery is normal. Dilbert cartoons are appearing on cubicle walls and bulletin boards, and people are beyond laughing at them.
Fast-forward three days. Jack and his staff have made their estimate of the new project and, given current commitments, staffing levels, and the normal amount of overtime, they firmly believe that they can deliver in six months. With some changes in priorities, maybe they can cut it to five months. But Jack has worked for Joe long enough to know that the end result of their discussion will be a four-month schedule that has no possibility of being met. With any luck, there'll be enough changes to justify an overrun; otherwise, there'll be the normal hell to pay. Further, the product's chance of working well will be nil.
Reader Service Number 030
Fast-forward five months. “Why can't you people ever deliver a decent product on time?” bellows Joe. The project is late, and the product is never going to get past the engineering department's quality-control checkpoint. Jack's latest estimate is for completion in two months. Most of the extra time is needed to rework the product to undo some of the defects that, Jack is convinced, are present because the team rushed through design and interim testing.
Get It Done Fast, Cheap, and Good. Conventional project management wisdom responds to the request for a fast, cheap, and good solution with “pick any two.” Unfortunately, relying on conventional wisdom often leads us down the wrong road. Conventional wisdom isn't what we need. Glib responses are the tools of jokesters. How about some innovative wisdom, or even some just plain wisdom? Plain wisdom is the kind that proves itself by resonating deeply in mind and gut, and by actually leading us to a powerfully effective course of action.
Wisdom teachings tell us to avoid either/or thinking. That's the kind of thinking that sees things as being black or white, this or that, good or bad. Why shouldn't a client be able to get a solution that is fast, cheap, and good? It is the project planner's job to negotiate the right schedule, budget, and product definition in order to get the client what she wants, when she wants it, for how much she wants to pay for it—within reason. Ah! Within reason. There's the rub.
Reasonable Constraints. Who gets to say what's reasonable? How often are requests for fast, cheap, and good solutions demands instead of requests? How often do project planners lack the courage or clout to “push back” at the demands, to negotiate reasonable project plans that deliver good products at the lowest possible cost within the shortest possible schedule? Within reason means that the probability of success is, at least, greater than zero.
The project constraints of time, cost, and product quality can be set arbitrarily and accepted by project managers and performers. But if they are unreasonable, they will not be met. When they are not met, there are costs—often significant costs—that include lost opportunities, people sitting and waiting for something to do, unhappy customers, lawsuits, penalties, lost credibility, high operating costs throughout the life of the product.
When unreasonable project deadlines and budgets are common, overtime and stress become chronic. Burnout and turnover often follow, leading to high costs and low productivity.
Project Success. Project success is what everyone should be after. An informal survey of a few thousand project managers, project performers, and other stakeholders, which I've conducted in hundreds of project management seminars, has defined project success in terms of a set of characteristics:
■ Meets business objectives (for example, the product makes a profit, or the change saves money)
■ Produces an outcome of acceptable quality
■ Is completed on time
■ Is within budget
■ Ends with harmony among project stakeholders (enough so that they can work together in future projects)
■ Teaches something about how to perform future projects.
As an exception, projects that are canceled as soon as their outcomes are no longer deemed desirable are successes even though they do not deliver the outcome nor meet their original objectives.
Loss Leader Projects. Sometimes it makes good business sense to bid a project below cost or set a deadline that probably won't be met. These are sales and business management decisions having more to do with client relations and long-term sales than with the work to be done. When the price or target date is set this way, evaluate project performance against the estimate made by the project performers, not the price and target date. Among the objectives in these “loss leader” projects is to minimize losses and come as close to the target date as possible, while delivering a viable product that satisfies the client. Evaluate the value of these based on the profitability of the overall client relationship or on other long-term, indirect gains (for example, the learning obtained by performing the project, or a proprietary product).
Project Manager's Responsibility. Project managers are responsible and accountable for project success. Project success hinges on the definition of realistic objectives. Dutifully accepting unreasonable objectives abrogates the project manager's responsibility. The project manager must assess the project's time, cost, and quality objectives, and give his professional input regarding the project's feasibility. Ultimately, it is the project manager's responsibility to go on record with his assessment of the probability of success.
Let's get real. How does a project manager, without committing career suicide, tell his management that the commitment they've made to deliver some product by some date for some price is ridiculous? How does he tell a salesman, client, or project sponsor that her desires are not likely to be met?
Well, for one thing, you can think it, but don't use the word ridiculous.
For another, plan well so that you can back up your assessment of project risk—the probability of meeting project objectives. Document your assumptions. Use past experience. Don't be afraid to bring up past failures and their costs, especially if they are chronic.
Negotiate. Become a master negotiator. Usually you don't have to say no. Usually you can say yes, but with conditions. Sometimes, the conditions, stated clearly and backed with a well-formulated argument, will prompt management to change its deadlines or to withdraw from the project. A project manager is not the decision-maker regarding whether the project should be done—that's up to senior management and the client. The project manager's responsibility is to present the facts, assessments, estimates, alternatives, and assumptions that decision-makers will use in making their decision.
Project Planning. Project planning consists of the detailed description of the project's outcome and of the way the project will proceed. The plan, when used properly, is a script for project performers and a prediction of the outcome. Because projects are usually too complex to be scripted with 100 percent accuracy, the project manager and performers are expected to adapt to current conditions—that is, ad lib—when appropriate. When it becomes appropriate to ad lib, the plan should be brought in synch with reality. A useful plan continuously provides the best possible prediction of the project outcome and of the steps to achieve it.
Though it is often necessary to set a target date before project estimating can be done, it is good practice to estimate without constraints to get the most realistic prediction of the project's outcome. If the estimate is that the project can be completed within its constraints, then no problem. If the estimate indicates that the constraints are too tight, then negotiate a plan that will meet the business objectives underlying the project.
Exhibit 1. The amount of work depends on the nature of the product, the process (tools, techniques, environment) and the quality and quantity of the resources.
Project planning is often the first thing jettisoned when targets are tight. “Who has time to plan? We barely have time to do the ‘real work.’” This is not uncommon thinking. Bypassing or speeding through planning is a big mistake. Planning is an opportunity to model the project, choose the best way to proceed, and ensure that everyone is on the same page. Projects take less time to perform when the work is planned than when the work is performed without planning. The more complex the project, the more planning makes a positive difference.
Don't Go Off Half-Cocked. There's an ancient wisdom tale about training fighting cocks. The Ta o Te Ching tells of a trainer who won't declare a cock ready to fight until it is unruffled by any stimulation—when it can act instead of react.
Relax. Panic and hyperactivity are counterproductive. Think. Plan collaboratively. Execute with discipline and precision. Have fun. Be constantly ready for change. Communicate. Keep a level head. Be realistic. Work as a healthy team.
Target Dates. A target date is an objective. Often target dates are set based on factors outside the project—such as the marketplace, desire for profit or reduction of expenses, legal regulations.
Even though a target date may be stated as a directive—“It must be done by ‘X’ date”—smart project managers know that it must be interpreted as a question: “Can we deliver an acceptable product by ‘X’ date?”
The estimated completion date is the outcome of project estimating. Scheduling should never be done in isolation. A project's schedule is based on the amount of work to be done and the type and availability of the people and machines needed to do it. The amount of work depends on the nature of the product, the process, and the quality and quantity of the resources, as explained in the schedule/budget negotiation algorithm in Exhibit 1. The schedule is optimized for a combination of product quality, cost, and time with the client and/or sponsor deciding on priorities.
The actual completion date is what really happened. The goals are to have the estimated completion date as close to the target date as possible, and to accurately predict the actual completion date.
Tradeoffs. The schedule/budget negotiation algorithm is the foundation for the negotiation of the optimal balance among product, cost, and time tradeoffs, which are the three principle parameters of project objectives and the project plan.
When making tradeoffs, there is a limit for each parameter. Product quality, features, and functions must be sufficient to satisfy business objectives and avoid embarrassment, lawsuits, and unexpected costs after the project is completed. Given the minimally acceptable product definition, there is a minimal time and cost—for instance, nine women cannot deliver a baby in one month.
Engage the client and upper management in the negotiation to highlight the tradeoffs. This avoids the all-too-common occurrence of clients thinking that they have cleverly gotten a great deal by squeezing the price and schedule down, when in fact they've tacitly created a situation that will guarantee a late, over budget, and/or poor quality product.
Organizational Learning. Realistic estimating, if it is not already the norm in your organization, requires a change that is best made from the top down. To get this and other fundamental changes to occur, there must be enough healthy communication to permit a candid assessment of project experience—particularly the causes, frequency, and costs (in image, penalties, lost opportunities, and so on) of late and/or over budget projects.
Scrutiny of the dynamics among the groups and individuals involved in making project commitments is necessary to identify causes of unrealistic commitments and set appropriate roles and responsibilities. For example, a sales representative should not be allowed to make a commitment to a client without first obtaining input from project performance group(s).
Postproject evaluation reviews are the forums in which lessons learned are highlighted and documented. Publishing the results and making them readily available is critical to ongoing learning. Candor is essential. Don't be afraid to hang out the dirty laundry. Give up blaming and the hiding of mistakes that goes along with it. Look for the causes of all problems and shortfalls. Do something to change the process.
Take Action. To make the necessary changes to improve project estimating, take action:
■ Collect and utilize past history.
■ Review sales and marketing incentives to promote realistic pricing.
■ Review all projects, and publish lessons learned.
■ Provide project management training throughout the organization.
■ Create and maintain a master schedule that shows how commitments for multiple projects impact resource availability, and use it when planning.
■ Identify standards of product quality, and consider meeting them when estimating.
IF YOU ARE IN AN industry that makes rational project planning impossible, then relieve unnecessary stress by owning up to the most likely probability of meeting schedule and budget commitments and to the business strategies that make “loss leader” projects an acceptable way to do business.
If your organization has not been sufficiently enlightened to enable rational thought, communication, and action, then protect yourself, your teammates, and your organization. Push back. Use you skills to present a solid argument. If nothing changes, perhaps it's time to update your résumé.
In short, Get real! Be aggressive and realistic. Seek to deliver what's needed, when it's needed, for the lowest cost possible, while maintaining a quality of life that makes sustained high-powered performance possible. ■
Reader Service Number 029
