How to K.I.S.S. and Get ‘er done BA style in 5 steps

Problems are complicated. Problems can be overwhelming, like a tangled string of Christmas lights twisted together in tight knots and impossible to untangle. It’s time to decorate the tree and the lights are in a jumbled mess with no end or beginning to the string. The thought of untangling the string to put on the tree is overwhelming. Where do you start? Can you ever untangle them? Yes! You can! With a plan and some patience , t’s always possible to untangle the lights.

Starting a new project can feel like a twisted tangled mess of lights. Scope is not clear, data is stored in dozens of systems, business rules are buried in documents you can’t find in SharePoint sites, processes are not documented and stakeholders are withholding information for requirements. A project tangled mess with no end or beginning. How can the tangled mess be managed? Despite the appearance of complexity, every tangled mess can be managed through following the simple process of analysis. Following Keep it Simple Silly (K.I.S.S.) principle is a tool to untangle the mess of requirements. There are five elements to this principle.

1. Create a problem statement

Teams swirl and are unsure of how to move forward when the problem they are focused on is not clear. Knowing what the problem is creates the foundation to untangle the mess of requirements. A great technique is to use a structured problem statement in four parts:
1. The problem of (describe the problem)
2. Affects (which stakeholders?)
3. The impact of which is (how are they impacted?)
4. A successful solution would be (describe what a successful solution looks like)

This format for the problem statement structures thinking about the problem. The format helps to drive out the real problem and understanding the impacts to measure the success of the solution. Does the solution solve the problem? I use this problem statement to remind stakeholders what we are focused on. If our discussion topics do not support this statement, those topics are added to the parking lot. The problem statement can be created at many different levels. There is an overall problem statement for the project. As you discover the features in the project, more specific problem statements can be created to focus conversation to specific requirements needed.

2. Create a context dataflow diagram

One of the common frustrations in teams is unclear scope. A simple way to create scope clarity is to create a context data flow diagram. This diagram has the delightful appearance of a flower , bringing smiles to all those that receive it! This technique creates the high level picture of the external agents, data and interfaces involved in the project. It is simple in principal but powerful. The tangled mess starts to feel manageable when it’s drawn out.

3. Breakdown the problem into manageable components

Trying to solve everything all at once is overwhelming and unmanageable. Breaking down the problem into smaller, manageable pieces of work allows the tangled mess to be unraveled. Approach the analysis process by focusing on a single piece of analysis at a time. The analysis process has four basic components: data, process, business rules, and external agents/actors. Each is important. Focusing on one at a time creates clarity.

I start with process. Create a high level process diagram to understand the business process. Knowing where you are is the start to understanding where you need to go. Pictures help create understanding very quickly. Keep the diagram high level to start with, the details will be added later. With the process understood, move on to the data. There is no process that does not involve data. Data, especially new data is critical to understand. Uncover the entities and attributes, the cardinality of data elements and their impact to the process. Focusing only on the data will uncover more than attempting to untangle all the requirements at once. The data discovery involves understanding the sources and destinations of the data, the external agents involved in the process and data transformation. These are identified in the context data flow diagram. Knowing what systems and people are involved with the interfaces we need to understand gives us context to the complexity of the project. Each interface can be analyzed separately, which is more manageable than dozens at once. Wrapped around all of these are business rules. These can touch each of the other components and must be understood. Business rules may not become requirements to a system change. They exist within and without the systems that support the business. Business rules can be enforced through process changes, data relationships or enforced with system changes. Breaking down your analysis thinking into these components isolates requirements and you will discover more details than focusing on them all together. Understanding these components will identify high level requirements or features that will need elicitation and discovery.

4. Create a plan

The prior three steps are the inputs into a business analysis plan. Planning is an essential part to turning the unmanageable into something manageable. A plan should include an approach to how elicitation will be performed, which techniques are needed, which stakeholders will be involved, identify the analysis techniques needed and what artifacts will be created. The plan will structure pieces of work. High level requirements are identified in the plan and an approach to each one can be identified. The plan organizes work and provides a basis for efforts estimates. The plan documents the stakeholder analysis such as what their influence is in the project, identifying decision makers before a decision is needed and describing how decisions will be made.

5. Determine difference in current state and future state

The difference in where you are today and where you want to go tomorrow is a gap. These gaps are analysis opportunities. Using the high level current state process diagram as a basis, as I discover more high level requirements, I update the diagram to indicate the future state process. I like to create a visual in the diagram to identify these gaps. This also helps to highlight what isn’t changing in the future. Knowing what the gaps are and approaching these one by one helps to make the analysis manageable.

Follow these 5 principles to keep it simple silly and allow a business analyst to get ‘er done!

Heather
A BA Without Borders