Before software consultancy project starts, there are lots of discussion and documentation needed. Among those, project proposal (or say quotation) is the most difficult one to produce.
Project proposal is the agreement between vendor (i.e. F5 Works) and clients on
- software deliverable
- service deliverable
- how much does it cost
- how long does it take
- other terms and conditions (e.g. privacy, cancellations, payment schedule, etc.)
Why project proposal is difficult to produce ?
Information is limited. Usually before anything starts, writing project proposal is like guessing the future. Most of the following won't be 100% ready at this stage:
- business operation
- website / apps user flow
- website / apps business logic
- non-functional expectation
time and resource is limited. In software consultation industry, quotation service is free of charge. Vendor is not getting paid before the client signs the contract with you. So, from vendor point of view, you don't want to over-spend time on pre-sales part.
it is just a plan for future. If we manage to know exact what will happen like minute by minute, of course we can have the perfect planning. However, we are no god. It is just impossible to predict how everything and everyone is going to work.
different working style. There are lots of non-development effort needed to get the project done. With different working style between development vendor and business client, there could be a huge variation on time and resources spent on communication, project management, knowledge transfer, etc.
Does Waterfall method helps ?
Waterfall development lifecycle requires getting the deliverable specification done upfront. Then development team just blindly follow the agreed contract to work.
However, it takes time to get the detailed specification done. Vendor does not want to work on the specification for free and client does not want to pay unless they know what they are going to receive. If one vendor spend a month on specification and then client picks another vendor, it is a month wasted.
Waterfall method does not allow scope changes. Perhaps during development, business client discovers new business requirement and wanna change task priority or drop tasks from original scope. It is not allowed in Waterfall, as it violates the specification and contract.
F5 way: Iterative Estimation
Initial conversation, ball park figure with range is provided. After we scan through the available information, usually within maximum 2 to 3 days, we give a high level preliminarily cost and time line range which we feel safe. Cost and time buffer are included in the proposal.
Before closing the deal, module level estimation is provided Timeline is broken down into month-size milestone and scope are broken down into manday-size module level tasks.
After each milestone, cost and timeline are refined. After every milestone completed, if either party wanna fine-tune scope, cost and timeline, contract will be updated.
F5 way: Detail Revision Process
In general, upcoming milestone is revised and agreed before it actually started.
For example, we usually start with a 3 to 4 weeks wireframe milestone. After wireframe is confirmed and accepted, we sit down with client and discuss if everything in wireframe are needed in the upcoming milestones.
If out of scope tasks are found, additional charge and extra time is needed to put into the project proposal. If in scope tasks are expanded, additional charge and extra time is needed to put into the project proposal. If in scope tasks are found to be obsolete, charge and time is reduced from the project proposal.
When the project moves forward, this updated project proposal (scope and timeline) will be the base for all future in-scope / out-scope negotiation.
And the revision process will be done again and again.
What if we cannot come to an agreement on the updated scope after certain milestone ? Both side may raise project cancellation and settle the outstanding charges or penalty.
It aligns expectation. We explicit speak out what we are going to deliver in upcoming milestones and client knows what they are going to receive with the money invested. Clarification from both side can be done before the next milestone starts.
It provides transparency. Scope and cost change decision are transparent and warn upfront.
It encourages client involvement. Client will participate more in the whole development and acceptance process.
It saves time to kickstart. Limited time is spent on perfecting the estimation before project starts.
It adapts changes. It allows both side to raise change during the development process
It estimates better (eventually). The project proposal is getting more and more precise milestone after milestone. Scope keeps converging when the project moves forward.
Cautions (not really Cons)
It requires education. It is different from traditional outsource vendor process:
- Not every client would see the benefit upfront
- Not every client know how to utilize the iterative process
- It is very different from other business expenses which are one-off and immutable.
It requires trust. It requires more than black and white contract:
- definition of scope is changing along the development, and either side can abuse the scope change flexibility.
- cancellation policy should be custom made according to different project natures and ideally protect both side.
It requires lots of communication. In order to keep things transparent and react fast (to scope and timeline change), extra project management tasks are needed.