Business Objectives for Software Projects

All Articles Culture Data Management Level 12 News Python Software Development Testing

In our previous blog post, we identified the three critical requirements or “specifications” needed by developers to design software that works—software that saves you time and money and helps you delight your customer. Here they are again:

  1. Business Requirements
  2. User Requirements
  3. Functional Requirements

Now, let’s look closer at the trickiest of the three: Business Requirements.

Common Sense and Common Practice Walk into a Bar…

Common Sense says, “Where are you going?”

Common Practice quips, “Well I don’t know, but we’re making great time!”

Sometimes we get in a hurry, make assumptions, mistake opinions as fact, and end up solving the wrong problem or causing even more problems.

To avoid this, here are three questions that will help you make a quality decision and truly understand if the project makes sense for your business. It will require that you slow down a bit and give them careful thought. And yes, these might seem like common sense, but we all know common sense and common practice don’t always cooperate with one another.

Question 1: What exactly is the business problem? No, really…what is it?

Question 2: How will a software solution solve it, if at all?

Question 3: Is there a positive ROI?

Let’s explore these in more detail:

#1: The Case of Decreased Production

Acme Widgets, Inc. is experiencing a decrease in production output on the 3rd shift. The plant manager calls a meeting with the shift supervisor and foreman to address the problem. After looking over some reports, and a couple of rounds of frustrated finger-pointing, they decide the decrease in output is due to slow delivery times by one of their suppliers.

They call the supplier and vent their anger.

An employee on the shop floor, who is friends with the supplier’s representative, hears of the heated meeting through the grapevine. She whispers to her friend that what is happening is much simpler.

Because the current software is slow, clunky and requires repetitive entry of the same information, shift workers cut corners to avoid using the system as it was intended, and sometimes don’t use it at all. Missing data causes bad information to be introduced into the process, which causes errors in reporting, and a production problem downstream.

#2: Beware the Hammer That Thinks Everything is a Nail

How will the leaders discover the truth and fix the problem? Will the line worker tell anyone what she knows? How and where does a software solution fit in, if at all?

Ideally, there is a culture of continuous improvement at Acme and employees are incented to share this information and improve the value creation process.

Regardless of culture, uncovering the root cause of the problem, creating a solution and, if needed, designing new or improving existing software requires:

  • Quality communication
  • An understanding of process modeling
  • Separating fact from opinion

In the case of decreased production at Acme, a closer look might reveal multiple causes and solutions for solving the problem:

  • It might be possible that the employees were not trained properly, and a simple training solution will do.
  • Perhaps employees are simply disgruntled with management, and even a perfect process and software to enable it wouldn’t change the outcome.
  • Error proofing enhancements and user interface improvements could be made in the software to reduce waste (entering the same data multiple times, excessive searching and clicking, etc.).
  • The data that drives the system could be disorganized and unreliable, causing users to resort to manual alternatives or not using the system at all. This is what is often called the “invisible factory.”

Yes, software if a very powerful enabler of business processes. It’s critical, however, that software doesn’t become the hammer that thinks everything is a nail.

#3: Is the Juice Worth the Squeeze?

Now that you’ve looked at your business problem more holistically and can make a more fact-based decision, will the project be worth it?

Here are 10 factors to consider:

  1. Cost Reduction
  2. Time Savings
  3. Revenue Generation
  4. Less Rework via Product and Process Defect Elimination
  5. Eliminated Safety Risks
  6. Customer Satisfaction Metrics
  7. Faster Go To Market Times
  8. Increased Production
  9. Reduced Employee Turnover
  10. Reduced Inventory

Any one of these can be enough to make the investment.

Want to share ideas, thoughts, or questions? Give us a call at 502.495.3936. We’d enjoy your input.

Read the next blog post in the Software Project Requirements series: Getting user Input.

Originally published on 2018-01-31 by Dale Gibbons

Reach out to us to discuss your complex deployment needs (or to chat about Star Trek)