12 problems when working on the terms of reference in an IT product

Writing a detailed Terms of Reference for an IT project has become a habit and is accepted as a standard. Everyone writes TORs, trying to reduce risks and simplify the work. But there are a number of problems associated with the work on TK, which should be taken into account in order to reduce risks in the project. These problems are discussed below.

The contractor makes a choice in favor of TOR

Decent Executor strives to achieve a business goal for the Customer. At the same time, the Contractor has a signed TOR, the implementation of which guarantees the receipt of money for work.

Imagine a situation when in the next point of the TOR there is a contradiction with the business purpose. What if by the middle of the project it turned out that it is possible to make it easier, better, faster, but not according to the TOR? The contractor will most likely turn a blind eye to efficiency and simply make the task as described and agreed.

The Contractor could go to the Customer to justify the uselessness and harmfulness of the erroneous point in the TOR, to make corrections to the TOR, to agree on amendments, to agree on changes to the budget. But agree that the easiest thing to do is not to do it, to accept the decrease in the quality of the result and just do as written.

By the way, ask yourself the question about the budget: how many Executors will want to reconcile the budget reduction if they see a better solution to the Customer’s problem? The question is rhetorical.

See how the Customer and the Executor interact with each other. In an ideal world, they should strive to achieve a business goal. But when the TOR appear, the Customer and the Contractor strive to implement the TOR in full. In addition to the initial movement towards Business Value, there is a desire to “tick all the boxes” in the TOR.

Pay attention to the motivation of each of the parties and you will see that the TOR now plays a central role in the project. The TOR will eventually replace the purpose of the project.

The customer makes a choice in favor of the TOR

Paradoxically, it is also easier for a customer to turn a blind eye to the efficiency of solving a business problem and do it as it is written in the TOR. This happens when the Customer is the one who does not risk money, for example, the head of the department or line manager, who was instructed to conduct the project.

Such people risk exceeding the budget or the term agreed in the project plan. But if they have done everything in accordance with the TOR, which was agreed upon by their superiors, then there is nothing to ask them.

The TOR only creates the illusion of complete certainty and control

The signed TOR guarantees that the performer has promised a certain result, but life does not guarantee that everything will happen according to the plan.

The problem is that the signed TOR is perceived as 100% definite future. Concerning it plans are under construction. But the statistics prompts that term and the project budget will be exceeded, and software will turn out not high enough quality.

The TOR really fixes tops of a design triangle, but this fixation creates only illusion of predictability and the control.

TOR is a silent source of answers

Questions are solved faster and more qualitatively during live communication. Planning, booth, demo, working in pairs, involving clients in testing, collecting feedback at early stages and constantly adjusting plans – all this is necessary to achieve quality.

When a detailed TOR is written, there is a temptation to read the TOR, rather than answer additional questions. Then the TOR replaces healthy communication on the project.

The problem is that the TOR will never be comprehensive. The analyst might have missed something, the architect meant it, but did not finish it. You can’t ask questions of the TOR, so you will go to think about the answer yourself.

The authors of the ToR are not available during the project

Analysts and architects are usually the only people in companies. They are divided into many parallel projects. If they have collected the requirements, described the task and gave it to work, they most likely went to make other projects right away.

If the Executors have any questions, they will most likely have to look for the answer in the text of the TOR because there will be no one to ask.

Describes only simple tasks

Sometimes the most risky and uncertain tasks cannot be studied and described in advance. They are more like R&D than function implementation. Here we have a direct analogy with clinical trials, the whole process and result of which cannot be described in advance, but only hypotheses and methods can be developed.

It turns out that a detailed TOR can be written only for very specific and relatively simple tasks. These tasks are located in the right sector of the Cynthia framework. The problem is that business rarely sets such simple and specific tasks. If you work on the functions that move the business forward, it is the upper left square of the Complex, and you can’t write the TOR on it anymore.

When is it time to stop writing the terms of reference?

Writing the TOR costs money that you want to save. In doing so, we balance between the two extremes:

  • Overpay with time and money for an overly detailed description of the tasks.
  • Describe the task in insufficient detail, which will lead to serious risks and mistakes.

The TOR does not record “quality”

As a developer and IT architect, I understand that any task, however detailed it may be described, can be done in hundreds of different ways. Some methods will be qualitative and expensive, others will be quick and “crutches”. In other words, when writing a code of terrible quality, you can formally fulfill the requirements of the TOR.

There are ways to achieve high quality IT products, but not with the help of TOR.

TOR works on an all-or-nothing basis.

Unfortunately, it is not possible to agree on half of the TOR or to agree to make the most important items of the agreed work. If the TOR is signed and the budget is allocated, you will have to do everything that is written in it. Its “monolithic” nature cannot be analyzed by Pareto, which will lead to inefficient work.

There’s no way to prove the consistency

If your TOR has more than a hundred pages, there are contradictions in this TOR. Interestingly, no one can prove otherwise. Can promise that he has checked everything, but he will not be able to prove or write a test for consistency. In fact, you always sign the TOR with contradictions.

It’s impossible to prove the completeness

As in the previous paragraph, it is impossible to prove that all scenarios, relationships, integration points, etc. are described in the TOR. It is possible to achieve 100% coverage of tasks only for an infinite budget, in other cases your TOR will not be complete.

It’s not inspiring.

Do not hope to inspire the Executive through the text of the TOR or try to convey to him the desire to achieve value for the business.

It’s not that bad.

The risks that these problems pose can be mitigated. For example, the contract could stipulate that the Tors could be changed, re-coordination procedures could be simplified, or the TOR could not be fully implemented, but the importance of achieving a business goal could be emphasized.

Work on each problem in one way or another is associated with building partnerships between the customer and the contractor, and this is a hard work.