Have you ever played the old party game where you whisper a statement to the person next to you and they pass it down the line? Most of the time, the last person to hear the statement is told something entirely different. Our communication regarding business processes too often ends with the same result.

I recently saw a survey that cited why a significant number of software projects fail, or are deemed “challenged.” Two of the top reasons given for these failures were lack of user involvement and poorly defined requirements. When developing new processes and implementing new applications systems, it is vital to get the necessary information from those who do the work—and this doesn’t mean just one or two people. A cross section of those who are actually conducting the business processes should be involved in the fact-gathering. From my experience conducting redesign workshops, I have found there are always cases of someone defining a work process, and someone else saying, “That’s not the way I was trained,” or “I have a better way to do that.”

Think about what would happen if only one of those two people was the primary source for gathering process steps during the requirements definition phase of a process change. The process depiction would not reflect the true current state, and the resulting requirements would most likely be poorly defined, incomplete or sub-optimized.

Another important reason for seeking as much involvement as possible is to make sure that all of the steps of a process are necessary and, ultimately, add value. The same survey found that in failed projects, many of the requested features were never used. This is often a direct result of not thoroughly questioning the value of each step in the process before defining what is required.  How many times has this phenomenon led to costly, complicated and unnecessary modifications to packaged systems?

Getting as many people as possible involved in defining processes can sometimes be messy. It’s easy to just take a short cut. But doing this right will ensure consistency, identify unnecessary activity, improve output quality, boost training efforts and, in the end, improve the defined requirements and supporting technology for the new process design.

This article can also be found at InsuranceNetworking.com.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access