KAZ's Thurow says it is important during the planning process to break the entire statement of work (SOW) down into discrete, credibly estimable tasks and then create a bottom-up plan. And since errors in EV stem from estimating error, measurement error and baseline error, reducing these errors helps validity. Never have tasks on the work breakdown structure (WBS) that are so large in scope that you can only guess partial completion from week to week, he advises. And keep an eagle eye out for manipulation.

"The only way to avoid delusion is to manage to small, cumulative deadlines," RNC Global's Dromgold agrees. "The current practice of breaking projects down into small 'doable' parts is okay, except when we then delude ourselves that progress is being made and are baffled when with integrating testing, things don't work.

"We have to have small chunks, integrated and measured progressively for actual delivered outcomes."

It is the only way to ensure your statistics do not lie.

SIDEBAR: Project Stealth

The success of the stealth bomber proves that even the most complex projects can be managed successfully

You just do not get any projects more complex than development of the F1178 stealth bomber, says Amsterdam-based program manager Peter Luiks. Yet his team successfully completed the project with nary a wishful thought.

The secret lay in the way the US Department of Defence laid down its terms of engagement. "The Defence project management [group] sets you constraints and sets you in a way of working where there is only one way possible, and that is first time right," Luiks says.

The project began with the Department of Defence getting the best people in the Western world together (as long as they could get security clearance). Their mission was to build a plane that would be invisible to all current and future radar systems and that would not radiate heat. Those were the preconditions under which the team was to bring their best in innovation to the table.

From there the team devised a document defining the initial scope of work, then refined it into a first scope of work that was checked and triple checked in Washington before being turned into a joint statement of work. That joint statement of work was huge - Luiks says laid out on the floor it would have covered an entire room and been three folders high - so the team then divided the work into phases and defined deliverables.

"Now, every week a progress report came in from staff managers, project managers, division managers and program managers," he says. "And nobody left the buildings until there was a green light given for the progress report. If there was any mismatch in the progress reports, on Saturday people would come back and work it out so Monday everything was back on track."

Luiks says earned value (EV) estimates are never reliable unless you prepare a joint statement of work, which defines the earned value for both parties involved.

"You must predefine the earned value that should come out of the major complex project from both sides, and first have a statement of work. From the statement of work you have to draft a joint statement of work where both parties sign off on milestones and phases of the plan," he says. "Now if in that last document you also co-sign on the earned value of what has to be reached and what will be considered acceptable value, then the problems are fixed."

Most customers do not know where their own earned value desires lie. And Luiks says organizations or business processes should be in total topological alignment.

Communications and visibility for successes demand the right scope of work analysis and a joint statement of work (SOW). The joint SOW must deliver weekly progress reports in the name of transparency. These weekly progress reports must contain the following items:

• progress made in line with the joint signed SOW

• budget spend in line with the joint SOW

• detected potential mismatches, and suggested paths to time and cost recovery

• concise "what if" scenarios matching progress to reality

• a clear goal statement for the next week

• a map of each task, division and project in topology, in order to produce a concise overview of all progress made.

By doing this the contractor has a one-on-one view of successes as well as any scope drift, he says.

SIDEBAR: How to Write a Statement of Work

By Mary Pratt

It's a tricky task that's essential to project success, and it's easier said than done

Statement of work. As straightforward as it sounds, getting one right is no easy task. But nothing is more fundamental to the success of a project. If the statement of work is too vague, too broad or too generic, it can leave room for various interpretations, which can lead to trouble down the road. That's true for an internal project, and it's doubly true when there are vendors involved.

"The failure to properly execute a statement of work is often the reason parties end up in a dispute," says David M Greenberg, an attorney in the technology, media and telecommunications practice group at Greenberg Traurig LLP 's New York office.

To get your project right the first time, follow these guidelines for writing an effective statement of work, or SOW, as it's affectionately called.

Understand what a SOW is. A SOW defines the scope of work required and the time in which it's to be performed. It's "the cornerstone to an agreement", says Nick Scafidi, IT procurement manager at energy supplier National Grid USA. "It sets expectations, deliverables, what's acceptable, the price, the pricing schedule. Without that, it's like saying to a contractor, 'Build me a house', [without] telling him when, what kind or how big."

Know what to include. Bruce Russell, who signed off on numerous SOWs when he was chief operating officer at a software development company, says a good one includes these things:

• Major deliverables and when they're expected.

• The tasks that support the deliverables, as well as which side - the hiring company or the service provider - will perform those tasks.

• The project's governance process, along with how often governing committees will meet.

• What resources are required for the project, what facilities will be used and whose equipment will be needed, as well as testing requirements.

• Who will pay which costs and when.

"The statement of work pulls together all the elements at the beginning," says Russell, now an executive professor at Northeastern University's College of Business in Boston. "And the more precise you can make it, the more quantitative, the better."

Define success. A statement of work should clarify for all parties what constitutes success or failure, says Melise Blakeslee, an attorney in the intellectual property, media and technology transactions group at McDermott Will & Emery LLP in Washington.

"You have to adequately describe what the work is and the criteria for how you both [will] agree" that something is successfully completed, says Ruth Anne Guerrero, standards manager at Project Management Institute, and a former IT project manager.

For example, she says, if you expect your vendor to develop user requirements, your SOW should state that the vendor must interview specific user groups and have them approve the requirements before the job is considered done. That defines success better than simply saying: "Vendor will produce user requirements."

The definition of success depends on the project, Guerrero says. IT project leaders need to specify whether successful implementation is defined by speed, response time, ease of use or all three and then quantify them in the SOW.

Don't forget a timetable. Successful implementations can't be defined by the system's speed or responsiveness alone, though. After all, what good is a great application if it takes a decade to build? That's why a SOW needs to include time elements. Guerrero recommends using language that allows some flexibility rather than a fixed date on the calendar. A SOW should specify, for instance, that the end-user requirements are due two months after the contract is signed - wording that still gets the project moving forward while accommodating potential problems such as a delay in signing the contract.

A SOW should also designate specific times for formal reviews, so all involved can confirm that they're on track, says Matt Liberatore, a professor in the department of decision and information technologies and the John F Connelly Chair in management at the College of Commerce and Finance at Villanova University.

Tie payment to milestones. Another key component to keeping work on track is setting specific milestones in the SOW and tying payment to successful completion, Blakeslee says.

When Scafidi writes a SOW, he specifies that payments to vendors are made upon acceptance of key deliverables. He also notes that he will retain a portion of the pay until the vendor proves that all the deliverables work together.

Use language everyone can understand. The IT department and its vendors aren't the only ones using the SOW, Blakeslee says. So don't write it as if only IT people will see it. "It should be understandable to end users, service providers, management and to a judge," she says.

Be specific. Although numerous parties have to understand the statement of work, be precise in describing the project's scope and requirements, Blakeslee says. She has seen documents that set vague goals, such as "will work to the best of their abilities". She compares that to a homeowner hiring a painter with instructions to "use the best effort possible".