Applitude

When talking about agile projects many books seems to be written under the assumption that you work with the whole life cycle, from its initial conception to maintenance and support of the system. But quite often, parts of the project are done by another supplier. This other supplier may have a different underlying motivation and his business may not be the same. The most common price unit in knowledge-based work is probably price per hour, direct or indirect. The buyer’s income model is probably different; it may be based on cost savings, or on either revenue from or new opportunities emerging from the product (or transaction), or interval based, such as price per month. Therefore, a built-in conflict may exist between the revenue model for the buyer and that of the supplier.

Who should take the commercial risk?

The buyer can handle the project on their own and just hire or contract some consultants that will work on a per-hour basis, in which case the full risk remains with the buyer.  Or the buyer can outsource a part of the project to a supplier, who also takes an agreed-upon portion of the risk as part of the deal.

This is often handled with a requirement phase that produces a requirement document that one or more suppliers use to develop a bid for winning the contract from the buyer. The contracts often include the total cost, some options (often add-ons) and a time when the delivery shall be done.

The problem with this is that it doesn’t facilitate changes and the flexibility to apply knowledge that you gain during the project very easily. When the project starts, keeping to the original plan becomes more important for both parties instead of maximizing the business value. This prevents either party from incurring cost or schedule overruns that could turn their side of the contract into a losing proposition.

This inflexibility negates the benefits of agile development projects, which are adaptive so as to maximize business value. But there are alternatives to fixed-scope/fix-price types of contracts. I will talk about different kinds of contracts soon but first I would like to explain maximal value focused.

Read the rest of this entry »

The traditional plan-driven projects are based on the traditional “iron triangle” of Time, Cost and Quality. All requirements have to be accounted for in the requirement phase and then the project is planned around the expected features to be delivered. The features are the first ones to be fixed, afterwards an estimation of time and costs in delivering those features is drawn up.

The Agile mindset, on the other hand, is to fix time and cost to manage a variable scope. This leads to the ability to hit deadlines both in the short and long perspective. This way it’s easier to focus on features that build value and to avoid building features that never will be used.
Remember Pareto’s principle – the old 80-20 rule. Vilfredo Pareto, an Italian economist, observed in 1906 that 80% of the land in Italy was owned by 20% of the population; he also observed that 20% of the pea pods in his garden contained 80% of the peas. This is how he came to formulate this principle. In business, people say that “80% of your sales come from 20% of your clients”. So wouldn’t it be great if you could avoid building features that will never be used?