How not to fill up an IT project?

Everyone knows that a significant proportion of IT projects fail. The reasons for these failures are different, but all those who dealt with this problem agree on one thing: careful preparation reduces the risks of failure.
The question is what to do during this preparation? How to properly prepare the project so that it successfully completed?

Why do projects fail?

Traditionally it is considered that you need to plan all the steps, paint the tasks and everything will be fine. However, if we analyze the unsuccessful projects, it will become clear that practically all of them had carried out such preliminary work and everything was carefully planned.

The main reason for the failure of IT projects is NOT enough detailed plans. The vast majority of projects fail due to underestimation of resistance to change. Then, when debriefing, this qualifies as a "human factor".
')
The specificity of each IT project is that it implements an intangible idea. In the course of each project, a new, unique product, business process or something else is created ... It is important that until the end of the project the exact parameters of the final product are not known to anyone for certain. This causes a high degree of uncertainty.

The second feature of IT projects is that they always entail a change in the way people work, order or conditions of work. After all, people work with programs on computers. That is, the vast majority of IT projects lead to the need for organizational change.

These two factors: high uncertainty, together with the inevitability of organizational change and form resistance to change. It always arises, in any IT project, in any company. The significance of this resistance is the higher, the greater the number of people affected by this project. The impact of resistance to change on an IT project is always great.

Overcome resistance before the change.

I already wrote earlier about the nature of resistance to change and how to overcome this resistance.
Briefly recall a few important things:

• the basis of resistance to change is human psychology, and not malicious intent, so resistance is inevitable;
• overcoming resistance consists in creating the right motivation for quickly passing the stages of the change curve, it is impossible to order to live in a new way

Since IT projects most often affect a large number of company employees, the strength of the resistance to change becomes great, and a lot of effort is needed to overcome it. In order not to fail the project, at the time of the start of organizational changes, it must have interested supporters who will set an example for others and reduce the resistance to change. Supporters are not only the IT implementation team, their circle must be wider and it’s necessary to form this circle at the very start of the project.

The idea is quite simple: involve key employees in the project preparation work, so that they endure the main negative factors of the impact of changes “on paper” during the project preparation. Then in the active phase, when the changes will actually occur, they will be more prepared and, instead of resistance, will give additional support.

Why is this possible?

If we recall the change curve, then a sharp failure after the announcement of the changes is caused by low awareness and uncertainty of the future - this leads to reflection and reduced productivity. If a person is prepared and already has some idea of ​​the future, understands his role in this process, instead of reflection 1, 2 and 3 stages of change, he will immediately fall into stage 4 - he will begin to adapt to changing conditions, taking into account the actions and reactions of others . Thus, being interested in changes, he becomes a locomotive of the process, rather than a ballast.

Graphically, this can be illustrated as follows:



In the course of a properly organized process of preparing a project, each of the participants in the working group models and tries on future changes: he rejects the proposals of his colleagues, holds on to his own experience, argues, and so on, thereby he goes through all the stages of the change process, without the changes themselves. He becomes more prepared by the moment of the beginning of transformations and is ready for negative reactions of his colleagues - he himself experienced them and found arguments in favor of changes. This allows to significantly reduce the resistance.

What to do in practice?

The theory is good and beautiful, but how to achieve this in practice? To do this, during the preparation of the project, you need to follow very simple recommendations.

1. Determine who is the customer

There are no successful IT projects without a Customer (exactly, with a capital letter). The customer is the one who answers the question “Do you need the results of this project?”, Always answers “Yes!” And in simple words, will very quickly be able to explain what these results are and what benefits they will bring.

If you are an IT company and implement a project for an external customer, then the Customer seems to be a priori. But it's not always the case. It often happens that the customer under the contract is the IT service, which is a contractor within the company.

Every IT project must have a Customer, and preferably several, from functional, non-IT departments. This dramatically increases the chances of a project of success. It will be very nice if the beginning of the project will be fixed by order and put into the work plan of not only the IT department.

2. Declare goals

The project must have clear goals. This seems obvious, but the question “why are we all doing this together” does not always find the answer. It is necessary to fix concrete and measurable goals on paper. Not "improving the efficiency of work", and "reducing processing time ...". This is very important, since it is the achievement of goals that serves as the basis for project support from its participants.

3. Build a team

This is a common practice, when IT projects themselves are prepared by IT projects, they torment everyone with “what do you need” questions, then they write TK for a long time, then they do this TK and no one needs the result. On this subject there are a lot of cartoons and publications. To avoid this, it is necessary that the project preparation team consists of department heads and / or key employees of those departments that will reap the benefits of automation. IT specialists at the training stage should act as experts, as methodologists, but not as project leaders.

4. Fix the image of the future

Overwhelmingly, the goal of an IT project is to change a business process or individual procedures. That is, it is obviously assumed that the work of people will change. The responsibility for entering and using information will change exactly, and the order will change. Very often, the implementation team or the “leadership”, that is, the drivers of the change process, take it for granted: “Well, it’s already clear that you’ll need to work differently,” they say.

But this “need will be different” is the worst thing for employees. It is very important to immerse participants in the process of change into the future — together with them to come up with and describe how the work will be organized, what new tools they will have, how they will pass each other pieces of paper and so on.
Further. It is important that the changes were first experienced in the modeling and description of business processes, and not in their real change. This critically reduces resistance to change.

5. Find a favor for all

“How will it be better?”, “What is important for you?”, “What should not be allowed?”, “What do you think?” Are the main questions that the IT project manager should ask the implementation team members and the staff of the involved units at the stage future modeling - descriptions of business processes. Each of the group members must independently find and fix for themselves what benefits the project will bring to him - this will ensure the success of your transformations.

6. Do not be lazy to write

“What is written with a pen cannot be cut down with an ax” - popular wisdom.
Consider that what is not fixed on paper does not exist. If you came up with a superprocess, you sat, everyone argued hotly, nodded, but you did not bother to document it in a form that everyone understands - be sure that in a day everyone will forget about it and you will start the next discussion from scratch - as if nothing happened! Therefore, if you want your ideas not to be lost - write down, document!

7. Do not think for others

Do not assume that you know something better than others. If you think that what you come up with will be convenient and useful - make sure with this, do not delay to the introduction. No need for people to make surprises - tell us about what you came up with, explain how everything will happen and listen carefully to the assessment. Do not argue, even if the assessment is not the one you expected. Just take note of this and make the necessary amendments to the draft. It is important that
people received as a result of the introduction of what they expect! Only in this case, they will provide support.

8. Make decisions

Avoiding decision making is a common mistake of the IT manager. If you are asked: "How do you think is better?", Do not respond in style "Well ... this is how you would be better, and better ...". Tell me your opinion, I am sure you have it.

9. Plan the implementation until fixing the result.

A very simple rule: “Made” - this does not mean “I did,” it means: “I was told that what I did was useful.”

There is a lot of talk about this, but few people bother to get confirmation that the result of the project is in demand and has brought some benefit to someone. And this is very important. Therefore, planning a project should not be limited to development and acceptance, but also lay the time and resources to evaluate the result of the customer.
Think in advance with him about how he will evaluate the result.

10. Write a report

Even if you are not asked and you are not accepted, write a report at the end of the project. First, it will clearly let know that it has ended. Often this point is not enough. And secondly, it will be an explicit declaration of the results of the project, which will need to be assessed. After all, if there is no result, then there is no assessment.

Against the background of the titanic efforts that the entire company had to make to do everything that was planned, amid controversy, disappointment and sleepless nights, the goals and objectives of the project often dissolve, its results take for granted. And without such a fixation of the results, project participants may remain dissatisfied with their work.

Briefly describe the objectives of the project, give your assessment of whether they are achieved or not. Analyze achievements and failures, Write about what each division involved in the project received, evaluate the changes, mark the project participants, highlight those you want to highlight. Send a report to the implementation team and your manager, even if your company doesn’t do it that way - you will see how positive it will give a result.