Allegory Child Welfare Clarifications Data Strategy Governance Homelessness Information & Referral Information System Design Interoperability Open Civic Data Performance Measurement Problem Statements Project Management Reviews Social Work Systems Thinking Taxonomies Veterans

REVEALED: The Secret Desire of Information System Stakeholders

A lot of projects to deploy human service information systems end up, sadly, as failures or only half-successes. Why?

Here’s one major reason: stakeholders have a secret desire—actually a secret expectation—that many project managers don’t understand. (In fact, it’s usually so secret that the stakeholders themselves don’t even know they have it.)

A typical scenario:

Imagine there’s a software system being designed to meet some set of specifications. You call a meeting of everyone involved in the project. You ask them a deliberately naïve question: What IS this information system anyway?

After they finish giving you the hairy eyeball, they all reply something like: This system will streamline {list of major business processes} and it has {list of handy dandy features}. In other words, everyone in the room talks about it the same way they’d talk about a Swiss Army knife: It’s a tool that contains a bunch of smaller tools.

That’s a red flag that things are probably going to turn out badly.

Fast forward to the same room a couple of months later. New stakeholders have entered the scene. They’ll need data to do their jobs. They weren’t around when the specs were written. But they’re delighted to hear that the system will collect data on a whole lot of areas they’re interested in: client demographics, history and risk factors, service plans, services provided, outcomes. So they sit down and make a list of the data they want. And then the project manager has to tell them: Sorry, we’ll only be able to give you maybe a bit more than half of what you’re asking for.

The new stakeholders are aghast. You mean the system won’t give us information on {a, b, c}? The developers are called in, and they explain: The {such-and-such interfaces} will capture data on that subject area, but in a different way. See how the specs for {reports x, y, z} were written?  And if the new stakeholders hint that the design is inadequate and perhaps even shortsighted, then the developers too go away frustrated. What, did they expect us to be clairvoyant? They weren’t around to tell us what they needed!

What’s going on? The real problem is a gap between two ways of looking at what the database is supposed to be. The (unspoken) position of one large part of the software development profession is: the database is just the substructure that supports a bunch of tools that we build to do specific things that were stated in requirements.

But the stakeholders have a different (unstated) expectation. They imagine that the database is intended to be an interrogable model of the organization’s work in its environment.

On its face, that idea might seem ridiculous. For how could a database be a model of a whole human service organization? Wouldn’t it have to be as rich and extensive as the organization itself, like Borges’ map which was as large as the Empire it described?

But no, fortunately the stakeholders are more reasonable than that. What they expect—subliminally, of course—is simply that each subject area captured in the database ought to be a rich enough, precise enough, coherent enough model of their organization’s reality so that the data will be able to answer a lot of reasonable permutations of questions about the organization’s work. (And the stakeholders shouldn’t have to articulate every possible permutation to the designers. It’s the designers’ job to make sure that a decent model gets built.)

And in fact, that is a reasonable enough expectation. The proof is in the successful projects (too few, alas!) that do anticipate a lot of their stakeholders’ needs.

There’s a typical scenario with those too:

Stakeholders walk nervously into the meeting with their list of new (or unexpectedly changed) requirements. The project manager and the developers frown, hold their breath… listen… and then exhale, relaxing as they realize that the requirements will not be difficult to meet after all… because the model they built was close enough to reality. Their model has passed yet another test.

But how do they do it? How do some designers build a good interrogable model of the business in its environment—while others only manage to build a Swiss Army knife?

It’s a matter of what they’re looking at and how they’re looking.

Much more about that in future posts.

—Derek Coursen

If you found this post useful, please pass it on! (And subscribe to the blog, if you haven’t already.)

Creative Commons License
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License