7 sins when working with requirements in the pre-project

In the last part

In the last part, I announced a series of articles on the work of the analyst in the pre-project. It listed the problems, solutions and some principles to keep in mind when starting an IT project. In the new parts of the cycle, we will examine all the questions in more detail.

Today we will discuss the problems of the pre-project, which are very common.



Here is a list of them (you are already familiar with it by the introduction}:
')
1) "Letter from Uncle Fyodor"
2) The full life cycle and the structure of both the system and the financial asset are not taken into account.
3) Excessive specification of requirements
4) The volume and sufficient division of the system are not presented.
5) No understanding of customer’s goals
6) There is no basis for accepting the result
7) Invalid requirements communication mode selected.

Let's discuss each item.

For those who do not want to wait for the following parts of a series of articles, there is a video of my report from the meeting that prompted them to be written. At the same time, I want to not only rewrite the theses of the speech, but also go out of the time frame of the report, adding to what has already been said, what did not fit in time or arose from the discussion afterwards.

"Letter from Uncle Fyodor"

Let's start with customer problems with low IT maturity and gradually complicate the situation.
Usually novice customers of IT systems act like this: several people express their thoughts about everything that comes to their mind in connection with the construction of the system under discussion. These thoughts are recorded as they are in random order and are called requirements.

Most often they do not write down everything that is needed for the success of building a system, but only initially incomprehensible or interesting to each of the authors personally. New or different from the fact that "and so it is clear to everyone." The choice of the right points of view and the completeness of the list of interested parties is out of the question.

Such requirements do not suffer from either completeness or consistency and unambiguity, nor clear.

The result of the assessment and planning on such source data most often corresponds to the expression: “we give any answers to any questions”.

Toward the end of the projects, we hear or say every day: “this system fully complies with the TK, but does not do what we need” or “oh, we forgot yet ...” or “in this TK we meant something completely different”.

On the part of the executor, such technical tasks first of all raise the question of how we will receive and pass the result. “Uncle Fyodor’s letter” for a performer is a good application for “getting into slavery” to the customer for a couple of years.

Not taken into account full life cycle and system structure

At some point it becomes clear that TK should be written and it should not be written at random.
And colleagues on the wave of insight fall into the following trap: if you have a hammer in your hands, then everything around looks like nails.

Depending on who gets the idea of ​​the project: to hardware specialists, software operators or someone else, we get skewed in different directions.

Software developers love to write detailed TZ on the program, forgetting that it is necessary to bring and install equipment, to attend to communication channels. Suppose it is even possible, but it will cost very different money.

Infrastructure specialists (especially from the supplier's side) and people with architect's ambitions like to be driven into beautiful architectural solutions to monitoring, disaster-recovery, high-load, and other “space ships plying the Bolshoi Theater”, forgetting about the functional composition.

Having understood the hardware and software often (but often late) find that we still need to somehow organize users, migrate data, “cut through” integration channels to neighboring systems and do a lot of interesting things that people forgot to put money and deadlines on. But what is even more interesting, it turns out, part of the work cannot be done without the participation of the customer, who does not always want to participate in something.

In short, not all the work that needs to be done to make the system work is planned. Or simply “alien” or incomprehensible sections of the project are marked as “this is not a problem” and are underestimated in terms of money and terms.

But that's not all.

The system should not only start, but also bring the expected effect and return the investment, no matter how much we consider this return. This is most often forgotten.

An already built, but useless system is sabotaged by users, does not receive the maintenance costs it needs and dies.

It would seem that the performer is not so important, because he will get his money. In fact, the lack of answers about efficiency and impact can create problems with financing already at the construction stage from the sponsor, when implementing from users and when handing over from the customer.

The closer the signing of the order of transfer to commercial operation, the more people think about the future - that they will soon have to be alone with the system, show the business effect and account for the investment. There are more comments, they are becoming more petty and meaningless - people are delaying the completion of trial operation, as they feel some kind of trick, but they cannot understand it.

The tasks of the pre-project phase are not taken into account.

Excessive detail requirements

Let's say we overcame the previous problems, made a decision to write TZ, understood who to remember to talk with, realized that the requirements should be checked for mutual contradictions and ensure completeness for all points of view.

At this stage, a frequent problem is the lack of understanding of the current assignment of requirements.
We do not need to load the command with the input yet and give comprehensive descriptions to testers. At the same time, having often heard that they need a TK, even before the start of the project, colleagues try to write (and customers order) a TK for software, the time of which is at the end of the technical project.

Now we need TK for the system - this is a different set of solutions, both in composition and purpose.
Inevitably, if you try to run ahead, it turns out to be either too expensive (and we still do not know whether we are doing the project further or not), or too vague, since it is impossible to make all the necessary decisions to start development in acceptable timeline and budget.

In such a situation, the people involved in the process lose faith in the practice of writing TK and go looking for a better life in other practices.

Not presented the volume and sufficient division of the system

Suppose we figured out which TK to write.

Given that the fate of the project is not clear, we are asked to make TK cheaper and often throw out the child with the water.

I have seen a lot of TK on the system, from which it is impossible to get a complete and clear list, giving a normal estimate. It’s not clear what to buy, what to place and what to supply, how to connect and configure, what to develop, who to teach, who to hire or distract, from where and where to migrate data, etc.

The cost estimate of the system is not specified and the “trading field” does not arise in terms of price and terms: what are we going to cut and what opportunities will “fall off”.

And this is natural, since before TK, you need to come up with a system concept.

The question of sufficient division of the system is one side of the coin. On the other side, the feasibility itself is the ability to obtain a planned effect and fulfill the requirements by combining a certain number of components into a single whole.

The conceptual image of the system that needs to be created is intended to prove that the users will get the capabilities they need, the customer will get the effect, and the sponsor will return the investment. And it also provides the basis for the composition of the system, leading to a reasonable definition of value.

A good concept is not free, you need to be able to make it inexpensive. Therefore, a bad concept is often done or no concept is done.

No understanding of customer goals

Having coped with the identification of the list of points for “marking”, we are closely approaching the issue of system efficiency. When the CFO tells us: “You have now read me 243 functional requirements, 15 non-functional requirements, 10 types of security, but for me this is white noise. Tell me more simply, what will improve if I now budget and spend this specific $ 5 million? Who can we fire? Will we sell or produce more? Are you ready to take this as a commitment? ”

People who allocate money think about efficiency and return - they are accountable for this money and performance. Such a question will be raised directly or indirectly and before the contractor at the time of the system’s acceptance of the system.

Usually, if the work goes through documents, business requirements (or customer requirements) that need to be created before the concept are responsible for answering such questions.

There is no basis for acceptance of the result

Having coped with the rationale of effectiveness (regardless of whether it was orally or in writing, precisely or approximately), we must solve the last task - to explain to the future project team what is expected of it in order to get exactly what we budget and justify, rather than the materialization of illusions, complexes, fears, ambitions, addictions and antipathies of the performer.

Requirements should be not only complete, reasonable, realizable, but also testable. This is a separate work and another document - the actual TK on the system, which should not be confused with the TK on software.

As a result, fulfilling the tasks of the pre-project, it is necessary to understand the business requirements, come up with the concept of the system, approve the conceptual solution variant that suits the customer in terms of price / effect ratio, or write down the final agreements for the project team.

Invalid requirement communication mode selected

And so we did everything right: we realized the importance of TK, did not entrust its development to random people and the random process, fulfilled the tasks of the pre-project phase and now all that was left was to bring solutions to all interested parties so that the basic agreement on the start of the project entered into force.

It can be a shame, having done significant work in a short time, realizing the efficiency, payback of the system, its conceptual image, creation plan and cost, simply not bringing it all to the right people who influence the launch of the project.

Communication in the pre-project is described by the phrase: "The first impression can be made only once." If the project is denied funding, because the sponsor is not convinced of the return, or the customer is not convinced of the effect, or the users are not convinced of the novelty of the received opportunities, then “show the class” will not work.

Who pays and how to make it cheaper

In the discussion of the previous part of this series of articles, comrade exehoo focused our attention on a very correct question: “Is there still a serious problem of the type“ And who will pay for pre-project work? ”

Indeed, when it is not clear whether we start or not, nobody likes to pay. For a solution provider, pre-project work falls into the sales and marketing budget, and for a customer organization, it’s often not known where.

However, the question of paying or not paying is not worth it. The correct question is: what to pay for and how much to pay.

You can go by trial and error, called by intelligent "prototyping". You can resort to design and work through the requirements.

The question is what is cheaper:

• pay for rework, which often means retraining of hundreds of thousands of users;
• or for the design, which often can not give enough true picture of the future.

The only answer to this question for all projects can not be given. Our task is to maintain a balance between the cost of decisions and their details, given the likelihood of their changes in the future. As soon as the design becomes more expensive rework, it must be stopped or moved to a later date, when there will be more certainty. Hence the principle of organizing the life cycle of an IT system in phases.

In more detail this question, as well as what else must be remembered when starting the launch of an IT project, we will discuss in the next part.