by , Conferences, No Comments

May 18

Cutter Summit 2006 – Outsourcing and Service Level Agreements

by Chad, Conferences, Comments Off on Cutter Summit 2006 – Outsourcing and Service Level Agreements

May 18

May 18, 2006

It’s been a few days since the Cutter Summit conference in Boston, and one of the sessions is still rolling around in my brain and won’t let go of my frontal lobes. It was Tim Lister’s talk on “Avoiding IT Litigation”. It was a particularly fun session because Tim made it a three-way speaker opportunity by inviting both Ed Yourdon and me to share the stage. I know I’ve already written about the talk, but it still haunts me because there are elements from it that pervade almost all software projects that I know of, even those that are not contracted or outsourced, and I still have a lot to say about it.

It starts with a story by Ed, who is surely one of the master storytellers of our field. For those of you who don’t know Ed, try reading any one of his 25+ books over his illustrious and ongoing career. Ed is one of my heroes and early mentors. (The first time I met Ed, I was a young buck speaking on the topic of software project estimation in the late 1980s. Ed packed the house with 200+ attendees at his speech – a tough act to follow. For my talk, I looked out into the revved-up crowd, and hyperventilated so much that I nearly passed out. But at the Summit, I felt just fine.)

I digress. Back to Ed. He showed the audience a contract at the heart of an IT litigation case for which he’s currently an expert witness. It amounts to a company hiring a large systems integrator (one who we all know, but can’t say who). The contract says: “We will commit to this project which will take 7 months, cost you $1 million, and we will provide you with … something.

Guess what? The “something” is not spelled out! Why? Because neither the client nor the vendor had any meaningful understanding of what that “something” was! Why? Because it hadn’t been invented yet! What was still to be invented was not even drafted on a design “blueprint.” But someone said it would cost $1 million and take 7 months.

Therein lies the problem. Software – even the interfaces to integrate (in this case) a licensed Enterprise Resource Package (ERP) system – is about invention! Tim commented that at early stages of invention, almost everything is foggy and hazy. That’s often an unalterable fact at the beginning of a project. And close to, or near the very end of the build phase is when we really really know exactly what this thing has ultimately become.

And when it finally snaps into focus, no two people in the history of this planet will likely agree that it was what they wanted. And if it takes more than 7 months and $1 million, someone’s gonna be mad. And when people get really mad, they call the lawyers. That’s what happened here.

My take on this: Service Level Agreements for this kind of work are really hard. Simply signing folks up to a cost productivity target and a deadline is bulltinky. The deadline has to be realistic, and it almost never is. Cost productivity is almost irrelevant. And what’s really important – the scope and the demonstrated performance/reliability – are almost never described in any meaningful way. Litigation is just waiting to happen – it’s no wonder the lawyers are rich. They’ve got a guaranteed business pipeline. (I’m having second thoughts about doing mediation – any lawyers out there who might need an expert witness in technology – I’m available for hire. Since more people want to litigate these days, I can change skin since I have kids to put through college.)

But for the non-lawyers and tech experts – what is there to do? For starters, I think we need a two-phased contracting process. One is perhaps a time and materials or cost-plus arrangement the project discovery phase. Some people call this analysis and design.

When those blueprints are fairly well understood (but not perfect), the next phase – when the thing is built – might be contracted with a cost-plus fixed fee, or fixed price contract. Breaking it up into at least two parts is essential to deal with outsourcing something that’s bound to be foggy and hazy at the early invention stages.

For agile development – there’s a variant on this theme, but it will have to wait for the next time when thoughts on service levels and contracts take hold of my frontal lobes.

    Comments are closed.