This post originated from an RSS feed registered with Agile Buzz
by Laurent Bossavit.
Original Post: The insurance point of view
Feed Title: Incipient(thoughts)
Feed URL: http://bossavit.com/thoughts/index.rdf
Feed Description: You're in a maze of twisty little decisions, all alike. You're in a maze of twisty little decisions, all different.
For a long time I've been wondering if one could make a business of insuring software projects.
OK, I suppose you've stopped laughing now. Consider a few facts. When I was writing about the parallels between Terry Gilliam's Don Quichote and software project failures, I came across a particular type of insurance contract: what the movie industry calls a "completion bond", "completion insurance" or "completion guarantee".
Completion guarantees generally apply to independent productions, who arrange funding from various sources - banks, public funds, and so on. If the movie production runs into technical trouble, the insurer will pay out money as required to complete the film - or they will have to reimburse the funders if the movie can't be salvaged at all. Providing completion guarantees turn out to be a nosy business. The insurer will look at every aspect of the production, cast, crew, screenplay, location... They will also expect regular reports from the production showing how the movie is progressing against its schedule. The cost of a completion guarantee seems to be a few percent of the total budget, usually less than 5%.
If nothing else, transposing completion guarantees to software development makes for an interesting thought experiment. Like a software project, a movie rarely starts with extremely detailed specifications. The screenplay comes closest to a spec; but at a typical 100 pages in length, it is only a bare outline of all the detailed decisions that will be necessary for shooting - from costumes to camera angles to catering, and so on. And even though movie scripts are revised and revised before production starts (i.e. before a completion guarantor sees them), they are often revised quite a lot after, too.
So, suppose you are in the business of insuring software project completion. Your job is not to make sure the project's funding comes through: if the project's sponsors cut funding, you are off the hook. Your job is not to make sure the end users love the software: after all, a film can be completed and bomb in the box office. Your job is to see the project go live, providing any extra money necessary to make that happen: funding a protracted beta testing phase to work out the bugs, hiring replacement coders, analysts, or project managers if part of the team leaves, and so on. If the project can't go live, you have to reimburse the project sponsors.
The flip side of the coin is that you have extensive powers of oversight over the project. Of course you don't particularly want to be involved in the day-to-day management, or in any creative decisions; that's not your job either. Your job is to assess, before and during, how likely the project is to complete, given the team, the project manager, the process, the technology, and so on. Any decision about the overall plan is subject to your approval. You can see a rough specification - maybe a list of use cases or user stories would come close to the level of detail in a movie script. (A huge difference is that there are standard expectations and even a standard physical format for movie scripts ! No such thing in our profession.)
What would be the items of first importance on which you would base your decision to provide completion insurance, or decline to do so ?
My hunch is that some of the things we get excited about - TDD, UML, MDA - would barely be on your radar. I could be wrong, but I suppose two of the important things would be story and people. By "people" I mean the project manager, product owner, developers, testers... You'd want to see the CVs of the key people involved in keeping things moving. I'm fairly sure "story", in the sense of what the project is meant to achieve for the business, whether it seems to be a serious bid at creating business value, whether its sponsors are truly committed to its success, would also be a major factor. I'm less sure that details of method or process would be investigated in any great detail, though the overall strategy could make a difference.
This is not to say that TDD, and so on, aren't important. To you as one of the people on the team they may be very important. They may be some of the skills which have earned you the sort of reputation which makes guarantors go, "Oh, if this guy (or gal) is on the team, I'll sleep easier about this project."
Story and people first (I can't decide in what order), process a distant third and a broad outline of process at that; that's what I think I'd look at if my business was completion insurance for software projects. I could change my mind about that; the point is that taking this view is a good way to review what we think is important about running software projects. So, what do you think ? What would you look at ?
Previous Topic
