Control
Human beings want to control everything. Their lives, other people, things around them, events which can affect them in any way. The illusion of control gives them certainty, the feeling of order, the impression that the world around them will somehow follow the rules, their rules.
And so we create plans, schedules, deadlines, policies, guidelines. We think that those measures will give us more control, or at least a better visibility of the world around us. Project managers do that to. Would it be through Gantt charts or weekly meetings, they think that they are actually able to predict something and, ultimately, to control precisely the flow, the realization of a project.
In practice, we cannot even control a thing as mundane as arriving at work for a given time. What if you tear your shoelace? What if there is a jam on the road? Or maybe the door of your garage is simply blocked? Maybe your child is sick and there is nobody else to take care of her? Or maybe the bus driver wasn't looking at the road at the moment when you were crossing?
Imagine a project as an organic structure, its growth being influenced by the environment. Similarly to a tree, the project is never the same and adapts to the environment, that is to thousands of different factors which can have from minimal to severe impact on it. In other words, the project is unpredictable.
Despite that, we, we who can easily be disrupted by a simple shoelace, set the deadlines, plan ahead, and, in essence, believe that we can know how and when the project will end. While being unable to predict our own death, we imagine that we can predict the death of our projects, despite the fact that, again and again, projects die much sooner than we thought, they die unexpectedly, they die unnoticeably, or they live for years while we thought that nobody will remember them few months after their birth.
This is not simply a business sustainability versus the complexity the IT personnel faces on daily basis, no; this is a core mistake companies approach software development. Things Taiichi Ohno explained nearly thirty years ago in manufacturing can excel much more within the software industry, where room for flexibility is much higher compared to manufacturing, but this is only one of the aspects which is misunderstood by many software companies. A much more substantial change resides in the approach of the notion of control.
Until control is the top priority, justified as a requirement for better visibility, adaptability is moved to the second plan, while it is specifically the adaptability which is crucial for every team. Like in war, planning ahead is key. Like in war, from the first encounter of the enemy, you must adapt the plan to the circumstances.
Business is war. Faster, more flexible teams have better chances to survive. They built the product with changes in mind, and they are ready to take whatever the real world will throw at them, and to use it at their advantage. Instead, rigid teams where control is everything cannot stand the constantly changing circumstances, and will inevitably lose the battle.
Manufacturing, and other industries in general, usually can't afford such flexibility. They have considerable prior costs, which involves investment, which, in turn, involves ROI, and so plans, schedules, deadlines, policies and guidelines. In software industry, any project can start small, with usually prior costs of several hundreds of dollars instead of hundreds of thousands.
Start small. Fail fast. Move on.
You don't need to control the project. You need to adapt it. Don't plan ahead, but do what is needed to do to ensure that the project will be malleable enough to face the changes.
You don't need to avoid failure. Embrace it. Learn from it. And then, start over, move on.
Agility is exactly about that. Agile project start small: there is not much to deliver at the first iteration, after a week of work. They fail fast: every blocking issue is noticed in the worst case at the end of an iteration. Finally, they move on, by iterating, and making iterations as short as possible.
Control, in those projects, doesn't make sense. Changes are so frequent that any plan ahead fails within hours or days. As soon as the team knows what to do next and where the project is going, they can bring the project shape, day after day. Day after day, they will deliver additional value to the customers; and in software development business, this is the only metric which actually matters.