The Community Blog for Business Analysts


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.


Want other software requirements posts?

Like this article:
  3 members liked this article

Related Articles


Only registered users may post comments.

Modern Analyst Blog Latests

As we start a new year many of us will take the time to reflect on our accomplishments from 2012 and plan our goals for 2013. We can set small or large goals. goals that will be accomplished quickly or could take several years. For 2013, I think Business Analysts should look to go beyond our traditional boundaries and set audacious goals. Merriam-...
Recently, I was asked by the IIBA to present a talk at one of their chapter meetings. I am reprinting here my response to that invitation in the hope that it will begin a conversation with fellow EEPs and BAs about an area of great concern to the profession. Hi xx …. Regarding the IIBA talk, there is another issue that I am considering. It's p...
Continuing the ABC series for Business Analysts, Howard Podeswa created the next installment titled "BA ABCs: “C” is for Class Diagram" as an article rather than a blog post. You can find the article here: BA ABCs: “C” is for Class Diagram Here are the previous two posts: BA ABCs: “A” is for Activity Diagram BA ABCs: “B” is for BPMN


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-2024 by Modern Analyst Media LLC