Software: Describing Problems or Suggesting Solutions

Home / Web to Print / Software: Describing Problems or Suggesting Solutions

Software: Describing Problems or Suggesting Solutions

The purpose of software is to solve business challenges – typically deployed to create a new business process or optimize an existing one. There are two experts on every software deployment project – the software experts and the business process experts.

A software project consists of the melding of these two sets of experts and two “systems” the business process and the software solution.

Listen, listen, listen – and “assume nothing fool.”

The most successful software projects happen when both teams focus 80% of their time listening and 20% talking. With this 80/20 split, the software experts learn about the business process, the business process experts learn about the software. The results – a “mapping” of the business process into the software solution that meets the requirements of this particular customer.

All business processes are not the same, a lot of them appear the same but there are nuances to each one – this is where the “assume nothing fool” comes in. There are also multiple ways of “mapping” business processes into software solutions, some more logical and efficient than others. Your first thought is rarely the most elegant; give yourself a chance to consider more alternatives than the one that pops into your head first. In my experience that is usually the most obvious and typically more complex than it needs to be.

Words of wisdom – both sets of experts, stay on your side of the fence, meaning business process experts – define requirements rather than offer potential solutions. What do I mean by this? Focus on WHY and WHAT vs. HOW – if your suggestion starts with “place a check box on this screen to do this function” you know you have jumped to the HOW before describing the WHY or the WHAT. The better the description, the better chance of a solution that takes into account how the whole system is tied together (product architecture).

Same goes for the software expert, I’ve sat in so many requirements gathering meetings where the business process expert starts throwing around terms that are clearly unique to this company. Specific terminology isn’t the problem, the fact that nobody asks for definitions is a huge problem.

We all have a habit of creating our own languages (for products, for processes, for businesses); defining the terms is critical to understanding. First the two expert teams need to understand each other and probably most important is to then understand what is the language of the end user(s). The last thing you want is to launch a product that utilizes language that is foreign to your intended audience, whether that language is print specific or business specific.

Suggestions:

  1. Everyone: Listen more than you talk
  2. Everyone: Define your terms
  3. Software Expert: the more you understand the business process the better you’ll map it into your software solution.
  4. Printer: focus on fully describing the requirement, resist suggesting HOW the requirement will be solved inside the software.

Leave a Comment