This is an old link ... let me redirect you ...

(... or click here if the page does not automatically redirect)

News for Wombats: Taming Unreasonable Requirements

I've heard from a couple of friends about some "classic" project requests - dilemmas they have recently faced. These unreasonable requests can be turned into something achievable and, potentially, more relevant / meaningful to the requestor, by approaching the problem from a different direction.

Request for Data: the Analytics Project

Classic scenario #1 arrives courtesy of the external Experts, analytic genii (sic) promising to reveal secrets of profitability and sources of revenue buried deep within our data sets. Their "simple request" is to pull all data from the system - customers and orders, vendors and payments, items and inventories - all classified by OBC; the Obvious and Brilliant Categories that, when summarized and sorted, will unlock our Big Opportunities.

Pulling data from the system is easy, but the desired attributes often do not exist in the system - or, they exist, but we have not (to date) filled in those details on our orders / payments / inventories. So, IT is asked to coordinate the bursting of data into separate spreadsheets, and distributing data sets to various areas of the business, to the people who know how to categorize the uncategorized.

Note the hidden work the consultants have pushed down. IT must frame the question to the business (can you categorize this data?), but they are often left with the task of explaining the original project and justifying this interruption. Remember, when the programmers came in this morning, this Data Collection project was not on their radar screen. Of course, this is perceived as IT resisting, being uncooperative ...

Sound familiar? It should, I've seen it at many companies, many functional areas of the business. There are some Obvious Truths that jump out when you think about this for a bit ...

Aha - that last one gives us a hint on how to slash the amount of work required to get actionable data in a reasonable amount of time. Haven't the external Experts seen data sets like this a million times? They are, after all, selling their experience in the problem space - why not engage in some targeted research? Based on experience, for companies of our type and size, what do you expect the answer to be? 

What cross selling opportunities are the most common?
What aggregate buying typically get the most bang for the buck?
Which product families are typically the slow movers?

Jump start the data categorization by guessing the Pareto sort, and target that data for characterization ...

Battling What "They" Say

A similar problem is often faced when proposing system and process change. A classic refuge of the change resistant is to stand behind an Unassailable Truism with a potential for problems ...

Not all of Our Vendors are ready for EDI ...
A great idea - but how will this impact The Customer?
You can't apply these changes to All Products ...

Well, yes, but this isn't helping us get to the benefits represented by this Cool New Thing; you are just defining Problems, not Solutions.

Still, this one can be fairly easy to defeat, by getting a bit more specific. Which vendors / customers / products are we talking about? Usually, there are just a few key instances where critical relationships (vendor or customer) must be maintained, or important product attributes will guide decisions / changes. Target these specifics, and don't try to develop solutions / rule sets that will work in all imaginable cases (diminishing returns, again).

News for Wombats

The phrase comes from an old Monty Python show, where a series of terribly redundant news programs, specific to parrots, gibbons, and wombats, pointed out that in all cases, "no parrots / gibbons / wombats were involved". ( Hey - it's funny in context. Not everybody appreciates Fibber McGee, either ). The point is - when time is of the essence, and you are looking to balance a complete design with relevant action, it helps to focus on the specifics.