Things would be so much easier if development occurred at the speed of thought. If one could simply design a data structure, and like magic, poof, it is implemented, populated, and updated constantly in production. Some virtualization tools can appear to instantiate such magicalizations, but those are usually the exceptions to the rule. Having projects done in the blink of an eye is a wonderful thought--whether that “blink” is a day, a week, a month, or even a quarter. But this is less important than that the efforts performed during that unit of time are efficient.
When applied implementation efforts are not efficient, more often than not, the inefficiencies are due to the interference of an imp known as churn, i.e., implementation wheels spinning away and not actually making progress. Churn is bad. Churn is one of the most destructive circumstances for any IT project. Churn may rise its ugly head at any point where a project requirement or need is left unclear. In this context “unclear” is evidenced where there is a task, or set of tasks, to be accomplished, but the designers, subject matter experts, or those in a leadership role are unable to articulate in detail how to perform those tasks. In the worst of situations, engineers may draw a box labeled “Magic Happens Here” for this particular item. It is in this gray landscape of the ambiguous where the churninator rules and can burn up countless implementation hours as components are built based on guesses and supposition rather than knowledge. Eventually, the implemented guess is uncovered as not being what is desired, and everyone is left unhappy.
In theory, Agile development approaches exist to solve this problem. The expectation is to fail quickly, recover, and move through to success. The idea that such circumstances are not embraced as part and parcel of the development process exposes the lie that many organizations are not quite as Agile as they would have people believe.
Many organizations are still holding on tight to the concept of project work being one-and-done, as the old waterfall promised; now, they just want the Agile speed, while they still desire the one-and-done result. This same attitude explains why technical debt lies untouched as the skeletons in many corporate IT closets. The churninator is fed every time a project is at a point where some metric, or other component, is not well defined. And rather than pausing to dig into the details and get the appropriate stakeholders to reach consensus, someone in a leadership role says the Nike tagline “Just Do It” to the implementation team.
Under the above circumstances, any work product is at great risk of being insufficient. As long as everyone involved in the project understands and accepts the risk for the ambiguity at issue, then all is more or less well. It is the opinion that such events “cannot happen here” that is the problem. If those opinions are held by leadership, that stance can result in serious consequences.
Project management needs to step into prominence whenever there is a mismatch between expectations and reality. The project manager needs to be involved in understanding the project and tasks well enough to recognize when the ambiguous tasks come into play. It should not be a surprise when the time comes to initiate these tasks. Ideally, when these ambiguities are encountered, there should be agreement to go into a discovery phase to provide clarity before moving forward, or at least an acknowledgement that the dependent work effort may require several iterations before reaching a finished state. Assuring that all those involved comprehend that there is an issue to be worked through, includes addressing circumstances as such and in a manner that will help everyone focus and ideally work through the ambiguity in as quick a manner as possible