Agile Projects Need Real-Time Plans

At the start of a blitz, 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 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

Continue Reading