Cutter launched its Enterprise Architecture Advisory Service in 1999. It seems appropriate to begin the new year with a brief survey of where this field has come in the last four years.

Cutter launched its Enterprise Architecture Advisory Service in 1999. It seems appropriate to begin the new year with a brief survey of where this field has come in the last four years.

Cutter launched its Enterprise Architecture Advisory Service in 1999. It seems appropriate to begin the new year with a brief survey of where this field has come in the last four years.

The most common method of software estimation, according to a recent survey by Cutter Consortium of more than 100 software development organizations of varied sizes, is the very basic technique of using the rough judgment of experienced developers -- the "guru" method.

The phenomenon of "burnout" is a familiar one within IT today -- not just in the US and Canada, but also in Western Europe, Australia, Japan, Hong Kong, Singapore, and other industrialized parts of the world. But although most people would agree that it's pervasive, and that it has probably grown worse because of the recent economic downturn, it hasn't gotten much detailed attention. In late 2002, Cutter Consortium conducted a modest survey on burnout. The results were intriguing and also somewhat sobering.

"The more efficient you are, the harder it is to change." In this article, Cutter Business Technology Council Fellow Tom DeMarco's adage will be our guidepost as we examine issues concerning IT and business, drawn from Cutter Consortium's surveys.

"Slack represents operational capability sacrificed in the interests of long-term (organizational) health." So writes Cutter Business Technology Council Fellow Tom DeMarco in his acclaimed book, Slack: Getting Past Burnout, Busy Work, and the Myth of Total Efficiency (Broadway Books, 2001). In this article, we continue our look at the issues related to slack, project management, and organizational survival drawn upon data from Cutter Consortium's surveys.

At the US automaker where I once worked, assembly plant shifts were scheduled back to back. If one shift finished at 3:00 pm, another was hard at work by 3:30. The plants' managers pushed hard to meet production quotas while minimizing input costs by keeping the line going pretty much all the time. The underlying productivity arithmetic is basic to any manager's: maximize output (cars), minimize inputs (labor, electricity to run the machines, etc.).

The management of risk is like driving a car -- everyone believes they do it really well, but very few people actually do so.

"Anything that can go wrong will go wrong."

-- Murphy's Law