Deconstruct Delivery Issues Using an Architecture Mindset

We’ve probably all experienced teams that have struggled to deliver what has been promised, estimated, quoted, sold and talked about. You may have even been on one of those teams. This post is a short one (What? Not everything I write is a novel) about some things that all parties can do to take a step back before it’s too late.

There are a ton of reasons that things can go wrong, but let’s just talk about one. Scope. BORING!

Here’s why it’s important to this post and the general dialog though. SOLUTION. OOOOOO! Exciting word!

Depending on who you are and what you do, you might define solution a bot differently than someone else…..and THERE is the issue.

In a world (<—C’mon, say it like that guy in the movie trailers…) where technology has become very dominant, there are a lot of people who focus on it. There are even a few very specific methodologies devoted to delivering it better. Fine. But when the word solution starts getting thrown around, get it collaboratively defined by all stakeholders.

  • To a technologist (generic term I use for developer, methodologist, enterprise architect, etc.), that might mean the technical solution. That is what they focus on.
  • To a sponsor, they might THINK the solution is the new platform, because that is what is tangible and visible.
  • To a test team, they typically only think about test the platform, usually not the process or information sharing changes.
  • To a UX team, mucho focus on usability and experience and user satisfaction on both.

These four all have a common technology thread. No issues with that from me.

Now think about this….

  • People use processes and information
  • Process and Information interact with technology and data that facilitate processes and information
  • Create new technology or change the existing technology, and you touch the data, processes and those pesky people.

A SOLUTION SCOPE should be all encompassing. Technology. Process. People. Simple as that. Just start asking some basic questions and you will likely find that the answers to at least one of these facets is not nearly thought through enough.

See what just happened here? I didn’t even have to cite the Standish Group Chaos Report on how poor requirements contribute to project failure. I took out whole scope threads to start defining where we can go wrong. Gotta’ have a scope to write a poor requirement, right?


  1. How would missing one of the two non-technical facets (process, people) effect a single project outcome?
  2. Same question, yet this time consider impacts to an enterprise platform
  3. How would delivery of value to the customer be impacted without a solid solution that encompassed all three?
  4. How would a process improvement program be stunted by eliminating technical concerns?
  5. How would an organizational restructuring or reduction in force impact processes and information?

Weigh in! Let’s hear what you have experienced! How has this issue manifested into delivery issues?

What questions do you make a part of your due diligence?