To set the scene, we were hired by the IT manager of a major corporation to conduct a Requirements Gathering Workshop for a project that he felt was impossible. The project sponsor was the Director of Marketing in the company (we’ll call him Mark) and he wanted to roll out a new product that had multi-million-dollar potential – if they could beat the competition to market.
When the Marketing Director requested IT support to add the product to their line, the IT Manager (let’s call him Ivan) recognized that it would require significant changes to the core software systems. Their initial estimate was that it would take at least 9 months to implement the changes. Mark felt they only had a 6-week window to be first to market.
Ivan, in an attempt to show that he was really trying everything to make the project succeed, called us. He requested that we schedule a 3-day Requirements Gathering Workshop that would be attended by Subject Matter Experts (SMEs) from Mark’s group and analysts from Ivan’s. He literally told us that he fully expected the result of the workshop would validate his stand and demonstrate that he was not being obstinate. Obviously, if the workshop delivered any other results, he would be ecstatic.
The Problem Analysis Kick Off
The first morning of the Workshop arrived and Mark had assembled 12 of his best and brightest people from all over the country to attend. Ivan had also invited his best systems analysts and developers to attend. To kick the session off, Mark stood up and addressed the group.
“I have never heard of this thing called a “Requirements Gathering Workshop”, he declared, “and I am not entirely convinced that it will help us achieve our goal. I am willing to give these folks the benefit of the doubt. We’re going to work with them today to see how much progress they make but if I am not satisfied by the end of the day that their approach is going to help us meet our goal, me and all of my people are going to go off on our own to work out a solution starting tomorrow.”
We had conducted many Requirements Gathering Workshops for large organizations in the past but had never started under that kind of “incentive”. We decided that all we could do was follow our approach and see how it worked out. We had experienced many successes before, why change it now?
Creating a DFD with Problems and Symptoms and “Real Problems”
Prior to the workshop, we had requested that everyone attending the workshop bring a list of seven plus-or-minus two problems that they thought this project would solve. We started the day by reviewing all of the submitted problems and creating a problem list. We then spent about 90 minutes applying a technique called “Aristotelian Problem Symptom Reduction” which is a phenomenal technique for identifying so-called problems that were out of scope, others that were really solutions in disguise, and still others that were symptoms of what we call the “Real Problems”.
Having completed that team-building process, we proceeded to involve the group in creating a level 2 Data Flow Diagram of the processes that would be impacted by the introduction of the new product. That consumed about 4 hours.
The meeting room they provided was exceptionally well suited for this purpose as they had walls that we could draw on with dry-erase markers, so the completed DFD spread across 2 walls in the room. The next step was, of course, to ask the participants to locate the problems that they had identified as “Real Problems” on the diagram using the technique we just explained.
There were about 60 problems on the list and when the group was finished posting the number of the problems on all of the potential trouble spots, 45 of the problems were written on and around a single process on the diagram. It was a process that IT knew was convoluted and was one of the primary reasons they had estimated the effort for the project so high.
Visible Problems and Possible Solutions
We completed this exercise before we ran out of time for the day. We had absolutely no idea what was going to happen next. Mark had been involved throughout the day in all phases of the process and had contributed enthusiastically to all exercises. He stood up to address the group.
“I had never seen one of these things called a DFD before today. From now on, I am not going to even approach IT with a request before I have a diagram like this that I have created and analyzed myself. I love the approach. It certainly makes the problems visible and I can see what a challenge this project poses for IT. Nonetheless, we need a solution. However, since these folks have gotten us this far this fast and I am impressed with their approach and their professionalism, I am willing to see how far we can get in the next two days. I do believe that if we are going to find a solution, this DFD and the Problems we posted are the key. So let’s get to work.”
Needless to say, we were immensely relieved and ecstatic with the success. Just to add the icing to the cake, we should also share the ultimate outcome of the workshop. Over the course of the next two days, we worked with the group to identify specific requirements and potential Quick Fixes (short-term, stop-gap solutions that can be implemented safely, quickly, and cheaply while the real project proceeds) to meet their “impossible” deadline. The DFD remained visible on the wall with all of the pain points identified. During breaks, various participants would often wander along the wall and discuss this process or that dataflow.
When All Was Said and Done
Mid-morning of the final day, several of the SMEs started chatting excitedly and asked us a couple of technical questions regarding how they might be able to modify the model. Their idea was to simply create a temporary dataflow that circumvented the core problem process and several other steps, then rejoined the standard flow very late. They explained that could manage that flow manually until an automated solution could be developed. Their idea was adopted. As a result, they were able to not just meet the 6-week deadline but beat it by 2 weeks! We had a new group of converts.
It is important to point out that we did not define their problems, they did. We did not create the DFD, we simply explained the concept and guided them through the process. We did not tell them where the problems were, we let them make these decisions. As facilitators of the workshop, our assignment was to simply teach our techniques to the group and provide guidance in their usage when the group had questions. The results of the techniques convinced the participants of the intrinsic value in this phenomenally revealing approach to understanding and modifying core business processes with minimal risk.
