Pitfall: Lying to yourself and others

[From Pitfalls of Modern Software Engineering by Bruce F. Webster (forthcoming)]

Categories: managerial

Self delusion and group delusion are all too common in software development projects. Several factors combine to bring this about. One is the natural optimism prevalent among software engineers, particularly when they are not allowed, encouraged, or required to spend sufficient time specifying and designing what they will develop. Another cause is the presumption that no major roadblocks or difficulties will be encountered along the way, either technical or organizational. A third factor is the persistent (if illogical) attitude on the part of upper management that because a project must be completed by a certain date, therefore it can and will be completed by that date, and information to the contrary is not welcome. Mix these and related factors and you have a major disaster in the making.

New technologies and/or methodologies (“TOMs”) have a way of magnifying these tendencies. Engineers become even more optimistic, technical managers see fewer roadblocks, and upper management, having read all the glowing articles about these particular TOMs in the business and trade publications, expects unrealistic results.

Symptoms

Irritation, anger, and disbelief when someone gives unpopular but honest appraisals of how things are going. Long, earnest explanations of why the standard rules of software development don’t apply in this case. And, of course, serious discrepancies between the planned schedule and actual results.

Consequences

Constant slips in the schedule, as expectations are continually reset to adjust to the new version of reality. Projects that ship very late, if at all. Loss of credibility for managers and developers. In the end, you end up looking dishonest, incompetent, or both.

Detection

Take aside the developers, managers, and others involved in the project, one at a time, and ask each person, “Do you think there’s anything we’re fooling ourselves about?” Make notes of the points each person brings up. Make a second pass through, but this time show them the list you’ve compiled and ask them what they agree with, what they disagree with, and what they’d like to add. The number and significance of items on the list should give you a good idea whether you and others are fooling yourselves about how the project is going.

Extraction

Given a significant list of items, you need to reschedule and plan again based on the information collected. This may not be easy or popular; in some cases, it may not even be possible, depending on how upper management reacts. Your choice may then be to either push ahead as best you can or find another job.

Prevention

Use the process described under Detection from the start of project planning and design. You may sacrifice popularity, but you’ll gain credibility—provided, of course, that they don’t reassign (or fire) you and put someone more amenable in charge.

References

[Professional experience]

About the Author: bfwebster

Webster is Principal and Founder at at Bruce F. Webster & Associates, as well as an Adjunct Professor for the BYU Computer Science Department. He works with organizations to help them with troubled or failed information technology (IT) projects. He has also worked in several dozen legal cases as a consultant and as a testifying expert, both in the United States and Japan. He can be reached at 303.502.4141 or at bwebster@bfwa.com.