Agile, and Scrum in particular, are buzzwords. Everyone wants to try out Scrum and reap its benefits. Clients (especially business clients) see a big advantage in not having to wait till all the requirements are carved in stone before starting a project. After all, Agile is about embracing change, so one can start a project with an idea that need not be documented in the most minute detail. With this thought in mind, they float a request for proposal (RFP) to vendor organizations.
However, one thing that every business does need is to come up with a dollar amount, a budget sanctioned for the project. This is the figure that will be tracked by management and used to assess the project's success or failure. Since, in the end, it is the ROI that matters and helps improve an organization's standing in the stock market, this dollar figure becomes very important. A small figure will lead the project manager to ask for more money during the course of the project, putting him or her at risk of being labeled a poor planner. A substantially high figure will make him or her look inefficient; other will argue that the money could be better used elsewhere.
Hence it is very important, from a PM's perspective, to arrive at a realistic figure. To do this, PMs depend on the vendor organization. However, I've often seen clients asking for a fixed quote based on requirements that are far from fixed. And since bids are competitive, vendor organizations feel the pressure of putting out the best bid while still maintaining a healthy profit margin. In a scenario where the requirements are not clear or not complete, this becomes a big challenge.
To address this scenario, I've listed some possible solutions:
- As a first step, we try to assess the quality of the input of the RFP by getting different experts from the domain and technology. These experts share their experience and come up with a list of questions. The questions are addressed internally and, if necessary, taken back to the client for further clarification.
- Next we try to assess the requirements from different perspectives. This step requires expertise from various sources and needs to be done carefully.
- Requirements that are clear; we foresee no significant changes
- Requirements that are incomplete; we foresee moderate changes
- Requirements that are ambiguous; we foresee many changes
- Requirements that are potentially missing or implicitly stated
- Once step 2 is done, we can create a table that summarizes the status of the information. Some examples are shown below:
As you can see, in Scenario One almost 50% of the requirements are assessed as moderate to clear, while almost 70% are unclear in Scenario Two. Therefore, each scenario requires a different approach for giving an accurate quote. While there is no scientific model available to make such a guess, some things can be done to mitigate risk:
- Identify the risks associated with the ambiguous requirements. Add that amount to the figure obtained from estimation of the relatively stable requirements. While this is not highly scientific, it provides a realistic approach to coming up with a budget. So if the estimate for the "stable" requirements is 40% of the total and amounts to $2,000, and the percentage of "ambiguous" requirements is 60%, its portion of the total cost could be set at $3,000. The big assumption here is that what's missing is similar in complexity to what's already known.
- Provide a quote based on time and materials for the Requirement Definition (RD) phase and another quote for the remaining phase. What this means is that for the RD phase, the vendor has the flexibility of adding or removing resources during the execution. The objective is not to get a signed-off requirement at the end but to move more requirements from an "ambiguous" or "missing" designation to a "moderate" or "clear" one. Once done, the risks become significantly lower and the client retains the opportunity to make the changes to the requirements during the project execution as needed — which, after all, follows a core principle of Agile (embrace change).
- Finally, in scenarios where neither of the above steps can be done, it's best to give a ballpark figure based on experience, while being aware of the underlying risks and assumptions. The basic Agile principle that ensures that the team is always working on the highest-priority item in the PB, and anything that's left out will be of lower value, will ensure that the budget is used for a good ROI.
Additionally, the vendor needs to make clear to the client, during the discussion process, that there can be changes to the project cost during the execution — and that, if necessary, these can be specified in the contract as well. The benefits for the client are:
- Cost changes won't come as a surprise at the end of the project.
- Even if the client decides to stop the project, there will already be a product working in the live environment, with all the features that the business thought were of highest priority.
The lesson here is that, while there are challenges in estimating bids for an Agile project, these challenges can be overcome through a logical and open-minded approach.