PM Controls: Low-Tech/High-Touch vs. High-Tech/Low-Touch

Agile teams are picky when it comes to the adoption of high-tech tools. On the one hand they seem positively geeky in the adoption automated build and testing tools. Yet on the other, absolute “luddites”, spurning technology, when it comes to project scheduling and tracking tools; favouring cards and poster sized graphs over computer based tools.

Why the schizophrenia over tools? When you dig deeper behind the reasons for these choices, some interesting facts emerge. Rather than relying on Work Breakdown Structures and Gantt Charts it is more common to see agile projects tracking work and progress via Big Visible Charts and task boards to track projects.

Work Breakdown Structures and Gantt Charts have many technical advantages over cards and corkboards. They can illustrate very deep hierarchies of tasks, support task dependency integrity checks, and allow the calculation of interesting metrics like slack, sub-assembly costs, and resource utilization. Yet, therein lies part of the problem, and the principle reason agile methods avoid these techniques. The math, statistics and reports that can be produced with these tools belies the volatile nature of what is being analyzed: tasks and estimates.

When we use tools that perform scheduling calculations and forecasting two problems arise...

1. Data accuracy perception increases
2. Barriers for stakeholder interaction are created

1) Data accuracy perception increases – just because we have a developers estimate entered into a expensive modelling tool does not alter the fact that it may be a lousy estimate, or more likely, today’s best estimate that is going to change as the project progresses and more information surfaces. Tools can create sophisticated models of the future that imply more credibility than their base data supports.

2) Barriers for stakeholder interaction are created – once tasks and estimates are codified into a Gantt Chart we drastically reduce the number of project stakeholders who can readily enhance, improve and update the plan. Usually it is just the project manager who is responsible for updating the plan. They will regularly ask the team how work is progressing and update the task durations based on actuals and estimates to complete, but how often do team members get to reschedule the tasks and insert new task groups?

These observations are reflected in Donald Reinertsen’s “Managing the Design factory” where he warns of sophisticated models: “There is a solid practical reason for not using a more sophisticated analysis: not everyone will understand it. The more complex we make a model, chasing after a bit more accuracy here and there, the more we create a formidable maze of calculations that will not be trusted by the team. It is far better to choose a simple modeling technique and have 100 percent of the team understand the model than it is to risk confusing half the team with an elaborate model that is 5% more accurate.”

Agile planning and tracking tools employ a Low-Tech High-Touch approach. This name comes from the fact that the tools are simple (cards, charts, etc) and easy for all team stakeholders to manipulate (move cards, reorder lists, etc). By adopting these deliberately primitive techniques we avoid a tool related data accuracy perception and allow more people to update the plans as reality dictates.

So What Should the Smart PM Do?
If you are not already doing so, try these Low-Tech High-Touch approaches. Encourage the team to plan iterations and track overall project status via such visual systems. Dedicate a wall in a teamroom or high traffic corridor for Big Visible Charts. Get the customer in front of the planning wall and show them the work done and work planned for the next iterations. When changes are requested work with the team and customer to visually prioritize the new work against the backdrop of existing features.

It’s Not Paranoia When Everyone is Out to Get You!
If this all sounds too Loosey-Goosey and lacking in professional best practice, back it up with your traditional planning approach. When I first started managing agile projects in the early 1990’s I was working at IBM in the UK who had standardized project planning and reporting formats. My PMO was not flexible and demanded standard plans, so I maintained a set for reporting and let the team maintain the work plan.

After several projects I had the proof I needed, the team plans tracked what was really happening on the project and reacted to project changes and challenges faster than I could rebaseline and level a resource profile. I could make my plans and statistics indicate whatever I wanted, but the Low-Tech High-Touch team plans were a faithful reflection of project status (good and bad).

If you operate in a highly regulated environment you may also need to keep parallel traditional plans, but let them be driven by the progress reported from the low tech plans. Taking digital photographs of the story cards and planning boards is a low interference safeguard. [and a good way to stop those pesky developers accidentally “loosing” the difficult story cards :)]