Fixed Price or Time&Material truth is somewhere between
The pros and cons of the FP and TM models are widely known, either their areas of application, but there is a range of tasks for which neither of these models work well. We are talking about projects with a fixed price, but variable scope.
FP does not allow changing the scope, in turn TM does not guarantee the achievement of results in a given period of time. I will tell you about an approach that we have successfully applied in a number of projects — a fixed price per month and a managed scope.
How the approach works:
When work on a project starts, the order of hours for the contract is usually already known if the company has the expertise in the industry. You can say how long the project will take, whether it will be approximately 800, 3000 or 10000 man / hours. If the client agrees about an approximate sum then from 5 to 10 percent of this time is allocated to the discovery phase, depending on project complexity from architecture perspective.
Discovery phase is required to cover up main use cases and scenarios and translate business requirements to project architecture. This phase is necessary in order to understand the principle of the future system and work out all the main scenarios. It does not include the development of all functional requirements, because it takes a lot of time and they will change in accordance with the wishes of the customer or project ongoing situation.
Delivery phase is the main phase where we work with expectations. So any changes that are required to apply are estimated and if changes have impact and delivery dates it’s communicated back and we change the approach, change the scope, change the team or postpone delivery depending on priorities. That allows transparent influence of changes. We always try to find optimal solutions in each case. It’s possible if there is a good architect and BA on the project.
So iterations go one by one based on milestones of the project’s version. Start from documentation creation allows us to make a good base for future steps.
This approach allows to split the risks between customer and contractor and don’t move all of them to one side.
Let’s look at the phases in detail
Discovery phase
During this phase, it is necessary to collect the set of information that will help make the feature driven work breakdown structure (WBS) and architecture approach of the solution. An indicative set of what can be included in the scope is presented below:
- Major system use cases
- Site Map/Mock ups (for web projects)
- Roles model for the entire system
- Design project architecture
- Component view
- Deployment view with costs model
- DB ER diagram
- Class diagram
- Main complicated flow-charts
- Some other system views that are required for clear understanding of the system main goal and flows.
- Define possible risks and strategies of mitigation
- Create an estimates and WBS
- Define delivery plan
All these steps are required to make it clear for the customer what should be performed and how much each feature costs.
Estimation and WBS example
Via this link you can find an estimation template example.
In the lines we have features, in the columns we have actions, that requires for project delivery. For each project columns will be different, it’s important not to miss some required features and actions for accurate estimations.
Min and Max time for coding are provided via developers, all other actions are calculated automatically based on formulas and coefficients. Coefficients cannot be used cross companies, as they are a result of the internal processes and team skills.
For example code coverage requirements can be different and in one project coefficient will be 15 percent of development time and if 80 or 100 percent converge required — time will be similar to development or even more.
Pointing out the type of job helps to understand team structure. On the last page in the template there is automatically calculation of hours base on this parameters.
It’s important to split tasks for blocks less than ~40 hours, for accurate estimation and clear understanding what should be performed in this feature. For example feature API development or Setup infrastructure cannot be estimated, as it is not clear what should be performed to complete it.
Also it’s a good point to ‘save’ 5–10% for unpredictable changes that will occur during development.
Delivery phase
Delivery phase starts from appropriate environment setup and collection of main functional requirements. During the discovery phase only the vision concept is created, as detailed requirements take much time.
Communication with customers happens twice a week for requirements facilitation and demo. In such cases clients have fast vision of what is going on and if something is not working as expected, required changes will be provided ASAP. Customer doesn’t communicate with the development team, only PM/BA/Architect or TL. Actually the team is not constant, only contact points, and the team is built on the principle of maximum efficiency. With this approach, there will not be one full stack, which should cover everything that is possible, but for each type of work a specialist of the appropriate knowledge and level is involved.Their won’t be a situation when architect should create layout or developer without skills create AWS environment. Management of such changes will be on the contractors side. Client doesn’t provide any interviews to the team and accepts that management is on the contractor side.
How changes are applied? If they can be covered with risks or some time was saved on previous features, then the feature is just accepted to the scope after prioritization and requirements development. In another case low priority feature is moved away from scope or other ideas on time save are applied. All possible risks and changes are discussed with the client and changes to the scope have to be approved.
Why should client believe to contractor
Actually, there is no reason beside reputation or references. That is why usually projects are started from some first step with a trial period, where the client can understand how a team can deliver and is it comfortable for him processes and communication approach that is proposed. This part of functionality is developed in the same format like all other iterations with discovery phase and team management.
This approach is effective in terms of value per buck and allows to adjust scope on the go. It requires established trust between client and contractor though.
