I know you are going to call me crazy, but I just have to let everyone know.  Machines are controlling us.  Don’t say I didn’t warn you.  You don’t believe me?  Okay, I’ll explain.

People come and go in organizations.  Systems tend to stay much longer.  Simple enough right?  Here is the kicker.  When that system was implemented, it was implemented to solve a problem.  But it did not have all the capabilities required to solve all the problems the business had.   So in order to fix the big problem, lots of little problems sprung up.

They weren’t an issue of course because the business had workarounds, usually manual ones.  No biggie right?  Well, maybe.  

Let us say it is five years later and the original people who worked with the system are gone.    The replacements were only trained on how to follow the process and not why the processes should be followed.  There is the start; the machine has people doing its bidding.  

Then a few years later it is decided that some systems should be replaced.  So when all of the requirements analysts come in to do their thing, they document the process as is from the users and SMEs.  This then gets propagated to the new systems.  And thus, the old system lives on through the new system.  The old bugs are now required functionality. 

We must stop them!  When working with old systems and processes don’t just ask what the current state of affairs is.  Be sure to ask why it is done the way it is.  This was happening on one of my previous projects.  The inabilities of the old system were being written into requirements for the new system.  Unnecessary needs for manual selections and processes were being maintained.  

The project was so large and unruly that other requirements analysts would simply write down the current process and confirm it is how things work.  This practice caused very complicated user interactions during the sales process and contract creation.  After the fact, people realized that they should have automated more and asked the user questions about what to do less. 

Because the software being implemented did not come with all this added functionality, it ended up costing the company much more money to reevaluate what was really needed, what could be covered by alternative existing features, and what would just go unimplemented.

By JHEEP

Want other software requirements posts? http://requirements.seilevel.com/blog/