Requirements Complexity

Back in December 2010, one of my stakeholders approached me with a feature request from our user community. As we talked through the request, we both realized that the system in question came close to meeting the request in several different ways, but did not fully meet the requirements with any of the different methods we tried. After an hour or so of brainstorming, we realized that being oh so close is still very far away. This was the beginning of what has become a four month escapade to finalize requirements for what appears to be the most simple of concepts.

Actually, the concept is very simple; its just easy to confuse, too. I remember thinking that it wouldn’t be very difficult to make a few system tweaks to one of the existing methods and we’ll reach the goal within a couple weeks. It just didn’t turn out that way in reality.

As a larger group of stakeholders began to assemble to address what needed to be done, a large set of competing options landed on the table. Some were significant in terms of system development, some were easier, but had very nasty reporting impacts. Another was simple development and had few reporting impacts, yet was essentially just hard-coding a band-aid over the system and praying nothing fell apart.

All of these solutions would meet the requirements, with different levels of risk and impact to other teams in our organization. The end question came down to, was it worth it to take the pain of a longer development time now (not to mention the business not seeing a return on its investment till much later) than to risk the whole system? Surprisingly, the answer came back as neither. We presented a list of options that didn’t require code changes, but did not completely meet the business requirements, and suggested that the business area go with an imperfect, yet quick return. There were clearly defined caveats to this approach, but our stakeholders signed off and we were good to go.

Or so we thought.

A few days after sign-off was complete, several of my stakeholders came storming down the hallway in a near panic. What do you mean that the no code solution isn’t perfect? Why didn’t you tell us?

Well, we did tell you. You signed off on it, right below the big disclaimer stating that it wouldn’t, 100% meet your requirements. In fact, during the sign-off meeting, we even read that section to you.

Oops.

In our business area’s defense, despite our spelling it out multiple times, we probably didn’t do a great job of communicating the business impacts of our proposal. Yes, we covered it, but likely put them to sleep with a bit more technical jargon than we would normally use, all for the sake of being thorough. We compromised the clarity of the message with extraneous detail, lulling our stakeholders into a false sense of security. Not that this in any way absolves them of having not read and comprehended, just that we were all culpable in this situation.

With that, we went back to the drawing board, working through all the scenarios yet another time. And another time. Eventually, my team and another team in the building put forth two different, yet complimentary solutions. The problem was, while they came to what was essentially the same outcome for both systems, integrating the two to talk to one another would be a nightmare for both teams.

By this time, over two months into the process of eliciting requirements for a project that literally takes six words to explain to anyone in the business, I had become pretty good about explaining the problem and what would eventually become the solution that the stakeholders selected. It was at this point that the contention between the developers and the analyst started. No fist fights or even strong language was used, just a passion for over-complication.

Developers live in a world of complexity and edge cases. After a decade in this business, I get that. We need developers as they force (in a nice way) us to think through the details as to how our requirements impact their solution. I ended up realizing that all these complicated scenarios I kept being hit with all came down to three rules, all of which were exclusive to one another. This epiphany was interesting when I started to explain it to others because, at first, no one wanted to believe it was just three rules. Even the lead BA for the other team didn’t want to believe it at first.

So I did what I probably should have done before, I sat down with all the teams and, through many hours, explained my three rules. People would say, “Yeah, but what about if we…” to which I would respond by naming a rule. At one point I think one person even started trying to make up crazy scenarios just to find a way to break my rules. They failed in this pursuit, not because I’m necessarily so smart, but because clear, simple requirements win.

Looking back on the situation, there are a few obvious things I did (and did not) do that would have made all the difference in the world to shortening what has now become a four month process to create requirements and design for an enhancement that, again, can be summed in six words. Here’s the list:

First, make it simple. The second requirements document that received sign-off, the one we are now implementing, has four lines of business requirements. Those are the six word description and the three mutually-exclusive rules. That’s it. There is zero ambiguity in what these mean. They are phrased in the business’ terms; language my stakeholders understand. Its not in BA or developer-speak. Its simple, its focused and it is precise. In short, its all the things that I should have done the first time but, because I was focused incorrectly on a solution, one which did not totally solve the problem but, I thought, would cause me less work. I couldn’t have been more wrong.

Second, never assume that by not meeting select requirements you make less work for yourself. You’re probably fooling yourself. It may look in the short term like you have less to do, but your stakeholders will come back at you (rightfully so) time and again until you either completely meet their needs or they give up on you ever meeting your needs and go around you.

Third, simplicity for some is complexity for others. When the two development teams created competing and contradictory solutions, we all lost. In this case, we lost at least two to three weeks of time trying to haggle out a solution that would work well for both teams. Both groups were rightly protective of the integrity of their systems, but we failed to realize that our simplicity was nothing more than complexity for everyone else.

Lastly, never forget the power that comes from crafting a simple solution. Once both development teams understood, and more importantly believed in, the rules as I laid them out, we began to realize that while the development effort would by no means be minor, it was by no means the hair-ball of code everyone first thought it would be. Yes, for one of the two teams, it meant a significant departure from the way they usually develop and would mean a substantial increase in the processing needed to complete their algorithms, but they’re smart people; they know how to do hard work.