How not to overwhelm an IT project?

    Everyone knows that a significant proportion of IT projects end in failure. The reasons for these failures are varied, but all who deal with this problem agree on one thing: careful preparation reduces the risk of failure.
    The question is what to do during this training? How to prepare a project so that it ends successfully?

    Why do projects fail?

    It is traditionally believed that you need to plan all the steps, paint the tasks and everything will be fine. However, if we analyze unsuccessful projects, it becomes clear that in almost all such preliminary work was carried out and everything was carefully planned.

    The main reason for the failure of IT projects is NOT detailed plans. The vast majority of projects fail due to underestimation of resistance to change. Then, during the debriefing, it is qualified 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, a business process or something else is created ... The important thing is that until the end of the project the exact parameters of the final product are not known to anyone. This leads to a high degree of uncertainty.

    The second feature of IT projects is that they always entail a change in the way, order or working conditions of people. After all, these are people who 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 a 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 this project will affect. The impact of resistance to change on an IT project is always great.

    Overcome resistance before the change

    I wrote earlier about the nature of resistance to change and how to overcome this resistance.
    I will briefly recall a few important things:
    • the basis of resistance to change is human psychology, and not evil intent, therefore resistance is inevitable;
    • overcoming resistance consists in creating the right motivation for quickly going through the stages of the change curve, you cannot order to live in a new way

    Since IT projects, most often, affect a large number of company employees, the strength of resistance to change is also becoming large and a lot of effort is needed to overcome it. In order not to fail the project, at the time of the beginning of organizational changes, it should have interested supporters who will serve as an example for others and will reduce resistance to changes. Supporters are not only an IT department implementation team, their circle should be wider and it is necessary to engage in the formation of this circle at the very start of the project.

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

    Why is this possible?

    If you recall the curve of changes, then the sharp failure after the announcement of the changes is caused by low awareness and uncertain future - this leads to reflection and lower productivity. If a person is prepared and already has some idea of ​​the future, understands his role in this process, then instead of reflecting on the 1st, 2nd and 3rd stages of changes, he will immediately fall into the 4th stage - he will begin to adapt to changing conditions, taking into account the actions and reactions of others . Thus, being interested in changes, he becomes the engine of the process, not the ballast.

    Graphically, this can be illustrated as follows: 

    During the properly organized process of preparing the project, each of the participants in the working group models and tries on future changes: denies the proposals of colleagues, holds on to his own experience, argues, and so on, thereby experiencing all stages of the change process, without any changes. He becomes more prepared for the moment of the beginning of the reforms and is ready for the negative reactions of his colleagues - he himself experienced them and found arguments in favor of the changes. This can significantly reduce resistance.

    What to do in practice?

    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 the customer is.

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

    If you are an IT company and are implementing 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 the contractor within the company.

    Each IT project must have a Customer, and preferably several, from functional, not IT departments. This dramatically increases the project's chances of success. It will be very cool if the start of the project is fixed by order and put not only in the IT department's work plan.

    2. Declare goals

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

    3. Assemble the team

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

    4. Capture the image of the future

    In the vast majority, 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 definitely change, orders will change. Very often, the implementation team or “leadership”, that is, the drivers of the change process, take this for granted: “Well, it’s clear that work will have to be different,” they say.

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

    5. Find benefits for everyone

    “What will be better?”, “What is important to you?”, “What cannot be allowed?”, “What do you think?” - these are the main questions that the IT project manager should ask participants of the implementation group and employees of the departments involved in the project at the stage of modeling the future - description of business processes. Each of the group members must independently find and fix for themselves what benefit 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” - folk wisdom.
    Consider that which is not fixed on paper does not exist. If you came up with a superprocess, you sat, argued hotly, nodded, but you didn’t bother to document it in a form understandable to everyone - be sure everyone will forget about it in a day and you will start the next discussion from scratch - as if there was nothing! 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 have come up with will be convenient and useful - make sure with this, do not delay until implementation. No need to make surprises for people - tell us about what you came up with, explain how everything will happen and carefully listen to the assessment. Do not argue, even if the assessment is not what you expected. Just take note of this and make the necessary amendments to the project. It is important that
    people get what they expect as a result of implementation! Only in this case, they will provide support.

    8. Make decisions

    Avoiding decision making is a common mistake of an IT manager. If you are asked: “What do you think is the best?”, Do not answer in the style of “Well ... it’s better for you, it’s better ...”. Tell me your opinion, I'm sure you have it.

    9. Plan implementation up to fixing the result

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

    They say a lot about this, but few people bother to get confirmation that the result of the project is in demand and has brought someone benefit. And this is very important. Therefore, when planning a project, you need not be limited to development and acceptance, but also lay down time and resources for evaluating the result by 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 it’s not accepted, write a report at the end of the project. Firstly, it will clearly let you know that it has ended. Often this point is sorely missed. And secondly - this will be an explicit declaration of the project results, which will need to be evaluated. 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 conceived, against the backdrop of disputes, disappointments and sleepless nights, the goals and objectives of the project often dissolve, its results become taken for granted. And without such recording of 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. Perform an analysis of achievements and failures, write about what each unit involved in the project received, evaluate the changes, mark the project participants, highlight those you want to highlight. Send a report to the implementation group and your manager, even if this is not accepted at your company - you will see how positive this will produce a result.

    Also popular now: