Mending Wall: Matches and mismatches in IT stakeholder expectations

Case in point: I was shown an astounding list of generic stakeholder expectations a while back, drawn up by an obviously frustrated group and titled “USER REQUIREMENTS FOR IT”.  The list is most interesting in what the items reveal between the lines. Let’s examine what probably caused this group to write down these specific but very abstract needs.

To most IT professionals, these come off as “unreasonable” demands at first examination. But they’re both understandable and revealing, if you take the stakeholder point of view, and if you remember the oft-cited adage that all progress depends on the unreasonable man.

It turns out that their list is almost certainly a history of (and response to) the various roadblocks they’ve been presented (by IT) over the years. (“Roadblock” being their view of matters, mind you).

Specifically, it’s likely that IT has tended to tell them something pretty close to the following at various key junctures on projects:

• “This is the way we do it”; it doesn’t matter that the business situation would necessitate a different approach
• Our SDLC dictates that we have to do it this way
• Our work is going to be serial; first we need to do this, then we’ll get around to doing that
• Last minute change just isn’t possible, no matter how necessary
• We’re already working on a large release elsewhere; you’ll have to wait for that to finish for resources to be available to work on your needs
• New functionality must be developed by our core team; we can’t offload that to another group for various reasons

Stakeholders don’t want the glass to be half empty or half full; they want a bigger glass and more liquid for it too.

But the stakeholders are tired of hearing such things. They “think different”, as the old marketing slogan had it.  These are people who don’t cheerfully accept the notion of “opportunity cost”. They don’t want their past decisions to automatically limit their future options.  They are impatient with the very notion of limits or constraints. They don’t want to be pushed to set priorities, because that means they’ve chosen one thing over another, when they really want both. They don’t want process to get in the way of immediate progress. They’re impatient with things being done serially, rather than in parallel. They know their needs change, legitimately, at the last minute, due to market pressures and other factors beyond their control. They don’t want the glass to be half empty or half full; they want a bigger glass and more liquid for it too.

In other words, IT stakeholders often look at IT processes and practices as being, well, a wall. And as Robert Frost put it in his well-known poem, “Mending Wall“, “something there is that doesn’t love a wall.” As you can see from the above list, to stakeholders, the wall of IT processes often shuts them out from getting what they need, rather than providing clear benefit.

But actually, despite how all this rings familiar to any long-standing IT worker, most stakeholders aren’t completely like this. Not deep down. Not if there’s proactive leadership and guidance. Most stakeholders, for example, actually do understand and welcome the opportunity to set priorities. They understand, in their gut, that it’s probably a good idea to avoid rework. They recognize that there are long-term considerations such as security and maintainability that can trump the need to “just get it done.”  But that doesn’t mean they won’t push back despite these understandings: as I wrote before, “everyone wants to get to heaven, but no one wants to do what it takes to get there.“

Stakeholders really do want things like robust delivery, solid systems, ease of maintenance and flexibility, and high predictability of time frames for development and release. It’s just that they don’t automatically, independently, intuitively understand the prerequisites to achieving those things: e.g., the need for careful prioritization of desired functionality; the importance of not trying to get everything all at once; the need to stick to a plan once it’s formulated, rather than changing the game every week; taking the time to test and carefully document even though those activities sometimes just seem to delay “the real work” of delivering what they want. They forget that “discipline is remembering what you really want.”

In short, it’s really a tug-of-war for the stakeholders themselves, a battle between their natural immediate wants and their long-term real underlying desires.

The answer to this perennial standoff?  Well, quite literally, “there isn’t one”: by which I mean that there isn’t one single answer. Instead, there are several, to be exercised simultaneously. And more than any single other entity in a corporation, success here depends on the adroit senior IT executive to bring off an appropriate balance.

• Be flexible. Your SDLC is important, but it can’t become absolute or “wall-like”. And while you’re being flexible (within reason, of course), recognize the downsides of doing so. It means there will be some rework. There will be interproject conflicts that could have been prevented had there been better planning and preparation. Roller derby is not ice ballet. Being scrappy will get you scraps and scrapes more often than not, but that’s just sometimes how the game needs to be played.
• Educate, as the opportunity presents. The flip side of Frost’s “something there is that doesn’t love a wall” is “good fences make good neighbors.”  Your stakeholders don’t automatically see the value in various IT processes and practices; only targeted discussion will help them do so. Having metering lights on freeway on-ramps seems to slow things down, but it actually speeds things up. Recognizing that isn’t intuitive.  Talk them through why your project may need the equivalent of metering lights.
• Emphasize collaboration and teamwork. In Frost’s poem, it can be argued, the actual process of working on the wall together (rather than the wall itself) is what makes for good neighbors. Figure out together what processes add real value.
• Constantly look for ways to de-couple your work so that chunks/projects can be done in parallel. Serial thinking can often become an easy out, a lazy excuse.  You’ll note that at least three of the points in the stakeholder list that led off this post have to do with conducting work in parallel.
• Lead. Without proactive, engaged senior leadership that constantly and effectively reminds everyone of the less visible goals, polls them on their reactions and then reframes the discussion, the stakeholder requirements list rapidly starts to include things that are frankly akin to wanting M&Ms for breakfast. Leadership brings balance and perspective.

Make no mistake about it: mending walls is hard. Doing just one or two of the above approaches will cause you to fail as surely as if you did none of them. And in my experience, absence of the appropriate balance almost always causes a company to devolve into systems chaos.