Why are projects late?
Project management has written thousands of books. Developed a huge number of methodologies and conducted billions of trainings.
But at the same time, almost everyone who managed projects or even simply participated in them knows that projects are late. And it does not matter whether it will be the production of programs, the preparation for the Olympics or the construction of a nuclear power plant. Projects are late.
Some methodologies simply suggest taking it for granted and somehow adapting themselves (for example, planning only the next stage), others try to impose military rigor by conducting Deadline and introducing a “reaction to deviations”.
')
I want to talk about something else. Not about why projects are late, and how to avoid it, but about why they are late. After all, if you think so - well, is it really possible to reset everything to planning errors? After all, like adults, experienced people, well, can't they be wrong all the time? And if they cannot, then they do it intentionally, right?
I will bring three possible situations to your judgment.
Situation first. Swiss knife or "and also a circle on the photo, and still we sing hunting"
All new and new features are added to the project. Initially conceived, a simple calendar turns into a planning system for the universe with elements of a social network and a gaming component. The creation of each new function takes time and effort, but the participants argue: “this is necessary, as the utility of the product increases for the consumer”.
The basis of this situation is somewhat illogical basic assumptions:
1. Each new feature adds value to the product.
That is not necessary. For example, I am terribly annoyed with a nail file in my knife. And I stopped using Nero when it became more than just burning disks.
Moreover, even if the function itself is good, it weights the product, making it more difficult to perceive and use. Moreover, the complication increases as a power function, but the benefit grows arithmetically.
It is easier to make a great simple product than a good complex one.
2. The product should please everyone
And people have different requests, and accordingly, we must offer our solution, our function for each request. The performance comes from somewhere in the prehistoric tribes - where the male should like to all females in order to leave as many offspring as possible. In reality, most of us cannot cope with a couple of dozen partners.
It is the same with projects - you don’t need to be liked by everyone. Much easier to enjoy parts, but much. Look at the iPhone: it does not have a huge number of obvious functions - and success is evident.
3. We are alone in this world
If we do not add a feature to our product, users will not be able to ...
Ah, leave ... Besides, there are thousands of ways to do this. And it is often clearer, simpler and more familiar to the user than our great features. You should not screw your own social network - there is VKontakte and FB for this, you should not write your own instant messenger - users will perfectly cope with already existing ones.
Situation two. Gloss or "I need to shine"
The project is already half a year ready. Beautiful, accurate, almost no bugs. It could be released right now, only you need to tweak a little here ... And we rule the design first, then we optimize the memory, we catch bugs, and then we rule the design. Hone every word in the instructions and system messages. Few alter the work of the first, second and third. The release of the project is again postponed ...
The basis of this situation again lies wrong prerequisites:
1. Our product must be flawless.
It is said that while creating the carpet, the master made one curl of the pattern asymmetrically, so that the carpet was not perfect. Such a curl, translated into Russian, was called "we are alive." Impeccability is a sign of a dying product.
2. Every edit makes the product better.
Each change blurs the original concept. After a while, the design will start to pour in, the texts will become official, and bugs will still appear, but in unexpected places.
If the project does not work “to make good” - polishing will not help. Improvements - like spices when cooking. They are needed, they will help to hide some of the flaws of the original recipe and enrich the taste. But at some point you need to stop - otherwise the food will be impossible to eat.
Or release it "as is" - or redo the whole product, starting with the concept.
Situation three. Check by fight or "the unasserted plane will not break".
The project is ready. But for some reason we are waiting.
Each product release is a test, an exam. For the project team, for the investor, for the customer. To release a product means to lose control over it, it means to get an assessment from the external environment. We want this. And we are very afraid - after all, the assessment may turn out to be bad. And fear - it is always irrational.
So, the next time your project will be late, before you look for excuses, ask yourself: why are you delaying it?
But at the same time, almost everyone who managed projects or even simply participated in them knows that projects are late. And it does not matter whether it will be the production of programs, the preparation for the Olympics or the construction of a nuclear power plant. Projects are late.
Some methodologies simply suggest taking it for granted and somehow adapting themselves (for example, planning only the next stage), others try to impose military rigor by conducting Deadline and introducing a “reaction to deviations”.
')
I want to talk about something else. Not about why projects are late, and how to avoid it, but about why they are late. After all, if you think so - well, is it really possible to reset everything to planning errors? After all, like adults, experienced people, well, can't they be wrong all the time? And if they cannot, then they do it intentionally, right?
I will bring three possible situations to your judgment.
Situation first. Swiss knife or "and also a circle on the photo, and still we sing hunting"
All new and new features are added to the project. Initially conceived, a simple calendar turns into a planning system for the universe with elements of a social network and a gaming component. The creation of each new function takes time and effort, but the participants argue: “this is necessary, as the utility of the product increases for the consumer”.
The basis of this situation is somewhat illogical basic assumptions:
1. Each new feature adds value to the product.
That is not necessary. For example, I am terribly annoyed with a nail file in my knife. And I stopped using Nero when it became more than just burning disks.
Moreover, even if the function itself is good, it weights the product, making it more difficult to perceive and use. Moreover, the complication increases as a power function, but the benefit grows arithmetically.
It is easier to make a great simple product than a good complex one.
2. The product should please everyone
And people have different requests, and accordingly, we must offer our solution, our function for each request. The performance comes from somewhere in the prehistoric tribes - where the male should like to all females in order to leave as many offspring as possible. In reality, most of us cannot cope with a couple of dozen partners.
It is the same with projects - you don’t need to be liked by everyone. Much easier to enjoy parts, but much. Look at the iPhone: it does not have a huge number of obvious functions - and success is evident.
3. We are alone in this world
If we do not add a feature to our product, users will not be able to ...
Ah, leave ... Besides, there are thousands of ways to do this. And it is often clearer, simpler and more familiar to the user than our great features. You should not screw your own social network - there is VKontakte and FB for this, you should not write your own instant messenger - users will perfectly cope with already existing ones.
Situation two. Gloss or "I need to shine"
The project is already half a year ready. Beautiful, accurate, almost no bugs. It could be released right now, only you need to tweak a little here ... And we rule the design first, then we optimize the memory, we catch bugs, and then we rule the design. Hone every word in the instructions and system messages. Few alter the work of the first, second and third. The release of the project is again postponed ...
The basis of this situation again lies wrong prerequisites:
1. Our product must be flawless.
It is said that while creating the carpet, the master made one curl of the pattern asymmetrically, so that the carpet was not perfect. Such a curl, translated into Russian, was called "we are alive." Impeccability is a sign of a dying product.
2. Every edit makes the product better.
Each change blurs the original concept. After a while, the design will start to pour in, the texts will become official, and bugs will still appear, but in unexpected places.
If the project does not work “to make good” - polishing will not help. Improvements - like spices when cooking. They are needed, they will help to hide some of the flaws of the original recipe and enrich the taste. But at some point you need to stop - otherwise the food will be impossible to eat.
Or release it "as is" - or redo the whole product, starting with the concept.
Situation three. Check by fight or "the unasserted plane will not break".
The project is ready. But for some reason we are waiting.
Each product release is a test, an exam. For the project team, for the investor, for the customer. To release a product means to lose control over it, it means to get an assessment from the external environment. We want this. And we are very afraid - after all, the assessment may turn out to be bad. And fear - it is always irrational.
So, the next time your project will be late, before you look for excuses, ask yourself: why are you delaying it?
Source: https://habr.com/ru/post/148662/
All Articles