Skip to main content

Author: Aaron Whittenberger

Becoming the Trusted Advisor

Written by Aaron Whittenberger on . Posted in Articles. 2 Comments on Becoming the Trusted Advisor

A couple of months ago I wrote on the value of the business analyst being a trusted adviser to many people on the project team and within the organization.  Read The Value of Business Analysis: The Trusted Advisor to see that discussion. 

I conveyed the business value of becoming that trusted advisor, but I didn’t tell you how to get there.  So if you read that article and thought to yourself “well that is all fine and dandy, but how do I become the trusted advisor to everyone within my company?”  Well, read on.

Set Expectations

Let your stakeholders know what is coming up next.  You shouldn’t leave anyone questioning next steps or action items; always call those out for both yourself and other team members.  When you take ownership of action items, that is called making a commitment.  It shows a willingness to be held accountable to complete the action item on time.  It does not guarantee completion on time, just shows your willingness to accept the responsibility.  There are many things that can crop up that get in the way of meeting commitments once they are made but never shy away from accepting the responsibility. This is a major way to earn respect.

When action items are assigned to other stakeholders on the team, especially when they intersect with action items assigned to you, check on their progress from time to time.  Your items may have a dependency on other’s action items or vice versa.  In the latter case, stay in contact with that team member and let them know your progress so that they may plan out their work on their action items.  When monitoring the progress of others, do it in a very non-intrusive and non-authoritative way.  Typically, you won’t have authority over someone else’s work so approach this from a co-worker checking on a friend or offering a helping hand.

Deliver

Now that you have made the commitment to take responsibility for an action item or task deliver on it.  Always work to finish your assigned tasks ahead of schedule so when those inevitable items pop up that take your time away from these tasks, you still have time to get back to it and deliver on time.  In this way your team members don’t see all your tasks slipping behind schedule. This is a major way to lose trust.  Be creative when the situation calls for it to complete task assignments.

I was always astounded by my children who always looked like they were trying to get a “C” in every class in school.  A “C” is a passing grade right…the problem was that far too many times they missed that “C”, and sometimes by a lot; so what did they end up with…a “D” or “F”.  When I was in school I always tried for an “A” in every class, whether I liked the subject or not.  So when I didn’t meet expectations what did I end up with….a higher GPA than my kids did.

Communicate

You know the old adage…communicate early, communicate often.  This ties back to setting expectations.  Let your team members know what to expect from you, so they can know how to work with you.  When new issues or risks pop up, identify and communicate them early so they can be properly managed.  Raise those red flags early.

Communicate bad news early.  When the project is behind schedule, when it needs more resources, or when lack of stakeholder engagement is slowing the project, address the issue with the project manager and/or project sponsor.  Be prepared with information and examples, and possibly a plan of action to get back on track.  This again ties back to setting expectations, are things slipping behind because expectations weren’t properly set or communicated?

{module ad 300×100 Large mobile}

Provide frequent updates to the project manager, project sponsor or other stakeholders on your work or the project solution.  Survey your stakeholders to determine the right level and frequency of communication.

Be Consistent

Be consistent in your setting of expectations, making commitments, communication, and interactions with your stakeholders.  Consistency is at the heart of integrity.  Inconsistency tends to build walls between people and inhibit collaboration.  When people don’t know how you will act or react, they may shy away from approaching or engaging you.  As a business analyst you need information, and when your stakeholders do not wish to interact with you or discuss issues in an open way, this impedes your ability to get the information you need to be effective.

Have the Courage to Challenge Appropriately

I will combine lessons from Elizabeth Larson, Rich Larson and Bob (BobtheBA) Prentiss to say have the courage to challenge appropriately.  It takes courage to deliver bad news or just say “No” to someone.  You may see how a simple “No” won’t go very far; people  will find other avenues to get what they want if they see you as a roadblock.  So be prepared to back up that “No” with solid evidence, data and/or facts.  As Elizabeth says ”Courage without preparation is foolish.”

You will not challenge every idea that others have; that  is truly foolish.  Make sure you take the time to understand fully the idea and reasoning behind it.  Determine if the idea has value and feasibility.  Take a structured approach to determining when it is time to challenge an idea.  When you do challenge, make sure you do it with respect to everyone including those that presented the idea to the group.  Make sure your challenge isn’t perceived as offensive or confrontational.  This is another good way to destroy trust.

To Gain Respect, Show Respect

This should go without saying, if you want respect you have to earn it.  One of the best ways to earn respect is to show it to others.  Respect every stakeholder’s expertise in their subject matter or domain.  Respect and acknowledge everyone’s contribution toward the common goal.  Respect their role within the team and organization.

Also, remember that your role within the organization is one of the newest, and not everyone has worked with a business analyst before or knows how to interact with that role.  So some education of your role within the team and organization may be in order.  Take a coaching approach to this opportunity and don’t make any feel dumb because they don’t know this yet.

Be Proactive

Anticipate the needs of others.  Not only your project manager and business stakeholders but your technical resources as well.  When preparing a presentation to management or your project team, anticipate questions you will get and be prepared to answer them.  Have adequate examples and models prepared to demonstrate an idea or concept.

When issues or risks arise, identify and communicate them early.  Possibly prepare an action or risk mitigation plan for it.  Don’t allow tasks to slip so far behind that it affects the project schedule and is noticeable by everyone, communicate roadblocks and other commitments, so team members understand the conflicts and pressures. In this way they understand that slippage isn’t because you are lazy; communicate the situation.

Take responsibility for action items and tasks quickly; ask for them, don’t wait for them to be assigned to you.

Be Authentic

Being authentic is simply being yourself.  Be sincere, speak from the heart, be respectful and be empathetic. Don’t mix your words in a cloud of ambiguity; say what you mean and mean what you say. Take the time to build relationships with your team members and stakeholders.  Be interested in their situation and ideas.  Understand their perspective, motivations and attitudes.  If you are not truly interested in their perspective, motivations and ideas; then don’t pretend that you are.  However, you will find how much harder it is to work as a business analyst when you don’t understand your stakeholders.

If you are able to master these skills and competencies, you will gain the trust and respect of your stakeholders.  Remember, that it takes much longer to regain respect and trust once destroyed then it does to earn it in the first place.  So take the easy road and earn that trust from the first encounter with every stakeholder and work vigorously to keep that trust.  Respect each stakeholder’s role in the project and organization, show your capabilities and you will earn their trust.

If you would like some additional reading on this topic, I suggest you take a look at:

  • The 7 Habits of Highly Effective People: Powerful Lessons in Personal Change by Stephen R. Covey (2013)
  • The Influencing Formula: How to Become a Trusted Advisor and Influence Without Authority by Elizabeth Larson and Richard Larson of Watermark Learning (2012)
  • The Speed of Trust: The One Thing that Changes Everything by Stephen M. R. Covey (2008)
  • Influence Without Authority by Allan R. Cohen  and David L. Bradford (2005)
  • The Trusted Advisor by David Maister, Charles Green and Robert Galford (2001)

Business Analysis Profession on its Path to Maturity

Written by Aaron Whittenberger on . Posted in Articles.

Often at the beginning of a new year, many people like to reflect upon the prior year and make plans for the upcoming year. Not only people but organizations often take on these activities of measuring the success of the past and making strategic plans for the future. A component of strategic planning is to recognize trends in the industry and to leverage those trends to the organization’s sustainability.

Since 2009, the folks at Watermark Learning have looked at the trends in business analysis and project management. Read here to see their latest reflections. In 2013, the Senior Leadership Team of the International Institute of Business Analysis (IIBA®) reflected upon predictions in the profession of 2011 and then looked at what the profession may look like in 2016. Read more here to see how they did.

Not to be outdone, two years ago I threw my hat into the ring. There were some very definite trends that were in their infancy in 2014 that prompted me to recognize them. You can read what I felt was just beginning back then and see how those areas have grown and affected the business analysis profession.

So if you have read both articles who would you say is better at predicting the future, Julian Sammy or me?

I won’t go through the ten trends I identified two years ago and see how far they have come in two years. I will leave that to your assessment. However, much of the same trends from back then I would reiterate again this year—Agile, Collaboration, Product Vision, Strategy, Training, Abundance of business analysis jobs and Business Analysis Centers of Excellence.
As some of these trends continue to be identified year after year by the folks at Watermark Learning, IIBA and myself, it just goes to show that these trends continue to grow and affect the business analysis profession. As I said two years ago “Agile is here to stay.” It is not only here to stay, but it also continues to grow. It may continue to face its challenges of organizations adopting the Agile approach, but we will increasingly see organizations that previously “tried” Agile find more methodical ways to adopt the principals. This should see an increased demand for Agile coaches, certified Scrum Masters, and product owners.

Instead of reiterating these trends and possibly adding a couple to the list. I want to do what any good business analyst does and get to the root cause of the intertwining fabric of these trends.

Business Analysts Work Feverishly to Deliver Value to the Organization

Value is a concept mentioned in this year’s trends identified by the folks at Watermark Learning. It is also the intertwining concept I noticed that many of the presentations from this past Building Business Capability Conference, the official conference of the IIBA. Whether the discussion topic was Business Architecture, Business Relationship Management, Collaboration, Organizational Change, Strategy, Critical Thinking or Agile; each presentation drove back to delivering value to the organization.

IT Business Analysts, or Business Systems Analysts, will need to be innovative to find new ways and new partners with which to collaborate to deliver faster and ensure solutions that deliver greater value to the organization. Even if not adopting Agile principals, IT Business Analysts will find innovative ways to show agility in their work.

{module ad 300×100 Large mobile}

Business Process Analysts will also be innovative in their models they use to help all stakeholders understand business processes and impact of proposed changes to those processes.
Business Intelligence Analysts will work to make data more predictive and prescriptive to deliver greater value to the organization. They will find new tools to make their use and interpretation of data more innovative.

Organizations will utilize business architecture so that key decision makers within the organization can understand the business and all its components, products, and services. Business architectures will become more complete and utilize multiple views and models to aid in that understanding.

Enterprise-level business analysis practice will aid Business Analysts, in whatever role, within the organization become more agile and deliver value to the organization. Delivering value will become a key objective of Business Analysis Centers of Excellences (BACoE) and Enterprise level business analysis practices. This trend I mentioned two years ago may be slower in developing than some of the others, but it will receive refined focus in upcoming years that will aide its maturity.

The International Institute of Business Analysis will continue to support the profession and the global business analysis community. New products and services will be introduced to this end. IIBA has announced that they will revamp their certification program to a multi-level competency-based program; recognizing practitioners at progressive stages of their business analysis career. This new certification program is slated to be launched in September of this year.

Recently, IIBA announced a new Enterprise Business Analysis Core Competency Assessment Framework (EBACC) to aid organizations to assess the maturity of their business analysis practice. Then new tools, products, and services will be introduced to help mature that practice at the enterprise level. This new focus on the enterprise level will cause an increase in BACoEs.

In 2014, the IIBA was just over ten years old, and the business analysis profession was in its infancy. Two years later it might have grown to its toddler stage. Certainly in comparison with PMI, at 46 years old and ASQ at 65 years old, you can certainly see that the business analysis profession is just starting out, but in its young life, it has made some great advances. I can’t wait to see where it goes in the next ten years.

The Value of Business Analysis:The Trusted Advisor

Written by Aaron Whittenberger on . Posted in Articles. 2 Comments on The Value of Business Analysis:The Trusted Advisor

Often when people talk about the Business Analyst being a trusted advisor within the organization, they are speaking about advising senior management of the organization. That role of the Business Analyst is that of a Management Consultant, the role of trusted advisor goes much beyond consulting or advising management.

The Business Analyst has to become a trusted advisor to everyone within the organization. Whether they are an IT Business Analyst, Business Architect, Process Analyst, Agile Business Analyst or Business Intelligence Analyst they will work with many people within the organization; and they must garner trust from everyone with which they work to gain the needed knowledge from those individuals or assist them in doing their tasks. So let’s look how the Business Analyst works with and advises others within the organization.

The Project Manager

The Business Analyst works with the Project Manager in managing the project to a successful completion. Although their focus is different; the Project Manager is focused on the project and the Business Analyst is focused on the product or solution, their goal of a successful completion of the project is the same. Like many members of the project team, the Project Manager relies on the requirements developed by the Business Analyst. The Business Analyst can advise the Project Manager throughout the project on concerns from both the business and technical stakeholders and may advise on activities or tasks to respond to those concerns.

The Project Sponsor and Business Stakeholders

As the major decision maker of the business stakeholders, the Business Analyst advises the Project sponsor on upcoming project business analysis activities, product features, solution scope boundaries and works with the Project sponsor and project team to resolve any issues that the business stakeholders raise. The Business Analyst works with the business stakeholders to draw out, analyze and document the business needs and requirements for the solution to resolve those needs. The rest of the project team and organization rely on the accuracy and clarity of those requirements. The Business Analyst works with the business stakeholders and Project sponsor to validate and approve the requirements.

The Enterprise Architect

Although an Enterprise Architect is considered a business analysis role, in larger and more complex organizations these will be two distinct roles; therefore, I list them separately. However, realize that in smaller organizations these roles may be performed by one individual. The Enterprise Architect will be concerned with the architecture of the solution being considered; they will develop the technical architecture for the solution based on the requirements of the project. They will put that technical input to the requirements during their development, then use those requirements to ensure the technical architecture of the solution is aligned with enterprise standards. During the development of the architecture and the solution the Business Analyst advises the enterprise architect on the business perspective of the requirements.

The Business Relationship Manager

The Business Relationship Manager is responsible for ensuring that the Project Sponsor is included in all correspondence necessary and that the project team understands the business perspective of the solution scope; in this respective, this is a business analysis role. The Business Analyst will advise the Business Relationship Manager the same as the Project Sponsor and ensure that they both are included in all communication and fully informed as to solution scope. They will ensure that the Project Sponsor and Business Relationship Manager understand the technical side of the solution scope.

The Development Team

As the development of the solution is about to begin the Business Analyst will hold a requirements review session with the development team and business team. This allows to get everyone on the same page with respect to the requirements. This gives the development team the opportunity to raise issues with the requirements, especially if features or components are functionally impossible to deliver. Also difficult to deliver features and components, and alternatives to those can be raised at this time. It is possible that the enterprise architect or Business Analyst has raised and considered alternatives prior to the requirements review. Like the enterprise architect, the Business Analyst will advise the development team on the business need and perspective of the requirements during the development phase of the project.

The Quality Assurance Team

Like the rest of the project team, the quality assurance testers will rely on the requirements for the solution. The quality assurance team will build their test cases on the requirements. The Business Analyst will put the business perspective on those requirements so that the quality assurance team understands the business reason and relative importance of the requirements.

Organizational Management

As the organization is expecting to receive some benefit from the change and its solution, the Business Analyst, possibly through the Project Manager, must advise business management of any changes in that expected benefit as the project progresses through its life cycle. Once delivered the Business Analyst will measure solution performance against developed success metrics and advise management on benefits realization.

So as you can see, the Business Analyst, as a trusted advisor, advises many individuals in many roles within the organization. They advise inside and outside of software development and process improvement projects. They advise on topics of business needs and perspective, technical constraints, data, business processes, architecture, communication needs, requirements, user acceptance testing, solution validation and more topics. They use numerous techniques and models to bring shared understanding of these topics across the project team and organization. So when interacting with anyone within the organization, or as someone in one of these other roles within the organization and interacting with a Business Analyst remember the Business Analyst’s duties as a trusted advisor.

The Value of Business Analysis: Storytelling

Written by Aaron Whittenberger on . Posted in Articles. 95 Comments on The Value of Business Analysis: Storytelling

One of the main duties of the IT Business Analyst, or Business Systems Analyst, is to document requirements for software development projects.  Many organizations believe this is the only role of the IT Business Analyst and utilize them only in this very narrow scope of duties.  Organizations that recognize the true strategic value that Business Analysts can bring to the organization will gain a competitive advantage in the marketplace. 

However, even if the organization defines the role of the Business Systems Analyst very narrowly to requirements documentation, those Systems Analysts can put the word “business” back into their role and show the organization the value they can bring to the table.  They can show management and the organization their value by going beyond documentation of requirements to telling the story of the project and its business solution.  Document the requirements of the project as management and the organization expects you to, but then package those requirements into a story that will tell anyone, even those unfamiliar, all about the project. So how do you start?

Business Case

The business case for the project defines the business problem that the sponsor wishes to have resolved.  It should define the benefits of the project and costs – thereby a cost-benefit-analysis, strategic alignment with organizational goals, business requirements, rough duration estimates, and if known at this time, alternative solutions.  The document is the one that the organizational project approval board reviews to approve and prioritize projects. These approved and prioritized projects make up the project portfolio that needs to be managed to deliver the maximum value and competitive advantage to the organization.  This is another value of business analysis, but that is a story for another day.

Define the True Business Need

Often, symptoms of the true business need or problem are included in the business case.  They are often statements of business stakeholders, what they experience in their work, or their pain points.  This is where the Business Analyst will ask “Why” to drive to the true business need.   Once you get to that true business need, you should also define the contributing conditions that are causing this business need.

Scope

It is true that the Project Manager defines and manages project scope, but the Business Analyst defines and manages solution scope.  Solution scope may be defined more narrowly, or more widely than project scope.  There may be multiple components to the solution to a project; each component will have the scope of that solution.  Solution scope may become wider than the project because the solution interacts with downstream systems.  When you tell the story of a project, you must mention the scope of the project and the solution.  These may be links to scope documentation, but should include more definition that is learned during the project.

Related Article: The Power of Story in Business Analysis

Requirements and Business Rules

Business rules are defined prior to project initiation.  Define stakeholder, solution, transition requirements and business rules during the discovery phase of the project.  These may be defined in multiple documents like a Business Requirements Document, Functional Requirements Document, System Design Specifications, or documents of other names.  Include any assumptions, constraints and dependencies related to those requirements.  Defining these requirements and business rules is the main duties of the Business Systems Analyst and should be included as the meat of the requirements package.

Business Glossary (Glossary of Terms)

An often missed part of a requirements package is a glossary of terms important to the project.  These are often business terms for the business unit(s) for which the project is to deliver a solution.  For product or software project, a technical team is assisting to deliver the solution to the business unit(s), and may not be familiar with the business terms of that business unit(s).  As noted in the introduction of this article, the requirements package should tell the story of the project to those unfamiliar with the project; therefore a business glossary is necessary to ensure your audience understands the package.

Pictures

A picture is worth a thousand words.  They also help the audience consume and understand content much quicker than text.  This should start in the scope section with some type of scope diagram, such as a project functional decomposition or context diagram.  There are several business analysis techniques that deliver a picture or diagram to its audience; these include business model canvas, data flow diagrams, data modeling, decision modeling, mind mapping, organizational modeling, state diagrams, process flows, and prototyping to name a few. Any picture, model or diagram developed during the project should be included in the requirements package.

Use Cases

Use cases are an effective business analysis technique to understand the interaction between an actor, or actors, and a system.  Use cases can be used to highlight a specific process within the scope of the solution to help the audience understand the specifics and reasons for the process.

Lessons Learned

The project team learns a lot during the discovery phase of the project.  Some organizations may call this the analysis and design phase(s) of the project.  These lessons are usually learned after the creation of the business case and scope documents; and therefore, should be included in the requirements package.

Why?

Hopefully by now you are asking yourself “why would I create this one all-inclusive document in addition to all the other documentation created during a project?”  It may even sound to you like duplication of effort or documentation, and I hope you don’t dismiss it as such.  The value of creating this one package was outlined in the introduction to this article – to tell the story of the project.  It should tell someone unfamiliar with the project, or business unit(s) involved, all about the project, its purpose, scope, business problem, requirements, and solution. 

As a person unfamiliar with the project, how would you find out these things about the project?  How would you know what documents to read? In what order would you read these documents?  The requirements package wraps all this documentation into one neat package for easily readability and shows in the order that documentation of the project should be read in order to know what happened during the project.  This is how you tell the story of the project and increase your value as a business analyst to the organization.

From the Archives – The Value of Business Analysis: Assessing Organizational Readiness

Written by Aaron Whittenberger on . Posted in Articles.

Originially Published 10/27/14

One of the key roles of Business Analysts in the solution implementation process is to assess the readiness of the organization to take full advantage of the new solution. This is the role in which the Business Analyst acts as a Change Agent in the organization. Whether this is a software enhancement, new system implementation, business architecture, business intelligence, data, business process, product change, or change implemented by a customer, supplier or regulator, effective communication of the upcoming change to all affected by the change is important to preparing the organization to capture the expected benefit of the change.

The Goal

The goal of an organizational readiness assessment is to make sure that all affected parts of the organization, inside and outside the organization, is ready for a change that is about to take place within the organization. Effective communication is the key element in informing the organization that a change is on its way. The communication plan should include a description of the change, why this change is necessary and being made, how it will impact all the parts (business units) of the organization and the necessary steps of organizational change to prepare for the change. When the change is big enough, simple communication may not be enough to prepare the organization for the change, and training requirements need to be identified.

External Initiated Change

Sometimes a change is initiated by an external organization or agency that impacts your organization. This may be a customer, supplier or business partner that makes a change for their organization that impacts yours; such as they change a system interface you use to get information to or from them, or they change a business process that impacts your processes. Sometimes this is a regulatory agency that enacts a new legislation or guideline that your organization must conform to. This mostly impacts organizations in heavily regulated industries such as financial services, pharmacy or biotech.

Internal Change Affecting Others

Your organization may make a change of its systems or operations that affect your customers, suppliers or business partners. Your communication plan must extend beyond the walls of your organization; you must inform your business partner(s) of the upcoming change, timeline and the expected impact upon their organization.

Internal Change Affecting Only Your Organization

Then there is the change that affects only your organization. Whether this is a system change or operational change, effective communication throughout the organization may determine the success or failure of the change. It may not be that the solution or change was bad or inappropriate for the organization, but the acceptance of the change was not successful. This could simply because affected business units were not informed or prepared for the organizational change; or possibly just not prepared in time for the change.

Elements of the Organizational Readiness Assessment

When assessing the readiness of the organization for an upcoming change, you must assess the organization’s culture, operations and impact of the change on the organizational units. Proper assessment of these elements will give a full picture of the state of the organizational preparedness to make the necessary change to use the new solution.

Culture Assessment

Assess the beliefs, attitudes and feelings of the affected people within the organization and their willingness to accept the proposed change. The goal of this assessment is to determine whether the affected people understand the reason for the change, whether they believe that the change will be beneficial to them and the organization, and they understand why the change is required. So, in general, you trying to determine if the people affected by the organizational change want this change to be successful.

Operational Assessment

Assessing the organization’s operations determines whether the organization is able to take advantage of the new capabilities of the change, and evaluate whether the people within the organization are prepared to make use of the new solution. Determine if training is necessary and has been performed, whether new policies or procedures have been defined, whether IT systems are in place to support the new solution are in place, and whether the solution is capable of performing at the required level to give the organization the expected benefit.

Impact Assessment

Impact assessment assesses whether the people within the organization understand how the change will affect them. Some things that need to be examined are the functions, location, tasks and concerns of these people and the impact of the change on these things.

Transition Requirements

From this organizational assessment you may be able to identify transition requirements; capabilities needed to get from the current state to the new solution. Once the new solution is implemented these capabilities are no longer needed. Training is such a capability. Training on a new or enhanced system, new procedures or business process may be necessary, but once everyone affected is trained continual training is not necessary. For a system migration, it may be necessary to migrate data from the old system to the new system. Once the data is transferred, it will not be necessary to perform that function again. You may have manipulated servers or system communication channels to move that data more easily and quickly. Once the data is migrated, you may remove those capabilities.

Implementation Plan

The organizational assessment may identify transitional requirements, and these may become part of the Implementation Plan. The implementation plan is the plan for implementing the new solution, or how we get from current state to the new solution. The implementation plan will identify the culture, operational, systems and stakeholder changes that must be made to make full use of the capabilities of the solution being implemented. This is the essence of the organizational change; the execution of the implementation plan takes the organization from its current state through the changes necessary to prepare for the main organizational change to take place.

Conclusion

Changes within organizations aren’t just made, they are planned then executed. Assessing the state of the organization and the steps the organization must make, on a culture, operational, technical and stakeholder impact level is necessary to ensure that the organization will gain the most benefit from the new change solution. Proper organizational readiness assessment will help ensure that the organization is prepared to implement a new change solution for the organization and take full advantage of the new capabilities of that solution.

Don’t forget to leave your comments below.