Terms of reference as a project knowledge base

Software development is the process of creating knowledge. The general idea of the product, the design prototypes and the concept of the architecture may appear before the beginning of development, but their correctness or incorrectness will be checked only during the work on the project.

TOR is a source of losses

I’ve always been quite skeptical about the detailed terms of reference and over time this position is only getting stronger.

What does it mean to get a detailed ToR before the work starts?

  1. The customer talks about the project and asks to evaluate it
  2. We ask for a project description to understand the scope of work
  3. Obtain project terms of reference (this will not be exhaustive, especially in large projects)
  4. Reading, analyzing, evaluating. We will be asked to sign up for the deadline, so the assessment immediately includes our risks, IE increase time and money
  5. The customer agrees and asks us to sign up for the term and price
  6. To which we, defending our interests, explain that after signing the TORs it will be difficult to make changes to it. We will have to reconcile the price and term
  7. In order not to go for re-coordination, the customer tries to take into account in advance in this TOR everything that is possible and impossible

The situation has lost out.

Let’s see what each side gets in the end:

  • The customer will still make changes to the TOR, we can take this as a fact. The more the project, the more often we make releases, the more changes will be made. We still do not do TK, and we solve a business problem, only in it till last nobody will admit
  • If we have agreed on the architecture in advance with the customer’s technicians, we will start making changes to the architecture as soon as we get started. The more detailed this original architecture was, the more changes will be made. Again, if the architecture was part of the TOR, we will have to reconcile the timing and budget
  • There are a lot of tasks in the TOR, which the customer will never need, but since they are in the TOR, it means that we will have to do them. This leads to loss of time and money on both sides
  • With the help of the TOR we wanted to limit the customer’s “wants”, but received them with excess: the first part was added to the TOR by the customer for the future + the second part came in the form of changes in the course of the project
  • Worst of all in this situation to users as terms of realization are stretched out

Problems of TOR re-coordination

The most interesting thing about this approach is the process of rescheduling and budgeting. This magic procedure rarely happens with the release of win-win. The customer can shift the release date, but will restrain himself from changing the budget to the last one.

The situation may become an impasse and its resolution will depend on the amount of advance payment for the work and the way already passed. If the advance payment was small and has already passed quite a lot from the start date of the project, the customer begins to successfully press the performer. If the project is at the beginning and the advance can be returned, the executor has a chance to give up the project without unnecessary conflicts.

You can restrain yourself and even go to court, you can even win in court, but this is no longer a project, but a loss of time and nerves. After that, the customer will try to spoil your reputation.

History knows the cases of successful budget recoordination, but it is very rare.

Agile without TOR

You will say that this rudiment in the form of TOR no longer exists in Agile projects. We have the customer at hand, we make Story Mapping, keep Kan ban board in plain sight, make releases every day, everyone understands the current state of the project. In this case, no one will think about six months to write a detailed TOR and only then give it to work.

Reincarnation of TOR

Recently, I have been facing interesting features of large projects. They have so much functionality that the Product Owner itself begins to forget what the system is capable of and how exactly it should work.

In one of our projects we work with the QA team, which is located in another company in another city. This complicates communication.

In this case, we have the following:

  • We plan the tasks on Monday
  • Every day we make releases
  • We do a demo once a week
  • Maintain a document that describes all the functionality of the system

The last part is dealt with by Product Owner together with the technical writer. The resulting document remains from development and is constantly changing as the work progresses. The customer sees the product, conducts a demo for customers, receives a processed connection and wants to make the product better. We get design sketches and an approximate description. We implement, show, get more detailed User Story, finish the task.

As a result, we have documents that contain all the User Story and detailed descriptions of the system parts. Recently, I realized that this is a TOR that is only iterative and ready to be changed, not imposed from the beginning of the project.

It is essentially a project knowledge base that is actively used by all participants in the development process. Especially this part is useful for QA, which should monitor the regression.

Getting rid of losses

Writing a detailed TOR before the start of work, as well as Big Design Up Front, leads to losses in IT-production.

On the other hand, the practice of accumulating knowledge about the project is very effective. I believe that the concept of TK creation should be changed towards iterative development and readiness for changes.

That it has occurred both customers, and executors should understand value of accumulation of knowledge about the project and to adhere to thrifty ways of management of the project.