All program teams run the risk of developing a culture that encourages deception and self-delusion. Here's how to avoid fostering an environment of "wishful thinking" and keep your projects out of strife.

The status reports showed everything running on track. The risk management plan had mitigated all major concerns. The pre-cutover "readiness" assessment had given the project a green light and the steering committee had approved the new IT system for go live.

However, just one week after the system did indeed go live the metal fabrication company had to call in full service accounting and advisory firm Pitcher Partners to help resurrect the project . . . and its business.

For that week the company found itself able to deliver just half the normal volume of product. The system was spewing out some orders twice and the company had to throw out some custom-made material. The system could not even invoice satisfied orders. The switchboard was in "meltdown" as long-standing customers, with idle subcontract crews waiting for products, demanded information about the progress of their orders.

It was obvious the system was not fulfilling expectation. But why had the project proved such a dramatic failure and how had the project team ever approved going live?

Blame must go to management by wishful thinking, says Pitcher Partners director Rob McKie. When project managers know how to beat the system, projects can get the green light all the way to their eventual failure. They can be late, blow the budget and never deliver anything usable to the customer and still present as being on course and delivering right to the end.

The simple fact is, program teams can subconsciously develop a culture that encourages deception and self-delusion. In his blog Coding Horror, Californian programmer Jeff Atwood wrote in a May 7, 2004 post:

"I am amazed at how many problems in software development boil down to wishful thinking. How many times have you heard statements like these?

• None of the team members really believed that they could complete the project according to the schedule they were given, but they thought that maybe if everyone worked hard, and nothing went wrong, and they got a few lucky breaks, they just might be able to pull it off.

• Our team hasn't done very much work to coordinate the interfaces among the different parts of the product, but we've all been in good communication about other things, and the interfaces are relatively simple, so it'll probably take only a day or two to shake out the bugs.

• We don't need to show the final round of changes to the prototype to the customer. I'm sure we know what they want by now.

• The team is saying that it will take an extraordinary effort to meet the deadline, and they missed their first milestone by a few days, but I think they can bring this one in on time."

Atwood says most software developers are by nature highly motivated; the real art of managing programmers lies in knowing when to de-motivate them. Where they can sometimes go wrong is in failing to distinguish between optimism and wishful thinking.

"Wishful thinking isn't just optimism," Atwood says. "It's closing your eyes and hoping something works when you have no reasonable basis for thinking it will. Wishful thinking at the beginning of a project leads to big blowups at the end of a project. Wishful thinking undermines meaningful planning and may be at the root of more software problems than all other causes combined."

As an article by project management expert Rob Thomsett of the Thomsett Company points out, politics is often behind much of the wishful thinking. Thomsett says his company's research has shown that within certain conditions, IT people are good at estimating - it is just that like politicians, they have learned to massage the message with political spin.

"It is our belief that over the 30-plus years of commercial computing [people have] developed a series of sophisticated political games that have become a replacement for estimation as a formal process. More importantly, like all good games they are passed on from generation to generation by 'children' IT people learning from 'adult' managers who of course learnt the games from their adults when they were children and so on," Thomsett writes.