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.


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.



The Necessity of Agility


I’m a nuisance when it comes to system design because I can’t get things right first time. I feel guilty, of course, because asking that things should be done again, or done differently, costs us time and money, and I really ought to be able to get it right at the start, if only I thought about it more carefully.

But, better that I should raise issues now rather than later when it’s too late.


Last Friday I was reviewing the new browser-capable version of invoicing that we’re developing for Version 4.9 of time@work, due out in September (or so). Our invoicing module is complex (I should say ‘sophisticated’ really – it’s the right salesman’s euphemism) since our system is multi-company, and invoicing allows recalculation, discounting, exclusion, addition, rounding and all sorts of other features. Producing a .Net browser version has taken months, but we’re nearly done.

It all began some months ago when I sat down with our systems analyst and looked at the mock-up he’d produced. This followed some hours of discussion over the previous days. The mock-up allowed us to click through the invoicing process, from one dummy screen to another, ‘trying out’ how invoicing might look. Our invoicing process can involve about six different pages, and we’d thought very carefully about what fields should be where, and how to reduce the end-user’s clicks and make the whole process as intuitive as possible..

But, despite that, a mock-up isn’t real, so, to our developers’ dismay, when I looked at the system on Friday, with real data and real programming logic behind the screens, it didn’t seem so easy to use as we’d thought it might be, and it was obvious to me that we’d made a few mistakes.

Years ago, when I worked for Coopers & Lybrand Consulting Services in Budapest I went on a ‘Summit D’ course which was all about systems analysis, specification and development. I was taught the typical ‘cascade’ method. Each phase must be completed before the next phase is begun. Once systems analysis is complete, a requirements document must be produced that the end-users will sign off as correct, then a system specification, and then you build the actual system. Not much room for revision. When the system is complete, it’s take it or leave it, and ‘this is what you signed off on!

But we’re human and our imagination is limited. We need to touch and feel things before we know they are right. So, nowadays, I much prefer the ‘agile’ method of system development or system implementation. You engage in repeated demonstrations and mock-ups and at every stage you allow for revision and successive approximation to what is really needed. The end-user sees what he’s getting long before the system comes out of the laboratory. Of course he’s never HAPPY but he’s less UNHAPPY this way!

True, without careful control this can be an expensive method, but it’s certainly cheaper than delivering a big, expensive, system to users who find it totally unusable.

So, though I feel guilty from time to time at contradicting myself and asking for change, I know that it’s inevitable, and it’s the best way I know. So, forgive me, designers and programmers. And, after all, it’s not as if you don’t occasionally make a few tiny mistakes yourselves.

Here’s a happy user:

agility 2