Risk contracts in Business Case

By Eugenio, on July 23rd, 2009

Finding the right connections

In the Business Case, Risks are future occurrences that could reduce the ability to respect Costs and Timescale (and Performance).

The risks are shaped by “Options” and the resources needed for reducing their impacts should be found within the “Benefits Expected”. If the strategy for tackling a risk is based on its acceptance (yesterday’s post) , “Reasons” should be strong enough for sustaining the (potential) damage for the ratio that has not been covered by any form of hedging.

Risks in relation with contract’s type

PMI supplies three forms of contracts:

Fixed price:

A lump-sum amount will be paid for the delivery of well defined outcome (either product or service).

Cost reimbursable:

The seller will receive the corresponding amount of the incurred expenses plus a fee representing the seller profit. Costs are categorized in direct one (those incurred for the exclusive benefit of the project) and indirect one (the company’ overheads).

Time & Material:

The seller makes available resources, whose costs are categorized by professional skills. In this case there is no incentives related to meet or exceed selected project’s targets.

Whatever is the chosen contract’s type, the basic risks remain the same. They could be resumed in few questions:

Are the estimations (likelihoods) “good enough” for allowing the people with the right skills and means to match the requirements?
1. What does mean “good enough?
  1. If estimations are too optimistic create a situation where less money available reduces the possibility either to hire the people with right skills, or they do not have time and “machine” sufficient for delivering the “product” with the stated properties and qualities (either features or performances)
  2. If estimations are too large, the buyer would find difficult to accept a price beyond the market value.
Is the concept of “Quality” shared among all stakeholders? It shall encompass all aspects of the project. These are some important topics:
1. Clarity and feasibility of requirements.
2. Criteria for evaluating the importance of each feature (i.e. bluntly: how many users will benefit from it?)
3. Is the chosen architecture (COTS) near to the product’s needs?
4. Is there enough familiarity with the proposed technologies?
5. What can be considered properly “done”?

Productivity is not enough

Reducing the process of producing software to the development (perhaps with the collaboration of a “special” stakeholder) offers a good chance of “if you build it, they will come” situation.

Whether the project covers all step of the product’s implementation, or it is limited to the production, the Business Case has to supply valid interfaces for the remaining processes.

This is a simple list, just for reminder:

implementation
functional tests
documentation
1. for users
2. maintenance
3. learned lessons (best source for next estimations)
training
maintenance

Conclusion

Considering the “Reasons” as questions and “Options” (with Costs and Timescale) as answer could improve the role of “Risk” as first test for the project’s feasibility, in first instance and then to probe the organization’s capacity to deal with the uncertainties.