Good enough would be great

By Joe Shepley posted 02-10-2011 01:21


In the last post I talked about the importance of taking the time to clearly identify your target users when rolling out E2.0 capabilities. I also presented a high-level walkthrough of an effective exercise for not only figuring out who your users are, but also for determining what business activities are most important to them and the capabilities (technology and otherwise) needed to support them.

But as far as that exercise gets you, it’s not the end point for E2.0 implementation planning, because if you hand this list of capabilities to IT, more often than not they’ll come back with a system that has every conceivable option available to deliver the capabilities you’ve listed: after all, this is what you’ve asked for, right?

Yet what would really suffice for most organizations to address user needs is a good enough technology solution. As the old saying goes, don’t let perfect be the enemy of good enough.

With that having been said, let’s take a look at an exercise that’ll help you strike the right balance between good enough and perfect in order to meet your user’s needs more effectively.

Everything in no particular order

When IT over-engineers a solution, what’s usually to blame is the lack of clear priorities to guide the intelligent management of the trade-offs required to design a cost-effective system that still meets user needs. What’s needed to correct this is a ranking exercise to give you some idea of the relative importance of the capabilities you’ve identified.

There’s lots of ways to take a set of capabilities and rank them, especially when you can trace them back to business activities and the users who own them. Consider the following criteria:

  1. User group status of the activity owners
  2. Positive financial or risk impact of providing a capability
  3. Negative financial or risk impact of not providing a capability
  4. Probability of success delivering a capability
  5. User footprint affected

Each one of these criteria will generate a different prioritization of your capabilities, as will different combinations of them. So how do you choose which to use?

Get it all out there

If there’s an obvious choice (e.g., CEO has dictated that all projects must show a positive ROI), then the choice is simple. But if there isn’t (and even if there is), it’s quite valuable to create a matrix to score the capabilities against all each criterion.

The following figure is an example of what this kind of matrix might look like.

Figure 1 – Capability Matrix (Sorted by Capability)

As you can see in this figure, having a single place that details how each capability ranks according to each criterion is a handy thing to have.

Start digging in

But beyond that, you can sort in Excel by criterion to begin to get a feel for how prioritizations based on different assumptions might look. The next two figures show how these capabilities might shake out differently depending on the criterion you decide to use for ranking.

Figure 2 – Capability Matrix (Sorted by Criterion 1)

Figure 3 – Capability Matrix (Sorted by Criterion 3)

Some things that jump out:

  • Capabilities B and H rank at the top in Figure 2 and near the bottom in Figure 3
  • Capability F ranks near the top in both
  • Criterion 1 gets you three “1s”; criterion 3 gets you two “1s”

Interesting stuff, but to make it fully meaningful, you need to sort by each criterion and do a similar comparison of high and low ranking capabilities as well as the number of “1s”, “2s”, and “3s” you get with each.

Getting fancy

In most cases, however, you’ll want more nuance in your prioritization, which will require you to sort by more than one criterion. The next two figures illustrate possibilities for doing so with our example capabilities.

Figure 4 – Capability Matrix (Sorted by Criteria 2 and 4)

Figure 5 – Capability Matrix (Sorted by Criteria 4 and 5)

Some things that jump out when you look at all “1s” across both criteria in each figure:

  • Criteria 2 and 4 get you eight “1s” (Capabilities A, B, C, D, F, G, H, and I)
  • Criteria 4 and 5 get you five “1s” (Capabilities A, B, D, G, and I)
  • Capabilities F and H score high in Figure 4, low in Figure 5
  • Using criteria 2 and 4 delivers every capability delivered by criteria 4 and 5 and then some

Again, this is interesting, but needs to be part of a full analysis of the matrix to be really meaningful. You’ll need to sort by all possible combinations of criteria and do a similar comparison of high and low ranking capabilities as well as the number of “1s”, “2s”, and “3s” you get with each.

The final word

By this point, you’ll have generated some great data points and analysis to ground an intelligent, informed conversation with IT and end users about what kind of system should be built to respond to user needs.

If you decide to give them everything, you’ll have some ammunition to justify the Cadillac approach. And if you need to trim down what you can deliver (the more likely situation) you can give end users solid reasons why they didn’t get every single one of their needs met.

I’ve found these techniques of great value as a consultant and in a previous life working on the other side of the table trying to get things done inside of IT departments. Hopefully you can take some or all of them and apply them in your day-to-day work.

And if you all have other ways to tackle this same problem (or anything else to add), by all means jump in and get the conversation started—always love to hear from you all out there!