Separating the problem and the solution

In my practice, I encounter the following situation quite often, and you may too: people are discussing a solution and argue about it when the key issue at hand is that the problem that the solution attempts to address is ill-defined or just plain absent. Lots of resources are assigned to work on the solution and technical talk becomes dominant, to the point that business users who are having the problem to solve lose track of what is being discussed. Most of the time, the solution is overly convoluted or too simplistic. All this boils down to a communication problem. We can summarize the situation by saying that the techies have won. It is very important to be able to express business requirements in a language that is understandable by business. The modeling techniques that are mastered by the system analysts must be used to express the problem using a controlled terminology centered around the business. The net result is that there is a quantum leap in the coherence of the message. Good basics is what counts and when authoring requiremnts for/with business users, technology shall always be number two and act as a solid ground upon which business can rest solidly. The added-value shall be clear and a solution that is not achieving that business value with an economy of means is not to be pursued (today, even Google is killing non-ROI-generating products). Today, for most kinds of business, technology is available to fulfill the vast majority of non-functional requirement like scalability and availability, even for free (just look how far OpenSolaris goes in that regard). The effort is thus to be directed towards expresing the problem space in clear terms. All of the above does not means that technology shouldn't be used to explore the problem space. Prototypes are a must have because of IKIWISI (the "I'll Know It When I'll See It effect). Always remember, to the user "the interface is the application". But in reality, the interface is not the full application and that's why in order to explore all sides properly, the only sane way to go is the iterative way. I always try to think in terms of investment and benefit. A good enough benefit with low effort is the best route because by having a sound strategy and composing low-effort/good-benefit tactics, you can almost always overrun a massive effort that will dissipate tons of money in intercommunication and delays. Business and IT do not see the world the same way:
Business IT
  1. big picture
  2. objectives
  3. KPIs
  4. opportunities
  5. ROI
  6. competition
  7. short availability
  8. low attention to detail
  9. customer centric
  10. marketing/sales
  11. policy setting
  12. customers
  13. markets
  1. process details
  2. technology focus
  3. solutions
  4. legacy integration
  5. systems centric
  6. logical
  7. rational
  8. policy implementation
  9. issues, backlogs
But they do need a common ground upon which they can communicate with each other. How to get there ? As the achievement of good communication is quite a culture shift, we must have the following in place:
  1. egos are subordinated to the objective (easier said than done by any measure)
  2. basic shared concepts are in place (problem statement, product positioning, domain model at the entities level, business process model, systems mapping, AS-IS and TO-BE perspectives, workflows identification, key policies)
  3. decision making procedure is in place
  4. accountabilities are established
These elements shall be instilled in the culture by neutral advisors on a very practical basis. An oucne of practice is better than lots of theory and the point is not to lecture people about concepts but to show them how to fish by leading the way first. At the same time, it is very important that the advisors have a strong theoretical framework upon which to back their interventions. This also provides for strong coherence. Devices to track progress. A number of devices is necessary to track progress. In fact, the state of important key items have to be monitored. Amongst these, we can find the opportunity being studied. All efforts in the endeavor have to move the state of this opportunity from vague to paying off. As important things, we can name risk, team, specified system, ... All of these must be tracked and will for a dashboard upon which business and IT can discuss options and actions that do make sense. Value of the approach The value in applying the approach is that resulting performance will be improved and that a streamlined approach will bring visibility, a very missing pieces in a lot of places where obfuscation takes over intelligence. The delivery time will be curtained as well since much less time will be spend in dissipating energy and money. So, start working better by separating he problem and the solution.