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.
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