Tuesday 7 June 2011

Catch-22 Approach

One of the most common issues I’ve encountered over the years has been the expectation that the user can write functional requirements. The user may know what they want, but don’t know how to translate their requirements into something the IT person can understand.  Consequently, the IT person waits for the user to provide requirements and the user waits for the IT person to determine what is needed.  The user complains that IT does not respond to their needs and IT complains that the users don’t know what they want.

Determining functional requirements needs to be a joint effort involving both IT and the users. Sure, that makes perfect sense, but in my 30 years’ experience with multiple organizations, only a couple of them had approaches that engaged both IT and the user.  Surprisingly, a government organization was one of these.  With a project budget of $2.3 million and two previous failed attempts, I was seconded to the functional department to develop the requirements and strategic direction. Over a 6 month period, I facilitated the review and documentation of every stage of the department’s operation, from front-line workers to upper management.  This approach fostered solid relationships with staff, encouraged management buy-in and provided the necessary insight to succeed.  And it meant that by the time I was ready to begin the design work, I knew who to go to for answers and efficient decision making.

Loaning IT resources to the department worked so well that all projects, in this particular government organization, started to be done this way. The IT staff became experts on how the entire operation functioned, leading to better functional requirements in less time. User involvement was high and systems met expectations. When combined with agile development, we seemed to have the perfect approach.  However, it couldn't last forever, a change in management and the catch-22 approach was re-instated as the standard.

As an employee, I was guilty of occasionally using catch 22 to my advantage when I was too busy or didn’t really want to do a project.  Simply asking the user for functional requirements was a great stall tactic. The user would disappear for weeks or months and in some cases did not come back.  Not good customer service, however perfectly acceptable as the standard catch 22 approach.