Creating a project management system at Yandex Tolstoy Camp. Part 2

    According to statistics, about 50% of IT projects go beyond the budget, time or do not fully meet the expectations of customers. Among other reasons are deficiencies in the management process, blurring of the project boundaries (in particular, due to a lack of control over these borders) and the lack of consideration of project risks. We raised these problems in our last article .


    If you want to know how we at e-Legion deal with these problems and make projects successful, welcome to cat.

    Project price

    Note: this section may seem captained to experienced managers. If you get this feeling, just go to the next section =)

    Let's start by understanding what the price of the project that the studio puts to the customer is made up of. The following is true for all custom development companies.
    • Cost of work - an estimate of the work required in the project in hours, multiplied by the cost of the hour. Usually separately considered the cost of analytics and design, development and testing. The average project is 60-70%.
    • Margin is, in fact, the earnings of our company. On average, the market margin is planned at the level of 20-40% (without taking risks into account), but often the project results turn out to be less due to underestimation of risks.
    • Often part of the margin is reserved for risks. If we know that on average in projects we are mistaken with estimates of 10%, it is logical to take this error into account in advance and raise the price for the client a bit so as not to lose our profit. On average, the risks associated with the project are at the level of 10-20% (in addition to 20-40% of the margin).

    It is clear that the price has a upper limit - the price of competitors, how much the customer is willing to spend. How can you influence the price?

    • The cost of work directly depends on their volume (what the customer asked to do is an objectively irreducible parameter) and the price of an hour (which depends on many factors, the description of which is beyond the scope of this article and which, in fact, cannot be changed within the framework of one project, but only within the entire organization).
    • Margin - in principle, for a prospective customer, the first project may be with zero or even negative margin (i.e. unprofitable for the company). But in general, any company wants to make money and does not want to share margin.
    • Risks can be divided into two parts: fixed (depends on the organization, client, project, developers who will work on the project, possible illnesses of employees, etc.) and on “risks of ignorance” (which reflect what usually great uncertainty - there are no exact requirements, implementation details are not clear, etc.).

    From the above, it can be seen that reducing uncertainty seems to be the easiest factor to change. Let's do it.

    Project Evaluation

    How to reduce uncertainty? Clarify customer requirements, understand what components the system will consist of and what functions it will perform. The more we think about the project in advance, the less likely it is that during the project new tasks will appear that will have to be performed at our own expense.

    During the evaluation, do not forget that the evaluation itself is also not free. On average, an evaluation of a project received from a customer takes from 2 hours to 1 week and requires the involvement of developers, analysts and testers. Thus, the evaluation of one project for a company costs about 10 to 100 man-hours! Given the fact that not every evaluated project is sold, the company's costs reach rather large amounts.

    Our decision

    We decided to try using the Mind map (connection diagrams) to compile the project structure and evaluate them: The


    central element of the Mind map is the name of the project. Its children are components of the future system (for a mobile application, screens; you can use custom scripts or other components that are clear to the customer). Next, for each screen, its main functions are recorded. Common components (for example, dialog boxes) sooner or later are taken out in a separate parent element of the first level. Without spending more time and not applying any secret skills, the team of appraisers gets a much more detailed map of the future application. The level of detail is such that the most recent elements of the Mind map rarely have an estimate of more than 4-8 hours.

    If it is not possible to give an accurate assessment of any element, we can add some element that reflects the risk:


    The customer is given the details of the assessment at the level of the very first child elements. These elements reflect some business components (use case, application screen) and therefore are understandable to customers.

    What is most interesting, during the course of the project it turned out that this map is also much more accurate - the number of unexpected tasks has greatly decreased (exact numbers - at the end of the article).

    Project progress

    Let's say the project is sold and it’s time to implement it. At this point, many make a mistake and lose the connection between the elements of the application that were identified during the evaluation and sold to the customer, and the tasks that start up in the task tracker. And many do not make such a mistake =) and, nevertheless, spend a lot of time monitoring that the amount of work in the task tracker corresponds to the sold estimate at the end of the project. Many task trackers either do not allow you to organize multi-level hierarchies at all, or they allow you to do this unintuitively. What problems did we have?
    • Due to the loss of communication, it is very difficult to understand that any additional task that appeared during the project leads to exceeding the “sold” estimate and we begin to implement it at our own expense.
    • Due to the lack of a good representation of the task hierarchy in the tracker, it is difficult to understand the status of the readiness of a particular function (in our case, the screen of a mobile application). When such a need arises, PM must manually view the entire list of tasks in the tracker and understand if there are any unfinished tasks related to the screen of interest to us.


    And here the Mind map came to the rescue. The same Mind map, which turned out during the evaluation, is also used in development - tasks of the lowest level are entered into the tracker and are given for execution. Knowing the structure, PM (and other project participants) can easily determine which tasks are under the node corresponding to a particular screen. The node itself contains information about the initial assessment, so PM immediately notices its excess (when a new task appears) and can take action.

    Status is noted on “low-level” tasks — those that developers work with in the tracker — and is “broadcast” to higher levels of the chart. This allows project managers and CTOs to easily see the status of the entire project:

    gray - the problem has not yet been started, green - the task is ready, yellow - the task is at work, red - there are some problems.

    If necessary, you can quickly understand what caused this or that problem:


    You can apply a filter to tasks that require the attention of a manager:


    An additional bonus that we never expected was a significant reduction in testing costs. It is explained by the fact that the developers saw the status of a particular screen and tried to complete the tasks associated with it before starting work on a new screen (we transfer the application for testing on-screen or by client’s business features). And if earlier it happened that the developers sent screens for testing on which there were incomplete tasks, now fully completed screens began to come into testing.

    The complex economics of prime numbers

    Promised Results.

    In projects that used the new approach, the following improvements were noted:
    • 20% reduction in testing costs.
    • 50% reduction in excess of initial estimates (due to more accurate assessment and control of excess estimates).
    • Project managers began to spend 5-10% (subjective assessment) less time on team control and due to this they were able to communicate more with the customer.

    How can this affect the profitability of the project? Let's assume that the project price is 100 conventional units. In accordance with the price structure explained above, the margin and risks in such a project is approximately 30; development costs - 60; for testing - 10. Let’s say the risk shooters “ate” 20 units, i.e. the real margin was only 10. With the risks reduced by 50% (10 cu), and testing costs - by 20% (2 cu), the margin could increase from 10 to 22 - i.e. more than 100%!

    What's next?

    Having tested the new approach on several projects, we decided to bring light to the masses to share our experience and automate our tools and processes. To do this, several volunteers went to the Tolstoy Startup Camp and are currently developing a SNAP project management system that implements the described processes.

    Automation is so far seen in the following places:
    • Integration of the Mind map with the task tracker - now quite a lot of time is spent on keeping the Mind map up to date
    • Automation of control of initial assessments - now managers control this manually, in the future, when approaching the initial assessment, yellow and red bulbs will light up =)
    • Project Templates
    • Perhaps - a knowledge base about project risks for statistics and more accurate risk accounting
    • And for the management of the company - a top-level “map” of the entire portfolio of projects with its budget and goodies like resource planning between projects.

    The SNAP team will be happy to answer questions about the applied methodology, and can help you learn how to use Mind maps to evaluate and manage your projects.

    How do you rate your projects?

    Also popular now: