“We have a friendly relationship with this counterparty” or how to stay without documentation on the project

“We have a friendly relationship with this counterparty” or how to stay without documentation on the project

Author’s notes

I was invited to the project described below as a system analyst and project manager. Combining the two roles was possible, but it took a lot of time.

The title does not reflect the whole essence of the article, the climax and resolution will be lower.

The article will be useful for both beginners and experienced specialists in the fields of: project management, business and system analysis.

Active persons:

  • counterparty/executor – the company that develops the product;

  • the customer company is a large company with an internal bureaucracy, for which the product was developed, and which took me on the project.

A little boring, or for reference

One of the tasks of a business or system analyst is to compile project documentation: various specifications, description of integrations, technical tasks, etc.

One of the tasks of the project manager is to record the meeting arrangements, keep the minutes and save them not somewhere in oneself or by mail, but, for example, to maintain a separate page in Confluence, so that all project participants have the opportunity at any time to familiarize themselves with the results of a particular meeting. .

This is said always and everywhere, but for some reason, analysts and project managers, even with work experience, periodically neglect these rules. Therefore, in some companies, analysts are asked at interviews: “You came to a project where there is no documentation, and the people who developed the software have long since left. All. What are you going to do? Where and how will you look for information?” Such situations are enough even in our time, but let’s see what it can lead to.


The project was small by company standards, so it had a limited team:

About a year before I joined the company, the composition of the participants was as in the picture. On the part of the customer (where I was hired to work), neither an analyst nor a project manager was allocated. I did not find out why such a decision was made, but I will make an assumption that after the implementation of a ready-made box solution (box), the customer was so satisfied with the work of the contractor that he decided to transfer the task of developing a new module to the box to the contractor. The project also had two direct customers from related fields (heads of departments for which the module was being developed).

A few months after the start, the project began to slip – the first difficulties arose in accordance with technical issues.

A few months later, the number of questions increased, and the company decided to hire a project manager for the project.

A project manager was hired, who soon resigned. The situation in the project was not improved.

And after about 3 months, they took me on the project, warning that the status of the project was approximately as follows: “it is very difficult, it is not clear what to do, the deadlines have already been missed 2-3 times.”

What was given at the start when I joined the project:

  • a product (boxed solution) that works properly for 1 year, with the possibility of customization, located on the side of the counterparty;

  • the project is in the development stage: finishing work is required (development, integration and implementation of an additional module), there is a deadline;

  • the box with the module under development must be transferred to the company circuit;

  • risk – prohibition of system operation if requirements are not met within the last approved deadline;

  • the selection and coordination of the new architecture is delayed for several months, there is no final decision;

  • one analyst from the counterparty;

  • project manager who resigned 3 months ago;

  • several customers who communicate directly with the counterparty.

What you need to do:

  • coordinate the architectural scheme;

  • continue the development of the module;

  • nick.

Any analyst’s work on a new project begins with studying the subject area: how the business process is built, how the system works or will work, what the requirements are, and whether these requirements meet business rules and restrictions. And the first thing I encountered was the complete lack of documentation (except for two architectural schemes with a new module). Seemingly a young product, a team working on the product in full force, all you have to do is go and ask. That’s what I did, however, I was not very satisfied with the following results:

  • lack of business communication between the customer and the contractor, and, as a result, the lack of recorded meetings, as well as their results;

  • lack of a signed development contract (“they have successfully implemented the current product, we (customers) have no complaints, we can conclude a contract in the process”);

  • lack of a concept or other document that states what requirements should be applied to the new module;

  • the new architectural scheme had an additional module that was not in the current scheme, but it was already implemented on the side of the counterparty and worked (“we agreed with them amicably, they expanded the functionality of our system, no, we did not agree with anyone , We believe them “);

  • only one customer fully understood why the product is needed and what are the plans for its development;

  • the understanding of the requirements of the executor and the customer for the new module turned out to be different.

Due to the lack of documentation, many meetings had to be held just to restore the chain of events. This took up valuable time and the project was not completed by the deadline. Security disabled the product for about a month. At this time, there were active negotiations within the company to allow us to continue using the product.

What work was done by me:

  1. The business process is represented in BPMN notation. It was necessary to understand where we would need the module being developed, and what kind of process we have in general, since not all customers already understood.

  2. Describes the current architecture, all modules. This made it possible to choose and agree on the future architectural scheme.

  3. Communication with the vendor has been transferred to a business channel: all meetings are planned, and the results of the meetings are recorded. Advantages of implementing this approach:

    3.1. controversial issues began to be resolved quickly;

    3.2. it became impossible to forget something.

    There were difficulties in implementing such an approach:

    3.3. the executor became less active in solving issues;

    3.4. the executor was dissatisfied with the fact that in the middle of the development, new requirements appeared that were not there before, and he associated their appearance with structural changes in the project.

  4. An agreement was reached to include an unfixed but mandatory requirement in the current development without changing the cost.

  5. Options for using the new functionality have been compiled.

  6. The technical task has been written. It was not possible to agree.

It would seem that it was possible to stabilize the project and agree on the continuation of the product, but after the above decisions, communication with the counterparty became extremely difficult: the agreement of the written documentation was slow, and the documentation provided by the contractor required frequent questions and adjustments. In the “new” mandatory requirement, it was not possible to agree on an implementation option with the counterparty, the negotiations came to an impasse.

As a result, after going around and around for a long time, it was decided that it is easier to abandon the development of this module and look for other types of solutions.

The options found turned out to be slightly more expensive than the current solution, even taking into account the costs already incurred.

Results of the case

  1. If the requirements were recorded at the start of the project, the project would not have dragged on for so many months.

  2. If at least minimal documentation was compiled, it would not be necessary to waste both my resources (to restore the documentation) and the resources of colleagues with whom I constantly interacted. The aphorism “time is money” is perfect here. The documentation appeared, and the project was closed.

  3. If there was no communication like “friendly relations”, many issues could be closed, and with a high probability the new module would be successfully implemented.

  4. If everyone on the project had performed their duties as required, such chaos would not have happened. At first, I thought that the problem was the lack of product documentation, but the problem turned out to be the project management itself: building healthy relationships, fixing agreements and monitoring the work and results of specialists.

Since the story does not tolerate the conventional method, therefore we leave the “if” in our dreams and put the project on the “experience” shelf.

Read other interesting stories from the IT world, as well as how to get into this world, on my channel.

Related posts