Needs vs. Wants PDF Print E-mail
Written by Gerald Neal   
Tuesday, 18 May 2010 14:15

Needs v WantsA long time ago, in a distant galaxy, I was a young team leader on a project that was to generate standard customer letters using a complex combination of document fragments. The client needed the letters “immediately” but fortunately there was some flexibility as we were simply automating an existing manual system.

While simple documents might have a field or two with customised information (e.g. a mail-merge with name and address fields inserted), these compound documents used standard paragraphs that were included (or not) dependent upon variables. At the time, I was engaged by a government agency to produce the code for generating these compound documents, and, as part of a team of eight, we were to produce 245 “standard letters.”  Each letter needed a single COBOL program that generated the letter based upon variables, then printed the letter on letterhead for the first page, then plain paper for the rest of the document at the printer physically closest to the requester.  This was pretty advanced stuff for the mainframe back in 1988! 

Knowing that there would eventually be 245 separate COBOL programs I decided it would be wise to design the programs with maintenance in mind.  To that end a skeleton program would be created to cater for those aspects that applied to all of the letters.  Given the pressure to produce at least some of the letters quickly I set part of the team to work on getting some of the letters out and the rest of the team to designing and building the skeleton program. 

Soon enough we had a dozen letter programs up and running before the ultimate skeleton was produced and we retrofitted the dozen programs into the skeleton.  Then we hit high gear and started to pump out the programs, but wait, one of the developers had a really good coding solution that simplified the skeleton program and would make maintenance significantly easier.  Only trouble was we would now have to retrofit about 25 programs, which would put us behind schedule.  

I explained the situation to my 1up manager who was in agreement that we should retrofit. My 1up explained it to my 2up who also agreed, who then explained it to the Head of IT (due to this being a high profile project) who said no due to the pressure for delivery from the business side.

I pondered this outcome.  I knew that maintenance of the 245 programs without the good coding solution was going to take longer and therefore be more expensive.  I reasoned that there would be constant minor changes to the programs due to legislative changes, policy changes and changing options and products.  I estimated that it would take about 8 days to retrofit (change, compile, test and put into production) the 25 letters that we had already done, but once done we would be able to produce a new letter much faster, up to 4 letters per week.  I therefore reasoned that we would be back on track at about the 45th letter and would be able to build further efficiency by honing our production process.    

One part of me felt I should build a stronger business case and present this up the line again, hoping for approval from the Head of IT.  But the other part of me didn’t believe that would ever happen, regardless of how strong my business case was.  Going directly to the Business client was not an option as the IT/Business relationship at that time was poisonous.

I evaluated the remaining options:

  1. Comply with the directive as given, incorporate the new code in the new letters but don’t retrofit the old letters thereby leaving a mess for someone else to clean up in the future
  2. Assign one member of the team to retrofit the old letters with the new code and have the remainder of the team push on with the new skeleton
  3. Have the whole team retrofit the old letters then go full speed into the new letters with the new skeleton 

Other options like taking the Head of IT out for a drink or a quiet chat did not occur to me at that time and to be realistic would not have happened back then anyway (the Head of IT introduced himself as “GOD” to my team only semi-jokingly when we first started). Or arranging with my 1st and 2nd up managers to cover for me for a couple of weeks, was not in my nature.  If I was going to make the decision then I was going to have to wear the consequence – alone. 

So what did I do? More interestingly, what would YOU do? I'll tell you the rest of my story in Part 2 of my scenario in an upcoming issue .... stay tuned.


Gerald Neal
About the author:

Gerald is an experienced Project Manager and Senior Business Analyst who works in the Financial Services industry. He has worked across the development lifecycle and been part of a number of enterprise-wide process improvement initiatives. Gerald has a passion for best practices and governance having been active in several industry groups including PMI, SPIN, QESP, IIBA and ISACA.

Read More >>
Comments (0)Add Comment

Write comment

security code
Write the displayed characters


busy
Last Updated on Monday, 05 July 2010 11:37
 

User Login