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 TrustedAdvisor 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 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 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 other’s, this needs to be done 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?

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 fully understand 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 effects the project schedule and is noticeable by everyone, communicate roadblocks and other commitments so team members understands 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)

 

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 Enterprise Architect is considered a business analysis role, in larger and more complex organization these will be two distinct roles; therefore, I list them separately. However, realize that in smaller organization these roles may be performed by one individual. The enterprise architect will be concerned with the architecture of the solution being considered; they will be 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 to ensure 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 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 advice management on benefit 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.

 

Aaron Whittenberger, CBAP is a senior business analyst in the Cincinnati, Ohio area. He has over 28 years of business and IT experience, including 16 years of business analysis and 15 years of consulting experience. Aaron is an avid Business Analyst, Business Process Analyst, Project Manager, Blogger, Mentor, Trainer and Presenter.  He is a champion for the IIBA®, business analysis as a profession and the recognition of its practitioners.  You may connect with Aaron on LinkedIn or follow him on twitter @TheWittyBA.