Click here to check out my blog at CIO.com: http://advice.cio.com/taxonomy/term/30/0

I started with the definition of agility in business as: the ability to consistently earn alpha profits that are 2 – 4% (and sometimes more) higher than the market average. Responsiveness and agility enables companies to earn an additional 2 – 4 % because they can make a hundred small adjustments every day to reduce operating costs and increase revenues. And sometimes responsiveness and agility enables you to earn even more by sensing and moving quickly to capitalize on opportunities for new products or services that, for a while, have terrific profit margins.

I decided to use this results oriented definition instead of attempting to describe what agility is because we have a lot yet so any description I offer now will only change later. Also, I figured that unless agility actually delivers additional profits, then why go to all the trouble of being agile and responsive in the first place?

There is one caveat to this definition of business agility though – true agility is self-sustaining, not self-consuming. By this I mean companies can always get a short-term boost to profit margins by cutting headcount, reducing customer service, squeezing suppliers for lower prices, and deferring repairs and improvements to infrastructure. But that is self-consuming, like spending down your bank account. It’s not responsive because it isn’t sustainable; it does not create or renew; it only uses up.

So if business agility is the ability to consistently earn an additional 2-4% (and sometimes more) then what is the combination of factors that delivers this delightful state of affaires? At this point I ordered another café-au-lait. And as I sipped that hot, foamy, milky coffee, I looked out the plate glass window and saw a woman walking by with two big dogs; the dogs were so happy to be outside they pulled at their leashes and wanted to charge off down the street. She worked hard to keep them out of trouble.

Then I eavesdropped on a conversation going on at the table next to me. A couple of college students were discussing an upcoming organic chemistry test; one student was showing the other how to read a formula and draw out the molecular structure implied by the formula. Good coffee houses serve up a stimulating mix of impressions like this to go along with their fine fare and the resulting blend is often the source of interesting ideas.

Here’s the idea that emerged from the blend of that second café-au-lait and the impressions I just described. First of all, I think responsiveness happens when we see something we want and when we are highly motivated to go after it. But we can’t just go charging off down the street; we have to focus on what’s important and act effectively. Secondly, I think there’s a formula to measure responsiveness and it goes like this:

Business Responsiveness = (Visibility + Motivation) x Training

What this means is that companies will consistently earn an additional 2-4% alpha profit if their people can clearly see what’s going on in their area of operation and if they have the motivation to respond appropriately. The effect of this visibility and motivation will be multiplied and magnified by the training people get. The better people are trained, the greater the results will be.

This formula identifies the main factors that promote responsiveness and it shows how they interact with each other to produce different levels of responsiveness. It points out what factors to measure when we’re trying to assess the level of business responsiveness possessed by a company. Visibility can be measured by the technology and procedures a company uses to collect, store, disseminate and display information. Motivation can be measured by the incentives and authority people are given to make decisions and act to achieve company objectives. Training builds peoples’ skills for using visibility, for making good decisions, and acting effectively to achieve objectives. So training can be measured as well.

Now we can start to discuss responsiveness best practices using a common and measurable framework to compare one practice to another (did I leave out something important?). This formula is either a very useful insight or it’s the result of too much caffeine.

It is a common but mistaken notion that the project leader (or “system builder”) should both run the project and also do the project office work. This is analogous to the idea that the manager of a business unit should both run the unit’s operations and also do the accounting for the unit. Although business managers need accurate accounting data to be successful that does not therefore mean they should be accountants, and it’s equally false to suggest that because system builders need accurate project plans they should therefore be the ones who maintain the project plan. We provide business managers with accounting support, and we need to provide system builders with project office support.

Properly maintaining the project plan, doing status reports and answering questions on a 30-Day Blitz is a job that takes anywhere from two to four hours a day depending on what is happening on any particular day. Based on what the project plan shows from one day to the next, that is how the system builder knows what tasks need the most attention. The system builder guides the fast pace of development by spending lots of time facilitating progress on the tasks that most threaten the project’s timely completion. That’s a job requiring eight to ten hours every day. So there simply is not enough time in a day for the same person to do both jobs well (and both must be done well in order to deliver success).

My colleagues and I recently coached a development team through two successful 30-Day Blitzes where they built and then further enhanced a supply chain visibility system that supports their company’s retail and manufacturing operations. The coordination between the system builder and the team member who did the project management provided a text book example of how to run a tight project.

Every morning at the team’s standup status meeting, Cynthia, a senior business analyst, projected the project plan on the wall of the team room and walked through each task currently being worked on. Tasks on the plan were broken down to a level of detail where no task was more that three days long, and tasks were recorded as either started, finished, or delayed; there was none of that percent complete nonsense (can anyone tell me what 70% percent complete actually means?).

A task was deemed finished only when the task deliverable could be seen by the whole project team. If a task was delayed, the extra time needed to finish it was added to its duration; everyone could see the effect that had on the project plan. When new project tasks were needed to deal with unexpected developments, those tasks and their durations and dependencies were added to the plan. Again, everyone could see the effect on the overall project.

Paul was the system builder, and as Cynthia polled the team members and updated the plan, he watched the shifting tasks on the critical path. When delays or new tasks threatened timely project completion, he led the team through discussions of possible responses and decided on the best alternatives. After the meeting was over, Cynthia updated the project plan to reflect these decisions and Paul got personally involved in facilitating the critical tasks that needed his attention.

The project plan was a living document. It evolved and gained more and more task detail as the team progressed through the build phase. Because the plan was always up to date and accurately reflected progress and expectations on the project, it gave everybody a clear picture of what was happening; so they could work together to solve problems that arose. It also gave senior managers not on the project the information they needed and saved team members from being distracted by endless management questions and misplaced advice.

No initial plan survives contact with reality; things will not happen the way you think they will. And since there isn’t much slack in the build phase of an agile 30-Day Blitz, the system builder and the blitz team must respond quickly to new developments. The system builder and the project team need a continuously updated project plan showing daily progress at the detailed task level to stay on top of a fast-paced project.

As the project progresses, new tasks get added to the plan, other tasks get removed or updated, and task dependencies change constantly. Without an accurate and current plan, the system builder loses track of what’s really going on and soon the cumulative impact of changing tasks and dependencies gets out of hand. Unexpected news starts arriving with increasing frequency and there is little time to act effectively. The system builder and the blitz team get pushed into a mode of merely reacting to one unpleasant surprise after another.

A 30-Day Blitz is a way to get more development work done with less time, less money and less management supervision. But what makes that possible is more planning, more coordination and more visibility into what is occurring on the blitz. It is the use of accurate real-time plans and status updates that enables people to deliver the extraordinary productivity that comes from agility.

If you are in charge of a project, you can be lulled into a false sense of security as the weeks go by, yet the status reports become a paper trail that comes back to haunt you. Because important information is in those reports somewhere and because you don’t see it, you will pay the consequences unless you take steps to make sure key issues and potential problems are clearly highlighted.

Some years ago I led a team of developers on a big development project. We were subcontracting to a much larger company that was the prime contractor on this multi-million dollar project. Every Friday by lunch time I had to turn in a report on my doings for that week. I listed tasks completed, tasks that were challenged and obstacles that my team faced. I also listed all sorts of project statistics such as man-hours planned versus man-hours actual that week, earned value credits on my work, and projected critical task man-hours for the coming week.

Then the prime contractor would take my report and all the other similar reports from the other project team leaders and compile a grand all-encompassing status report that reviewed all aspects of the project. This report was then delivered to the business executives at the client company who were responsible for project oversight and who were approving payments on the project.

After the project had been going on for about a year (and getting nowhere) the client company began to get impatient. Senior managers from this company began to investigate what was going on; they demanded to know what was happening on the project and where their money was going.

This is typical. Team leaders on projects like this spend 20% of their time or more each week filling out reports; a large project office organization churns out voluminous status reports filled with words and statistics, and still nobody really knows what is going on.

Vice presidents at the client company had routinely been signing off on the status reports they received each week without ever reading them in detail. Who has time for all those words, all that boring, badly written text that takes for ever to get to the point? But therein was their downfall.

When the client company figured out that not much was getting done and demanded a refund of some of the tens of millions of dollars they had spent, the prime contractor brought out the loose leaf binders full of those voluminous weekly status reports.

A weekly status report was typically 35-40 pages long with bar charts and line graphs thrown in to illustrate whatever point the report writer wanted to emphasize. At the end of these reports was a spot for several signatures indicating that the report had been read and its information therefore communicated.

The prime contractor showed that several of the client’s vice presidents had signed off on these reports week after week, month after month. Then they began pointing out certain sentences and paragraphs buried here and there in those weekly reports. In those passages were statements about problems and delays and cost overruns on the project.

“We told you there were problems,” the prime contactor said, “and you didn’t say anything so we assumed you wanted us to just keep going.” I can only imagine the sinking feeling in the pit of their stomachs as the vice presidents whose signatures were on those status reports began to contemplate the mess they were in.

After that meeting the project went on as if nothing had happened for another couple of months and then the project was quietly wrapped up and shut down. The client company wrote off more than $100 million and I heard that the vice presidents who had signed those weekly reports had all left the company “to pursue personal interests.”

I realized I could easily have made the same mistake as those vice presidents. I resolved to learn from their misfortune and thereafter, on my own projects, I instituted a short and simple format for the status reports I requested from by development team leaders. This format is designed to get to the main points right away, to give clear answers, and to quickly flag issues that could become big problems for the project.

My status report is composed of five questions that cover all the major problems that can occur on a system development project. They are yes or no questions, and if you answer yes to any one of them, then I ask for a short description of the problem and suggestions for how to resolve the problem. After the five questions, I then ask for only a few sentences about what was accomplished this week and what will be accomplished next week.

Such a report is never more than two pages long so it actually gets read by me and everyone else who needs to know what is going on. There is no place to hide the bad news so I quickly find out what is happening. This format has saved me more than once from the fate of those former vice presidents.

Here are the five questions that get to the heart of the matter so effectively:

1.  Has the scope of any project task changed?  (Yes/No)
2.  Will any major activity or milestone date be missed?  (Yes/No)
3.  Does the project team need any outside skills or expertise?  (Yes/No)
4.  Are there any unsolved technical problems?  (Yes/No)
5.  Are there any unresolved user review or approval problems?  (Yes/No)

(For all questions marked Yes, briefly explain the problem and recommend possible solutions.)