This is the first of a two-part look at a “Day in the Life” of a Business Analyst (BA). It’s broken into hours as a simple way to illustrate the myriad duties and skills that a BA needs to have, but in real life the process described below would take weeks, months, or possibly years, depending on the size of the effort. And, as every BA knows, there’s no such thing as a typical day – or even a standard job description. We’ll look here at the phases that every effort has, and tools that every BA needs.
At its core, the role of a Business Analyst is to help define and solve business problems. The role might have Solutions or Requirements in the title, and are known as Managers, Analysts, and Specialists. No matter what they’re called, the BA must zero in on the issue, determine its root cause, model the processes, develop solution requirements, choose a solution that balances time, cost, and scope constraints, assess the impact of the change, get buy-in from the sponsors and stakeholders, document the functional and technical requirements, help set priorities, track the development to ensure that the requirements are met, and measure and report on the result. They must facilitate meetings, resolve conflict, understand technical jargon, write clearly, present effectively, and advocate for all sides. Is that so much to ask?
The three components of process, people, and tools should be part of every analysis. In addition to standard BA skills, Business Process Management training brings additional power to the table.Ready to start our day?
6:00 – 7:00 a.m. Stakeholder Meeting.
The Project Manager has set up a conference call to introduce the BA to the project sponsor and her team, many of whom work in different time zones. The team has a hard time describing the problem, and they are already jumping to solutions. The BA refocuses them and has them describe their process at a high level. Although there are several software applications used within the process, most of these were packages the company had already invested in. They were repurposed for this process, in many cases causing additional steps in the process.
The BA schedules follow-up calls with key team members. At the end of the meeting, they agree on a high-level problem statement.
7:00 – 8:00 a.m.: Document the As-Is.
The BA begins the As-Is model, diagraming each step, decision, and handoff in the process. He estimates elapsed and cycle time that he will validate later. The diagram includes the tools and technology used, where applicable. He highlights unknowns and potential problem areas. There are a number of areas where he notices rework or redundant steps. In some cases, the BA suspects that these are work-arounds that once solved a problem, but that now have become institutionalized.
8:00 – 10:00 a.m.: Follow-Up Calls.
The BA uses the follow-up calls to validate the As-Is model he has begun with individual team members, and to probe to understand their pain points. Although the team is assuming that they need new software to solve their problem, the BA walks each of them through several process gaps he has uncovered in their area. He verifies his assumption that the process lacks an owner and a governance mechanism. During his conversations, it’s also revealed that some members of the team may not have the skills or training to use the software they have to full advantage. A couple of the team members display a strong resistance to change that he will have to overcome throughout the requirements process. The tools themselves may need to be enhanced or replaced, but it’s too early to make that decision until the requirements are more fully understood. These potential automation points are highlighted on the diagram.
10:00 – 11:30 a.m.: Facilitate Workshop.
The team meets to validate the As-Is model, and to begin process analysis. They eventually agree that the root cause of several areas of opportunity was the lack of process and requirements definition during the origination of the team. The team then starts describing their ideal vision of how things should work. They focus on decision criteria, business rules, and the experience they want their customer to have. Using this information, they begin to construct a To-Be model, which – used with the As-Is – will be the basis of their requirements. This model focuses strictly on what is needed, not how it will be done. That step will be included as they develop solutions.
11:30 a.m. – 12:00 noon: Gap Analysis.
The BA facilitates another meeting, this time with key members of the team and stakeholders from the upstream and downstream processes. He makes sure to include the individuals who are not comfortable with change. They discuss the gap between the As-Is and To-Be models. Basically, the questions center on what they need but don’t have, and what they have but don’t need. This can include any of the three dimensions of people, process, or tools. They discover that, in addition to the process needing to be streamlined to eliminate non-value-added steps, they should look at new technology to support the process. There may also need to be some reorganization within the team, to enable each member to work from their strengths.
This gap analysis will be the basis for the requirements that will be documented, validated, prioritized, planned, and signed off by the end of the day. The requirements, in turn, will allow them to develop and choose options to solve for the problem and its root cause.
Even though we’re only half-way through what will end up being a very long day, we need to leave our BA for a few weeks, until we pick up with Part II of A Day in The Life of a BA.
