Good IT companies that care about the quality of their implementations usually firmly convince their clients to join SCRUM methodology with Time & Materials settlement model. I will not write about the advantages of this approach, as already wrote about it at length.
However, the common problem is lack of understanding and acceptance of such settlement by the Board, Home Office or the project sponsor. What can you do in such a situation?
Below we present some solutions.
Pre-implementation analysis before estimation
Preceding the work with a thorough pre-implementation analysis lets you prepare a detailed implementation backlog and thoroughly estimate the amount of work and thus the cost and schedule. Dividing the project into analysis stage (here sometimes companies agree to a fixed price) and implementation stage often gives the feeling of better mutual understanding. A detailed backlog presented to the board can be a convincing argument for the acceptance of implementation estimate. Sometimes companies fear that valuation after the analysis stage will change so much that they won’t be able to realize implementation. You can prevent that by including business arrangement – e.g. if the estimate increases by more than 100%, the company won’t pay full cost of the analysis.
In this approach, work is still accounted for the worked time but the list of features may change and the team manages work to launch the application in a fixed budget. It may decrease or increase the number of functions, but for the Board so low-level arrangements are usually no longer a problem. Of course, provided that the application meets business objectives.
This above approach included in the formal method of estimation. Functions are divided into Must, Should, Could and Won’t. The amount of work devoted to Must functions can’t exceed 60% of the total work. IT company commits to bringing Must, Should and Could functions only if time allows it. Thus, implementation of critical business processes it is assured.
A slightly different approach to the same problem is budgeting not the project cost but the cost of the team that creates and manages the project. This approach often works in corporations. The role of a manager is to convince the Board to create an eCommerce team and its partial outsourcing. Sometimes it completely changes the perspective and allows for working freely in SCRUM. Reference visits may be a strong argument for this approach. I don’t know any company implementing eCommerce on a large scale that doesn’t budget IT work like that. Meeting with the Board of such a company can quickly convince your Board. Remember – CEOs want to talk to other CEOs.
Using know-how of your IT department
Your IT department often works in a way described above. They can attest to the benefits of such approach. Another idea is using IT department’s help in carrying out internal estimation of the project. This estimation will usually be higher than the external estimation and you can use it as a worst-case cost scenario. This cost can be treated internally as your budget for the project and presented to the Board.
The Board may also be convinced by the precision of estimation and keeping to it. Thus, you can start the project from the stage on which the company makes the first few sprints and compares estimation with reality. That’s how we begin our cooperation with many clients after taking over development and maintenance of their software. Such test sprints may include particularly risky elements of the project – e.g. integration.
Read also: Time&Materials? Definitely!