How do we approach project assessment?
A short guide from the business and technical managers of the ITQ Group development competence center, Daniel Knezhevich and Maxim Makeev.
Hello! Today we want to talk about pre-project research – the stage of development of IT projects.
Let's start with an example. One day, one fintech company rolled out a new functionality for sale. The functionality did not work. We began to look into it and found out that we had not taken into account the necessary changes in the core. system, and without them the new functionality is ineffective. Let's go to the developers. systems: the backlog is full for a year in advance, it won’t be possible to get in out of turn. Two years later, the functionality remains unreleased. Meanwhile, it is important for one of the business areas; its absence carries regulatory risks for the company…
We are sure that you have also encountered situations where projects already put into development greatly exceeded the established budget limits, were stretched over time, were frozen, or were released with severe defects, losing in quality. Or they reached production, but the functionality included in the project turned out to be of no use to anyone, or the project itself was unprofitable. The reason in most cases is the absence of a pre-project research stage, which saves money and resources.
In this material we will look at what a pre-project is for, how to carry it out and how to convince a business customer to spend money on it.
Let's start with the base.
What is a pre-project and why is it needed?
Pre-project is the stage that precedes the design work itself. During pre-project research, customers and contractors understand the goals of the project, their relevance, achievability, scale, etc.
They sort it out – that means they don’t just discuss and record something, but prepare a full-fledged document based on the results of this work.
The purpose of this stage is to evaluate future work, agree on and allocate a budget. Or, this also happens, you come to the conclusion that it is inappropriate to launch the project.
What questions does the pre-project ask and what answers does it provide?
As part of the pre-project, the team forms answers to important questions:
goals and business effects of the project;
business, technical and infrastructure requirements;
project participants: systems/persons responsible for these systems/performers;
determination of an architectural solution (not always performed, but if performed, it significantly improves the quality of the assessment);
scope of works;
time costs.
And receives important information:
a set of customer requirements;
decomposition of work (dividing it into separate tasks);
assessment of labor costs and implementation deadlines;
calendar plan;
agreed budget.
What is the main value of the pre-project?
A pre-design helps make a more informed decision about the feasibility of the project. Roughly speaking, if it seems to you that some new feature simply needs to be implemented in a banking application, then after the pre-project you no longer think that you are sure of it. Either they were convinced of the opposite: the feature is not so necessary or implementation will be unprofitable.
The same applies to the launch of new products and the development of complex systems: a pre-project makes it possible to assess as closely as possible both future costs (in order to subsequently include them in the budget) and the potential benefits from implementation. And connect one with the other.
In addition, pre-project research allows project participants to agree and better understand each other's goals, objectives and limitations.
How does a pre-project work with risks?
Project risks are associated with unplanned budget growth, missed deadlines, loss of quality, or the inability to implement the project in principle.
The reasons may be different: design errors, business requirements that were not taken into account, lack of specialists with the necessary qualifications, lack of human resources, and finally, loss of employees due to burnout (if people have to work for two people day and night to meet deadlines, The budget is not enough and you have to sacrifice quality).
Another example: we launched a project with a top-level estimate without diving into the details. At the implementation stage, we realized that some of the work had not been taken into account. Current resources: human and budgetary were not enough to implement the project within the given time frame. And the timing in this case was critical. As a result, the scope of work had to be cut, functionality suffered, and the business effects of the project were not fully achieved.
And if a pre-project had been carried out, then the difficulties that arose during implementation would have been clear even before the start of development. The team would have the opportunity to decide what to do about it: increase the budget, increase the timeline, or adjust the business requirements.
If there is an analytics stage, then why do we need a pre-project?
Most likely, some readers by this point have already had a question: don’t all of the listed works belong to the analytics stage? Maybe a pre-project is the same analytics, just under a different name?
No. A pre-project is a top-level assessment, determination and coordination of global goals. At this stage, the budget is formed. And at the analytics stage, they do not deal with global goals – it is assumed that they have already been approved, like the budget. And if during the analysis it suddenly turns out that there is not enough money, it will be difficult to agree on additional funds. As a result, you will have to sacrifice project goals or skimp on quality.
Pre-project stages
Let's look at the main stages of the pre-project.
Stage 1. We agree on the goals and business effects of the project.
At this stage, we clarify the goals and expectations of all stakeholders. Goals should be clear to all participants, unambiguous, and lead to a tangible business effect, which ideally can also be measured.
For example:
Launch a credit pipeline that will lead to increasing the customer base by 20% and increasing the speed of processing loan applications in the mobile application by 2 minutes.
Change the credit card issue button in MP from red to green, which will attract + 100,000 clients.
Develop a new system and transfer 100% of users there from an application that does not meet the regulator’s requirements.
Review and change the banking product registration process to improve the user experience: Reduce the time required to complete an application by 2 minutes and reduce the number of support calls by 35%.
Measurable indicators are needed so that at the end of the project you can evaluate how successful it was. Additionally, other parameters can be developed: compliance with the budget, deadlines, quality, completeness of implementation.
Stage 2. Formulate business requirements
At this stage, we collect the most detailed business requirements from all stakeholders so that there is clarity regarding solving the problem at the business level: what exactly needs to be done and how. Afterwards, we assess the scope of the requirements, make sure that they do not contradict each other, and estimate the costs of implementing the project.
End-to-end stage. UI design
It seems that this certainly does not apply to the pre-project, because UI is usually designed at the analytics stage or after it. Why do this before?
Because this will help to better evaluate the scope of work and, most importantly, will enable customers to see the final result and understand whether it meets the set goals and objectives.
If you design during or after the analytics phase, then when it turns out that the UI of the future system should work differently, and this differently involves more work, more resources and more money, you will have to face a difficult choice: cut the budget or cut the business -requirements. Or roll back the development and start the analytics stage all over again. And this is time and money.
Stage 3. Forming an architectural vision for the project
At this stage, we should have a list of systems that will participate in the project: existing ones and those to be created. Understanding how these systems will be integrated with each other. This will give you an idea of the necessary modifications.
Architectural solutions are often overlooked at the pre-design stage. For example, in one of the projects at the initial stages (pre-project and even analytics) all systems were not identified. As a result, there was a major failure during the implementation phase. We had to roll back improvements from sales, spend significant time on corrections, and negotiate with related teams so that they urgently take on new tasks. Result: a time shift of two months and plus 3 million budget.
Stage 4. Determine the scope of work
Here we decompose business requirements into small tasks that need to be completed to implement the entire project. After the scope is ready, we turn to the previously collected business requirements to make sure that they are all taken into account and the tasks are fully decomposed.
Stage 5. We begin to evaluate the project: participants, types of work, resources
We take a scope of work and evaluate the resources (analysts, testers, developers, etc.) and the amount of work for each role. As a result, we obtain data on the number of man-days for the implementation of each task and the project as a whole.
Important point. Some types of work are forgotten to be taken into account in the estimate, and as a result, the budget and deadlines are missed. So don't forget about these tasks:
unit/auto/load testing;
checks for compliance with safety requirements;
acceptance tests;
preparation of instructions for users;
preparation and execution of applications for network access.
Is it possible to take everything into account in a scope? Of course not.
Therefore, in addition to the volume estimate, we include:
20% – when everything is clear
30% – there are gray areas
50% – when there is a lot of unknowns (in general, this means that the preliminary project was done poorly).
Stage 6. Determine the methodology for conducting the project.
The methodology stage is needed in order to formulate and agree on exactly how the project will be managed.
What questions do we answer:
What methodology do we use: WATERFALL, SCRUM, KANBAN, etc.
What are our development standards:
Is there a code review?
Preparation and review of technical, test, architectural documentation? If yes, at what stages?
How and what kind of testing is carried out?
Other questions that relate to the development process and will help the team make it more transparent.
How will interaction between teams take place:
How are teams synchronized?
Who participates in the meetings: RP or team representatives?
How often do meetings take place?
How and with what frequency do we synchronize with the business customer?
How are acceptance tests carried out?
Etc.
This stage seems less important than the others, however, it helps reduce the time for building an interaction model and increases work efficiency. If possible, you need to devote time to him. The minimum is to decide on the methodology, the procedure for preparing documentation, and the scheme of interaction between teams.
Stage 7. Develop and agree on a project plan
We take our scope and:
We prioritize tasks and planned time frames for their implementation;
draw up a project map;
We coordinate the work and the project map with customers and project implementers;
We form control points for the implementation of the plan: how we will monitor the progress of the project.
The plan also indicates which tasks are carried out in parallel and which ones sequentially.
Stage 8. We agree and approve the budget
Then we calculate the budget and prepare a presentation to defend the project so that money is allocated for implementation. In the presentation we usually indicate:
goals and business effects;
required resources;
budget;
profitability.
That is, as a result, you will have two documents in your hands. The first is more complete and detailed, formed based on the results of pre-project research, the second is a presentation with the most important aspects of the future project.
What is needed to make a preliminary project
If we are talking about introducing a new feature into an existing application, some changes or improvements, you can do it in a couple of weeks.
If you are preparing to start a serious project that will last a couple of years, budget for at least two months.
For the pre-project, we need: an architect, an analyst and a project manager, who will communicate with development and testing leads at different stages. And, of course, money.
To pre-calculate the costs of a pre-project, you need to take into account the volume and nature of the business processes for which you plan to create a new system or feature, the number of screen forms, integration and modification of the database. As a result, you will receive an estimate of the labor intensity of the future research and a list of specialists who will need to be involved in it. Based on this data, you can calculate the timing and cost of the preliminary project. If you average, the normal cost of a pre-project is no more than 5% of the forecast budget of the project itself.
If the pre-project is so good, then why don't they make it?
From our personal experience, we were convinced that 80% of projects start without a pre-project analytics stage.
Firstly, no one wants to spend time and money on this. In large businesses, money is allocated for the implementation of the projects themselves as part of annual planning. Pre-project studies often concern next year's projects, and there is usually no budget for this.
Secondly, it always seems that it is better to start faster, but you can sort out the details at the analytics stage.
And finally, politics. It happens that for a business customer a project is a stepping stone to a new position. If at the pre-project stage it turns out that the project itself is not viable, the desired increase will not occur.
How to argue the need for a pre-project to business customers and is it realistic?
To convince colleagues or customers that you need a pre-project research stage, rely on the following points:
1. A preliminary project will help create an accurate budget for the project. A situation where there is simply not enough money for implementation will not happen.
2. The accuracy of estimating labor costs and implementation deadlines will increase significantly – you will meet the deadlines, and the development team will not burn out and run to quit.
3. Business requirements and functionality will be as stated: you will not have to give up anything in the process, or release a half-finished product that will not meet the original goals.
4. You will be able to evaluate the profitability of development, rather than focusing on the approximate financial effect.
In other words, by investing in the pre-project, you reduce the uncertainty in the project. If the level of uncertainty is high (many business requirements, systems and improvements), then the risks of force majeure are also high. And they can result in significant losses. Whereas the costs of the pre-project are always planned and are kept within 5% of the project budget.
And one last point. If we are talking about in-house development, then it is easier to agree on a pre-design. If you work for an outsourcing company, then tenders await you. And tenders are often about “making a Cybertruck at the price of a Moskvich.”
It seems that asking the customer to first spend money on pre-project research is an unrealistic task. However, if the customer is interested in the quality of the final product and wants to work with an experienced team that has expertise in the industry and similar tasks, then this point can be agreed upon.
Share in the comments your experience with pre-project research and how you can convince business customers that they are really needed.
