Fixed Price and Agility

I’ve come to love ‘agile’ systems implementation methods, and they are rightly fashionable in the nerdy circles in which I move.

But when I was trained on business software implementation methods many decades ago, I was told that it had to go like this:

  • find out what the customer wants, and write it all down,
  • get his sign-off on the requirements document,
  • design the system, and write it all down,
  • get his sign-off on the system specification,
  • build the system,
  • get his sign-off on the system,
  • and so on.

It didn’t work well. In the first step you might get it nearly 95% right, though there was still a danger that the customer didn’t know what he wanted until he’d seen what he might get.

But the second step was usually the dangerous one. If you’d gained the customer’s trust by the time you’d put the specification in front of him, he’d usually sign it off, even if he had no idea what it meant. System specifications are usually written in an inhuman language using the terminology of the target system. Crucially, they convey nothing at all about what it might be like actually to use a system.

The system build would often happen somewhere far away in a software laboratory, to which, of course, the customer would usually be denied access.

And then the last step didn’t happen, because when he saw what you’d built he wasn’t usually very happy.

agilecascade

This was the old-fashioned ‘cascade’ method and it’s rightly out of fashion. The ‘agile’ method involves more frequent meetings, discussions and demonstrations, so that the customer sees what you’ve understood, what you’ve designed, and what you’ve built and can quickly tell you if you’ve got it wrong before it’s too expensive to change course. When you’re implementing highly configurable software systems such as our time@work, expense@work or forms@work products, or Infor’s SunSystems, prototyping is relatively easy and this method is perfect.

At systems@work we’re doing a big implementation project for a fund services provider. It involves expenses, vendor invoice management, billing, timesheets and lots of workflow and reporting, and all the accounting that goes with all the transactions that are implied. Yesterday we conducted an important  prototyping session, and I’m happy to say that it went well. There are a few things that we must change, but there are no fundamental misunderstandings.

But what about the agile method when a project is a fixed price one? Isn’t it potentially a recipe for disaster, in that changes of course are unpredictable and there’s no single moment when you can pin down the project scope in a system specification and treat all subsequent changes as separately chargeable?

This is not an easy question to answer. Wise and experienced project managers will build in a large ‘contingency’ component and perhaps put more emphasis on getting the requirements document right (even this stage of the project can involve proof-of-concept prototype demonstrations). But if you allow changes at later stages it’s hard to charge extra for them.

There is no perfect method. I would only say that if you believe the old ‘cascade’ method is a better one for large fixed price projects you are probably deluding yourself. You may be able more easily to define what’s out of scope, but it will be no easier to obtain the customer’s agreement that he should pay for all the ‘mistakes’ and scope creep, whether they are demonstrably his fault or yours.

 

 

There’s nothing more unreadable than a system specification

System specifications are even more unreadable and useless than business books. I don’t mean because they are boring, which they obviously are, and often poorly written in a language that combines ordinary words with business and technical jargon. Rather, they’re unreadable and useless because they don’t serve their purpose. They fail as descriptions of systems.

The system specification occupies a sacred spot in the evolution of a software implementation project somewhere between requirements analysis and system building.

First, you find out what the customer wants, you write these requirements down and then you get the customer to confirm that you’ve understood the requirements by reading your notes and signing them.

Then you retreat to the turret of your castle and there you specify the system. It’s a kind of alchemy. You take the raw material of what the customer wants and transform it into something (potentially) marvellous using your own special knowledge, experience and skills.

And then what?

Well, at this point the customer is supposed to read (and understand) what you’ve written, and sign his or her acceptance of the design. By doing so he is often also signing away his legal right to ask for changes.

The trouble is that the customer usually has no idea what you really mean by all your alchemical formulae. He’s like someone who can’t read music being presented with the musical score of Stravinsky’s Rite of Spring. He will have no idea what it sounds like.

You have described the system using the language of the software that you know and he doesn’t, showing screenshots from the system that you know and he doesn’t, and the document is so long anyway, and so dry, that he can’t possibly know what he’s really signing up to.

Of course, there are better ways. Customers (end users particularly) should get a chance to play with a system before they sign off on a prototype (together with the document that’s supposed to describe it). There’s then a much better chance that they will know what you mean. Granted there must be some kind of document (more for your own purposes than the customer’s) that documents the design, but what the customer should be exposed to is a kind of prototype, a moving model, that you and he refine over a series of meetings.

This is the ‘agile’ approach to system implementation, a method inspired by the ‘agile development’ method used for software development. Perhaps, using methods like these, there will be fewer occasions when you end up building a monster and hearing the customer say, ‘But that isn’t what I meant at all!’