Part 2: Five Steps to Data Driven Business Analysis with Blueprint
Last time I explored the price an organization pays continuing to support a document-centric business analysis practice in Blueprint. Beyond the real dollar costs of document template authoring services and training document based practices reduce productivity, accountability, and the reliability of your requirements. Here are five steps you can take to make the change to a data-centric business analysis practice:
Step 1: Take the Plunge
There are always reasons not to change the status quo. If you want to get full value from Blueprint you need to take the plunge. Inspect your reasons carefully. You might be surprised with what you find. Compliance usually requires signed off requirements, not a signed off document. Blueprint’s review and approval functionality ensures greater accountability with a record of which requirements were reviewed and approved by which stakeholders.
You are also likely to find that reviewers will be glad to not have to sit through another review of a 100 page BRD. Do not jump off the deep end though. Pick a pilot project with stakeholders who are ready for change. Demonstrate the collaboration, review, and approval capabilities to the organization with them. They will become your partners and champions in the change to a data-centric approach.
Step 2: Build an Analysis Framework
The traditional BRD often serves as an analysis tool as well. The structure in the document provides a framework for thorough requirements elicitation. It is critical that you build a Project Model into Blueprint to provide the same capability. Include Tooltips and Default Descriptions for key artifacts. Tailor the Group Labels to your analysis practices. Build a Reuse repository of common artifacts for analysts. Include common artifacts in the base project model that are prepopulated with information analysts need.
You can also extend your Blueprint Project Model with Blueprint’s new Nonfunctional Pack. This feature provides Roxanne Miller’s best practices for nonfunctional requirements. It also includes Blueprint’s best practice approach for analysis planning and elicitation. Add the questions implicit in your document template to the model as well to make full use of this practice.
Step 3: Know Your Data
When I review the documents that make up a business analysis methodology they tend to contain two kinds of content. One kind is common; information that provides context about the initiative, stakeholders, and organization. The other is the unique business analysis artifacts. It is important to make this distinction when you develop your Project Model in Blueprint. This also allows you to stop the duplication and cut and paste that makes the document-centric world so onerous for authors and collaborators.
It is also important to look beyond your BRD. Much of the content that makes up a business requirements document was also present in your organizational mission and vision, business and enterprise architecture documents, portfolio planning documents, presentations, and project charters. Downstream systems architectures, detailed designs, and test plans repeat the same information. This repetition not only creates extra work, it also introduces the risk of transcription error. It also makes traceability a more difficult exercise than it would be if all of the content was in a single repository.
Step 4: Lead With Your Collaboration Strategy
Someone has to be the first to make a change. You do this when you make use of your Blueprint Collaboration Strategy. This strategy is a key to making a change. Part of it defining the process and stakeholders who will participate in reviews at each business analysis milestone in your methodology. You should also define what business analysis artifacts in Blueprint they need to collaborate around. A project sponsor is going to be interested in different artifacts than a line of business lead, subject matter expert, project manager, or software developer. Make sure you only share what is relevant to make the content easy to consume.
You also have to model the way by using the tool yourself. Whether you are eliciting requirements or reviewing them stakeholders will follow your lead. If you bring a document they will continue to expect documents. You will lead the change to a data-centric business analysis practice when you elicit requirements directly into Blueprint, start informal reviews early with @mentions, and do walkthroughs, informal, and formal reviews in Blueprint.
Step 5: Get Visual
I have sat through many BRD walkthroughs in my career. The worst were ones where we would show up and receive a copy of the document for the first time. People’s eye glazed over as page after page of text scrolled by. The conversation would get hijacked and sprint down a rabbit hole after a single point. Reviewing early and often helped avoid this. Another key element was models. When reviewers can see how all of the words fit together and flow you can lead a much more effective review. Models help make the change to a data-centric Business Analysis practice. Business process diagrams, use cases, domain diagrams, and other models all help provide the context that makes it easier to understand complicated requirements.
Modeling is also a critical part of your business analysis practice. Traceability is only part of this. It is important to know where your requirements come from. It is equally important to see how they all fit together. The IIBA BABOK 3.0 refers to this as the Requirements Architecture. It ensures that your analysis presents a holistic picture of what the organization needs to achieve. This picture is also the one that will make the most sense to the people you collaborate with. Lead with the right models and you can break free from your BRD.
Lastly, if you put it in a document…
If you put it in a document today you should put it in Blueprint in the future. This will help avoid duplication of work, transcription errors, and ensure your business analysts create a holistic view of the requirements that drive change in your organization. It will also drive the development of a more mature business analysis practice focused making sure your organization does the right thing. Blueprint’s JumpStart deployment and adoption methodology will get you there.
