John F Filicetti, IT Project Management Office director with the Greater Seattle Area Children's Hospital, is writing a book, Get It Done: A Practical Guide to Project Delivery. In many years of project involvement he has seen not only project managers looking at the wrong goal but executives looking at or measuring the wrong thing causing the wrong outcome.

Project managers spend much of their time involved with status reporting. Often, reporting the negatives causes concern and inspection from above, Filicetti says. In response, many project leaders understate the issues and overstate the benefits.

"I have consulted with many companies where I advise simple reporting metrics to avoid misstatement of status and achievements. Project teams misstate their issues and status to avoid more problems from above and hope things change before the real word gets out," he says. "Many project teams don't want tools to provide status automatically or by standards set by the organization."

Equally, Filicetti says lack of accountability and an inability to lead and influence change continue to dog project management. Many project teams do not have the power to carry out their projects and do not want to give a negative report. They understate problems and overstate their optimism. No one holds them accountable so they make changes at will. Many executives do not want to own up to their lack of leadership and knowledge of what it takes to achieve project goals. They also misstate their reports.

Beating the System

The second project managers learn a system they start figuring out how to beat it. It is part of the job description, says independent project management consultant Tristan Yates. Project managers have plenty of control over their project, and they can use this control to make their project look better in the eyes of earned value. Padding the schedule, putting the easiest tasks first, and overestimating progress can leave a project smelling like roses long after the rot has set in. At least, that is, until the team hits its first hard deliverable.

"There's really no substitute for verifiable milestones," Yates says. "Which would you rather have: a project with a great earned value score, or a project that actually delivered something useful to the customer?"

The earned value calculation takes two inputs: cost and schedule. What is missing is quality. Unless you have a way to judge the quality of deliverables independently, putting an EVM system in place is just encouraging your project manager to cut corners, Yates says.

You should also try to learn when such measures are useful. William Brown, currently program/project manager, Ball of Gold Corporation, says EV is not worth the effort for smaller projects. He tends to use EV only for projects taking more than eight months or costing more than $5 million, or ones that are mission critical.

Brown first used earned value in the program office AT&T Solutions set up to build the US Government's electronic federal tax payment system. The project, which ran about eight years ago, involved multiple vendors working on multiple projects. He says EVM proved "pretty effective" but also taught him some valuable lessons about good project management.

"One of the common mistakes," Brown says, "is to allow some value to be earned when the tasks for a deliverable get started. This is a technique that is pretty standard: you know, you will allow the vendor 50 percent of the value when they start work. But then what happens is when the vendor sees his project getting into trouble, he just starts tasks so that he can earn than 50 percent. Pretty soon all of the tasks have been started."

The lesson, he says, is to ensure each deliverable is 100 percent complete before assigning any value.

Once Were Heroes

Some software developers place a high emphasis on project heroics, thinking that certain kinds of heroics can be helpful, blogging programmer Atwood says. But highlighting heroics in any form can do more harm than good. As renowned consultant Tom DeMarco says, can-do attitudes escalate minor setbacks into true disasters.

The opposite of can-do attitudes is not can't-do but simple pragmatism. Atwood is a firm believer in the premise that it is always better to under-promise and over-deliver. Rather than saying: "It can't be done", project leaders should promise only what is essential while continuing to develop alternatives and contingency plans as time allows. He says being realistic does not mean giving up; it takes a lot more bravery to admit the unknown than it does to blindly promise the world.

It is quite usual for project leaders to face initial high projected costs with large scope and long schedule, notes Gary Elliott, management consultant at US company Information Management Group. In such circumstances you can almost always limit scope, limit costs with cheaper resources (which is not always cost-effective), and crash or fast track the schedule to decrease metrics.

"If the project teams actually do well this is actual performance, so I wouldn't call it manipulation," he says.

In fact, it is usually much better to go for quality and build in a longer schedule, with some slack time on the critical path to allow for unexpected events. Elliott says never forget that increased scope, inexperienced staff and defective requirements planning are responsible for 50 percent of project failures. Poor project planning shows itself even if project teams excel at implementation.

"Oftentimes faulty planning is translated into defective project implementations where the operational project teams get blamed for the faulty organizational structure, the faulty management processes and the unreasonable time, scope and cost projections. I almost never do a project in organizational risk management topics without first doing an organizational assessment," he says.

"At every decision point I look at how KPT [knowledge, process and technology] impacts the project in the areas of scope, schedule, cost, quality and risk. You also have to be able to give the power to make decisions and trade-offs and the flexibility to do so to the operational project manager. You can never plan out every aspect of a project, and unexpected things always occur. This is why you need a human, well-trained, knowledgeable and experienced project manager to manage the behaviours of the people on the project," Elliott says.