Legend has it, that Once upon a time, not so far away in the past, in a not so faraway land, there used to be a Healthcare Corporation.

Everything in the IT department went on in their own pace, until one day the  IT sponsor suddenly felt the urgent need to implement some new software to fulfill his yearly IT spend target. He beckoned the head of operations,  and said, “thou art the expert, so implement for the team a brand new medical authorization solution. And do it fast, i charge thee.“.

The business operations guy, in this case the Subject Matter Expert, on war footing, called upon the IT vendor and said, “tell me, o mighty vendor, can you make for us with mighty haste such a software, by making sure that your development team does not divide the Sunday from the week; working hard so that this sweaty haste Doth make the night joint programmers with the day?” The vendor side account manager, tempted to say “Tush, tush, ’twill not happen“, is pulled down by the prospect of a new SOW (scope of work document, the final signed off contract, in other words, revenue for the company), says ” In that and all things will we show our duty.

Off went the news of an impending chaos that’s about to ensue. Suddenly a team is assembled out of people, with the skill mapping exercise completely undermined. The BA is sent out on a one month long elaboration session, with the client himself barely ready with his top level objectives and KPIs. A loosely made BRD document is fashioned out of the verbal notes taken from the business users and used in the elaboration and before you know, the use case document is ready.

The development team, by now under tremendous pressure of an impending deadline, couldn’t properly unit test the

code in its entirety and has to ship them to the QA cycle, hoping that the code would work, which now at the able hands of the QA team, fails spectacularly.
With daily rising number of defects and increasing apprehension of the client, the general health of the project comes under question.

The project is shipped to UAT, and suddenly all hell breaks loose! Since the user group didn’t know what to expect, suddenly started raising UAT defects of the ‘requirement’ category, warranting loads of code change.

This being a fixed bid project, the thin lines between requirement gap, enhancement request, and ‘but-this-is-only-common-sense-that-it-should-work-like-that’ defects, blur. Lots of efforts go accounted, and thus, unbilled. The software doesn’t come out to be of the highest quality.

The purpose is defeated. 

So much for the problem statement.

What are things, right from inception to the closure, that you think went wrong? What are the checkpoints that should have been established to ensure a quality product?

We explore the answers in our next installment. As always, i seek your feedbacks in all forms in your comments below, and also on my facebook page http://facebook.com/YourITLatte.

Till then, happy learning!

Advertisements