Corporate Alzheimer’s and Deadline Management

12 August 2004

by Michael Mah, Senior Consultant, Cutter Consortium

Lately, I’ve been paying attention to my memory or, perhaps, lack of it. I’ve noticed that, among other things, lapses are often related to the number of parallel tasks going on in my head. The more tasks I have to think about, the more I forget. So I try to focus on only a few things at a time; better to do a few things well than a lot of things poorly.

So it goes with companies. Recently, several of my clients have been experiencing a surge in the number of projects they are performing at one time. With the US economy on the rebound, the backlog of projects once on hold is now under pressure to be completed. There’s also another dimension: the staffs that were scaled way back during the recession. Doing more with less was the mantra of the day. Now, with extra work bursting through the dams, overworked IT staffs are suffering a double whammy between the additional projects needing to get done and the shortage of experienced people. As a result, corporate short-term memory is suffering as teams are trying to do six to 10 things at once (a common range for today’s IT professional).

How is this manifesting itself? Here are a few examples: I have four clients right now who need to baseline their IT applications productivity. Two are involved in large-scale package implementations, one is considering outsourcing, and another is implementing agile methods. All are trying to deal with harsh deadlines and immense demands for functionality within aggressive dates. Project slips and cost overruns have been the recent norm. Common interests include the need to quantify productivity so as to better estimate new projects.

To baseline their present productivity levels, I’m working with their teams to gather facts about their recent and current projects. When did they start? When did they finish? How much functionality was produced? How many trouble reports were issued in the first month after rollout? These are basic metrics.

And while the information eventually comes together, let me tell you, it’s been tricky at best. Half the time, folks are tied up in various meetings; the other half of the time, we have to reschedule for one reason or another. When we do meet face to face, we sometimes discover that key information went out the door when someone left for another job. With the economy rebounding, more folks have left the company as other positions became available — after being burned out from long overtime hours, they finally split.

So, the organism that is the “organization” has lost its short-term memory, and in some cases its long-term memory too, as staff attrition takes its toll. I’m not only talking about worker bees, but senior execs have been affected as well when it comes to the “brain drain.”

So what can someone do about this? As much as it might pain some people, one answer is to write things down (literally and figuratively speaking). If deadlines and dates, both present and future, challenge your organization, then write down what happened on recent projects when it comes to how teams have met their deadlines.

In the words of Professor Eric Abrahamson of Columbia University’s School of Business:

Only by remembering the past can we avoid making the same old mistakes — and take advantage of valuable opportunities. By contrast, companies that forget the past are condemned to relive it. Every company needs memory keepers with the clout to make themselves heard. They help an organization undertake change without engendering unnecessary chaos, cynicism, and burnout.
(For more on Professor Abrahamson’s recent work, I recommend his latest book, Change Without Pain: How Managers Can Overcome Initiative Overload, Organizational Chaos, and Employee Burnout.)

So, here are a few pointers on preventing memory loss in your organization when it comes to how projects have met their goals:

At the completion of a project, hold a mini post mortem. Gather around and talk about what happened. Order pizza. Appoint a meeting secretary to take notes as people review the project while the information is fresh on everyone’s mind.

Scribe it out on the whiteboard. Draw a timeline. Sketch out the start and finish dates of the major phases, such as the requirements and planning phase, and the design/build/test phase. Highlight major events, like the start of systems test, beta test, and initial release.

Sketch the staffing profile. Use full-time equivalent staff, so if six people were responsible for requirements analysis, but they split their time 50% across another project over a four-month time frame, then count them as three people over those four months. That means they spent 3 x 4 = 12 person months of effort, designing the requirements. If 10 people then spend the next 10 months designing, building, and testing software, then 100 person months of effort was spent over those 10 months.

Tally the amount of functionality built by the team. Sometimes, the work is a combination of three parts of a pie: new code, code that’s modified, and reused code that’s unmodified (but tested with the new and changed code). You might choose to express this as the number of modules, methods, classes, objects, etc.

List out the number of trouble reports in the first month of operational service. You might even tally these in order of severity, such as showstoppers, moderate, and cosmetic defects.

After all this is sketched out, take a digital photograph of the whiteboard. Save the JPEG file on an open server for people to access a memory bank of historical projects.

Why is this kind of project history important? In an Agile Project Management E-Mail Advisor entitled “Date Visibility” (8 July 2004), my fellow Cutter colleague Jim Highsmith, director of the Agile Project Management Practice, describes the challenge of agile organizations when it comes to managing dates, deadlines, and project estimates. Executives have to run the business — it’s their fiduciary responsibility to their shareholders and their employees. They can’t do this effectively if teams can’t tell them when a project has a reasonable chance of getting done.

Management, under these types of pressures, has finite patience for teams, agile or otherwise, when they say, “I dunno,” when asked to provide a project estimate. Highsmith says it’s like waving a red flag in front of a bull. If you can’t reliably estimate your next project, this could very well jeopardize your job. You run the risk of appearing either inexperienced or ineffective as a project manager, or you’ll get signed up to high demands within an “impossible” deadline — one that could result in a “death-march” for your team.

But with a little experience and project history, you can bring a vast amount of leverage to project negotiations and thus better manage your downside risks. If someone says they want your team to build this much stuff in say, six months, you can look at other projects that were either that big, and/or those that took six months — provided that you have a corporate memory of completed projects to help guide your decisions. Comparing your estimates or targets against these trends will give you the evidence you need to determine what can (and what can not) be done.

This enables us to better manage client and management expectations, and to have greater chances of making good on our promises. That’s what makes an experienced manager.

— Michael Mah, Senior Consultant, Cutter Consortium

© 2004 Cutter Consortium. All rights reserved.