Taming Chaos: How to Manage Risks in IT Projects and Not Lose Money

How often do you find that some processes in your life do not go according to plan? And the thought constantly pops into your head: why didn’t I predict this, it could have been avoided. Unfortunately or fortunately, it is simply impossible to foresee all possible developments, even the efficiency is not 100%.

Such situations are especially relevant when there are two parties, for example, the customer and the contractor. And the IT sphere is no exception. Let's consider a situation where you have agreed on the scope of work, and then the customer says: "just add this small feature", then it's no wonder that it will entail a dozen more interrelated tasks. It is at this moment that we face the risk of "not meeting the budget or deadlines". Therefore, competent scope management and risk assessment help keep the project under control.

Risk management is not just boring bureaucracy, but a vital skill that allows you not only to avoid disaster, but also to reach the finish line with a profit and a satisfied customer. In this article, we will consider how risks arise, what they are and how to manage them. But first, let's get acquainted.

My name is Nikita Rossikhin, I am the head of the project office at RDN Group. Our team specializes in developing complex and high-load solutions for industrial companies: personal accounts, trading platforms, portals and integration projects. RDN Group is one of the few 1C-Bitrix partners with the competence of large corporate implementations of an advanced level, which is needed to complete Enterprise projects. I have 10 years of experience in IT project management, so I am ready to share my knowledge with you.

Two pillars on which risk management is based

Over the course of my work, I have identified two main risks to which any problem boils down – this is a budget risk with the legal framework of the contract and the complexities of the account of interaction with the customer (not to set the customer against yourself and at the same time be within the legal framework) and the risk of changing the scope of work. But in fact, this still ultimately boils down to a budget risk. Since the risk of changing the scope of work entails a time risk, and here we will immediately include the risk of the quality of work, because you can counteract the risk associated with an additional volume of work with fact tracking. In simple terms, this is when you overwhelm the project with resources if you do not have time to do something, but you must remember that in this case the budget increases. And, accordingly, everything flows into a budget risk.

In addition to financial risks, one should not forget about the human factor, since one of the main resources on the project is people. The departure of a specialist from the team is always a loss of knowledge, experience and expertise, which can be critical for the successful completion of the project.

In such a case, there is a need to urgently find a replacement and adapt the new employee, immerse him in the project. This process requires time and resources, which inevitably leads to an increase in budget costs.

Starting line: contract and presale

Let's start with the basics. Before you dive into the depths of code and design, you need to sign a contract. Determine whether Fixed Price or Time & Materials is more beneficial for you. This will determine your risk management strategy.

At the same time, remember about the budget; if it is not agreed upon, then it may not even get to the conclusion of an agreement.

Since the preliminary stage of any project is pre-sale, we, starting to communicate with the customer, already take on a certain risk, since we do not yet know whether this project will become ours or not. But we are already spending the resources of our employees on it.

The grade is approximately as follows: if the project is Enterprise level, then we are ready to spend several months working on the pre-sale, but if we see that the customer does not fully understand whether he needs this project or not, he does not have a formed need, there are no problems, then you can spend a lot of time just selling the idea of implementing the project. And then the question arises, is the game worth the candle? If the customer has not defined the needs, does not have a clear vision of the final product, be prepared for the fact that the pre-sale will turn into a long and tedious process of "selling the idea".

Risk, appetite or what we are willing to do

Important: "At the pre-sale stage, it is necessary to clearly assess your risks, understand how "mature" the customer is and whether you are ready to invest time and resources in this project." In turn, we assess the maturity of the customer based on internal criteria.

After that, you need to determine your risk appetite – what risks are you willing to take for the sake of potential benefit. Conduct lead scoring, evaluate the potential customer and their project.

Many companies refuse the classic "Waterfall" and do not want to start a project with PPO, in which case we evaluate the project based on our expertise using the resource approach.

After that, we move on to a detailed assessment of different blocks. We like the approach in which each employee assesses their block of work; most often, this approach involves the Team Lead, developer, analyst, designer, etc.

It is recommended to add a certain percentage to this estimate – a kind of "safety cushion" that depends on your direct and indirect costs. The risks are explained by the lack of technical specifications, software and the fact that "appetite comes with eating" – the customer will want more functionality than originally planned.

Roadmap and project profitability

Once the budget has been determined, it is necessary to create a project roadmap, which reflects the relationship between time, resources and cost. At this stage, it is important to remember that creating a product is a joint effort between the development team and the customer.

Customers often forget that deadlines depend not only on us, but also on their timely provision of information, coordination of stages and feedback.

Include time in the deadlines for approvals and iterations, which can be from 3 to 6.

Also, allow more time for the most critical modules.

And don’t forget about the main thing – the profitability of the project.

Profitability may suffer due to team downtime caused by delays in approval by the customer. To avoid this, it is necessary to clearly spell out the terms in the contract and remind about the deadlines in a timely manner. If the contract specifies two iterations, but in fact there are more, then it is necessary to close with additional work, since the implementation of functionality that was not included in the project is an additional resource.

Read more materials on this topic in Compass CIO

Legal protection and labor cost assessment

Often, a project always turns out to be much larger than its cost was estimated, in connection with this, at the stage of concluding a contract, it is important to work out all the risks with a lawyer and to describe the progress of work in the documents in as much detail as possible. However, it is impossible to calculate everything, so it is important to maintain contact with a lawyer in case of concluding additional agreements.

One of the most common situations in project activities is a discrepancy in the assessment of labor costs between the developer and the customer. You have signed a contract, estimated the task at a certain number of hours, but in the process of work it turns out that the client sees it as much more labor-intensive, while refusing to pay for additional work, since for him the formulation of the task has remained the same. In such cases, it is necessary to competently build the process.

When using a hybrid approach, the essence of the work is as follows: each task is considered as a separate project with its own life cycle, including the stages of analytics, design, development and testing. The life cycle of each task begins with analytics, where the scope of work is determined. The key point is the approval of the technical specifications (TS) and design layouts (if there is a design) for this task. After these artifacts are approved, any deviations from them should be treated as additional work.

It should be noted that the success of a project depends on the ability to balance between satisfying the customer's needs, meeting deadlines and ensuring the profitability of your business.

Acceptance and release: area of responsibility and testing

Successful completion of the project depends not only on high-quality development, but also on the competent organization of the acceptance and release process. It is necessary to specify in the contract in advance:

• Acceptance Criteria: Clear criteria that the system must meet for successful acceptance by the customer.

• Integration testing: The need to conduct integration testing to check the compatibility of the system with other customer systems. If the customer refuses to conduct testing and says that he does not want to spend money on acceptance, it is important to specify in the contract that further responsibility passes to the customer. We transfer the correct code that runs on our servers.

• Area of ​​responsibility: Delineation of responsibility for errors and shortcomings that arise on the customer’s side (for example, due to incorrect data).

• Feedback deadlines: Regulated deadlines for the provision of feedback by the customer. In case of violation of deadlines, the contractor is not responsible for the shift in release dates.

Release: Prepare for the unexpected and have a plan "B".

Even with careful preparation for the release, there is always a risk of unexpected problems. Therefore, it is necessary to have an action plan in case of failure. If errors are detected on the customer's side, it is necessary to promptly solve these problems, working in force majeure mode. I note that such situations are best solved by decomposing a large problem and then consistently eliminating the shortcomings. That is, understand the problem, prioritize the errors and break them down into sub-problems.

Risks when moving a project to technical support

When a project is transferred to technical support approximately one month before the release, it is recommended to:

• Form a legal basis: Draw up an agreement that clearly defines the boundaries of responsibility, the composition of the support team (pool), service levels (SLA) and the procedure for accepting tasks. This will help avoid disagreements and clearly understand who is responsible for what.

• Establish personal contact: Don't limit yourself to a formal contract. Conduct "behind the scenes" negotiations to establish trusting relationships with the support team and the customer. Discuss the details of the interaction and find mutual understanding. This approach will not only legally protect your interests, but also create a favorable atmosphere for effective technical support, ensuring stable and reliable operation of your project.

Risks are everywhere, but you shouldn't be afraid of them, the main thing is to learn how to manage them. Risk management in an IT project is a continuous process that requires experience, flexibility and open communication with the customer. Only with a competent approach can you avoid conflicts, meet deadlines and budget, and ultimately create a successful product that meets the customer's needs – a project that will truly meet the company's business needs, and not just be done for show as part of the digitalization trend.