Having been a Business Analyst (BA) for many years, I was given the opportunity in 2015 to step into a role that I considered new territory. I accepted a project assignment as an OCM Practitioner/Analyst for a multi-year program, with multiple projects, that was introducing massive changes to the client. There were both enterprise-wide changes and cultural shifts that were required to support the future growth of the company.
Do I Really Need a Business Case?
A completely legitimate answer to this question is “no”….BUT only if you have a lot of time, money, and people - and a desire to waste all three!
|A business case:
A business case, at the very least, makes one think more carefully about a future initiative. At its best, a business case helps ensure an organization is undertaking an initiative that will add value, which includes being in alignment with organizational goals.
Another benefit of writing a business case is that it sets the parameters for the initiative, which then feed into the project planning process making it easier for the project sponsor and project manager to move the initiative forward.
Have you ever seen the movie “Zero Effect?” It stars Bill Pullman as a Private Investigator. In it, he says, “The best way to follow someone is to get where they are going, first.” In a lot of ways, the job of a Business Analyst is like being a Private Investigator. Both jobs require observation skills, listening skills, creative problem solving, and of course, the ability to ask the right questions.
In my ten years of working within the IT industry, managing requirements has never been a clear-cut task, especially when the triple constraints – Scope, Cost and Time – always change due to business conditions. (For more information on the triple constraints, please refer to the latest version of the PMBOK guide.) But suffice it to say, managing requirements is challenging because of their ambiguity, which happens when they have not been communicated clearly to the appropriate stakeholders. To make matters even more challenging, ambiguity further propagates depending on how the various stakeholders interpret those requirements and document them. As this infamous comic cleverly illustrates:
Business analysts have a potentially long list of responsibilities and deliverables. Finding the time within a project to include all of the best practices can often be a challenge, and some important techniques, deliverables, and responsibilities are often neglected or ignored simply because there isn’t enough time available. This includes such things as requirements traceability, stakeholder analysis, reports analysis, impact assessments, and handoffs to other project team members. These are often sacrificed for the sake of creating the perfect requirements document, use cases, or diagrams and models. I’d like to focus this article on one of these often neglected work items – handoffs to other project team members.
The role Business Analysts play, and the titles they receive, vary from organization to organization and from project to project. They have a whole realm of responsibilities covering enterprise analysis, planning and monitoring, elicitation, requirements analysis, requirements management and communication, and solution assessment and validation.
Topics: Business Analysis
Kevin Brenna is the Chief Business Analyst and Executive Vice President for the IIBA, and I had the good fortune of seeing his keynote speech at the Building Business Capability (BBC) conference in Las Vegas in 2013. It was about the past, present, and future of business analysis.
Topics: Business Analysis
The term “requirements traceability” refers to the ability to map requirements back to business goals and objectives, and also to map requirements forward to test cases, business processes, software, training materials, and more. The concept is quite simple, really – it’s a way to tie everything together from start to finish, and make sure that end products align with originating goals and objectives.
Looking back across my career, I’ve had the opportunity to work with many different and unique businesses, operating in various industries. I’ve also worked on a wide variety of projects, from new application development, to solution selection, to solution integration and implementation. One thing that I’ve learned during that time is that for all the differences and uniqueness, most businesses and projects have much more in common than most people expect. Sure, the culture of a business or industry might be different, and work being performed might be completely unique, but many of the underlying needs, attitudes, approaches, personalities, and behaviours that you encounter from one project or business to another are fundamentally the same.
The Object Management Group (OMG) is defining a new standard for decision modeling: Decision Model and Notation (DMN). If you aren't familiar with the OMG, they are an organization whose goal is to develop standards by reviewing and refining commonalities between existing models and notation.