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 >>