Influencing without authority

rev up your internal consulting skills

How often have you met with business clients to gather their requirements only to have them provide you with their solution? And because they have already given their solution, they can’t understand why you want to spend any time defining their requirements! Or, perhaps your sponsor or business clients are at the opposite end of the spectrum. They may be overly busy, stressed-out, and distracted, and again don’t have time to define their real needs, or to articulate their detailed requirements.

Many project managers (PMs) and business analysts (BAs) find themselves facing this dilemma. Frequently, and for various reasons, we are unable or afraid to ask too many questions of sponsors and business clients to determine real business needs behind stated solutions or problems. Project time pressures also force us to produce tangible outcomes, often too quickly, and the outputs of project plans and requirements documents are rarely considered ‘real’ progress!

This paper addresses these common quandaries and provides a framework for rethinking how to handle business problems and opportunities. It makes a case for “doing the right thing” by taking a consultative approach to work that will better provide clients what they truly need and want. The framework is straightforward, yet will reduce the amount of time you hear these dreaded words from clients: “Oh, darn, you gave me what I asked for!” It offers tips on how to respectfully question key stakeholders about their real needs and provide recommendations that best meet their business objectives. All in all, the benefits of this approach are to reduce the amount of rework on projects, saving time, money, and greatly improving client satisfaction.

The Need for Influence

Influence

So, what is influence and why do we want it? Influence is the ability to sway others, to cause them to affect change. Business professionals today are motivated to do an outstanding job and to make a difference in their organizations like never before. With that desire and spirit comes the determination to influence business and project outcomes in unprecedented ways. Organizations also contribute to the phenomenon by being perpetually short-staffed, requiring people to perform many different jobs and take on additional responsibility. For example at one of our major clients, project managers typically function as program managers, and business analysts perform many traditional project management tasks.

In situations in which people must perform duties at a level higher than the authority of their position allows, conflicts and other tensions frequently arise. When PMs and BAs are expected to produce change in their organizations through projects, they often lack the authority needed to “make it happen.” However, when business partners abdicate their responsibility on projects, then later blame the project participants when projects fail to deliver, conflict and discouragement can result.

One of the ways we can influence change is to act as consultants as we gather requirements. This paper discusses how we can be consultants to the business to ensure that complete requirements are gathered and that the project outcome meets the business needs. We call that “Doing the Right Thing.”

The Scary Truth

To put into perspective the need for a better way of handling project requests, managing requirements, and ultimately making customers happy, consider these facts:

  • A study found the total percentage of project budget due to requirements defects is 25 to 40 percent and costs the U.S. economy $59.5 billion annually. “Several authoritative studies have shown that requirements engineering defects cost 10 to 200 times as much to correct once fielded than if they were detected during requirements development.” (Mead, 2005, p.1).
  • According to the same study, reworking requirements defects on most software development projects costs 40 to 50 percent of total project effort. (Mead, 2005, p.1).
  • Requirements problems are among the top causes of why projects: 1) are significantly over budget and behind schedule, 2) deliver significantly reduced scope, 3) deliver poor-quality software applications, 4) are not significantly used once delivered, and 5) are cancelled. (Mead, 2005, p.1).
  • “Poorly defined applications have led to a persistent miscommunication between business and IT that largely contributes to a 66% project failure rate for these applications, costing U.S. businesses at least $30B every year.” (IIBA, 2006, p. 6).
  • “Communication challenges between business teams and technologists are chronic — we estimate that 60%-80% of project failures can be attributed directly to poor requirements gathering, analysis, and management.” (IIBA, 2006, p. 6).
  • 56% of defects can be attributed to requirements, and 82% of all rework effort is to fix defects. (IIBA, 2006, p. 6).
  • Lack of User Involvement and Executive Support are consistently the #1 and #2 reasons for failed projects. Together, they account for 33% of the factors behind failed projects. (Standish Group, 2004, p. 3)

Barriers to Effective Project Influence

Lack of Authority

As PMs and BAs, we often don’t have the ultimate authority to ensure appropriate solutions are found and implemented which is why there is a strong risk of project rework. So, the only alternative left, then, is to try and influence without the corresponding authority. The two types of influence available to us are using our expertise (expert) and our leadership (personal power).

It’s Easy to have Influence with Authority

The Quick Influence Route

Exhibit 1 - The Quick Influence Route

PMs and BAs have control over planning, execution, and documenting/managing projects and requirements. But, as a rule, we have little direct power over the business to ensure there is adequate time for discovering requirements or to keep sponsors engaged.

To summarize this discussion on authority, BAs and PMs have little direct power and authority on projects. However, without influence, projects will probably require rework and may not accomplish their goals. At the same time, business leaders continue to be frustrated by the delays and reduced functionality of challenged projects.

Lack of Sponsor Support

It’s difficult to effectively influence without executive support. If our sponsors are too dominant or too weak, it’s harder for us to positively influence the project. There are three general types of sponsors who are the most challenging to deal with on projects:

Types of Challenging Sponsors

Exhibit 2 – Types of Challenging Sponsors

Unclear Roles and Responsibilities

If project managers and business analysts are perceived as “gophers” or order-takers, their influence could well be reduced. Also, even when business clients seem to abdicate their authority, influence is not automatically assigned to the PM or BA. Often, when PMs and BAs step in and assume decision-making, they end up “owning” the project and outcome, and often are blamed when the product does not work satisfactorily. One of the most common areas of confusion is the project charter, or project initiation type of document. When project managers or business analysts develop the charter, the team ends up taking at least partial ownership of it. With that ownership comes a level of responsibility for the project that should rest with the business partner.

Another widespread blurring of responsibilities is approving changes to requirements. When BAs or PMs control scope on a project, and approve or deny changes to scope, they assume the responsibility of the project owner. The result of this approach can range from inflexibility (which can cause lack of desired functionality) to rampant scope creep (with cost and time overruns).

Other Factors

Other barriers to effective influencing can include:

  • Company culture. Hierarchical communications and styles tend to prohibit influencing without authority.
  • Product complexity. The more complex a product, the more the PM or BA will need to have product expertise. Learning new products can inhibit the ability to influence; however, without that expertise, the PM’s credibility is greatly reduced.
  • Lack of time to meet with the right people to help clients discover and verify their requirements.
  • Lack of participation or inconsistent participation by the business. It’s hard to influence when clients refuse to take ownership for their final product.

Overcoming these Barriers

Consultative Model

What’s missing is a consultative approach. This type of approach involves working with the business to understand the organization problem or opportunity, recommending the appropriate solution, and facilitating the implementation of the solution. We call this “Doing the Right Thing” because it involves probing into the real need behind the stated need to avoid delivering products that don’t meet business needs or are difficult to use. This approach helps avoid “jumping to solutions” and dramatically reduces the “Oh, darn you gave me what I asked for” syndrome.

A consultative approach is to:

  1. Understand the Business Problem or Opportunity based on the actual business problem or opportunity, and its underlying root cause or business driver, then
  2. Recommend Appropriate Solutions, which is to say, find out the “Right Thing” that meets business needs. Finally, to ensure proper delivery, we then need to
  3. Facilitate a Workable Implementation Approach and Evaluation Measures to ensure the solution meets business needs, and will continue to do so.

Understand the Business Problem or Opportunity

Getting to the Real Situation

There are a variety of methods to understand and solve business problems, including:

  • Six Sigma has been popular lately, although it is stronger on process than on project management.
  • BPM. Various flavors of Business Process Management, also known as business process improvement, analysis, or mapping.
  • A Guide to the Project Management Body of Knowledge (PMBOK® Guide) addresses business needs mainly from a PM standpoint.
  • SARIE. A simple but effective consulting approach we use in working to do the “right thing” is based on an acronym for Situation, Analysis, Recommendation, Implementation, and Evaluation. It starts with the situation, and focuses analysis on the underlying causes or drivers behind the situation.

Whatever the approach, better outcomes will result if people follow it consistently, which requires training and organization commitment. It also requires trust between you, the consultant, and your client. There are ways to work at building trust, summarized in Exhibit 3. Some of these things we may do naturally, such as acting with integrity, but others, like establishing a communications protocol, are things you can practice.

Methods of Building Trust

Exhibit 3 - Methods of Building Trust

Change Agent as Consultant

Another way of ensuring the right thing on projects is to concentrate on facilitating the change, not owning it. In many ways, this is what happens whenever a sale is made.

Many consulting processes are based on industry-recognized sales processes. Here is our recommended consultative process, which can be directly applied by PMs and BAs to project work.

  • Prospecting
  • Qualifying and Needs Awareness and Analysis
  • Proposing and Closing
  • Follow-through and Servicing what was sold

As with any consulting process, understanding the business situation requires sincere questioning of our clients and their needs. It is the first step in “engaging” sponsors and can help in building their respect for you. Questioning is part of both prospecting and “qualifying” our clients. We need to ask good questions to discover what those needs are, as opposed to being a walking product encyclopedia where we spew forth feature after feature of our process or product.

An example of the above is a project manager at a customer of ours who spent time during status meetings with clients reading to them from the PMBOK! An approach like this is sure to irritate most business partners and risks alienating them.

Questioning Tips for Consultants
  • Probe deeply to determine what motivates our clients and sponsor. For instance, in order for us to really get at the real need behind the stated need, we would not ask an executive “what is your business need for an ERP system?”. Instead, we would want to determine the pain related to not having integrated systems. “Deeply” means asking “why” (or “what causes that” up to 5 times to get to the real needs.
  • Use listening skills well. This is essential to really understand answers. Paraphrase, clarify, summarize, follow-up, and keep probing deeper.
  • Watch non-verbals. Remember, only 7% of communication is verbal. Over half of communication is visual.
  • Ask both open-ended and closed-ended questions. Use them appropriately, employing open-ended questions to uncover needs and closed-ended questions to confirm specifics.
  • Avoid leading questions. Examples of leading questions: “What do you think about SAP?” “Have you ever thought of having a PMO?” “Have you ever thought of a web site?” Non-leading questions encourage sponsor to “open up” and reveal their needs.

In general, consultative questioning as discussed here helps to discover needs together, which helps to increase buy-in. Below are some of our favorite tools for uncovering the real business problem or opportunity.

Tools for Analyzing Business Problems

Exhibit 4 – Tools for Analyzing Business Problems

Recommend Appropriate Solutions

As we know, but people don’t buy a product for its own sake; they buy what the product can do for them. For instance, we buy certain brands of toothpaste because we want whiter teeth or less plaque, or fresh breath. Business leaders don’t want to invest in technology or project management for its own sake, no matter how compelling a discipline they are for us. The reason business executives invest in a project or new technology it is to reduce costs, increase revenues, make happier customers, etc. The solution and any alternatives we recommend should reflect their business goals and objectives.

All too often, as PM or BA practitioners, we focus on the features and functions of the products we are producing. Whatever the project, a significant amount of time is spent on defining the requirements for what the product IS (features) and what it will DO (functions). Much less time is devoted to determining the ADVANTAGE of using the new product (in other words, the benefits to the business).

The second part of our consulting model involves recommending solutions that match what was discovered in the first phase, Understand the Business Problem or Opportunity, so the recommendation is in balance with the need. Effective consultants always focus on benefits to the “customer.” For example, a benefit of a web site might be to reduce calls to the help desk, so focus on the most common types of help desk requests, and put them on the web site first.

Working with Stakeholders

Part of the consulting and “change agent” process is to respond appropriately to various types of stakeholders. Effective consultants instinctively adjust their style and approach depending on the type of client they are serving. We can do the same as internal consultants to maximize our effectiveness. Consider the 3 types of sponsors described earlier. Exhibit 5 lists various strategies for adapting to each type.

Strategies for Difficult Sponsors

Exhibit 5 – Strategies for Difficult Sponsors

Strategies for Difficult Sponsors

Exhibit 6 – Tools for Analyzing and Prioritizing Recommendations

Facilitate a Workable Implementation Approach and Evaluation Measures

An important part of the influencing process is to recognize a simple truth: even the best recommendations will go to waste if they are not accepted.

One thing that can help in assessing how well your recommendations will be accepted is to perform some simple audience analysis. As mentioned earlier, effective consultants adapt their approach to fit the audience. So, it can be crucial to categorize your stakeholders and concentrate on the ones with the most authority: those who can champion or sabotage your efforts.

Evaluation Measures

The key to evaluating a project outcome is to do it in business terms. Yes, it can be important to have project metrics such as earned value, variances from baselines, etc. But, those are project evaluations.

The SARIE method previously mentioned has separate steps that deal with both Implementation and Evaluation. Implementation typically involves a project, and normal PM methods and measurements are employed. The Evaluation portion of SARIE is meant to remind us that we need to facilitate the evaluation of our change or new product. The evaluation measures used should be determined by and meaningful to the business.

Remember to find out what the business cares about in order to link alternatives and recommendations to those benefits. As you are helping the business put evaluation criteria together, remember to determine meaningful measures of the benefits. A few typical measures include: a) cycle time of a process, b) number of inputs and outputs in a process and their cost, c) customer satisfaction, d) cost of rework (waste, scrap, defects), etc.

Tools for Recommending Solutions

Exhibit 7 – Tools for Recommending Solutions

Summary

By employing a consultative approach, project professionals can gain the needed influence to facilitate positive project outcomes. This approach combines good analysis skills to uncover real needs, plus corresponding “change agent skills” to aid in working with the human aspects of change that invariably arise in projects . The outcome is greater influence on projects and other work efforts.

The Consulting Route to Influence

Exhibit 8 – The Consulting Route to Influence

Why do we want greater influence? If we can more often facilitate clients to “Do the Right Thing,” it will lead to less rework on projects, save time, money, increase the satisfaction of those clients, and provide us with almost immediate credibility. Any good consultant would be happy with that!

References

IIBA (International Institute of Business Analysis) Alliance Training Seminar, PowerPoint presentation dated May 30, 2006, Barret, Kathleen, principal author

SEI Square Project - System Quality Requirements Engineering (SQUARE) Project), updated 5/12/05. © Carnegie Mellon University, Software Engineering Institute Principal Investigators: Mead, Nancy R., Firesmith, Donald (FY2004), and Woody, Carol Retrieved on 7/15/05, from http://www.cert.org/sse/square.html

Standish Group, 2003 Chaos Report, © 2004, The Standish Group Retrieved originally on 3/14/2004 from http://www.standishgroup.com/chaos/introduction.pdf.

Project Management Institute. (2004) A guide to the Project Management body of knowledge (PMBOK®) (3rd ed.). Newtown Square, PA: Project Management Institute.

© 2006, Watermark Learning, Inc.
Originally published as a part of 2006 PMI Global Congress Proceedings – Seattle, Washington

Advertisement

Advertisement

Related Content

  • PM Network

    Agile Assurance member content open

    By Parsi, Novid Some project teams believe agile means skimping on requirements management. They're dead wrong. When they disregard this crucial component, they put project success on the line: For 35 percent of…

  • Project Management Journal

    Project Managers' Competences member content locked

    By Saunders Pacheco do Vale, João Walter | Nunes, Breno | Carvalho, Marly Monteiro de This article investigates the individual competences of project managers through a methodological approach.

  • Project Management Journal

    The Influence of Behavioral Competencies on Project Performance member content locked

    By Gruden, Nika | Stare, Aljaž We carried out a quantitative survey to identify the importance and influence of competencies on efficient project performance.

  • PM Network

    Resist The Rush member content open

    By Liskow, Mike Do software project teams still need dedicated business analysts? I've heard this debated frequently of late. Some argue that it's more efficient for developers to collect requirements directly from…

  • PMI White Paper

    Business Analysis member content open

    When business analysis is properly accounted for and executed on projects and programs, high-quality requirements are produced; stakeholders are more engaged; the solution delivers intended value;…

Advertisement