Similar to my last post, I wanted to continue down the Requirements path – to discuss a situation I ran into several years ago. This was a situation where the Application Owner and Information Technology (IT) were both correct, but someone had to wrong.
At the time, I was a Developer/Business Analyst combo (times were tough back then) and the Subject Matter Expert (SME) had worked with the Application Owner for over 10 years at the time. They worked together on a daily basis and both had a very strong background on the business needs the application was designed to fulfill.
The enhancement life cycle (if we can call it that) was that the SME spent time with the Application Owner in order to understand what features he wanted to see. She would provide feedback on the impact to the end-users, since she maintained a strong relationship with the user-base. Once they were ready, they would bring the enhancement request to IT. After I reviewed the request with the SME, I looped my supervisor in on the changes and then started documenting the requirements. Once they were complete, the SME reviewed/approved the requirements and development started.
Throughout the development process, I would have the SME check what had been put into place at that point. This was before Agile Software Development had gained momentum, so it was more of an iterative approach. As the feature reached completion, the SME and I were both impressed and excited about our solution.
We deployed the changes into the Test environment and setup a meeting to demo the enhancements to the Application Owner. My supervisor decided to join us. We all expected to enjoy a round of “high 5’s” after the demo was complete. In our view, this was merely a formality before deploying the fixes to the Production environment.
The Application Owner sat through the demo and didn’t really say much. I didn’t put too much stock in his reaction at the time, since the guy always had a million things on his mind. When we finished, he looked at us and announced, “this is not at all what I expected to see.” I know my mouth hit the floor, as did the SME’s. My supervisor’s face turned a shade of red, which matched the reddish tint in his hair.
We walked through his expectations during that same meeting. He was right, what he expected to see was not what we had built. Fortunately, a great deal of the underlying components and design were not impacted and the time to fix the application was measured in hours and not days or weeks.
In the end, when you look at what was developed initially and what was ultimately deployed into the Production environment, both solutions achieved the needs noted in the requirements documentation. Of course, both could not be right, so one of them had to be wrong. Since the Application Owner was the customer and I (as an IT employee) was the IT solution provider, I had to be wrong. I was okay with that.
I have struggled trying to figure out how to prevent this scenario from happening. Mind you, this is not a common scenario, but one that has happened enough over the years. I would have never expected the SME to be that far off from the Application Owner’s vision. After all, they had worked together for 10+ years and both had a great understanding of the problem they wanted to solve.
I wondered if more screen shots or even a wire-frame might have helped. But at the same time, I would not have expected the Application Owner to get involved at that level – remember, the guy always has a million things on his mind. I am certain the extra documentation would have been overkill at the time – since the SME and I were on the same page.
In the end, I think this is one of those situations where the problem has to occur once. Then, when additional features are requested down the road, it will be easy to ask that the Application Owner be looped into the process periodically. Making this suggestion prior to running into this scenario could impact the relationship with the SME, which I don’t believe is worth the risk.