In our profession there is often talk about business analysts needing to get out of the detail and take a look at the bigger picture to make sure your efforts are still heading towards the goal of the project and the company goals. I refer to the syndrome of never getting out of the details as being "in the weeds." In theory, looking at the big picture every now and then makes perfect sense. I have been asked by BAs how do you do it and when is a good time. I thought I would give an example of how I try to build-in project milestones where I force myself to pull back the weeds and take a look to make sure I am heading down the right path. Now, on agile projects this should be built in to the process. Before beginning a new sprint, the team should be looking at the big picture and determining the right path. The example below addresses how I did this on a recent project using more of a traditional approach.The Project
I was the lead analyst on a project with a goal to elicit and analyze the business processes for four sister companies to help them determine if it was feasible to build an enterprise-wide technical solution for all companies. The project was initiated because each company had built and maintained systems. In many cases there were multiple systems with the same feature set. This project was part of a large initiative to reduce costs. The thought was, if there was one system rather than four, the long term cost to maintain and enhance the system would be less. The first step we took was to identify every business process conducted by each company and come to an agreement on all the process names. It was imperative to compare apples to apples. That effort revealed 145 unique processes to analyze. Yikes...that's a lot! I'm not even going to bring up the timeline given to us. Let's just say it was unrealistic.
Insert Milestones
The business stakeholders did not want any recommendation until all the processes were analyzed. They felt very strongly that without seeing the analysis of all processes, there was no way they could make a decision. Deep down I knew if we waited to show results of our analysis until the end there was a huge risk of us missing the mark. So I convinced the business stakeholders that we should attack the 145 processes by breaking them into smaller logical groups. We organized the 145 processes into 16 high-level groups. That is about nine processes per group which was very manageable chunks. The project plan was developed to attack the highest priority groups first. I also was able to have everyone agree we should stop at the end of each group and validate our understanding of the processes, present similarities across the companies, present variations, as well as the benefits and challenges of moving forward with an enterprise solution. In essence, we applied an agile approach under the disguise of a traditional approach. This is where we had milestones built in to the plan to get our heads out of the weeds.
The Result
After we analyzed the first group, we validated our understanding of the processes, presented similarities across the companies, presented variations, as well as the benefits and challenges of moving forward with an enterprise solution. Then we asked two questions to the group.
- Did the information provided give you enough information to make a decision about moving forward with an enterprise solution?
- Was there a reason to continue to the next group?
We wanted to uncover any issues our stakeholders had with what we presented. We had to know if we were doing what was necessary to meet the project objective. This gave us an opportunity to inspect how we were doing and what needed to be changed. Based on the answers, appropriate changes were made to our approach and we were asked to continue to the next group.
After the next group was complete, we asked the same questions. This time the business was able to determine that it was no longer necessary to compare business processes across the four companies. They had enough information to realize building an enterprise solution was not worth the investment. The initial project was canceled and new projects were initiated to help each company build update, and maintain their systems. In this case, our path ended before we anticipated.
By building in milestones in our project to get out of the weeds, two critical things happened:
- The initial project was stopped, potentially saving approximately 200k in cost.
- By stopping the initial project and moving forward with implementation projects for the companies, they will realize the benefits of new and enhanced systems four months earlier.
By getting your head out of the weeds and checking to see if you are still headed down the correct path is a characteristic of a seasoned business analyst. As you gain more experience you will naturally look up every now and then. If you are not there yet start inserting milestones in your plan to give you definite points in time to look up and make sure you are headed down the right path.
Stay on the right path!
Kupe
Don't forget to leave your comments below
Jonathan "Kupe" Kupersmith is Director of Client Solutions, B2T Training and has over 12 years of business analysis experience. He has served as the lead Business Analyst and Project Manager on projects in various industries. He serves as a mentor for business analysis professionals and is a Certified Business Analysis Professional (CBAP) through the IIBA and is BA Certified through B2T Training. Kupe is a connector and has a goal in life to meet everyone! Contact Kupe at This email address is being protected from spambots. You need JavaScript enabled to view it.
Comments