REVEALED: The Secret Desire of Information System Stakeholders
Posted: 2013/09/17 Filed under: Data Strategy, Information System Design, Project Management, Systems Thinking 4 CommentsA 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.
If you found this post useful, please pass it on! (And subscribe to the blog, if you haven’t already.)
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International License
Human Service Informatics 
Derek, clearly some of this is founded on software development circa 1990s. I think everyone assumes today agile development and web and mobile. Also the data model should reflect the business processes and be extensible easily, so you can add tables to cover new needs, and then engineer new forms and web services to deliver those very quickly, e.g. few hours, not weeks and months.
Reporting has always been the Achilles Heel, but again reporting tools now let the end users do a lot of the slicing and dicing themselves. Hope I’m not stealing too much from follow on articles?!
And of course check out what we are doing with Open-XDX and XML and JSON that allows you to deliver these kinds of rapid SOA plug and play style functionalities – see the VerifyXML web site for more details.
David,
For years I’ve been hearing that “the data model should reflect the business processes” but I still have no idea what that’s supposed to mean. If the idea is simply that the data model must contain all the data necessary to support the business processes… well yes, of course. But I suspect that most people really mean something like “the data model should be directly inferred from the business processes.” I’ve certainly encountered the work of many database designers who do exactly that. Whether it qualifies as data modeling is another question. I think not.
Because as you say, the data model “should be extensible easily.” Focusing too directly and literally on business processes is one of the main causes of inflexible database designs—and therefore project failure. Empirical research (one paper by Shanks and another by Batra and Davis) has found that one of the hallmarks of experienced modelers is that they introduce useful new concepts that do not directly originate in the requirements; by doing so, they create models that are more flexible, more easily comprehensible to stakeholders, and of higher overall quality. They do this by spending more time holistically understanding problems; categorizing problems into standard abstractions; and drawing on their previous experience of similar situations. In short, they are not spending all their time looking directly at the requirements.
As for how this relates to agile development… I actually admire and support many parts of the agile methodologies, but in practical experience I have found that there’s a tendency to give good data modeling short shrift. I’ve even run into extreme advocates who deny the need for formal data modeling at all. More than once I’ve witnessed agile designers (who referred to the database as a “persistence engine”) having to very laboriously “refactor” a structure that any good data modeler would have rejected without even needing to lay eyes on the requirements! No reason that agile has to be that way, of course. It’s a matter of equilibrium—balancing the use of different tools and techniques, knowing where each one is most needed.
Best,
Derek
Derek,
Based on the discussion above, I think it might be worthwhile to devote a post to this idea of a tension between agile requirements-driven development and up-front data modeling with modelers taking the lead through holistically understanding the environment. What is the best way to achieve the desired flexibility?
I think this also relates to the fact that typically customers do not come in saying “We want to build a system to run our entire operation.” Instead, they say “We want to build a system to do ‘A’ and ‘B’.” I know that eventually they are going to want “C” , “D” and “E” and I tend to want to model accordingly. (“Are you absolutely sure that you don’t need to track changes in that area over time?”) But sometimes they say “No, that would add undesired complexity (and expense and time) to the completion of ‘A’ and ‘B’.”
And in general, reduction of complexity is a good thing. That concern should be considered as a counterpoint to modeling toward flexibility and anticipating every need. Check out this article on the subject.
Brian,
This is an excellent article, thanks for sharing it! I suspect I’ll need to read it a bunch of times at intervals before many of its implications can surface. One question I see it pointing to: How to define/perceive optimal level of simplicity/complexity for different kinds of artifacts? His example of a toggle array getting exponentially more complex is easy to grasp. Things get murkier when we look for the optimal level of simplicity/complexity to represent aspects of a human service setting as a set of definitions, a set of taxonomies, or regions of a domain model. (Part of the argument I’m trying to explore/develop is that for the purposes of improving information management in the human service sector, there may actually be levels of simplicity/complexity that could be shown to be optimal in the sense of being able to satisfy the broadest possible set of reasonable but not yet articulated user needs.)
Derek