Ideal requirements and how to deal with it

In past parts

In the first part of the series, I announced a series of articles about the work of the analyst in the pre-project. It lists the problems, solutions and some principles that you need to remember when starting an IT project.

In the last, second part, I talked about the frequent problems of the pre-project and received regular comments in the comments: “It is well written about the problems, everything is just like in reality. But the solution is proposed in the style of "Do not do bad, and you will do well" neskazhui , "But this is life, it is generally written in the article. How is it necessary? ” Other_letter .


The story about how to, I will divide into parts:

1. That's right: that is, it would be nice to do so, but usually it turns out only partially. These will be the next two stories.
2. What advice can be given on each phase of working with requirements: to ease the situation when something went wrong, to fit into real restrictions.

Over the next two notes, I will describe a number of simple principles regarding the design of IT systems, their life cycle, the organization of analytical work and building relationships around the project. Many people know them, but they are not always used in reality.

Among them:

• IT system design and IT product classification
• V-model levels, system life cycle and view of the system as a financial asset
• Uncertainty Cone and Design Phases
• How does evaluation work?
• The full scope of tasks of the pre-project phase and the values ​​realized in this process
• How to get enough resources for a pre-project

I repeat for those who do not want to wait for the next parts of the cycle. There is a video of my report from the mitap, which served as the impetus for writing these notes. At the same time, I want not only to rewrite the theses of the presentation, but also to get out of the time frame of the report, adding to what has already been said, that which did not fit in time or arose as a result of the discussion after.

IT Product Classification

Regardless of which class of product an IT project produces, it must be remembered that the ultimate essence of automation is to transfer mental work from people to machines.

For whatever small part of the system we are responsible for, the final result will be obtained after combining people, technical devices, software and information into a single whole, called an automated system.

Starting an automated system, in addition to obtaining and combining all components, includes the reorganization of automated activities. And in the last five years, such a reorganization is increasingly accompanied by a restructuring of the administrative, legal and financial relations of the parties around the system. In the latter case, we are already dealing with an IT service in which the line between the business process and automation has been erased.

The full hierarchy of IT products looks like this:

• IT service includes a business structure with an automated system integrated into it.
• An automated system includes people and a software and hardware complex (information system).
• Software and hardware complex - these are programs, hardware and data, interconnected.
• A program, equipment, or data can themselves be an independent custom-made or mass product with its own cycle of creation, development, and maintenance.

If you go deeper and take into account that decisions according to scenarios of interaction of parts and decisions on connecting parts create independent added value, we must take into account all types of collateral that can be ordered separately:

• Mathematical
• Software
• Technical
• Informational
• Linguistic
• Metrological
• Ergonomic
• Organizational
• Methodical
• Legal
• Financial

The subject of delivery of the IT project can be any of the listed types of products, their part, combination, as well as services for changing / servicing all of the above.
It would seem that the described principle cannot be violated. If all components of the system do not fit together and into automated activities, then a miracle will not happen. This “lack of ignition” occurs on its own due to various problems with requirements, communication, design, and simply due to errors.

At the same time, project managers often deliberately remove uncomfortable parts of the system from their scope. For example, “supplying equipment is not our task”, or “do your own support for users”, or “forget” to include data migration, user training and trial operation in the plan. This happens for various reasons: there are no relevant resources, non-core work or products, it is not clear there are fears that it will become expensive and the customer will refuse to launch the project.

In any case, each element of the system outside the scope of your project is an external uncontrolled interested person who will provide the missing part, a communication channel and the need to coordinate what you are doing with what the subcontractor will do.

Communication itself, coordination of design decisions with related parts - these are the work and risks that clearly should appear in the project plan.



The main answer to the question “what to do?” Is “to understand the class of your delivery item and see how it fits into the higher system”.

Extended V-model and system life cycle

In fact, the implementation of different parts of the work on the system by different contractors or different subgroups of the project is a normal situation. In order for the parts to be coordinated among themselves, a number of technical solutions are singled out separately and are called solution architecture in Western terminology or a technical project in Russian.
Solutions are not only technical.

To illustrate the nesting of IT products, the procedure for making / verifying decisions and the interaction of their life cycles, you can use the V-model. It reflects two simple facts: it is better to design from large to small, but assemble it into a single whole and test it in the reverse order.

For the IT product hierarchy shown in the previous section, we can build an extended V-model.



If we work on Agile, then all these steps are performed within each user story. If we have longer iterations, then an entire queue or subsystem passes immediately through these phases.

On the V-model, depending on the type of IT product, you can see how much design should be completed before the start of our project. On the other hand, it is clear what actions will be completed for the final validation of our item of delivery.

Accordingly, the results of the previous design should come to our input (and not always “by gravity”), and validation actions will cause requests for changes, support or defects identified after delivery.

Classification of IT projects

From the understanding of the structure of the IT product, the concept of the V-model and its relationship with the life cycle of our product and its parts, one more conclusion follows: before you “write off” the project plan, risk register or any work practices with colleagues or from the Internet , you need to make sure that the configuration of our project is close to the "donor project".

At each of the levels and types of solutions presented above, a different number of changes is planned.

There are projects to replace the server with a more productive one. There are projects for moving from one data center to another. There is a change in the language of the system or just the service provider.
There are projects creating an IT service for the mass consumer from scratch. There are projects that change business processes and some software tools. All these are different projects with their own specifics. And there are still a huge number of options.

To see how large the distance between the two projects is, you can use the map of design decisions, reflecting the degree of change for each type of decision and the boundaries of our responsibility.

Here is an example of a map of design decisions for one real IT project, the purpose of which is deep refactoring and replacement of mass service software, which was supposed to accelerate the development of the service, new features, replacement of the visual style solution and some other improvements.



The second column shows the profile of changes by type of decision, which can be used to compare the project with other projects.

The third column adds the degree of controllability of decisions in an “as is” situation. That is, it is important for us whether there is where to look or ask how this or that aspect of the service is now arranged.

Combining data on the scale of changes and the degree of uncertainty of the current state of affairs, we received risks from the scale of changes in the object, which was initially uncontrollable. Added to this are the risks from decisions and objects that are not in our power and are currently not in a controlled state - these are solutions by which we are completely dependent on subcontractors and the customer.

This map can be clarified: disclose in more detail the types of decisions, add columns responsible for fixing the sources of information and responsibility for decisions, add data on decision-making for the “how will” state and analyze the corresponding risks.

System as a financial asset

The last thing I want to tell you today is the principle that plays the role of K. Marx’s Universal Formula for Capital for the economy or the Shekhart-Deming cycle for managing processes for building IT systems.



The sponsor gives money under the guarantee of the customer to convert the expected effect into a return on investment.

The customer provides system requirements that guarantee the creation of the expected effect.
Contractor based on requirements makes the system.

Users use the system, this brings the expected effect, which translates into a return on investment.

This circle must be closed. If something does not work out: the system cannot be used, the effect is not achieved, the return on investment does not work out - this is a problem project. If we cannot even predict the return on investment, the effect or the order of use is a time bomb.

At whatever level of the V-model we enter into the project, we need to imagine how the investment return cycle is configured:

• who is in the roles of sponsor, customer, artist and users,
• what is the return and investments, what are they made up of,
• how is the effect formed
• what will be the use.

A picture for a particular system can usually be estimated on a piece of paper in one or two conversations. All cliffs, questions and ambiguities should be transformed into risks. Until the financial cycle becomes clear, the project cannot be launched.

Here I am the first (but not the last) time I want to approve the main goal of the analyst in the pre-project: it is necessary to close ten disadvantageous projects in order for one profitable to receive sufficient funding.

Eventually

Above, we examined the principles for determining the context of a project:

• Definition of product class, and superior system
• Definition of previous and subsequent design decisions and work outside the scope of our project
• Determining the life cycle of a financial asset over our project

Already knowing the gaps and inconsistencies of the context eliminates fatal problems and obviously does not start a failed project.

In the next article, we will finish discussing the basic principles of an ideal project launch, in order to proceed further to discussing what to do with imperfect situations.