Ideal requirements come back

In past parts

In the first part, I announced a series of articles on the work of the analyst in the pre-project. It listed the problems, solutions and principles that need to be remembered when starting an IT project.

In the second part I talked about the frequent problems of the pre-project.

In the last article we discussed the first part of the basic principles:

• IT system design and IT product classification.
• V-model levels and system life cycle.
• A look at the system as a financial asset.

In this article we will finish with the description of “how to”, to further discuss what to do if it does not work out correctly.

What you will learn from this post:

• On the cone of uncertainty and design phases.
• How the assessment works.
• About the full complement of the tasks of the pre-project phase and the values ​​realized at the same time.
• How to get enough resources for a pre-project.

If you do not want to wait for the next parts of the cycle, you can watch the video of my report, on the basis of which this series of articles is written.

System Life Cycle and Cone of Uncertainty

The cone of uncertainty is one of the central concepts of design and modern project management. The essence of the concept: the less information we have, the higher the uncertainty, which can be expressed in the form of scatter of terms and cost of the project.



Each phase of building a system removes some of the uncertainty. When passing through the typical phases of the project, the uncertainty decreases exponentially:

• When we have an idea expressed in a half-page brief, the spread in cost and impact can reach several orders of magnitude.

• When business requirements have arisen, and the business plan or business model has been worked out, we reduce the cost / benefit spread to order.

• To further reduce the spread, you need to work out key decisions on the appearance and design of the system. Such a study reduces the spread to half order. Despite the fact that the spread is still large, the analysis of the ratio of returns and costs gives the main decision - whether we will build the system or look for something more profitable.

• By specifying the conditions in which the system will be built (who will do it and at what time), we can reduce the cost spread to values ​​with which you can work with project management methods, laying stocks and processing risks. The specified conditions are recorded in the technical task.

• Only technical design provides an almost accurate estimate with an error acceptable to the business.

What follows from this:

• In terms of resource allocation, we should have time to roll up the project before we spent a significant share of the cost, if it has ceased to be profitable. Phases from brief to technical design should occupy a small fraction of the total cost of the system.

• You also need to understand that you can not come up with the idea and immediately lay the cost. When they tell you that there are 20 million here and that’s for sure, having only a brief, don’t believe it, it doesn’t happen that way.

• Business requirements and conceptual work should be done, as they remove uncertainty, but it may not fight back if the project does not start. As a result, the phases should be as cheap as possible, but qualitatively remove uncertainty.

How the assessment works

There is a common misconception that impedes the normal launch of pre-project work: if we cannot quickly provide an accurate assessment, then we should not bother with the requirements at all. This is not true. The sum of inaccurate estimates more precisely is a fact from probability theory.



In this case, the pre-project study should give a division of the system and work plan into several dozens of comparable parts, and an assessment for each part should be done by analogy or a more accurate method. The sum of the estimates will have a smaller variation than each individual estimate.
If the quality of the conceptual development does not allow to get the division of the system into parts acceptable for evaluation, then we do not reduce the scatter of the assessment and there is no sense in associating with such development.

The phases of the project in terms of assessment mode are as follows:

• When there is an idea expressed in a half-page brief, we are able to evaluate by analogy.

• When we have worked on business requirements, a business plan or a business model, we can single out the key parameters of the system and make an assessment by analogy with the use of a large-scale factor.

• The concept gives the division into several dozen parts and works, which allows you to sum up the estimates made by analogy, and calculate the key risk management plan.

• The terms of reference replaces the assessment of parts of the system by analogy with the obligations of suppliers by type of work. Assessments of parts made by analogy are converted into expert assessments. The risks of error in assessment are passed on to suppliers.

• Technical design provides the division of the system into hundreds and thousands of parts, each of which is evaluated expertly or with the involvement of statistics on the implementation of previous projects.

If the essence described above is not included in the pre-project works, they are best not to do. In order to achieve a real reduction in uncertainty, it is necessary not only to increase the thickness of the documentation package for the system, but also to ensure that there are measurable and implementable requirements and solutions.

Another common idea is: "Business requirements should not be measurable." Remember - this is a lie!

What you need to achieve in the pre-project

In the previous parts, this was discussed in terms of problems. Now I will briefly repeat what tasks should be set and carried out in any pre-project:

1. Understand the time and cost to plan costs and make a go / not go decision. It is advisable to predict the effect and impact to speed up this decision.
2. Complete the system:
   
   
   • Show the customer an understanding of his goals.
   • Show users the solution to their problems.
   • Successfully complete the auction for the budget (it is always there).
3. Create a basis for acceptance (a contract for the volume and quality of the result - a technical task), do not forget to put in the plan the validation of the resulting system in terms of the practical justification of the expectations of all parties.
4. Determine the resources: types, stages, terms, volumes of work and sources of resources in order to confirm the estimates of the performers and fix the cost of the system.

If such tasks are not set explicitly and their solution is not planned, it is better not to waste time at all - this project can become successful only by chance.

Why it may not (or may not) work

As a result of all the previous arguments, we have 3 conflicting conditions:

1. Pre-project analysis needs to be done quickly.
2. Pre-project analysis should be done cheaply.
3. Pre-project analysis should be done qualitatively.

Those who are familiar with the rule of the project triangle, understand that this does not happen.

There are a few additional difficulties:

1. Pre-project analysis may show low returns on the proposed solution, and this will become uninteresting to the customer and sponsor.
2. Pre-project analysis can increase the scope of the project or the total cost of ownership regarding the initial assumptions, and this will again become uninteresting to the customer and the sponsor.
3. Pre-project analysis can reduce the scope of a project with respect to initial assumptions, and it is often not interesting for an external contractor.

In connection with all these difficulties, I want you and I to understand one thing: the problems of a pre-project are insoluble if we do not side with the sponsor and do not look at the IT project as a financial asset.

In the comments to the previous article, the opinion was expressed: “The pre-project should be opened as soon as possible, but it should be borne in mind that the scope of the pre-project is limited by its effectiveness. Such a pre-project is considered effective, after which the project will be launched. This is the main key indicator of the effectiveness of a pre-project. ” (c) WizardryIB

This is a fairly common point of view among project managers. After all, if something is entrusted to you, you have to kill yourself, squeeze the team down to the ground, turn out the suppliers to the breaks, rape the customer, but reach the goal.

On the other hand, if the project manager closes his own project, he will reduce his own workplace.

The correct approach is to get rid of a bad asset as early as possible. The task of the analyst and the manager in the pre-project is to do it.

How to get the budget for the pre-project

In order to tread the path to a constructive and consistent removal of uncertainty around the IT project, it is necessary to clarify with the customer and the sponsor a common position regarding the attitude to the project as a financial asset.

The picture shows the normal ratio of uncertainty, investment and return.



While the uncertainty is great, we must invest little and reduce it.

As soon as the uncertainty about the ratio of investments and benefits becomes an acceptable level, it is possible to invest the bulk of resources in order to arrive at a return. At the end of each phase, you need to make an honest decision: to work further or close the project.

To do this, at the end of each phase there must be an estimate of the ratio of investment and return at the level of accuracy that is natural for the current phase.

The customer needs to show the current level of uncertainty, the current reasonable estimate of benefits and costs. If the benefits exceed the cost, it makes sense to discuss the further removal of uncertainty.

The rhetoric can be like this: “We see a profit forecast that significantly exceeds the cost of the system, let's spend a small fraction of the predicted value or benefit in order to clarify the estimates and decide to start building the system.”

My (very average) recommendations on the ratio of the cost of parts of a pre-project:

• Everything that happens before construction should not cost more than 10-30% of the project.

• The pre-project should cost an order of magnitude less - it is 1-3% of the predicted cost of the system.

• In the early stages, while there are no business requirements, the predicted cost may not be and must be repelled from the calculated return - you can take 0.1—0.2% for the life of the system on the budget for creating business requirements (taking into account the fact that it does not start each proposed project).

For example, if we sell a system that costs ~ 100 million (by analogy). It makes sense if the returns from its operation amount to at least ~ 300-500 million taking into account the low accuracy of all estimates.

In this case, such expenses can be considered normal:

• Business requirements - 0.5-1 million rubles.

• Concept - 1-3 million rubles.

• Technical project - 10-30 million rubles.

Here deviations in any direction are possible. But the general principle is this: the resources invested should be correlated with the predicted profit and the probability of its receipt, depending on the current level of uncertainty.

Short summary

Here we will complete the review of the correct pre-project and repeat the most important thing:

1. The project must be considered as a risky financial asset.
2. The level of uncertainty should be known to everyone and discussed among all stakeholders.
3. The cost of the analysis should be related to the expected profit and probability of its receipt.
4. In the course of development, it is necessary to achieve quality requirements sufficient to estimate the cost and timing with the accuracy inherent in the current phase.
5. In particular, business requirements must already be measurable.
6. It is necessary to remember about the complete list of tasks of the pre-project phase, the omission of each of which increases the probability of project failure by orders of magnitude.

Life shows that for various reasons it is not always possible to observe these principles. In some cases, a project that was damaged before launch can be saved or at least slightly improved. We will talk about this in the following parts of the series.