Clients often turn to developers like magicians, hoping that they will create a Miracle IT product. It will solve all problems: it will bring in crowds of customers, increase sales, and reduce costs. But this is impossible without the efforts of the customer himself and without accurate economic calculations.
Do customers assess the economic impact of implementing each feature? Are developers given only tasks that will 100% lead to results? Practice shows that, of course, there is planning on the part of the customer, but the backlog of tasks assigned to developers is rarely correlated with business goals and objectives and is even less frequently reviewed. But after months of development without understanding the economic effect, it is easy to come to negative results and go beyond budgets.
Another problem is conflicts of interest between departments and departments. For the team to work effectively and the project to achieve its goals faster, some of the tasks in the backlog should have a higher priority, and some should have a lower priority. If different departments (on the customer's side) do not understand that their tasks are being fairly postponed to suit other tasks, a lot of speculation and conflicts arise.
How exactly to approach the issue of development management planning, taking into account these problems, will be discussed in this article.
Moving in small steps and the Deming cycle
Edward Deming formulated the PDCA model of continuous quality management: plan—do—check—act (Russian planning — action — inspection — adjustment). The PDCA cycle is closely linked to the Agile philosophy and also encourages us to act in short iterations, stay in close touch with reality and check whether we are going in the right direction every time.
For product development to be effective, it is necessary to:
1. clearly define the goal, outline a plan;
2. take the necessary actions in accordance with the plan and goals (do);
3. at every wheel revolution (every development cycle), regularly check whether we are moving in the right direction (check);
4. if our actions do not bring us closer to the goal, adjust them in the right direction (act).
It looks like MVP development principles, right?
IN one of the previous articles We have already discussed that Agile software is a complex system with a large number of factors whose causal relationships are unclear. When ordering development, it is difficult for any customer to anticipate all the problems that programmers will face and formulate requirements for the finished product.
But there are effective ways to add clarity and streamline work. Let's take a closer look at the Impact Mapping technique and unit calculator as one of the DDDM (data-driven decision making) application tools.
Impact Mapping
The Impact Mapping method helps to clearly formulate project goals in accordance with the goals of the entire business. To do this, you need to build an intelligence map with answers to four main questions.
1. Why? Why do you need this product? What business problem should it solve?
2. Who? Who can influence the achievement of this goal?
3. How? What can he do?
4. What? What specific steps should a responsible person take as part of his tasks?
An example of how the Impact Mapping method works
Common development management challenges that Impact Mapping saves from
1. Excessive functionality
Impact Mapping shows the value of every action. If there is no value, it means that this is a redundant solution — we must abandon it.
2. Inconsistency of actions, lack of control and coordination within the customer company
To answer the question “who?” It is necessary to identify everyone who is influencing the solution of the problem. Production and sales managers, marketers and logisticians, and any other employees who can influence the development product and the final achievement of goals should at least meet and discuss all tasks.
Everyone's area of responsibility will be recorded in an impact map. This makes it easier to monitor the implementation of decisions.
What happens if you skip this step is described in the next case study.
We created a B2B portal for a wholesale food supplier. The customer described the functionality he needed, but it turned out that in real life things don't work the way they dreamed. We were able to find out about this only when testing the product by one of the departments, which no one saw fit to involve in creating the terms of reference (another question is why they even needed the terms of reference). The launch of the project had to be postponed.
3. It's hard to compare choices
For each goal, Impact Mapping groups all possible options for achieving this goal. After analyzing and comparing their effectiveness at specific KPI/OKR, we can be sure that our decision is correct (and no hassle of choosing).
4. It is difficult to plan development time and budget
This is probably the most common customer fear of agile development methodologies. But when all actions are broken down into steps, it's much easier to plan, right? If you work in short iterations (for example, two weeks), follow the PDCA cycle, regularly check your actions against goals, and quickly make adjustments in case of deviations—you will agree that it will be easier to achieve success than with a planning horizon of one year or five years.
The main consequence of using influence maps is a clear solution to the customer's business problems, rather than functionality for the sake of functionality.
Impact Mapping example for an online clothing and footwear store
Let's say a customer comes to an IT company — the owner of a large online clothing and footwear store with a request for an urgent website redesign.
Project managers cannot take on a task with this wording, because it does not correspond to the data-driven approach to making management decisions. The first thing you need to ask is “why?” and define the goal of the project, then digitize it, write it down in numerical terms. Otherwise, it will be impossible to evaluate the results and draw conclusions (“we did a great job, we achieved the goal” or “we failed to achieve the goal, let's think about why and how to fix it”).
For example, after a joint discussion, it may turn out that the customer's business goal is to increase sales by 1.5% over the next three months.
Project managers need to do Impact Mapping together with the customer, and the picture may turn out like this: there are four ways to increase sales by 1.5%.
The Impact Mapping method can also be used for B2B portals, for example, estimate the percentage of use of the portal when ordering (ideally 100%). For a CRM/BPM system, the target may be the percentage of users working in CRM out of the total number of employees.
In the case of our customer who wanted a redesign, the question is: maybe he doesn't need a redesign at all? To find out, let's compare all the solutions and choose the most profitable one. A useful method for this comparison is the unit economy. It also helps you test how your values relate to your actual actions.
Let's take a closer look at the most useful tool: a unit calculator, which we always use for e-commerce projects and we recommend that everyone use it before starting a development task.
Unit calculator
Each action (developing every piece of functionality) should ideally be related to some project value. A green button or a new design — everything should somehow change the project metrics and somehow pay off. After all, if development is not related to business value, development costs will seem very high to the customer.
The unit economy clearly shows the profitability of each change in a project or project as a whole: how much does the business earn (or lose) from each order, from each user, and from each end customer. It is convenient to use for this purpose unit calculator in the form of an Excel spreadsheet. Let's look at the most simplified version of such a calculator (in fact, the unit economy has much more influencing factors and much more complex formulas, but this example will help us understand the main principles of calculation).
An example of a simple unit calculator
In this table, we change the values in the influencing cells (user or potential customer flow, conversion, paying, revenue per payer, how much the customer pays on average, costs per sale or commission, purchases per payer) to see changes in the values in the dependent cell (gross profit, or revenue).
You can add any factors to your particular business as influencing cells. For example, different sales channels, the cost of attracting new users, changes in logistics costs, etc.
In some cases, when we receive tasks from clients, we suggest that they first use the unit calculator to assess the impact of implementing a new feature and how revenue will change.
Why do we need this?
We can't afford to work hard; the shortage of qualified developers and the market's demand to constantly improve something mean that the project's backlog is always more than the team can actually do. The features that the client wants to implement should be sorted by priority, and some should be completely abandoned.
A recent example
We are currently working on E-commerce-a project for a major jewelry brand. Payment for orders in their online store is made on the bank's website. The client wants to redesign the checkout and make a form of payment right on the site.
To take on this task, the project manager needs to correlate its value with the project's ultimate business goals. The main problem may be the lack of analytics. What if no one has ever monitored what percentage of potential customers “fall off” during the payment step? Is paying through the bank's website really bad for sales? If the conversion difference is zero or insignificant, then there will be no benefit from changing the form of payment, but at this time we will not be able to create any other, more significant functionality. The effect may be the opposite: customers will be afraid to pay immediately on the site, which will reduce sales. Without analyzing the “before” state, it is impossible to know whether “after” will get worse or better.
In this example, you first need to connect web analytics to collect data for an informed decision. If we see that there really is a problem, we will change the form of payment according to the PDCA cycle: we plan, change it, measure it — if the result is not satisfactory, roll it back.
What should I do after evaluating and comparing all the ways to achieve the goal?
1. If a feature offered by a client does not play a significant role,
Having this information can help the client change backlog priorities.
2. If the unit calculator shows that even a 0.01% change in conversion will give a significant financial result,
It's worth starting improvements from the bottlenecks of the sales funnel. But conversion is not always the main factor. Sometimes it's better to work with retention first or provide the project with high-quality traffic, and only then return to feature development.
Conclusion
When ordering development, customers are usually excited. They think that now they will find the magic pill that will solve their problems. They focus on IT, forgetting about conversions and profitability.
After working with IIDF (Internet Initiatives Development Fund), we firmly learned that it is necessary to compile Impact Mapping and calculate the unit economy of each project before starting work. And then, when introducing any innovations, constantly review and recalculate them.
Ideally, this should be done by the customer. But sometimes we see that development decisions are made without taking into account specific figures, and in such cases we are ready to help with advice.
This is how we are developing a data-driven approach to making management decisions among our customers, and we are happy with the results of this work: bad features have been reduced to zero, clients' business goals are achieved quickly, which is reflected, among other things, in high NPS for our projects (over the past two months, the team has received a maximum of 10 points).
