Output-Based Agreements (OBA) enable a customer & supplier to agree an acceptable price for a suitable quantity of functionality, simplifying contractual negotiations, while freeing the developers to use whatever methods are most effective for achieving the desired outcome(s).

Of course, different ‘types’ of software functionality are subject to differing non-functional requirements (actually, the entire gamut of ‘ilities’ identified by ISO9126… reliability, portability, maintainability, security, timeliness, etc.).

The functional requirements for the real-time embedded software controlling an automotive braking system is likely to be subject to different non-functional requirements than the functional requirements for a web-based online shopping application.

But these differences can be reflected by applying a different unit-price. Just as Jersey Royal new potatoes are priced differently per kilogram than last season’s King Edward old potatoes (best for chipping or baking).

Before measuring value, projects first must measure their outputs (rather than only inputs: effort, time & money).

Measuring value isn’t simple. Value depends on the users’ perspective & behaviour. Users derive value only if they use a product. ROI depends as much or more on the behaviour, skill, experience & environment of the end-user than on the supplier.

It’s the supplier’s job to understand how users perceive value & what can be done to maximise it.

But customers are happy to buy goods & services for a (fair) price-per-unit delivered.

That’s how shoppers buy groceries (potatoes/kilo). How drivers buy cars (£/car). How audiences buy entertainment (pay-to-view).

Customers don’t expect suppliers to second guess what meal they will cook using the potatoes, or where & how far they’ll drive in the car. That’s the customer’s business.

In the same way, it is reasonable to buy software functionality (with particular non-functional characteristics) as a commodity, using a unit-based pricing regime.

(expanded from my 5 minute talk at the Not The Agile2010 Conference on 10-Aug-10)

If you are a software developer, how do you regard your work – as science, engineering, craft or art?

The fact is, it matters little what developers and the end-users of the software products think. Those who have responsibility for signing the cheques and commissioning the work regard software as commodity.

Now consider. What is it that agile developers most hate about the so-called ‘waterfall’ software life-cycle?

I suggest it is the ‘big design up front‘ aka ‘batch & queue‘ approach in which both those commissioning the software and the developers pretend it is feasible to identify all the requirements in one go. Ever since Daniel McCracken and Michael Jackson published their 1982 paper ‘Lifecycle concept considered harmful’, the impossible nature of such an endeavour has been pretty clear. Being forced to adopt a batch & queue approach that you know is wasteful and ineffective is frustrating, at the very least.

So, what do members of the agile community like most about lean-agile methods?

Perhaps many would consider the most important aspect to be the importance placed upon person-to-person interactions, with developers engaging closely with end-users and with other team members. It seems that organisational structures & rules that prevent this desired interpersonal work style are perceived to be very de-motivating. I know several software engineers who have left their employers because they believed inter-departmental barriers made effective processes impossible.

OK. If agile developers want to use effective methods to engage closely with the end-users, to deliver value incrementally… what is it that project sponsors (the folks who find the budgets & sign the cheques) want from their ‘contract’ with the developers?

I suggest they want assurance. That is, predictability and close to certainty that they will get what they want (or need), in the quantity needed, at the right time and place, at an affordable price. And because even the CFO and their C-Level colleagues have to justify their expenditures to the CEO, the company board & the shareholders, they need to be able to demonstrate value for money.

Hmm. How do we square this circle, where the technical folk on the supply ‘side’ recognise the uncertainty inherent in development and innovation, while the decision-makers on the customer ‘side’ value certainty? We need a form of contractual arrangement that somehow facilitates an effective process and satisfies both groups.

This is exactly what Output-Based Agreements (OBA) achieve.

Determination of requirements is best described as a process of exploration. This is true for practically all new developments and most enhancements to existing systems. Ideally, it involves both end-users (i.e. experts in the business domain) and technicians (i.e. those with the know-how of what the technology can offer). The requirements evolve as both parties learn more about what is needed, and what is possible, through a process of feedback. And the most pertinent feedback is derived when initial ideas are put into operation. Then people can see how their ideas work in practice. What is more, stakeholders benefit from incremental satisfaction of their highest priority needs. But this exploration (and experimentation) takes time.

So it is in the interests of both parties to get going as soon as possible. No one benefits (except maybe the lawyers) from a long-winded procurement process that involves time-consuming negotiations regarding the exact details of requirements (which is, as I’ve said, a task doomed to failure). In any case, there is no necessity to determine the Nth level of detail up front, and significant benefits from not doing so. By deferring commitment until the last responsible moment, customers enable suppliers to keep design options open, thereby maximising the potential value delivered.

Here is the secret for winning business, for satisfying both the customer’s need for an assured outcome, and the suppliers desire to use effective lean-agile methods. Divorce the iterative process of exploration & delivery from the process of negotiating the price and terms & conditions. This is what OBA achieves.

The technique is familiar to nearly every housewife. Say the housewife goes to the greengrocers for the weekly or monthly shop. They know it is likely their family will want to eat potatoes at several meals during the coming days. But they don’t have to decide up front and in exact detail what they will cook. That depends on circumstances and what the family fancies on the day. For different meals they may serve boiled potatoes, mash, roast potatoes, jacket potatoes, potato salads, chips, wedges, potato dauphinoise, etc. (ref: http://www.lovepotatoes.co.uk/recipes/). The choice of what to cook can be deferred to be decided until just before each meal.

So the housewife buys a quantity of potatoes, say 5 kilos. For an agreed price. Say 78p per kilo. A total cost of £3.90 GBP. Of course, every potato is different. Some are small, some are larger, some are a funny shape. It doesn’t matter. It is perfectly feasible for the shopkeeper and the housewife to negotiate a price per kilo and clinch the deal.

That’s essentially how an Output-Based Agreement works. The customer and supplier agree delivery of a quantity of software functionality, and a price that is satisfactory to both. The total price is calculated from an initial coarse estimate of the quantity required, say 1000 COSMIC Function Points (CFP), and an agreed unit price, say £500 GBP/CFP. So the contract price is agreed at £500,000 GBP.

The supplier must have a good idea of the process performance they achieve, and hence their unit cost for producing software (of the kind required, using reasonably familiar technology, etc.). They must allow for a suitable profit margin. Given such information, and agreement from the customer to commit end-user effort to the development, they will be able to commit to agreed completion dates. They’ll be able to determine how many teams, the team size, and number of iterations or sprints.

Experience suggests that, because there always will be some uncertainty in the initial estimate of the quantity required (i.e. the functional size of the functional user requirements), it is wise for the parties to agree a tolerance (say +/– 10%) for the total delivery.

The OBA can include clauses that cover the situation for when the scope of the functional user requirements turns out to be larger than both the initial estimate and the tolerance combined. One way is to agree a 2^nd tolerance band of another 20% say, to permit a total requirements size of up to 1000 x 130% = 1300 CFP. I suggest a premium price is agreed for these ‘extra’ requirements, say £600 GBP/CFP, in this example. This is to dissuade the customer staff from gold-plating their requirements unnecessarily. The funding for such ‘extra’ requirements should come from a ‘risk reserve’ budget, managed at a senior level, so that the Product Owner and the Development Team have to justify the expenditure.

A further clause can be included in the OBA to cater for the situation when, during the early exploration of the desired outcome, the parties determine that the initial coarse estimate is seriously flawed. In which case, the best thing to do may be to stop and start again.

Contracts like this have been used by some since the 1990s. Users often find that the services of a 3^rd party Scope Manager can be instrumental in facilitating an effective working relationship. The Scope Manager is independent and objective, and hence can be trusted by both customer and supplier. They bring the skills of a ‘Quantity Surveyor’ to the project, taking responsibility for determination and agreement of the initial estimate. They work with the Development Team to monitor the size of the functional requirements, and report to customer & supplier management throughout the development, in step with the sprint schedule.

The Project Sponsor gets assured delivery of an agreed scope, on time, within budget. They understand the price and can demonstrate value-for-money. The Development Team and the Users work together effectively to explore the demand & deliver results incrementally. Everyone’s happy.

Simple really. But isn’t that the essence of the lean, agile approach?

Time for a new approach!

On 28^th July 2011 the House of Commons Public Administration Select Committee (PASC) published its 12^th report titled ‘Government and IT — “a recipe for rip-offs”: time for a new approach’ (ref: http://ow.ly/5Pm2e ). Amongst other findings this report calls for: better measurement & benchmarking; greater transparency; smaller contracts; more engagement with SMEs; an outcome-focus that avoids over specification; leveraging agile practices; increased user engagement in service design; improving ICT acquisition skills and acting as an ‘intelligent customer’; a stronger role for Senior Responsible Officers (aka Product Owners); and the use of open standards. The aim being to reduce the cost of services that rely on software while maintaining the quality of public service. Hence the subtitle: ‘time for a new approach’.

The need for a ‘new approach’ to purchasing software systems is surely felt as much by the private sector as by the public sector.

Governance needs assured outcomes

Budget-holders, senior decision-makers and especially Chief Finance Officers in customer organisations are required to ensure good governance of any projects they commit to. They need assurance from their suppliers that the desired outcome will be achieved on-time and within budget, delivering products of acceptable quality. The schedule often is set by the natural cycle of the business. The budget has to be compatible with the organisation’s annual budgeting process. Such disciplines are unavoidable.

This raises barriers for those suppliers, particularly small to medium enterprises (SME), that recognise that agile practices offer the least-risk, most-effective route to the development of innovative products that deliver business value and a satisfying user experience.

Many commentators have suggested that the agile, incremental delivery approach is incompatible with the essential needs of government and corporate managers to demonstrate good governance of ICT projects. Indeed, Alistair Maughan, an experienced corporate lawyer who has advised on large public and private ICT contracts including HM Revenue & Custom’s controversial 10-year £8.5bn deal with Capgemini, has recently argued < http://ow.ly/5Rr1F > that “Agile… won’t work in the real world” of government ICT projects. One basic argument used is that projects fail due to a “lack of trust between customer and supplier” and hence the “Agile credo of, “Let’s trust each other some more” is undermined from the start.

This seems an insurmountable barrier to, or at least a grave constraint on, the success of SMEs using agile practices.

Yet there is a tried-and-tested solution that has been used by some customers and suppliers, large and small, for approaching twenty years. And nowadays it is easier than ever.

‘Specification’ does not assure the outcomes

The traditional solution has been for customers to attempt to specify their requirements to the Nth degree of detail, then to negotiate a fixed price contract with their preferred supplier; the classic ‘big design up front’ approach. Customers have assumed that, if they deal with large corporate suppliers, their risk is reduced because the supplier has sufficiently large resources to cope with the inevitable changes in the requirements. But as the man once said, “TANSTAAFL! – There ain’t no such thing as a free lunch”! Such behaviour naturally pushes up the price paid, favours an ever-decreasing number of large systems integrators, constrains innovation, and incentivises the supplier to impose restrictive change management procedures and charges.

It is, in any case, theoretically impossible to specify requirements in advance like this. Furthermore, because the end-users that specify the requirements are told they have just one chance, they are incentivised to cram every potential need they can think of into the specification. This inflates the scope with lots of features that ultimately prove to be unnecessary. Competition between stakeholders makes prioritisation time-consuming. Specifiers resist signing-off specifications, because they are never sure whether they’ve omitted something later deemed to be critical. They don’t want the blame! This increases the risk the project will be late, expensive, over-budget and deliver defect-ridden results.

So what’s the solution?

When buying commodities (such as potatoes or logs of wood) we don’t try to specify the detail of each potato or log. We agree the nature of the commodity and an acceptable unit-price. Then the customer specifies the quantity of the commodity they want and a fixed price is agreed, calculated by multiplying the quantity by the unit-price. Simples!

Variations in the individual potatoes and logs are accommodated during the delivery, which is subject to appropriate, fast, cheap, unobtrusive quality controls and progress tracking.

Both customer and supplier collaborate and coordinate resources to ensure delivery aligns with the business needs and work continues until the agreed quantity is delivered.

Frameworks treat software as a commodity

Many contracts for outsourced software development actually already work this way; especially large framework agreements, both in the public and private sectors, in the UK and abroad.

The parties agree acceptable unit-prices for whatever kinds of software functionality are needed (usually there are a small number of software ‘types’, maybe 2 to 8 kinds). Then for each new development or enhancement project, the parties agree the required quantity of software functionality, expressing the scope in terms of the ‘functional size’ of the requirements measured e.g. in COSMIC Function Points. Then a simple contractual arrangement is agreed. The need for detailed specification and prioritisation is deferred, to be thrashed out piecemeal by the end-users and the developers who are closest to the business need (to the ‘gemba’, as the Japanese say).

Prerequisites

In such a scheme, an onus is placed on the supplier to measure, understand and have confidence in its process performance. Improvements in performance result in direct benefits to the supplier, in increased business and/or profit margins. Changes in the backlog are measured as they are made and their effects on scope and costs are immediately visible to all.

In turn the customer must be prepared to allocate the resources necessary to explore the detail requirements and provide the rapid feedback and collaboration that the developers need. The customer must be prepared to prioritise within the agreed scope. Via rapid feedback the end-users ensure the work remains aligned with demand and changing business needs.

This is how risk is minimised for all concerned. It is also how trust is established and sustained, resulting in less waste; better, longer-running business relationships; and better products.

The role of the ‘Quantity Surveyor’

Of course, both customer and supplier must have confidence in the characterisation of the required functionality and the credibility of the measurements used to determine the functional size.

For this reason, some customer-supplier partnerships have found it helpful to engage an independent, objective and trusted third party ‘Quantity Surveyor of IT’ (aka. a ‘Scope Manager’) who can provide the necessary assurance of the measurements and the ‘fairness’ of the price charged.

Using an internationally-recognised standard measure (e.g. COSMIC FPA) to quantify functional requirements makes visible the effect of additional requirements on the cost of development, and enables independent, objective measurement audit.

Why COSMIC?

The COSMIC Function Point Analysis method is technology-independent and applicable to a wide range of software types. It provides creditable, reliable measurements that can be used in estimating, to track requirements burn-down, and to facilitate Output-Based Agreements for software development and enhancements. Such agreements satisfy the customer organisation’s need for assured outcomes, while enabling the supplier and end-users to explore the detailed requirements iteratively to get the best results from agile practices.

Employed correctly, COSMIC provides budget-holders with the assurance they need that they will receive value-for-money and have their outcomes fulfilled on-time, within budget.

This is achieved, not through a specious ‘big design up front’ specification, but by commissioning software development on a commodity basis, deferring commitment to detailed requirements to the last responsible moment commensurate with the customer’s purpose and required return-on-investment. Applied this way, COSMIC simplifies and speeds negotiations and reduces the costs of sale and acquisition.

COSMIC provides an objective, repeatable and technology-independent measure of the functional size of software requirements. The method facilitates comparisons and benchmarks of process performance over time, between processes & technologies, and across projects & organisations. COSMIC measures can be independently audited and benchmarked. It is an international standard (ISO/IEC 19761:2011) used in at least 30 countries. It has been adopted as a National Standard in Japan, Mexico and Spain. The method is an open method, with the Measurement Manual and related guidelines available in the public domain from the COSMIC website (ref: < www.cosmicon.com > ).

Sitting in the middle listening to thought-leaders like Grant Rule, Stephen Parry, Tom Gilb, Bob Marshall etc. is frustrating for a writer like me. I want to capture and distill the thoughts and insights that constantly fly past me.

So in this blog I’ve appointed myself the unofficial special correspondent for Rightshifting. I will be seeking to share with you my thoughts on the discussions I am privileged to share.

I thought I’d start with one image I dreamed up following a discussion between Grant and Bob about the components of organisational effectiveness. Rightshifting effectiveness is not a model. It’s not even a methodology. So what is it?

I think it’s like the DNA of living organisms. You can create a human-like skeleton; you can even, these days, create a something approaching a human-like nervous system. But unless it has the core ingredient of life inside it, it’s not a living thing.

In the same way, there is organisational DNA. You can have systems, and processes, and products and people; but without the core ingredients  it’s not an evolving, growing, sustainable organisation.

It seems to us there are four elements of organisational DNA – leadership, organisation of work, problem-solving, and design/engineering.

In effective organisations, entrepreneurial leadership is  endemic throughout the organisational culture.

“Entrepreneurial Leaders are born not made”

Are they? Let’s analyse what the words mean:

Entrepreneurial: the ability to spot and exploit opportunities

Leaders: inspiring and enabling others to achieve an objective

So an effective organisation needs entrepreneurial leadership not just at the top, but running through the business like DNA. To be an entrepreneurial leader, any individual needs:

Talent. This is the bit you’re born with. Every parent knows that every child  is born with talent. Whether it turns out to be a talent for doing things in a reliable and methodical manner or for creating amazing new products; or simply the ability  to empathise and communicate – in other words, to care. Our working experience is a personal history of applied talent. All too often, regrettably, it’s a history of largely wasted talent.

Passion A real leader cares about achieving the outcome – whether the outcome is turning over a million or having a clean street. They care enough to subvert ego and do whatever it takes to get the right result. Such passion and commitment inspire others. A cleaner with a meticulous pride in doing a good job can be as inspirational a leader in their area of expertise as a charismatic executive. If you’re running a hospital – or a hotel – entrepreneurial leaders on the cleaning staff are crucial.

Time In a crisis, you don’t think about what you’re doing. You react. If your organisation is in a permanent state of crisis, the odds are no-one is thinking. Leaders are pro-active, and an effective military leader equips his troops to think for themselves and react intelligently to events.

Permission The organisational cutlure has to give people permission to think for themselves. Thinking takes time. It may be time away from your desk. It may be time when it looks like you’re not working.

To be innovative and creative, people have to have permission to be wrong. If  you get a slap in the face every time you open your mouth, you have two choices – keep quiet or learn to fight back. Neither are conducive to releasing the inner talents of working men and women. Keeping quiet and keeping your head down means you simply disengage your creative thought processes from your working life; there is no point in doing anything other than passively “going with the flow”.  Fighting back can initially be exhilarating, but after spending a while banging your head against a brick wall, it is nice to stop.

Support Empowerment has to be real. People have to be given the backing, the budget, and the resources to do good things. If my boss listens very nicely then goes out and does precisely what he/she wants I will quickly understand that  “Staff empowerment” is a gloss. It’s not a real change in the status quo. If every time I try to do anything, there is no budget available – or the hoops you have to jump through to get funded are too fiery for my nerves – I am likely to choose a quieter life.

Skills Whether it’s presenting, persuading, communicating, writing software code, managing a team, or making the tea, there are a host of different skills that support a successful business enterprise. No-one has all of them. The entrepreneurial leader has an insatiable curiousity and a huge willingness to listen and learn. The successful business feeds and directs this hunger.

And finally :

Trust Any organisation is the sum of its parts, and what comes around goes around. Each individual engaged in the enterprise has to feel able to trust the integrity and the judgement of their peers, their subordinates, and – crucially – the management and executive. Once lost, such trust is very hard to regain.

Next time – organising Lean workflow

Sue

Pretty much since “software” was first invented (60 years ago?),  numerous folk have been promoting an ‘engineering-led’ approach to ‘software projects’.  Yet this advice goes largely unheeded, with the result that the relative success of IT projects is poor, and has improved very little  during all my years in IT (38 and counting).  Given that such admonishments seemed to have had such little effect in all that time, I also find myself asking,  “Do I think it likely that further exhortations to those involved in ‘software projects’ to change their project practices is likely to achieve improved value delivery to stakeholders?”

And I have to conclude that the answer is “No”.

Following Albert Einstein’s adage that, “The definition of insanity is doing the same thing over and over again and expecting different results”, it seems to me that we need an entirely new approach. A new approach which goes to the root causes of what actually goes wrong in the end-to-end process. Why are the honest endeavours of software developers often so disconnected from the delivery of customer and stakeholder value?

Observation of what actually happens in organisations suggests there are two root conditions to the problem:

1) Those responsible for business strategy are disengaged from, and know relatively little about, software-intensive systems and technology. So they structure their organisations so that software & technology people are segregated into silos. In those silos, the inmates talk amongst themselves in whatever arcane language they choose. But importantly, they don’t communicate (or interfere) with the ‘real business’.

2) Everyone conspires to pretend that software-related activities should be managed as ‘projects’. That is, as chunks of work that start and end (on more or less clear and agreed dates), that have more or less well-defined goals, that contain a list of activities (tasks) that are assigned by a ‘project manager’ to a project team to which ‘resources’ are assigned for a limited period.

The results of studies too numerous to mention shows that most software projects are ‘challenged’ or ‘fail’. One study suggested that the majority of experienced project managers (and I am sure, folk playing other roles) expect at least 1 in 3 of the projects they lead to fail! As systems become more complex, and larger, they employ more teams combining projects into programmes… which further reduces the likelihood of successful achievement of the overall goals.

My conclusion is that we need a complete change of mindset. We need to move away from the inherently batch & queue concept of the ‘project life-cycle’ (as promoted by organisations including BCS, APM, PMI, OGC, SEI, NCC, ISO, IEEE, IET, etc. etc.) to a different approach.

I suggest that the required new mindset will accommodate the ideas of flow production and lean systems thinking that first began to be developed systematically (in e.g. automotive engineering) around 100 years ago. (Of course, one can trace elements of flow production & lean at least back to Carthage c.300-200 BC, but let’s ignore the history for now.)

I posit that Tom Gilb’s Evo method, and other agile methods such as XP, Scrum, Flowchain, and software Kanban, etc., begin to achieve ‘better’ results compared to ‘traditional’ big-design-up-front, wholly batch & queue methods, precisely because they encourage workers to focus on smaller batches of stakeholder value. In other words, value in terms the software developer can get to grips with.

Agile methods are one or more steps nearer to the ideal of ‘single piece continuous flow’. BUT… they are inherently limited because they continue to create & disband teams, to establish & abandon value streams, to create & throw away know-how, at – it seems – every opportunity. And crucially, they allow the C-suite and ‘business-side’ managers to ignore their responsibilities for the system of work and for the desired outcome.

Flow production (toward which Evo, Flowchain and Kanban currently make the nearest approaches IMO) would:

A) Make the entire end-to-end, whole-life, ‘concept to consumption & retirement’ process of defining, deciding, acquiring, designing, developing, operating, supporting, maintaining & replacing software-intensive systems a visible, inherent part of normal business operations… forcing issues onto the management horizon  so they can be addressed as business issues – and not just something technologists worry about.

B) Because it would be apparent that software & IT issues were causing interruption to (or even cessation of) the flow of value,  C-suite executives would have to recognise the pressing need to engage with software & IT related issues just as much as they do with other kinds of business issue. Conversely, the engagement of  the ‘systems and software engineers’ with ‘the business’ would also be stimulated, the role of each and the communication between them finally becoming acknowledged as a main artery of the organisation’s lifeblood.

Flow production can only work effectively with the active engagement of all involved. For this reason it is a far more sustainable business model than other, perhaps more familiar, approaches. It embeds the ability to flex and respond to market forces deeply into the organisational culture. The focus on ‘the unforgiving minute’ forces constraints and problems out into the open where everyone can see them. It won’t allow problems to be swept under the carpet, or passed from one department to another like the proverbial buck. Hidden problems will always result in debts in one or more of the five kinds of capital. And such hidden debts, whether financial, technical, intellectual, social or environmental, all too often bite you when you least expect it. They will injure or kill the project – and destroy stakeholder value. Even if the project avoids repaying its hidden debts, this usually means that the debt has been passed-off onto one or another unsuspecting stakeholder group (sometimes, the end-customer or taxpayer). Which must be judged as unethical behaviour.

Unfortunately, not only have most people in the software industry been taught to sit in their silos and focus largely on coding,  they and their masters have developed a cultural love affair with the project concept. To the extent that everyone assumes that all work has to be compartmentalised into projects, the very epitome of batch & queue thinking.

Tell me what you think. Has the software project had its day, or is there another way of revolutionising workpatterns in the software industry?

I’ll be talking to some other folk about these issues in the first  SMS’ “Mythbuster” webinar on Wednesday 12th Jan. at 4.00 pm GMT (see our “webinar” page under the Library section) We’ll update you with their feedback.