It happens all the time, both in enterprises and in other social systems. People suffer from something that is wrong or getting worse each day, although, basically, this would not be necessary. Perhaps because processes and/or the supporting technology have outlived their usefulness. But perhaps only because technological debts have accumulated. Because a system that used to be quite useful became totally out-dated as time went by. After all, a system that used to be a good tool can also suffer from old age.
Those enthusiastic people in the enterprise who worked with the system found out about this and are now unhappy with the situation. The same is true for those responsible. Consequently, the old world has to be improved. Everybody desires the same thing, because they know quite well what they need and want.
And then there is the job for the project head. He gets the great task. He is supposed to significantly improve a state of affairs which is making many people unhappy.
Basically, everything seems quite simple: both the users of the system and those responsible for the technology know exactly what they want. The “leaders”, too, back the project. Even the budget is available and actually seems quite generous.
But then come the eggheads with their strange ideas: legal service, worker’s council, data security, quality popes, administrative instances and diverse persons responsible for processes want to be heard. Additionally, quite a few “minor zones of battle” are created for personal reasons.
A complex Requirement Engineerung (RE) is initiated. The most adventurous extra functions are created through bizarre mind games. And all of a sudden, you will find functions on the documents that you will probably never need. To make up for it, the most elemental basics were forgotten.
In doing so, the people pervert a project goal in such a way that it becomes the natural enemy of all parties involved in the project. Naturally, the project will blunder from the outset. And even when the project starts, “wise ones” will already foresee that the entire thing is going to end in disaster.
However, the “wise ones” prefer to keep quiet. After all, they do not want to seem to be the eternal grumblers. Besides, they know that their arguments will not be heard, anyway. Just like they know that the morbidly pleasant anticipation, too, will not help anybody. Instead, it will only harm everybody. So what to do?
Isn’t it really a shame?
Incidentally, what I related here is not something that rarely happens. As I perceive it, it actually happens at least with fifty per cent of all projects. The idle power will climb infinitely. And only because we sometimes find heroes who in the end will see to it that the damaged projects will work out after all, you mostly get some desired results. Even if in a rough-and-ready manner.
Well, this is when I start dreaming of an improvement process which is supported by all parties concerned and where simple improvements are carried out in small, shared steps like pearls strung together pragmatically on different chains. This is when the journey becomes the goal. Very “agile”, “lean” and “open”.
Why not with Mobprogramming and similar innovative methods? But I will write about mob programming and that it might actually be a helpful collaboration model for leadership teams at some other time.
RMD
(Translated by EG)
Loading ...