The development of technically complex web services, applications or websites is a time-consuming task that involves the infusion of large budgets. Imagine that you decided to launch just such a project, found a reliable contractor with deep expertise, allocated funds, spoke the TOR, outlined tight deadlines and regularly monitor progress.
It would seem that all the steps for the success of the project have been completed…
This is exactly the hook we fell for when we started developing a drawing with complex mechanics for one of our clients without a clear statement of the task. As a result, 182 hours of development were wasted, but even more time was spent by the project manager to resolve the situation. Add to this an immeasurable number of nerve cells on both sides.
Although it may seem that such an experience only undermined our reputation and stole profits, in fact it allowed us to build an effective preparatory process — project design. We tell you how it was and what lessons we learned.
A few introductory facts
In the summer of 2019, our regular customer sets the task to implement the promotion mechanism to attract new customers. We get 4 pages of the description of the draw with a big prize and tight deadlines — about three weeks for everything about everything. The promotion should be completed by the New Year.
Despite the complex mechanics, where the chances of winning are determined by various parameters, the ex-head of web projects decided that everything was clear and launched the project. No additional collection of requirements, no elaborated corner cases (borderline cases that need to be taken into account for a high-quality user experience), no formalization of TK with agreed formats of schemes or documents.
“The initial TOR from any customer is not a ready—made statement of the task for the developer, at least without additional collection of requirements and clarification of the nuances of future functionality. Often this is an informal vision of the final product in general terms. Our task is not to deploy the customer with the words “go write normally”, but to understand his pain (goal, business task, name is not so important), which he wants to express in the form of text”,
— the analyst Atigro shares.
Prerequisites for future failure
Evaluation of the project in isolation from the TOR. Having considered the customer’s introductory notes as the final guide for development, we calculated the labor costs approximately, without reference to specific points of the TOR.
Imaginary transparency. “Here’s the task — implement” — the path to a million edits, rewriting technical documentation and unjustified expectations.
Sprint deadline. The seemingly simple TK, the already established partnership and the lack of a clear protocol of actions led to the fact that the project was handed over not in three weeks, but almost six months later.
As a result, the project was completed not in early September, but in mid-April 2020, when the pandemic hit the world and the action was no longer relevant.
Houston, we have a problem, or how we realized that something went wrong
After the programmer implemented the solution for the received TOR and we were happy to inform the customer that everything was ready, a cycle of unexpected questions began. Here are some of them.
“And this is not how we imagined it”
“How do I view bonuses accrued for payments? Where is the formula by which they are calculated? How do I change the coefficient for certain users? Where is the list of all the participants of the action?”
Here are just some of the issues on which our imagination did not coincide with the customer’s ideas. It turned out that there were simply no specifics for implementing such requirements.
“What if the user does X?”
“What about registered but not authorized users? Or users of the application will be able to register for the promotion if they visit the landing page from a mobile device: do we have only a unique phone number for the application, and an email and password for the site?”
These cases were not described in the TOR, and we did not even know that the customer had archaic architectural specifics with a non-unique phone number. As a result, we worked out options for additional requirements and upgraded the architecture.
“And it works differently for us”
Is the soft removal of site users somehow taken into account for the participants of the action?”
Again, this function was not mentioned in the customer’s TOR, and we did not provide separate conditions for users removed by this method. As a result, we had to work out the requirements, spend time developing several implementation options and finish the agreed one.
From unreasonable expectations to clear design
At the end of the project, we made 4 main conclusions:
The customer’s vision does not reflect the full picture. The initial TK from the customer is rather introductory data that needs to be worked out in order to make a clear TK. This can be proved by a couple of illustrative examples, after which phrases like “You have a detailed description of the task, you just need to implement it” will disappear. At the same time, we, as contractors, demonstrate expertise, not intellectual superiority.
Clear requirements — less room for imagination. You can collect them in different ways. The easiest and most effective way is an interview.
From “rare cases” you can always add up a mountain. The study of borderline cases has become a mandatory checklist item for us when preparing the TOR. It is important to understand that force majeure is possible, even if you carefully dive into the subtleties of the project. You need to put time on them — just in case.
A pre—agreed format of work means fewer surprises. We have already prepared diagrams and documents, but we flexibly change them for the customer, for example, if you need to apply a certain modeling notation.
These lessons actually became the postulates of the pre-project work, which we called “Analytics and Design”. It consists of eight steps that allow us to dive deeply into the customer’s project, carefully think through and design a model of the future solution, fix requirements and give an accurate estimate of development costs.
Measure seven times — cut once
Now we don’t start working on any project without design and analytics. A thorough debriefing and hours of discussions allowed us to deduce the key stages of pre-project activities, objectively assess the timing and facets of the possible in order to immediately agree on the real expectations on both sides.
As a result, we not only increased the internal efficiency and quality of the final solution, but also found a way to save the customer’s budget.