When I meet with clients for the first time, they often present me with a project concept and requirements already defined. Measures of success are usually loose or absent, but a firm deadline is common. The client often jumps right to cost, scope, or some other set of variables they believe are of primary importance. Here I hit the brakes, and work with the client to discover the real problem the project is trying to solve. I won’t discuss software at all. No methodologies, no processes, no code, no products. The only thing I’ll discuss is the client’s business objectives, not technical ones.
Clients are often shocked at my apparent lack of concern about the technical details. We will, of course, discuss them when it makes sense. In order to best serve my clients, I need to understand more about them and their business.
Discovering Objectives
Ostensibly, it would appear that the business objective for a specific problem (or set of problems) is to just solve that problem. However, business problems usually don’t specify success metrics that a business is trying to achieve. It’s the metrics that we’ll use to determine whether or not the problem has been solved or mitigated.
How do we uncover the business objective? I always establish understanding of the business problem by asking, “What is the business problem that you are trying to solve?” I tend to keep asking, “Why is that a problem?” (rather annoyingly at times) until I get to the money, cost, efficiency, or the regulatory answer. Once I get an answer that involves any of these dimensions, I have the business problem.
Here are some examples of business problems, restated as objectives:
| Problem |
|---|
| Confidence in current web hosting vendor has declined. |
| Conversion rate on the e-commerce site has declined 20% in the past year. Customer’s can’t easily check out on mobile devices. |
| Customer support is inundated with customer complaints about slow website performance. |
It is critical to understand that objectives are outcomes not inputs. These are not deliverables. I hate that word.
Measuring Success
It’s always interesting to observe with clients that go through this exercise with me how their solution concept changes. While their vision for a solution may not be the same, they are more confident in our joint ability to solve the business problem, now that the objectives are clear.
Now that we’ve discovered the business objective, how do we measure success? We need to describe specific outcomes that meet these objectives.
Here are some example success metrics:
- Potential website downtime is below 24 hours, as evidenced by a disaster recovery test.
- Average conversion rate on the e-commerce site has increased by 10%.
- Customer support incidents relating to website performance have decreased by 25%.
We also use the business objectives together with success metrics in order to control scope. Clients often request “bells and whistles” after a project has begun. Regardless of the “cool” factor, if a feature can’t be linked back to one of the stated business objectives, it’s out of scope.
Assigning Value
How is the client’s condition better after we’ve met the business objectives? In other words, what is the solution worth to the client? It could be a quantitative value in dollars, such as “double net profit”, or it could be something more subjective, such as “increased discretionary time.”
Ultimately, I work with my clients to achieve dramatic results, improve the condition of their business, and make their lives better.