How adoption metrics help IT project implementation

This approach, in the classical sense, can be attributed to IT products focused on results. The main goal is to determine as fully as possible the functional set that the product must perform to meet the initially identified customer requirements, and to determine those that can be implemented in the current project.

Project scope, or project boundaries, by decomposing the global task, shows us what part of the final product will be implemented in the current project. Simply put, we define the line between what we implement now and what we will postpone for later or refuse altogether. Project boundaries help us not only to qualitatively plan the scope of work, but also come in handy for containing the customer's exorbitant desires. The most important thing is that when defining project boundaries, you need to use functions, not entities of the subject area, which can lead to a number of negative consequences.

In addition to product-oriented projects, we should not forget about result-oriented projects. The result can be assessed both from a financial point of view and from the company's image (socio-economic point of view). Almost always, the customer of the project evaluates its effectiveness by the return on investment and the time it takes to reach full payback. At the same time, the contractor (IT unit) must use existing project management standards for an objective assessment of the work performed. If you look from the side of the IT project manager, he must answer three questions:

1. whether the project met the planned resource requirements;

2. whether the project was completed within the planned timeframe;

3. whether the project was within the planned budget.

If the answer is “yes” everywhere, the project can be formally considered successful. In any case, proper planning, task decomposition, collection and analysis of business requirements are already half the success of the project. But do not forget that the success of the project is not identical to the success of the product and does not guarantee a full return on investment and profit.

Here we cannot do without correctly formed metrics of survival and a clear understanding of what kind of business process reengineering needs to be carried out (if necessary).

Adoption metrics are quantitative indicators of the project that allow you to evaluate the performance and operability of the model. Metrics are necessary to focus on the project indicators, both from the side of the business customer and the product team, since the development process and business process reengineering are two inseparable actions within one company. Any IT solution should improve processes and go, at least, within the framework of the company's strategic goals, and ideally – ahead of them, offering innovative solutions. If from the development side, success depends mainly on defining the requirements for implementation, work planning and the competencies of the team, then from the business side, the main success at the stage of implementation in the business model is overcoming psychological barriers to change. Often there is a fear that a new IT solution will completely replace you as a specialist.

From personal observation, I will note that during my work in business analysis of an IT company, closely interacting with the customer, the level of resistance to change increases with increasing work experience, but there are exceptions. Basically, these specialists have spent their entire professional life in certain familiar conditions and do not want to leave their comfort zone. The most open to innovations are young specialists who are just starting to try themselves in various professional roles, do not like routine and see horizons for expanding their experience through automation of processes. If it is easy and quick to work with the second group, then with the first one, sometimes it is necessary to use change management tools.

Every specialist, regardless of age or position, should be involved in the process of development, implementation and operation. Yes, unfortunately, very often the fate of a finished product can depend only on the human factor. To avoid this and competently implement a ready-made IT solution, in “difficult” situations, it is necessary to use the KPI tool (key performance indicators – these are numerical indicators of activity that help measure the degree of achievement of goals or process optimality, namely: effectiveness and efficiency, in extremely rare cases, administrative resource, in the person of a senior manager). Using our product as an example, we can say that after two years we have reached maximum consensus and well-established the process of interaction with representatives of the business customer.

Most of the metrics for our projects (both current and historical) can be viewed by opening the analytical data platform. Below is an example of survival metrics: the number of sessions, which show how often users use the implemented product, and the number of users themselves, where we see that after the launch of the product, in the second month there was a deterioration in the indicators. Having received these statistics, we quickly analyzed the causes, identified the factors and took measures to stabilize the situation (including minor refinement of the product), after which the indicators stabilized and were fixed at a level higher than at the start of the project.

My clear conviction: correctly defined metrics at the requirements development stage and, if necessary, their clarification after implementation are beneficial to both the customer and the development team. This allows you to create a popular and convenient product, shows the need to monitor the survival rates. Ideally, the described situation should not be allowed, monitoring should be carried out from the first day of launch, in addition, it is necessary to collect feedback from users on compliance with expectations regarding the availability of information and ease of use.