Why project managers often lose to analysts, and they, in turn, often relent to testers.

Why project managers often lose to analysts, and they, in turn, often relent to testers.

Introduction

Are you familiar with this situation, presented in the title of the article, and have you thought about the answer to this question?

Oddly enough, the same answer might work for these two different cases. In both cases, the winner is the one who correctly understands and works with the requirements. But if you look under the hood, you find that the meaning inherent in the answer in both cases is very different.

Let us consider the first case. Let's start by looking at the structure of the requirement. Links - what is a requirement. In short, we have two components of the requirement. One part is related to management. And the second part describes the actual content. In total, we have managerial attributes and a description of the essence. Management attributes include author, criticality, complexity and cost of implementation, timing of implementation, etc.

Now let's imagine that the PM and the analyst came to a meeting with the customer at some stage of the contract conclusion. They will have to bargain on terms and amounts. They have a well-written document by an analyst. But at the same time, the PM knows it only superficially. And he did not delve into the structuring and detailing of the requirement. That's a little below he, isn't it? It runs into the classic situation: And as it happens in almost all cases, at the meeting it turns out that there is not enough time or money for development, or both at the same time.

The PM immediately begins to make every effort to push hard document and bargain for the total planned amount ...

It's not hard to guess what awaits our developers along the way ... But here an analyst can intervene with a proposal to go through the document and decide whether everything described in the document is really so necessary for the customer. It often happens that the customer can really make concessions, BUT! ... not for money, but with the implementation of one or more requirements. Thus, the analyst becomes the leading link in the negotiations, and the PM, who seems to have such a duty, is in the shadows. And, if he does not make the appropriate conclusions, then very soon project management can go to the analyst.

This is how often PMs grow from analysts.

In the author's practice, there was a very funny case when a PM, who did not want to work with the requirements, was unable to draw up a work plan for the project. So this PM easily forgave the analyst that "there is still no final version of the technical requirements", but he could not forgive the fact that there is no Gantt chart for the project's tasks. And the analyst had to do the PM's job.

As a result, the project was passed, and PM lost the tender for the next similar project to another PM from a competing company. This PM turned out to be his former analyst, who by that time had been overbought by competitors. Here is a good example of what reluctance to deal with management requirements leads to.

Let's consider one more situation.

A categorical demand comes from the customer: to realize "the possibility of multiple choice of values from the reference books of the system being developed." DevLead and PM are shocked: The requirement cuts at the root the simple architecture underlying the developed one and significantly increases the project budget. The situation is saved only by negotiations with the participation of an analyst, as a result, it turns out that multiple choice is needed only to form a logical condition for data sampling in analytics. And in all other cases, in real work, multiple choice is even harmful and completely unnecessary for the customer. As a result, the budget increases only slightly.

And in this case, one of the PM key function (bargaining with the customer on the part of the requirements being implemented) is lost by him and is intercepted by the analyst. Several such cases and PM can say goodbye to the position.

Both of these cases refer to the initial phases of the project, when the system under development or is not yet at all, or it is in its infancy.
But as the project develops, working versions of the system appear and its active testing begins. And here our universal favorite, in the shadow of the tester, or even suffers a handsome macho analyst is embarrassment from not being ready to answer his questions.

Moreover, the latent inconsistency of the requirements fixed by the analyst and approved by the customer at the early stages of development is revealed, as well as the incompleteness of these requirements. And more and more often the analyst looks like who has missed the contradiction of requirements a klutz or their incompleteness. The superiority in expertise regarding the capabilities of the system is steadily shifting to the tester, and the analyst, with his analytical documents, is increasingly becoming like a useless empty barrel.

Now let's go back to the structure of the requirement and take a deeper look at it.

<Quote from Wiki>

A requirement is some useful property of a system that must be implemented during development.
Now let's think about how accurate this definition is: Indeed, at the early stages of the project, the system itself is not yet available, how can we talk about its properties? Only as some kind of representation or description.
It is obvious that the analyst in the initial phases of the project deals precisely with descriptions and has the properties of the system only in his representations.

Accordingly, the rest of the project participants also form their own ideas, based on the same description formed by the analyst (moreover, each has his own, not always and not completely consistent with the ideas of the other participants).
This reasoning may seem casuistic. But only until we move on to the phases of the project, where the system is completely ready or almost ready. Together with the system itself, its real properties appear, with which the tester works.

This is where the weakness of requirements is manifested in the usual sense for the analyst: System properties in descriptions and speculations (only). In contrast to the real properties of a "living", albeit not ideal, but really working system.

So it turns out that the analyst is mess around, and the tester is engaged in real deal with real things ...
The author knows a case when a very rich company-developer of a very famous software product decided (in addition to the testing department) to acquire an analytics department.

It all ended with the fact that the "guru", the head of the created analytical department, was spectacularly fired, and the department itself was disbanded into testing and maintenance departments.