The business can't abdicate its project responsibility

A couple of years ago I was parachuted into a government project to review its requirements. The customer...

A couple of years ago I was parachuted into a government project to review its requirements. The customer was getting fed up, having waited two years for the supplier to deliver more than promises.

I went to do a gap analysis. The idea was to find out if the business requirements would be met by the code being developed. Unfortunately, the business requirements had been "misplaced".

Day one

On day one there was a lot of talk about the requirements being contained in a complete series of Case-wise models on a site in another town. I printed out one of the models it took up 12 A4 pages. I painstakingly cut the pages so they could be taped together. I then pored over the diagram late into the evening, and thought I sort of understood the runes.

In the morning we went down to the business site and passed a very amiable 20 minutes with the Case-wise manager. As the meeting was coming to an end, I got the big diagram out and unfolded it on his desk and said, "OK, before we go, I was hoping you would just walk me through this diagram so I can assure myself I understand it."

He looked at it. Silence.

I said, "Do you understand this diagram?" He said, "No". I said, "Who does?" He said, "Well, the business expert understands the process, and he sat with the Case-wise operator and they made this diagram together."

So the modeller understood the Case-wise notation but not the process, and the domain expert understood the process but not the model. Great. The Case-wise models were useless. Not a great start.

Any day now!

As my time on that project continued I learned a lot of things. Dates came and went without any release. Once a date had passed, it wasn't mentioned again. On the outside, the project team resolutely chose to look on the bright side: the code release remained only days away!

I asked to see what had been done. I asked to see anything at all. My e-mails weren't returned. When I went to find the design manager, he was in a meeting, which lasted eight weeks. I came to recognise this phenomenon as the tyranny of optimism.

The tyranny of optimism is fed by a tyranny of experts, with overpaid consultants marching around hardwood floors in polished shoes producing no visible work and blaming the lack of progress on the incomprehension of mere mortals. When the coders view themselves as a band of heroes who are the only ones standing between civilisation and the abyss, the project is surely doomed.

Processes not interrogated

I didn't know it at the time but by the time I got there it was already too late. The requirements, such as they were, recorded the existing business process without anyone ever bothering to ask why they did it that way. The existing process had grown up over time, was full of manual workarounds to accommodate flaky automation, and they were preparing to reintroduce the workarounds in the new system.

I worked day and night to rewrite the requirements together with a talented fellow from the business. We shared the results of our work. It went down like a lead balloon.

A project's senior responsible owner (SRO) needs to have the confidence to say, "You may understand this, but I don't. Do it again."

The customer must own their business requirements and they must understand the delivery process enough to know when they are being strung along. They need enough courage and authority to say, "You promised me it on Monday, now it's Wednesday. What's going on?" They need to know how to tell the difference between a reason, an excuse and a diversion it's known as a personal locus of evaluation.

Inescapable duty

The SRO needs to have seen good artifacts to know when they are being presented with poor ones. Sorry, Gordon, but it isn't possible for the supplier to perform the duties of the customer. It takes two to tango, no matter how hard one pretends. The dance requires both parties learn the steps.

Sure, this particular project was well managed all the project management artifacts were produced, filed and forgotten. When the auditors came in, they found nothing amiss. But the project didn't deliver anything. Where there is no connection between the project's management and the underlying software engineering methodology, it's not a dance, it's a scrum that has misplaced the ball.

Peter Merrick holds a PhD from UEA in software engineering

A good example of unambiguous requirements representation in the context of a lightweight project delivery framework is available here >>


Power politics and IT projects >>

Optimum value from IT investments >>

Read more on IT project management