Hit the mark
Estimating methods aren't always cut and dried. Three real examples show how project managers are finding ways to adapt and improve current practices.
SOFTWARE PROJECT ASSIST PTY. LTD.,
BY LYNNE JACKSON • PHOTOGRAPHY BY JON LOVE
Calpine Corp., an independent San Jose, Calif., USA-based power producer, had an estimating problem. It took too long to develop schedules for state-of-the-art natural gas-fired power facilities—four to six months, for example, for project control managers to develop baseline schedules once they signed a construction agreement with contractors. Despite their best efforts, project managers consistently saw these schedules fall short. Contractors missed delivery dates, and labor costs escalated.
Today, company representatives bring baseline schedules and project estimates to the agreement table. In 18 months, the Calpine Project Controls team created techniques and tools that streamline the schedule creation process, control costs and help everyone involved follow established schedules and budgets throughout the project life cycle. Today, the firm can pinpoint estimates within a 3 to 5 percent margin. “We've reduced scheduling development from months to weeks,” says Jim Saba, senior construction analyst for Calpine Project Controls.
Calpine isn't alone. Innovative project managers are refining proven techniques to provide realistic project schedules and baselines.
The Calpine team endured more than a few failures before achieving success. In 1999, the company realized current practices could not adequately handle the mounting workload. It faced a dozen construction projects costing $350 to $500 million, each with anticipated 26-month life cycles. Managers worked furiously to fill missing gaps by developing detailed documentation to define every imaginable aspect of procurement, engineering, design and construction, according to Guy Gaines, Calpine project controls manager.
|For those project teams which use the tools, we can almost invariably count $10 million to $12 million in under-runs compared to those who don't, representing about 12 percent of total labor costs.|
|JIM SABA, SENIOR CONSTRUCTION ANALYST, CALPINE PROJECT CONTROLS, SAN JOSE, CALIF., USA|
“Despite the documentation, we saw continued failure,” Gaines says. “We were struggling with insufficient details, missing scope, connecting with the wrong people. There was a lack of integration between engineering, construction and site design.”
Calpine Project Control Director Dave Purdy spearheaded the movement for change, persuading contractors to comply with the new contracts or risk losing the projects. However, projects still fell behind, and costs rose despite support from senior management and reams of documentation. Clearly, being incomplete wasn't the only problem; the process had to be fixed.
The Calpine project control team went to work, analyzing system flaws and evaluating potential solutions. Project managers needed a tool to integrate the processes, teams and schedules into a unified approach that promoted accountability and reporting on a daily basis. They also wanted to independently verify contractors’ schedules and estimates and needed a system that would validate or refute them, forcing contractors to closely examine their estimates, monitor their progress and report on the results.
Consequently, the team abandoned its standard scheduling system and sought a better way. After 18 months of refinement, the team introduced its internal Calpine Standard Progress and Schedule Management (CSPASM) system, which relies heavily on customized versions of Microsoft® Excel spreadsheets and a Microsoft Access database.
The Calpine Standard Progress and Schedule Management (CSPASM) system relies heavily on customized versions of Microsoft Excel spreadsheets and a Microsoft Access database.
Today, contractors and project managers load statements describing project activities into an Excel workbook, along with the available resources they plan to deploy, and devote special attention to estimating manpower and task duration.
“We use a noun and a verb concept that lists the nouns of the building projects on the left and actions or verbs needed to fulfill them,” Gaines says. “Then we start the scheduling and development process by bringing the entire team together and locking them in a room until they get a scope on the project and report the activities needed in sentences.”
The workbook lets Calpine's project team rapidly associate crews with tasks, calculate task durations and reconcile differences with contractors. The Access database retrieves project details and resource information, develops initial estimates and uploads it to the corresponding scheduling system at the backend.
Calpine created a project library to map its construction and re-engineering projects, which involve similar, if not identical, procedures and components. The system implements detailed estimates for each activity, duration and cost into the library, enabling CSPASMs to compare its own estimates against the contractors’.
However, for the system to hit its target estimate— 3 to 5 percent of the project—contractors and managers must input a vast amount of data at the project's inception. The CSPASM system breaks down each piece of equipment used and converts it into an activity using the system's noun/verb sentence concept. This helps the team nail down the labor hours and resources needed for each part of the project as the system concentrates heavily on staffing, rate of execution and risk areas for each activity.
“When we started doing this, a lot of people said it was a waste of time,” Gaines says. “But when they saw the results, they changed their mind. Before we implemented this processing, the overall scheduling and estimates would take five to six months and proceed into the project. Now it takes three to five weeks for the average team.”
Because the scheduling system establishes a project team calendar, templates and forms for ongoing updates and progress reports, project managers quickly can identify problems that affect scheduling or disrupt estimates, including bad weather or inadequate or excessive resources dedicated to a specific task.
“For those project teams which use the tools, we can almost invariably count $10 million to $12 million in under-runs compared to those who don't, representing about 12 percent of total labor costs,” Saba estimates.
To control estimates and keep schedules on track, William Bates, chief executive officer of Bates Project Management in Ottawa, Canada, developed his own methodology.
Bates derived his labor contingency estimating methodology from similar practices that IBM developed in the 1960s, with enhancements. He subdivided the process into specific requirements, definitions and categories and used them to estimate the work processes and resources needed for each project. He now universally applies this process to all projects from construction to software development to policy development.
“We have a process for defining the work processes, breaking them down into smaller pieces and estimating resources for cost and scheduling,” Bates says. “I am a very strong believer in identifying work processes and having the lowest level managers—who are closest to the actual process and those performing the work— identify time frames. Then you are less likely to underestimate or guesstimate wrong.”
This process helps ensure successful estimates because managers tend to set realistic estimates and commit to them. Bates’ labor-estimating methodology examines the project from multiple perspectives using seven contingency factors, which are subdivided into 18 major categories. Each category encompasses specific processes, resources and risk factors. The factors include:
Management and Methodology Process Impact.
|I am a very strong believer in identifying work processes and having the lowest level managers—who are closest to the actual process and those performing the work—identify time frames.|
|WILLIAM BATES, CHIEF EXECUTIVE OFFICER, BATES PROJECT MANAGEMENT, OTTAWA, CANADA|
BACK ON COURSE
In an ideal world, project managers always spot potential problems before they explode. Unfortunately, the world is a messy place.
“With regard to major blowouts, they shouldn't happen, but they do,” says Richard Pittman, managing director of Software Project Assist Pty. Ltd. “The greatest cause is a subcontractor or team who cannot meet their obligations. This is why visibility of ‘yardstones’ is so important.” Yardstones represent the incremental progressions between milestones.
Pittman suggests gaining visibility into each work process, especially those handled by subcontractors. Project managers should know each team's objectives, how they plan to meet them and who is doing what, and they must obtain ongoing status reports—the yardstones—with measurable progress. This visibility provides project managers with a proactive method of identifying potential problems before they manifest and disrupt the project. When a problem arises, project managers should review reports and look for the core problems. Fallback plans help compensate for the problem.
Yardstones can put pressure on subcontractors to meet short-term estimates and deadlines, contributing to successful final delivery. But the yardstones must be written carefully to define measurable results and be set at reasonable increments. Pittman cautions against setting multiple yardstones for the same timeframe, as subcontractors will be less likely to meet them and it will be harder for the project manager to identify a project falling off course.
“Visibility into subcontractors’ work will help identify major risks and implement mitigants in a side budget that run in parallel with the project,” Pittman says. “For example, if a part of the system uses a very non-standard database, you can at least get a fallback started on a better platform. You need a fallback if it's a very high risk, and you see an integration problem that will stop the whole system.”
“Our approach is a bit different than others,” Bates says. “We have well-defined phases for each project type, and we marry them to the various life cycles of the project. We have a hierarchal chart with the top box as the final deliverable and break down the others into work processes or tasks that should be completed within a four- to six-week cycle.”
Bates utilizes descending classes of estimates, with the initial one carrying the highest risk and most sweeping estimate. Class D encompasses a general forecast that, in IT projects for example, is 60 to 70 percent accurate, and Class A ends with a targeted estimate that falls within 10 percent of the established IT project budget.
As the planning progresses, Bates defines Classes D through A by associating numbers with specific work tasks, which have been disseminated from larger processes, thereby minimizing risk and increasing the estimates’ accuracy. Each class may take weeks or even months to complete depending on the project's size.
This article is copyrighted material and has been reproduced with the permission of PMI.
Riding the Wave
Richard Pittman, managing director of Software Project Assist Pty. Ltd., a consultancy with offices in Sydney and Melbourne, Australia, follows the rolling wave concept by creating an overall schedule, adding smaller details and subdividing work processes as the project unfolds, instead of defining every activity early.
In rolling wave scheduling, project managers plan details over a short horizon. Each period, the plan is moved forward by a corresponding amount. “Some project managers like to break down the work in excruciating detail before they start,” Pittman says. “I like to break down the work schedule in big chunks and then refine it in a month or two as I go along. The theory is, if the large schedule and estimate is on track, you will be able to get the smaller ones to follow. When delegating, I like to get people to use a critical chain process, which provides people with an effective way of building resilience into their plans.”
However, Pittman customizes the rolling wave practice to suit the software development projects that he manages and generally ignores the S curve (the graphic display of cumulative costs, labor hours or percentage of work plotted against time), which he says better suits tangible projects, such as construction, because “pouring concrete is easier to measure than writing code.”
Pittman maps out the software development process during the early planning phases as the wave starts to build. Later he defines and estimates such processes as integration and testing at a high level based on the development estimates. He pays particular attention to identifying subprocesses and interdependent ones, especially if they involve different departments, such as legal or human resources. For example, another department often relies on the software platform and/or the engineers to perform routine operations and must be considered when estimating the programmers’ time or taking the platform offline.
The amount and type of work drives the plan, but properly estimating the work requires combining customers’ input with proven methods. “If anything of any size is being estimated, you must have more than one person doing it,” Pittman says. “Even if you are doing it by function, you have to get two opinions from qualified people and resolve the difference. I have never seen an estimate drop as a result of open discussion. The project team can come from different angles and that helps, but you've got to compare what they estimate. If one person does a function point estimate and the other performs a work breakdown estimate, you can compare those. It may not be too easy, but you can do it.” PM
Lynne Jackson is a Woolwich Township, N.J., USA-based high-tech writer and analyst. She has written for CNN.com, the Gartner Group, McGraw-Hill, Internet Week, Network World, ServiceNews and Midrange Systems.
Unauthorized reproduction of this material is strictly prohibited.
PM NETWORK | JULY 2003 | www.pmi.org