Mending Wall: Matches and mismatches in IT stakeholder expectations

Oil and water? Some days, the disconnect between stakeholder expectations and IT capabilities (and sensibilities) seems staggering.

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.

User requirements for IT

  • Must be adaptable to business situation
  • Must be able to employ multiple SDLC (Software Development Lifecycle) techniques as the situation dictates
  • Must be able to work in a highly parallized (sic!) environment
  • Must be able to accept and adapt to last minute scope
  • Should have multiple channels for functionality development both in terms of large releases and off cycle enhancements that occur in parallel.
  • Must provide the ability to externalize functionality to external teams to quickly develop new functionality
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.


  1. Sage advice as always … really enjoyed the post.

    The IT individuals that provide the “relationship management” function with the stakeholders, I find, often have the hardest job in corporate IT today. They have to have enough understanding of the value of IT processes/SDLC’s/etc. to have credible discussions with more technical IT resources while at the same time, the ability to “sell” the value of those processes to stakeholders while driving them to prioritize their IT needs. If they are effective in their balancing act, the entire IT delivery chain is more productive and stakeholders are feeling the productivity. If they aren’t, as you say, it causes a company to devolve into systems chaos.

    I recently wrote about how an IT manager that doesn’t own the PMO/stakeholder relationship can push for some progress on your excellent points here:

  2. The “relationship manager” that jfbauer talks about has the job of convincing BOTH ‘sides’ of the need for flexibility, not just the business. Without enough technical knowledge, deeper than ‘just’ project management, that person is another business person who doesn’t know enough to cry “bullshit” when IT are being inflexible for their own purposes (such as unnecessary standardisation on one tool at the expense of another).

  3. Yes: agreed with both John and Martin. In my experience, I’ve insisted on hiring quality PMO people (by which I mean, as Martin indicates, people with both technical knowledge AND project management capability) even ahead of bulking up the technical team. Without that effective relationship management, “hiring more techies” doesn’t help get more done; in fact, it can be the opposite.

    Thanks for commenting.

  4. Martin … I agree … I should have rounded out my comment with expanding on what I meant by “credibility”. You indeed captured some of my thoughts on what credibility means to the IT side of the relationship equation.

  5. This post was great! I wrote about it on our CIO Executive Series blog at We have over 180 IT executives in our group and they’re always looking for ways to better manage stakeholder expectations.

    BTW…Wondering if you would be interested in speaking to our group? Our meetings are virtual roundtables and r CIO members could benefit from your keen insights.


  1. […] Today has been a good “thinking” day for me so far. First, I read a great post by Peter Kratzman on Mending Wall: Matches and Mismatches in IT stakeholder expectations […]

  2. […] Article: Mending Wall: Matches and mismatches in IT stakeholder expectations […]

Speak Your Mind


This site uses Akismet to reduce spam. Learn how your comment data is processed.