Why and when should you choose FFF? Let's get a look.
1. Three combinations
Each of the approaches to project management is essentially different in that it fixes or does not fix the following values: budget, scope of work, time frame and internal quality of the system.
A specific combination creates certain working conditions, has pros and cons:
- Fixed price
- Three points of the project triangle are fixed: time, money and amount of work.
- The main risks are assumed by the contractor and, as a result, these risks are reflected in the assessment. In addition, risks are created for the customer, I wrote about this in article 12 problems when working on a technical assignment in an IT product .
- A big plus of this approach is the project parameters predefined before the start of work. Very often the business / government needs to specify the term, money and amount of work in the contract.
- . , . , .
- .
- Time and Materials (T&M)
- , - .
- .
- , .
- , . , , .
- .
- ( , Product Owner'), , , , .
- Fix Time and Budget, Flex Scope (FFF)
- : , .
- .
- , , .
- , .
- , , . .
- : , / , .
- , .. . , , , , , , .
– , . , «», , , . . , , SonarQube. Podlodka.
2.
Why are these three combinations formed? Why can't you fix everything? After all, the simplest thing is to fix the budget, scope of work, release date and internal quality of the system, sign a contract (if the customer is an internal one, then go through the approval procedure with stakeholders) and do the work with an accurate hit in all four values. But, as practice shows, there is a fundamental problem that does not make it easy to go through this path without distortion.
No one has any problems with calculating the budget, it is quite easy to calculate the release date and there are many metrics and checklists to set a specific level of quality for an IT product. It's all simple if you can accurately estimate the scope of work. In other words, if there is a detailed list of tasks and an accurate estimate of this amount of work, then the other three values are easily calculated. Conversely, if there is no exact estimate, then the rest of the values will also be inaccurate, because they are based on an estimate of the amount of work.
Estimating the scope of work is always a problem, because there is no single estimation methodology that would work with acceptable accuracy. All methods are based on the previous experience of a team that did similar things, which ultimately means inaccuracies, because people are inaccurate: emotional, optimistic, forgetful. The lack of an accurate assessment methodology is the first factor that prevents us from getting into the assessment of the amount of work.
I wrote more about this issue in the article Customer Satisfaction for Programmers: All Programmers Are Optimists . There is a link to report 36 from Vadim Makishvili, where he proposes to simply multiply the score by 3. Using the metaphor of laying and passing the route, it is written in the article Why do IT projects take 2-3 times longer than planned? ...
In the course of work on an IT product, the following changes: the list of tasks that need to be done, the depth of their elaboration, the approach to system design. This happens under the influence of the external environment: changes in the market, changes in the company's strategy, changes in policies within the company, feedback from users, new inputs from those who were silent at the stage of analytics and later decided to speak out, etc. Our inability to influence external influences is the second factor that prevents us from initially getting into the assessment.
The third factor is that there are no criteria for determining the achievement of completeness when describing the scope of work. The writing of the TK cannot be finished, it can only be stopped. I wrote about this in detail in the article When is it time to stop writing the Terms of Reference .
I must make a reservation that all this is true if you work in a rather complex area: according to the Cynefin framework, these are the Complex and Complicated areas. If your project gets into Obvious and at the same time it is rather short, then you will most likely estimate the amount of work very accurately.
In total, we have that the root of the problem lies in an inaccurate estimate of the scope of work and the practical impossibility of making this estimate accurate, therefore:
- Fixed price projects sacrifice the internal quality of the system, because it is almost impossible to get into an estimate with three fixed peaks. Or, in the same Fixed price projects, they re-budget so many risks to cover any inaccuracies in the assessment at all, which is ineffective.
- T&M , . Product Owner'.
- FFF , , « » , T&M.
3. ?
If it is impossible to estimate the scope of work with sufficient accuracy, then maybe not at all? There is such a movement #NoEstimates. In short, we organize the development process in such a way as to carry out tasks as efficiently as possible from the idea stage to roll-out into production, while maintaining high internal quality. They offer to organize the process using Kanban with tracking flow processing metrics and special attention to improving the process of delivering new features. Premature evaluations are considered harmful, evaluating and grooming the backlog is a waste of time.
Where to learn more about #NoEstimates:
- David Anderson talks a lot about this, for example, in his talk The Alternative Path to Enterprise Agility .
- Askhat Urazbayev spoke at AgileDays in his speech #NoEstimates: Non-evaluative development .
- Ron Jeffries wrote about this in the article Some Thoughts on Estimation .
- Denis Stebunov wrote about this on Habré in the article On Estimates of Terms in Software Development .
I am both for this approach. I like him as an engineer and as a leader. But life is so arranged that the owners of the budget need an estimate, at least at the first stages of work, at least an approximate one. At Byndyusoft, we sometimes move on to #NoEstimates, but only after a fairly long relationship with the customer and this does not always happen.
4. FFF - balance of flexibility and predictability
Although grades spoil life and are a waste of time, it’s difficult to get started without them. It is clear, however, that no estimate will be accurate. It turns out that the best option is to fix the deadline and budget so that the business can live with it, and leave the volume of work floating. In addition, the customer and the contractor must agree that at each moment of time the team is engaged only in the most important and necessary tasks, and the customer devotes time to monitor the dynamics of the choice of priorities.
The first time I saw the description of FFF was in Getting Real by 37signals in the Fix Time and Budget chapter , Flex Scope . At the moment, in my company, this is the most popular approach to work, both customers and we are satisfied with it.
5. Internal quality of the system
As I wrote above, working on FFF is possible if the company has competent developers who are able to ensure high internal quality of the system. This is usually accomplished by automating everything and everyone, creating checklists with best practices, constantly reviewing code and architecture, all kinds of testing, and most importantly, recruiting the right people to the team.
Why not forget about internal quality, writes Martin Fowler's blog article Is High Quality Software Worth the Cost? ... I wrote about this in the article Determining the failure of an IT project... In short, with FFF, changes in the direction of product development are assumed, and this implies sufficient flexibility of the system. If the quality of the system is low, then each "turn" will slow down development and increase its cost, up to a complete stop of the project.
If you want to work according to FFF, then put the quality criteria into the contract in order to fix them for sure.
6. Motivation of the customer and the contractor
FFF work gives the right motivation on the part of the customer and the contractor. Unlike Fixed Price, where the customer and the contractor communicate through the contract interface, and unlike T&M, where the customer can lose boundaries and spend more than necessary; at FFF, everyone has to invest in communications and “live” in the project in order to do the most important thing and at the same time satisfy the terms of the contract.
7. Choose FFF
Fixed price and T&M have their advantages in certain contexts:
- If you are participating in a tender and committing to complete a specific work within the agreed time and money, while communication is mostly built through a contract, the Fixed price is most likely the best option.
- If the customer knows exactly what he needs and knows how to effectively build the work process, then he just needs to buy T&M resources and dispose of them at his own discretion.
However, other things being equal, we try to choose FFF. This approach seems to be the most balanced: it reduces the risks of the customer and the contractor, creates the necessary motivation on both sides and takes care of the internal quality of the system.
Links:
- How and what terms of reference to write when working on Agile .
- The principle of project management in the design bureau of Artyom Gorbunov.