The Community Blog for Business Analysts

Seilevel
Seilevel

Learned Processes

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/

Like this article:
  0 members liked this article

Related Articles

COMMENTS

Only registered users may post comments.


Blog Information

» What is the Community Blog and what are the Benefits of Contributing?

» Review our Blog Posting Guidelines.

» I am looking for the original Modern Analyst blog posts.



Copyright 2006-2019 by Modern Analyst Media LLC