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?








How Project Analysis Matters to the Larger Architectural Picture

This post seeks to shed some light on the differences between project analysis and enterprise analysis, where business architecture takes on a more important and visible role. As our profession grows and matures, understanding the commonalities and differences in analytical technique will serve to promote the BA role.

Continue reading “How Project Analysis Matters to the Larger Architectural Picture”

Who, What, Where, When, Why, How

The words in the paragraph header above are the simplest terms that we, as business analysts, can focus on to collect information and maintain it during the execution of a project. They provide our view of the project world we will operate in. Without it, we don’t have a clue about what we are doing or where we are going on a project….and the BA plays a key role in setting up the whole team to understand the project and problem domain from the start. Yet even when we get all pertinent project data collected and analyzed, it is still common to get hit with scope expansion due to hidden surprises, and surprises can cause issues with success. Why is that?

Often, projects are more than what is in the SOW in front of us that defines our scope; miss it in the discovery and estimation and it’s too late. Missing the bigger picture is easy when focused on specific aspects of change or solution delivery. There are two really important reasons for this (well probably more, but you only have so much time to read here). First, failure to actively question reality, and; second, myopic views of a solution. Questioning is a primary skill of the business analyst and we are all able to execute this, but ACTIVELY questioning a series of stop gap questions can help avoid scope creep and pitfalls while concurrently building your domain knowledge.

Consider this scenario…..

Assume that you have identified five stakeholder groups and their roles on your project. You understand who they are, what they do in the business, what knowledge they have and what user stories/use cases they are associated with. You also have been able to identify their needs for the current project outcomes (process and software). As you build your process, you are able to tie activities to the stakeholders that have been identified. You then build a context diagram to understand the general system and data architecture for reference, and you are able to also tie your identified stakeholders to the in scope system. However, your research (YOUR QUESTIONING) shows that the system actual sends and receives data with three other systems; none owned or operated by your identified stakeholders. What are these other systems? What do they do? Who uses or relies on them? How do they map to the business?

You have just identified out-of-scope impacts to and from your project and are about to delve into business and enterprise architecture. (Thank gosh this doesn’t happen in real life, right?). Your limited view of your project domain has grown to include other business and/or technical architecture elements that all work together in some way. How a BA addresses these other elements is often the distinguishing characteristic of our profession.


Identify Project Impact to the Larger Enterprise Structure through Questioning

Projects are executed to complete a set of tasks to achieve a goal or objective. When they are estimated, it is not uncommon to have unknown elements, such as the scenario we just encountered. It’s easy to see how a project can quickly get into trouble when encountering surprises that impact scope, ability to complete on-time, and project budgets. The triple-threat at work!

A Technical Solution HAS IMPACTS! Analyze the Total Solution!

Good business analysts think about all the interdependencies that scope creep entails and the inquire about the details. Even when the answer is known, questioning serves as a validation mechanism. The three impacts/systems you identified are there for a reason. This is where the information you have or don’t have can be used to fill in gaps in the larger picture (remember no information is an answer, too). If you’ve ever done a logic puzzle, this is much in the same. You are using a few pieces of information to make assumptions and validate those to lock in as many facts as possible in order to solve the total puzzle.

At this point, knowing that new items have been identified, the most effective BA technique is to refer back to the technical architecture/business architecture/prior project documentation (because we KNOW that was the first thing you pulled together when you came on project. Right? Right!). If not, get your hands on it and start locating the pieces that form the domains that your project application and processes live in.

In the absence of these documents and diagrams, you have in this example the beginnings of at least your local architecture and how your project fits into the bigger elements.

Technical Documents and Diagrams that Are Helpful

There are several primary documents/diagrams that I rely on regularly to help shed light on the technical architecture. Each of these provides a specific view of the technical structure. There are MANY, MANY others.

  • Context Diagram: a simple model that shows a central system and the surrounding system architecture, plus the TYPE of information that gets passed back and forth. Easily consumable by business.
  • Technical Infrastructure Framework/Diagram: a complete model of the technical infrastructure on all levels. Usually very complex but an excellent source for researching technical architecture.
  • Data Dictionary + Data Model or ERD + Data Flow: This data “trifecta” is technical in nature but is built around business and organizational concepts and structures. Knowing what the data is reflects the “conversation” between roles and systems, which allows processes to function.
  • Integration Model: Usually not part of the technical repertoire, but a great addition to show which systems interact with one another and often includes data types for passed information through the integration points.

Business Documents and Diagrams that Are Helpful

There are several primary documents/diagrams that I rely on regularly to help shed light on the business or organizational architecture. Most you’ve heard of before.

  • Glossary of Terms and Acronyms: Cannot stress enough how important this super simple document is to have in place and iteratively built through the life of a project. Common taxonomy and shared understanding is a HUGE issue in achieving success on a project
  • Organization Chart: Another simple document that can help tie pieces together as information builds. It normally serves to identify people, roles, titles and business units, but ad-hoc notation can be added by the BA to includes capability utilization, data types, system utilization and more.
  • Process Flow and/or Use Case Diagram: The de facto form of “what the business does, who does what, when “it” occurs and how people and systems interact together.
  • Capability Model: A business architecture reference that defines what the business does, but not how. It represents the core capabilities for the master organization or the business units within/subsidiaries. The capability model can be used to map every other element of the organization to individual capabilities, which provides a clear line of sight view for people, processes, systems, data and other elements. It is often non-existent in less mature organizations, but the BA can begin to craft it as the project occurs to provide superior value and domain understanding.
  • Context Diagram: While this is a technical artifact, I really like how simple it is and have often used it to illustrate business units and the information and actions that pass back and forth between them.

Take Away

Requirements are often cited as a primary reason for project issues and failure, though I refuse to cite the Standish Chaos Report again. While true in some regards, the root cause is a much stickier issue that can be traced many times to lack of or elimination of proper discovery to clearly identify the complete scope of an effort. The BA encounters a situation in which requirements are essentially needed for an unknown, hence the importance of questioning. When encountering scope surprises…

  • ask the right questions (who, what, where, when, WHY, how) over and over
  • also question what is NOT evident or obvious (are there roles that don’t map to systems? data that doesn’t map to capabilities or process? process that doesn’t map to roles or systems?)
  • revisit the available documentation and interview key SMEs to acquire answers
  • pull the pieces of your problem domain together to build an updated view and define impact
  • document the architectural mappings and alignments as a value add for your customer (and your team’s ability to succeed)
  • learn the general architectural constructs that work best for YOU when trying to craft answers about the bigger pieces