At the start of an agile project (a 30-Day Blitz for instance), the system builder works with the project team to create the initial project plan, then they embark on the actual building of the system. As work progresses, change happens and unexpected things occur. If the project plan isn’t continuously updated, then this change is handled informally. Different people start keeping their own personal to-do lists, and pretty soon people lose track of what’s on each other’s to-do lists. Confusion, arguing and indecision start to cripple the team’s actions.
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.
Tags: agile, project management, real time plans
