The insurance point of view
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 ?
four comments:
For me, people is the clear first thing I’d look at. Even your “story” includes elements of people, e.g. sponsor commitment. (Sponsor commitment is my number one factor. These days I tend to tell clients “If your sponsor isn’t prepared to commit time to tbe project, maybe only an hour or two a week, then the project probably isn’t worth doing.” The project may not always need the time, but it will always need to commitment that it signifies.)
My experience working with execs in publishers of computer games (a combination of film and software) aligns to this. The first thing they look at is the team. If the team has a good track record, they barely look at the rest. If the team is unproven, then they look into the storyline, project plans, risk management, financial controls, etc in depth before they fund any development.
One difference you highlight is interesting: film has standard formats for scripts etc. So they don’t need to look at this stuff: they can spend all their time focusing on people and story. When everyone is baking their own methods and notations, then you also need to spend time asking whether their methods make sense.
Graham Oakes (URL) - 31 05 07 - 09:26
There are completion bonds on nearly project there is except software projects.
Glen B. Alleman () (URL) - 08 06 07 - 02:32
One or more comments are waiting for approval by an editor.
No trackbacks:
Trackback link: