From Vision to Value: The BA’s Guide to Conquering Transformation. (Part 2)

Welcome back to learning about how to move from envisioning business transformation to driving measurable value from your transformational efforts.

If you missed the first part, you can catch up here.

Previously, we looked into how, as a Business analyst, you should know the why of a transformation effort. In this guide's second part, we will dive into the world of process improvement and business requirements.

Without further ado, let’s dive right in.

Process Improvement.

What is the first thing that comes to mind when I say business transformation? Perhaps you’re thinking of business roles in the day-to-day operations of an organization or current as-is state versus a to-be solution. Or you’re thinking of business process maps and diagrams. And you’d be right for all of the above, especially business processes.

Process improvement can be further broken down into process analysis and process optimization.

Process analysis.

Understanding the business processes is vital when it comes to business transformation. If we want to understand how an organizational function operates, we look at the processes. If we want to understand if changes are possible in an organizational context, we need to understand the processes. How do you know what to look for? Where are the processes, and how do they get transformed? It’s equally important to understand the flow of the processes. The organizational context is all interconnected. If you pull one process out by itself, it’s almost like pulling a single puzzle piece out. But it’s the full picture that clearly shows the result. All the pieces put together are needed to form a picture to produce an outcome.

Next, build a visual representation of the processes, this is called process mapping. More times than not, in my experience, processes are contained in big documents with loads of text. Lift the information out, draw out the flow, and represent it simply as a process diagram. This will ensure that not only do you understand the flow, but it will immediately highlight areas of potential challenges and improvements plus, you’re able to summarize and update the process steps.

Now, if the processes are already drawn, investigate if they all follow the same format. You want to ensure standardization. After you are done with your process analysis, now, and only now, are we ready to start thinking about process optimization.

Process optimization: is a buzzword across every change and management consulting perspective out there. Every framework available has its method for optimizing processes. And sure, there are great benefits to Agile, Lean, Six Sigma and more, but you don’t need to worry about getting your green belt to do fundamental business transformation.

I can show you a framework-agnostic way of approaching this step. In the previous section, we spoke about understanding the existing processes, finding out the repository, and getting your head wrapped around the current picture. Let’s call this our “as-is” state. Something that you’d often hear too is a “to-be” state. This is the optimized future process. Now, processes are important because they can be a source of value and competitive advantage for the organization. An inefficient process, however, creates the opposite effect: diminished value and competitive disadvantage.

To re-engineer and optimize processes, you need a starting point. Let’s break down the entire process into a series of steps:

1. Look at what is happening in the current process. Ask what tasks are carried out and by whom. How long does it take to perform the tasks? Are there any delays with the current process? Are the current processes efficient, and are they a competitive advantage?
2. Take that information and create an as-is process diagram. This helps immensely to see and understand the process flow. It helps to add further data points, and it helps when we compare the as-is to the to-be state.
3. Collect the process data on how long each step in the process takes. Mark that on your diagram. You’d need that input for your stakeholder interviews and Subject-Matter Expert discussions.
4. Identify any delays between the steps and note those down. This is where you identify the bottlenecks, throughput time, turnaround time and other key metrics.
5. Identify the value for each process step. There are three types of value you need to capture.
   - Client value: These are steps in the process that directly add value to our customers and end users.
   - Business value: are steps in the process that add value to the business operations, such as data storage or enabling other business functions.
   - NVA or non-value add: If you’re struggling to identify a step as either client value or business value, the chances are it’s probably a non-value add step. This is your initial taste of what can be trimmed down from the process. Non-value-adding activities help you to understand why a process may be sluggish, with poor quality outputs or costing too much to perform.
6. Validate with stakeholders. Replay your process findings and validate your maps. Now you can finish here and begin your to-be state hypothesis, your investigation and your proposal for a more optimized and efficient process. But rather than leave it at that, I want you to take it one step further.
7. Collaborate with your stakeholders. Ask them how they would make the process more optimal and efficient. This is different from validation, where you just have them confirm what you have found. They own the process and would have more insights, so you have to work closely with them.

Now you’re asking them for new requirements, and by opening up the conversation, collaborating and problem-solving together, effective transformation and business process optimization is not only possible, it’s easily achieved.

The secret to excellent requirements.

Whether you are gathering your requirements before or after your process improvement efforts, you’re going to need a solid process when it comes to requirements because the quality of the requirements shapes the solution.

This section will not be diving into what requirements are and the process of requirements elicitation (that’s a topic for another day). Instead, I’ll share with you a simple framework for managing already elicited requirements, and I’ll explain why each step is important.

1. Document requirements: you’re probably thinking, of course, I’ll document the requirements. But you’ll be surprised at the number of times that I have had projects underway and requirements have come through in all shapes and sizes. New requirements come to light as part of meeting minutes, stakeholder interactions, and as part of formal project review meetings, and even as part of top executive discussions. Now, this is all good and well, you just need to be prepared for it. As part of your documentation approach, have a standardized way to document requirements. And I don’t only mean the initial ones, I mean all of them.
2. Have a central repository to store them. Once written down in detail to the same level, represent and agree on them as per the requirement's approval process. Irrespective of whether the requirement came from meeting minutes or the top executive, it should all follow the same process. You could have all the tools, smart reports, and top support on the project, but it’s the basic due diligence principle to document everything thoroughly and regularly.
3. Replay requirements back to the requesters and other stakeholders. If it’s agreed, it’s in the can, right? Not always. Even though you may have received it, documented it, and agreed on it with the project team and the stakeholders, there’s still a chance that it’s not needed. Over time and with perspective, they may come to realize a requirement is not needed. Also, what I have learned is that the same business stakeholders and end users may see the same business needs differently. Include regular review meetings, and review and replay requirements all together and with the same group of requesters. Prioritize and reprioritize until you are certain your list is solid.
4. Lock them down: what I mean by this is that once you agree to the requirements, have a deadline for changes and additions. Once the deadline has passed, this is it. No more amendments, improvements or tweaks. This, of course, is in the purest world and the real project dynamics may differ. I get it. But here’s the deal. Unless you have a cut-off date, people will continually approach you with ideas. Instead, agree that these late requirements can be part of the next phase or product improvement cycle.

If you want to dive deeper, the BABOK guide has these aspects covered in the sections called Elicitation and Collaboration, Requirements Life Cycle Management, and Requirements Analysis and Design Definition.

As we conclude, I’ll leave you with this:

A true business transformation speaks beyond buzzwords. It speaks your stakeholder’s language. It is not about complex requirements and convoluted solutions. It’s about having a consistent, simple approach to requirement solicitation, and this delivers high-quality outputs that directly satisfy the organizational needs.

Thanks for reading this far, for the next and final part, we will talk about how to set goals and measure success for our transformation efforts.