How to Deal with Conflicting Processes When You're Writing Software Requirements

As requirements experts, we are asked to gather requirements, using a variety of methods, from many sources. We are then expected to compile a comprehensive list from these sources.

On a recent project, I was asked to go into a customer’s manufacturing facility and observe the manufacturing technicians going through their daily activities to collect requirements for automating some of their activities. At the end of the observations, I was to present the customer with a documented process flow so that the development team could create the automation.

What do you do when every single one is different?

For several days, I was the guy following people around, making them nervous and asking a lot of "What did you just do" and "Why did you just do that" type of questions. Once all of the data was gathered and compiled, I found that of the four work shifts I had observed, each had its own way of doing some of the tasks. I needed to present the customer with one unified process.

Once the differences were identified, I needed to find a way of standardizing the process flows. These are the steps I took to combine the 4 into 1.

1) Does The Difference Really Matter?
The first thing was to determine if the difference between processes really mattered. Many of the steps were the same but executed in a different order. I spoke to the technicians that I had observed to ask why they did it one way and not the other. I also asked them what the impact would be if the steps were rearranged.

2)Move Low Impact Steps Around
For the steps that really did not matter, I made the decision on where to place them based on the feedback I had received. I created a process flow and asked the technicians to approve the “To Be” state. Once I had received their approval, I began to address the steps that remained.

3) Go With What You Have - And Get Feedback.
For the remaining steps I had to use a different process. First, I documented the difference as well as the technician’s reasons for the actions. Next, I presented the information to the management team and asked them to tell me how they wanted these activities to be completed.

When you're faced with multiple processes from every user, take a moment and break the information down to the steps that really matter. Once you've separated the wheat from the chaff you'll have a good idea of what to get approved and what to toss.