Sweet plans

Every time I plan, God laughs.

Plans are problematic. When you plan,

• not all needed information is available,
• the available information can be wrong or will change in future,
• if there are too many influencing factors, some consequences or dependencies can be overlooked and will become apparent only during execution.

So, often, at some point, the plan doesn’t fit to reality any more. Then, some people prefer to change the plan, and others try to change the reality. And because the real reality is an unapproachable lady that isn’t impressed by human plans, a parallel virtual reality will be created, where the plan is fine and its creator is safe.

Those who do the latter aren’t necesserally idiots or freshly graduated MBAs who don’t know better.

They rather have reasons preventing them from changing their plans. For example, the rules of the game in the firm they working for, could punish those who change their plans too often.

I saw enough corporations, where whole levels of management were living in this artificial reality. The catch is simple: as soon as there are other coworkers who confront real problems and earn real money for the company, and there is no transparence about who is contributing how much, it is perfectly possible to believe into the artificial reality and comfortably live there. And even if the company loses money, it is sometimes still possible to accuse others for not supporting the vision of this artificial reality and blame them for losses.

With management bathing in the warm artificial reality, the firm is drifting without control, so unchangeable plans add to the risks account. And the most dangerous kind of such plans are workflows and processes.

It seems to be fashionable today, to create processes for this and that. I’ve even seen one résumé, which looked more or less like this

• graduated from University
• worked at Company for one year, where I’ve installed a software development process for the team of four, and established various best practices

The guy was looking for a job as senior PM with salary much above the average.

But look, a process is just a plan. It is how we are going to develop a software product. Or wind up projects legally. Or control project outcome… And it is a pretty much “unchangeable” plan, because you’re not expected to change Processes (with the capital P) as you wish. And while the issues of unchangeable plans fully apply to processes, they also have their own, additional drawbacks.

Processes don’t differentiate between different kinds of the software projects the firm is going to do. It is financially infeasible to create processes for every possible combination of parameters defining a software project. So one generic process is created. But hello?! Is it supposed to be a silver bullet? Are we really going to handle 3 000 euro projects in the same way as 300 000 euro projects? Should a project consisting mainly from researching in a completely new field of technology be controlled in the same way as an old-school “just another web portal with articles, lists and, may be, this one modern thing, wait, how did they call it, SRS? SSR? Ah, RSS!”

Processes don’t differentiate between different kinds of people. Processes introduce roles and operate only with roles. But nobody is a role (or two). A role describes neccessarily only one or several basic skills and traits. Like, the role Developer is someone who can translate textual description of the feature into C#. In a concrete project, you have concrete people with their particular talents but also deficiences. Allowing people to do things they have a particular talent for, would bring more profit. Forcing them doing the things according to what is printed on their business cards would bring risks and losses.

Besides, there are differences how people approach and solve problems. Someone is a reactive person, so they start to write the code right away without much thinking, but they constantly look for smells and refactor the code on the way, so that they end up with a reasonable architecture, even though no initial code remains. Others are up-front persons, who will write down detailed requirements, then think upon them starring into infinity, and then put down an almost bug-free ready-to-use final version of the code. This difference is a deeply personal one, and ignoring it can be fatal for the projects.

An argument that is often being made for roles is that it makes people replaceable, and thus the resource planning easier. But the truth is that people are only replaceable in virtual reality. In real reality, replacing ANY team member however important he is, WILL change the main parameters of the project (i.e. profitability and risk level).

Processes often don’t have valid reasons to be created in the first place. Because they are often introduced as a replacement for a personal problem. Sometimes, this personal problem looks like a coworker performing not as expected, and I cannot handle the problem with him personally. Sometimes, somebody makes a mistake, and I don’t want to see it repeating in the future. Or I just have a job but don’t have time to search a person who would like to do it. 

Everytime I have such a personal problem, it is tempting to define a process, and let the bureaucracy to push onto the people and magically solve the issue. It is even more appealing, because a process promises me I don’t have to solve this sort of issues in the future again. The only problem with this logic is that processes can’t improve reality. Remember, that unapproachable lady who is not impressed by human writings? When a process confronts reality, guess who is always winning?

There are only three ways to solve personal problems:

1. Talk with the “problem” personally.
2. Decide you’re not going to solve this problem, and accept all consequences of that.
3. Remove the person

But back to the subject.

A good plan is a plan you’re always ready to throw away. And then create a new plan, according to new reality. At this very moment of time, with this particular team, in the current situation.

A good process… Well, the whole idea behind processes is to save planning efforts by defining something generic and always valid upfront. The only meaningful generic and always valid process I can come up with is as follows:

1. Use your head to plan how you’re going to handle current situation.
2. When situation changes, see #1.