Skip to main content

Tag: Best Practices

Good Practice, Best Practice and 1984

George Orwell got it

Whenever I hear the term “Best Practice” I think of 1984. Not the year, the novel. George Orwell tells of doublespeak, the language of the oppressive state. In doublespeak meanings are reversed: “War is Peace”, “Freedom is Slavery”,” Ignorance is Strength” and so on.

Words are powerful, as Big Brother knew, and repetition can change meaning. So it is with “Best Practice” which now really means “Mediocre Practice”, since it isn’t what “The Best” are doing merely the average.

But that isn’t even what I dislike most about the term. Worse is the implication that the pinnacle has been reached, after all what’s better than the best? So by a combination of repetition and implication mediocrity is now installed as the most desirable state.

IT is still growing up

Information Technology as an industry is in its infancy. It started in earnest fewer than 60 years ago. The reality is we have very little idea how to create and operate efficient, robust and usable software that meets the need of our users.

In another 60 years people will look back at the primitive state of our tools and methods and laugh, just as we now laugh at early attempts at medicine – think leeches! We try to make ourselves look respectable. We copy ideas from mature industries like architecture and engineering. But the reality is that IT projects are still regarded as failures 60-70% of the time.

Calling what we do today “Best Practice” is so wrong it’s not even funny. I know it’s just marketing, but as Orwell knew, words are powerful and what starts as a harmless phrase soon comes to represent truth.

Good Practice

So how do we change this? First we stop using the term “Best Practice”. When you find yourself reaching for this phrase, substitute “Good Practice” instead.

“Good Practice” is always worth striving for, and does not imply that any sort of pinnacle exists. It’s not complacent. It’s open to change and improvement and constructive criticism is welcomed. There is recognition that improvement is always possible. There is always room for something better.

If I’m still working in IT in 60 years, there will still be “Good Practice” – although it won’t look anything like what we do today. Hopefully we’ll also have left the whole idea of “Best Practice” behind us – with the leeches.

Don’t forget to leave your comments below.

Is a Business Analysis Center of Excellence Still Relevant?

As of this writing, it is the middle of 2014. Information technology is exceedingly more and more sophisticated, business is conducted with highly complex and macrotized operating models, information is stored in petabytes, and becoming “lean” and more “agile” is not just a desired operating mode or mantra but it is de rigueur for most companies; especially when these entities engage in mergers and acquisitions in order to maintain or amplify a competitive edge. The back office backdrop is no less significant. The drive for performance and operational output in the analysis, development and marketing of new products and services require increasingly more dependencies on the commoditization of information, domain knowledge, operational subject matter expertise and engagement of consultancy services.

The business of Business Analysis training and certification programs has taken notice of this and is responding to the above influences and pressures as well. Reliance on these consortiums is at an all-time high. The ubiquitous International Institute of Business Analysis (IIBA) remains outstanding with its business analysis certification program and now the Project Management Institute (PMI); an organization more known for its project, program and portfolio management standards, is offering a Business Analysis certification program of their own. Other organizations with an educational template are also experiencing a surge in business with requests for training services for the business analyst neophyte as well as the continuing education choice of the seasoned analyst practice professional.

The message is clear. As enterprises drive to maximize efficiencies and mission execution, business analysis as a service is not only needed but it is an equally critical component in the orchestration and delivery of business. However, if business analysts are still the primary content delivery arm of all project initiatives, they need to not only have a support structure to develop and raise competencies but the structure itself needs to be thoughtfully positioned to serve the organization as a whole in a capacity in par or commensurate with other strategic corporate units. This center of focus is both tactical and strategic. The tactical addresses the management of the practice of business analysis; communication of standards and methodologies, assessment and use of requirements management tools and the management and resource distribution of business analysis as a service. The strategic side is positioned to develop and expand on domain knowledge; analytics, enhancements to business process improvements, and to serve as a valuable research area for embryonic corporate initiatives. This is where a well-structured BA CoE comes into play.

BA CoE’s, in one form or another, have been around for over two decades. This longevity may very well speak for itself as this is a very long time given today’s appreciation and variety of methodologies, and the technological developments to support them. Much of the discussions around BA CoE’s however have remained static. While other disciplines have modified their approach to continue to be of value; allying their tactic to compliment the focal points of a company, the dialogue around business analysis and BA CoE’s has remained limited to the subject of process. So the challenge then is, how to best articulate the very real, quantitative and measurable value and impact of a BA CoE to a company. Given the business complexities faced by many organizations today, the necessities to make every dollar count, and the speed at which decisions need to be made; how to ask for a new cost center or staffing or capital dollars or yet another re-organization to realign an existing BA CoE or accommodate a new BA CoE. How to elevate the discussion above the narrative of a costly BA CoE for the purpose of just developing competency framework and of policing the delivery of “quality” requirements?

With perhaps the exception of those overnight booming “dot com” companies, all businesses struggle with improving the “bottom line”. There is always that delicate dance between capital and operational expenses, allocation of funds and budgets for new initiatives versus business as usual projects, and of course those expenses that are a must in order to keep the lights on and the doors open. Apply portfolio management of projects to any of these areas and at times, management of any of these financial responsibilities becomes an exercise in prestidigitation dexterity just to keep up with the speed and demands of the business enterprise. There are financial benefits projections, P&L and G&A documentation, SVA’s, earnings on project equity, capital utilization…etc. None of these terms and areas are new ways to manage corporate expenses and initiatives. However, the intense focused attention and the inordinate amount of time spent to manage these areas, is. Herein then are the problems / opportunities to move a BA CoE out of the value-neutral areas of process and methodology and into a productive, sustainable cost reduction and service delivery role.

There are at least three domain spaces where a properly realigned BA CoE could deliver cost-saving opportunities and benefits that can be realized in the short and long term. I have introduced some of these concepts already but will provide additional details here. These new added dimensions by the way are in line with and complimentary to the current historical role attributed to BA CoE’s.

Business Analysis as a “Service” – As mentioned at the beginning of this article, the current business climate and competitive atmosphere is such that companies feel compelled to reduce cost whenever possible in order to minimize expenses, appear fiscally responsible to shareholders or to flatten the organizational structure in order to realize a desired financial benefit; a financial benefit that hopefully translates into funding for a host of new initiatives. Many of these cost-reduction strategies are commonly applied to minimizing or replacing the labor force of full time employees with temporary allocation of contractors. This is a very common go-to tactic. However, while this scalability method makes sense in the short term and for those unique projects where the knowledge base may not exist, it is not an effective long term model for all companies, projects and corporate programs. As a result, the presence of contractors at times can account for over 70% of the business analysts and project management in almost any given organization. Apply the cost differential factors between temporary resources and internal full time resources and it will not require an advanced degree in macroeconomics to understand where the financial over-commitments will be. Additionally and in the long run, this not only ends up representing an enormous drain on the company’s operating budgets but a significant domain knowledge loss as well to an organization once these resources move on to other engagements and possibly with competitors.

A BA CoE, in addition to performing its role as a practice leader in a company, can help to mitigate project cost by operating as a resourcing partner. Working collaboratively with business unit leaders, it can help with project readiness and assessment of required analytical skills. It can source projects with the necessary talent from a pool of highly skilled and matured company BA’s.
In this capacity, it can provide BA resources to the enterprise using a scalable consultative service approach, with the benefit of promoting requirements standardization, methodology and retention of domain knowledge. In this form, the BA CoE provides a clear direction for all business analysis work by using accepted best in class and best-practice methods to deliver high quality work in a consistent, predictable and repeatable manner; especially to areas challenged by the lack of these resources. It can also ensure the work will be performed with the critical knowledge of tested processes and methodologies. These resources would be full time associates thereby retaining and leveraging any acquired knowledge for the future benefits of other engagements. When absolutely needed, the BA CoE can provisionally scale up to accommodate any high demand for resources. The BA CoE would recover the cost of resourcing and departmental staffing through each project engagement. The shift in resource allocation exempts business segments of the need to sustain staffing beyond the absolute need thereby affording better operational budget management. How much should a BA CoE staff for, is solely driven by the needs of the organization. The financial benefits of this model, when exercised and extrapolated across the enterprise can be staggering. This is a simple mathematical exercise; the customary costly use of temporary staffing with no long term value and no commitment to the organization versus the effective repurposing of internal, known and skilled resources at considerably less cost with the added amortized value of knowledge retention.

Requirements Management Tools – This is an incredible opportunity area where a BA CoE can demonstrate additional and critical value to any organization. Many companies are still relying on the use of productivity tools that have been around and virtually unchanged since the eighties to manage the thousands of project artifacts across departments, business units and lines of business. Think about this, if Word and Excel are the productivity tools of choice in your company to manually manage and communicate requirements today, you are using tools that were commercialized by Microsoft in the mid-eighties – three decades ago! Aside from the fancy graphical user interfaces they present today, very little in concept has changed since Word 1.0 and VisiCalc – yes, this is the precursor to Excel.

The assessment and valuation of the many tools available in the market today to aid in business analysis and requirements management is no less significant than the commitments companies make to invest in technologies to manage corporate finances, development of new software and new product releases. Millions if not billions of dollars are invested yearly by companies today in new market ideas. Given the complexities of today’s project portfolios and programs, the expected ROIs, the operational expenses to support large and complex proposals and the dependencies on costly consultative assets to make it all happen, is it not about time we enter the twenty first century with twenty first century technology to manage and communicate business requirements in line with the corporate vision?

I am not advocating technology for the sake of “the technology” or any particular requirements management software. I am however, in strong favor of investing in the most robust software that can meet and grow with the demands of the organization. I am encouraging the use of any software that can facilitate collaboration across the enterprise of any given company, provides the full measure of all that can be considered as requirements; Textual, Use Cases, UI Mock-ups, diagrams in native form, data or domain mapping…etc., The creation and cataloging of reusable artifacts…etc. These types of application software will accelerate development, compress timelines, produce better outcomes and ultimately save companies millions of dollars in operational expenses. Yes, the old saying “a fool with a tool is still a fool” is still worth remembering but is it not equally foolish to ignore benefits, savings, the bottom line purpose of what needs to be accomplished, the how and the when? How long can any company continue to expose itself to the inherent risks and expense of managing valuable information with hundreds of thousands of disconnected Word and Excel docs?

The Strategic Management Office for Business Analysis – This is probably too ostentatious or presumptuous a title for a BA CoE but I am trying to make a point. Every now and then; year or as a result of, or in preparation for a reorganization effort or a new president or CEO/COO/CFO, companies will spend millions of dollars in organizational capacity readiness, maturity assessment or project management maturity studies. The monies invested likely support companies specializing in these fields who in turn use supplemental materials likely developed by internal resources within the hosting company; vis-a-vis business analysts and other like resources. To add additional relevant observations, when these organizations search themselves for temporary talent to support these engagement it is not unusual that these companies will use these very same type of resources, with the same skills currently present within the contracting organization. These resources may in fact come from other hosting organizations, who through some disillusionment or lack of recognition seek employment of this type with companies that are appreciative of their talent.

If the above scenario appears too implausible or fancy or un-realistic, consider then the very common occurrence of a new project undertaking. A new product or service is to be advanced. Funding is acquired, staffing is committed and project timelines are developed. It is very likely that due to timing considerations; time-to-market concerns, decentralization of services, lack of or an unavailable documented experience, the project will commence as if it is a brand “new” endeavor. Given the benefits expected of this “new” program or product, the prospects are set high for a quick turnaround and with equally high expectation of realizing the expected ROI; all with an exceptional amount of pressures to deliver the project. The likely course of action for this project is to live with the limited amount of time to “analyze” the effort with the hope of mitigating the issues at engineering and deployment time; a well-known common and expensive approach. Had the organization had the benefit of the strategic management office described above it would have had the benefits of resources, reference libraries, domain knowledge expertise and the support structure to deliver the project within the expected budgets, ROIs and with minimal rework and defect remediation.

It cannot be overstated. A well-defined and structured BA CoE in the twenty-first century will offer significant cost savings benefits and opportunities for any company who chooses to improve productivity. These advantages may be in the form of improvements to estimated project ROIs, better cost control of resources or helping the organization to realize new revenue cycles due to the expanded prospects brought about by the existence of these knowledge domain centers. Meaningful appreciation of project management cannot be realized solely by the manipulation of project timelines, financial projection devices and dependencies on “the technology”. It requires the services of Business Analysts – the content delivery arm for every project. The reliance on external temporary workforce augmentation services comes at a premium, impacting project budget considerations, time spent on training outside resources and the eventual loss of domain knowledge when these resources leave an organization.

The strategic and quantitated value proposition of a BA CoE can be measured. It can be measured by the quality and success of projects, the savings brought about by the smart use and positioning of resources, the consistencies of work enabled by tested standards and methodology and the effective use of technologies to bring it all together. Technologies that will allow for the creation and use of centralized requirements artifact repositories, enterprise-wide views of all analysis artifacts, efforts, the relationships and dependencies of projects to one another as well as the impact to new initiatives. The amount of domain knowledge the BA CoE will accumulate with each successful business engagement is another area; acquired knowledge that can be leveraged again and again, to manage and maximize project speed-to-market. Another area is the direct or indirect correlation and alignment of a BA CoE to key corporate priorities and so on. Is a Business Analysis Center of Excellence (BA CoE) still relevant? You bet; now more than ever.

Don’t forget to leave your comments below.

Business Analysis: Sharing Your Knowledge: Why and How

Often, through their normal daily work the business analyst learns new knowledge about systems, business processes or the organization as a whole. In doing business analysis tasks on a daily basis, a business analyst investigates systems; whether through documentation analysis, interface analysis or interviews with system users or subject matter experts (SME), they learn how systems operate and how the business uses the system(s). Business Analysts are often called upon to document business processes, so they investigate those business processes through interviews or surveys of those involved in the process. Through Situation Analysis, Capability Gap Analysis, Feasibility Studies, SWOT Analysis, Market Research or Organizational Change Readiness assessment to implement a new project solution the business analyst learns about their organization and the business environment in which it operates.

All too often what happens when the business analyst leaves the team or organization is all that learned, and now tacit, knowledge leaves with them. Then comes the unpalatable task of replacing the business analyst and bringing the new person up to speed with the team. What can never be regained is that knowledge that left with the previous business analyst. Wouldn’t it be great to keep that tacit knowledge?

As the exiting business analyst how can you leave that knowledge with the team as you move on to other opportunities, especially when those opportunities are outside the organization? Do you want to spend the last two weeks on the team trying to hurriedly document all your tacit knowledge? Where do you store it; in what format? Let’s look at a better way.

An Internal Body of Knowledge

An internal Business Analysis Body of Knowledge is a centralized, electronic knowledge repository from which the entire business analysis team may draw knowledge. Centralized to one business analysis team or across the organization; who is this knowledge base to serve. Once you determine who your customers are, you can determine where to store this knowledge base to be centralized; and you can consider such things as security and access. You can determine if this should be stored on a shared network drive, SharePoint or another document repository.

Start from the beginning

Don’t wait until your final week or two in this role to try to leave all your knowledge with your co-workers. Start from your first weeks on the job. As you investigate and learn these systems, business processes and the organization start documenting what you learn about things. It is very difficult to document years of knowledge in your final week(s) on the team; so start soon after you join the team. Document as you learn. This also helps to ensure that important items don’t get forgotten.

Start Small and Grow

Egypt wasn’t built in a day, so don’t feel that you have to build an entire knowledge base in a week. If you start soon after you join the team then you won’t be rushed to build your internal body of knowledge in a week or two. You can build it over years of learning. Start from the first system or business process that you investigate. Document one system or business process and store that in your centralized place. There is your start. Add each system, business process or piece of organizational knowledge you learn while you are in this role and watch your body of knowledge grow. As the knowledge repository grows, you build the structure of the repository.

Start Yourself

You can bring the idea of a centralized knowledge base to your team and try to get buy-in; or you can just start yourself. You may have to determine what the team or corporate culture is to determine if you ask for permission or beg for forgiveness. As a consultant, it is my ‘value-add’ that I provide my clients. I build my internal body of knowledge and as I leave the team I show the team the knowledge I am leaving them.

Invite Others to Join In

Once you have the knowledge base started and others can see the value, invite them to add their knowledge to yours. This can grow the knowledge exponentially. Obtaining their buy-in is much easier when you can show them the value.

Get Started

So now you know what an internal business analysis body of knowledge is and have a concept of how to build one…get started. Determine who you wish the knowledge base to serve, determine where to store it and get started building it.

By building an internal business analysis body of knowledge for a team or organization that you will eventually leave; face it we all leave at some point whether by choice, retirement or other forces, you can leave behind business, systems and tacit knowledge you have built up over time. The great advantage of starting early is that you don’t have to hurry up, remember everything and build it all in a short timespan as you prepare to leave the team. For a consultant leaving a team, this is a great ‘value-add’ to provide for your clients.

Don’t forget to leave your comments below.

Productivity-Killing Monsters of Requirements and Tips to Slay Them

As a Business Analyst or Project Manager, you are on the front lines of bringing products to market that build value for your business. If you’re like most BAs, however, you spend too much time reporting status, explaining context and tracking decisions. From listening to you over the years, we’ve started the list by identifying six of the biggest challenges—or monsters—that BAs and PMs face (see list, below) but many other monsters lurk out there, slowing down your project and throwing obstacles in your way.

monsters

Example Monsters

Swoop Monster

This executive monster comes to you at the last minute with critical feedback you asked for weeks ago. Right when you’re about to move forward, she’ll swoop in to mix things up; chances are, Swoop results in more work and less time to get it done.

Rework Monster

The Rework monster pops up months after you’ve made a decision and moved forward. He wants all the details, asking you to prove who decided what was decided, when and why. Guess what happens next? You get to redo something!

CYA Monster

The CYA monster has selective memory and doesn’t remember that conversation where you both agreed on a new direction. Do you have the backup necessary answer this monster’s detailed questions?

Missing Monster

This monster is an essential contributor to your project, with a long history on your team and an ironclad memory. This monster is great… until he suddenly disappears forever with all that intelligence.

Meh Monster

Your finished product lands with a resounding… “meh” from this monster. He was expecting x, y, and z, but you delivered q, r and s. All that work you did turns out to be based on mismatched expectations so the best you could deliver is disappointment.

Cog Monster

The Cog monster blocks you from knowing the whole project, treating you like a task rabbit. She thinks as long as you do your part, and every other cog does theirs, the whole product will hum. Cog monster doesn’t understand the importance of providing context so that everyone knows what is being built and why.

Tips to Slay These Monsters

  • Give management better visibility and a continuous feedback loop to address issues before it’s too late. Be transparent and open for feedback at all phases of the project, and have frequent check-ins to get reactions early. If your team and executive staff are in the same office, this is easier to accomplish.
  • Provide full context of every decision so everyone understands the scope of the project and why. Cog monsters need your help seeing the value of context in empowering people to do their best work. This applies upstream to your stakeholders and customers so they understand what they’re getting and it applies downstream to your design, development and QA teams so they know exactly what to build and to test properly.
  • Embrace changes intelligently by connecting the dots, quickly assessing the impact and communicating updates to the right people involved automatically. As you know, we can’t talk about requirements without talking about change!
  • Break large, complex projects into smaller manageable parts, and let people filter in on what’s relevant to them. Manage project scope item by item to get work done. People naturally work on a list of a few items at a time. It’s how our brains work and we’re more productive that way.
  • Be proactive. People have selective memories. We all remember what we want to hear. What stakeholders forget is the additional things they add along the way or that you’ve had to reprioritize features as the scope evolves over time. Make sure everyone approves of the trade-offs resulting from the decisions.
  • Collaborate. New tools for managing requirements and the product delivery process can house the conversations, comments and decisions in the same place where the work takes place. Context is captured, reviews are public and nothing stays in someone’s head. Rethink the document-driven, meeting-heavy process and shift to a more modern way of working

Don’t forget to leave your comments below.

Oh…How I Wish I Knew This Before!

A few years ago, I had shifted with bag and baggage to the US. I thought that the upcoming project would consume me for at least a couple of years. Alas, that was not the case. I returned home in five months. Well, I don’t even want to begin to think about the financial and emotional set back that my family and I had to endure!

Why did this happen? The easy answer is always, “Oh! you know, the customer was totally ill-prepared. They did not even have the business case for the project and they had already spent $1M+. Can you believe that? Ultimately the CEO found out that there was no business case and revoked funding.” But this was only one of the reasons. There were several others. Among the others, one of the reasons was, well, me! I might have been the reason for the project getting scrapped!

You see, like in every project, there were two critical stakeholder roles for this project – the Sponsor and the Solution Owner. The sponsor was the head of IT. He controlled the budget. The solution owner was a director of a business division and he controlled the solution’s features. In most projects, these two roles are played by the same individual. But in this project, these two roles were played by two different individuals.

The PM, the Solution Architect and I were clear – go to the sponsor for budget, estimate approval, release plan and timeline. “Please the sponsor” was our motto. We went to the solution owner only for requirements sign off and kept him out of the loop for discussions on release planning. Here lies the problem!

These two individuals acted based on completely different set of motivations – having just got out of the debacle of a long drawn, several times over budget project, the sponsor wanted to show quick wins by having shorter release cycles, which meant that the budget per release was very limited and thus the features we could accommodate in a release was limited. The solution owner, on the other hand, maintained that each release should be of value to the end users. There is no point in releasing something which the end users would find unexciting. For him, the definition of quick win was not just to make a release, rather to make a release that would win accolades from the end users.

You may imagine what happened next – the sponsor and the solution owner never saw eye-to-eye. That they belonged in two different organizational units and did not have to regularly communicate with each other only exacerbated the situation. I would work with the PM on developing a release plan, estimates and project plan. We would then take it to the sponsor. He would look at it and instruct us to reduce the number of features and hence the estimates. We would do that. He would then approve the release plan. I would then go to the solution owner, who would look at the release plan and literally go ballistic. I would plead helplessness and indicate that I was at the mercy of the sponsor. He would care for none of that.

Eventually, I raised both my hands. I said, you guys work with each other and resolve your differences. Well, I’ll tell you something. They did resolve their differences. They had the project scrapped!

Was it my problem that the sponsor and solution owner did not get along? Is there anything that I could have done better? For both questions the answer is a resounding “Most certainly!” If only I had anticipated this tussle between stakeholders! If only I took a more proactive and a hands on approach to diffuse the tension between these two stakeholders. If only, if only…now do you get how I was one of the reasons for the project getting scrapped?

What could I do better? Stakeholder Analysis is a best practice that every BA must have mastery over. Alas, I studied this concept only after I returned from the US feeling like a hapless victim.

The purpose of stakeholder analysis is to analyze the interest and influence of each stakeholder and customize our collaboration strategy with each stakeholder with the sole intention of minimizing the adverse impact on the delivery of the solution.

Stakeholder Analysis enables the BA to deal with stakeholders as a matter of choice rather than chance!

So, let’s talk about stakeholder management:

Who is a stakeholder?

Stakeholder is anyone who is directly/indirectly, positively/negatively impacted by the problem and/or its solution. It is possible that someone is ‘positively’ impacted by the problem, in fact they might thrive and flourish inside the problem.

What is Stakeholder Management?

Stakeholder Management is about customizing collaboration strategies to suit the temperament and background of each stakeholder with an intention to “minimize the any adverse impact on the progress of a project” that could caused by a stakeholder.

Step 1: Stakeholder Identification

The first step in Stakeholder Management is obviously identification of all stakeholders. This activity begins as soon as the business needs are identified.

It is important, well, to make sure that all relevant stakeholders’ views have been considered in building the solution. The BABOK lists various stakeholder roles that can be used to identify stakeholders. But this is easier said than done. For example:

  1. Consider the stakeholder role ‘Regulator’. Most of us assume this to be the macro regulatory bodies like SEC, SEBI, FDA, TRAI, IRDA, FSA, etc. But somehow we forget that PMO of an organization is also a regulator – they regulate what, how and when project deliverables need to be produced.
  2. Consider Enterprise Security team. They regulate access to all ‘Applications’ in the enterprise, including the one that you are defining requirements for. Not only that, they also dictate security related requirements.
  3. Consider Sponsor – the one with the money is the sponsor. We all know that. We assume that the sponsor needs to be pleased all the time. Well, this is not true always. It is not JUST the sponsor that needs pleasing…there are other stakeholders. One of the most critical stakeholders that need to be closely managed is who I call “Business Owner” a.k.a Solution owner. (The BABOK does not call out a separate stakeholder role called solution owner. I assume they include this in their Domain SME.) The Solution Owner decides what features and functionality should the solution provide and also has a say in release planning (i.e. when does which feature become available in the solution. Fair, right?) Normally, there is one individual that sits in the roles of both Sponsor and Solution Owner. This is the best case scenario. The troublesome scenario is when these two roles are played by two different individuals, like in my case (described earlier).

Step 2: Stakeholder Analysis

The second step is stakeholder analysis. This comprises of two parts – understanding a stakeholders ‘interest’ and understanding a stakeholder ‘influence’. Let me dwell on these two points:

  1. Stakeholder Interest

    It is important to understand stakeholder’s interests because it gives us some indication on how much would the stakeholder care about exercising whatever influence s/he might have. Interest is a function of two factors – change appetite of the stakeholder and impact of the solution over the stakeholder.

    • Change Appetite is the disposition of the stakeholder towards the change. In other words, to what extent is the stakeholder willing to change.
    • Impact of the solution is to what extent will the solution force the stakeholder to change

    Stakeholder Interest is determined as follows:
    praveenfeb4

    Notice that if the Change Appetite is Low and Impact of Solution is High, the stakeholder will have a NEGATIVE interest in the project, which means that the stakeholder will not hesitate to scuttle the progress of the project or even kill it, provided s/he has adequate influence.

  2. Stakeholder Influence

    Stakeholder Influence is very simple. It is the degree to which the stakeholder can sway decisions to his/her line of thinking and impact the outcome of the project.

Step 3: Stakeholder Map

The third step in Stakeholder Management is to develop a visual model of stakeholder’s interest and influence, which is called a stakeholder map. It looks like this:

praveenfeb4 2

Each stakeholder gets assigned a quadrant, with the relative location in the quadrant indicating the extent of influence / interest of the stakeholder compared to other stakeholders. The RED circles indicate the stakeholders who have a negative interest.

“Okay…this is great”, I hear you saying. “Now what do I do? What significance do these quadrants hold? What is this about one stakeholder Bob moving from one quadrant to the other?”

A stakeholder map is the four quadrant Interest vs. Influence map. All the stakeholders fall into one of these four quadrants.

praveenfeb4 3

What do these quadrants represent?

The I Quadrant (top right) carries the most significance because the stakeholders who are high on both Interest and Influence are bracketed here.

But, mind you, the folk with negative Interest (the RED circles) can appear in the I and IV quadrants only…guess why?

What do I do with this map?

The stakeholder map essentially helps the BA figure out how the collaboration with the stakeholders should be.

praveenfeb4 4

I Quadrant – Manage Closely

High Influence & High (Positive) Interest

  1. Work in Collaboration/ Partnership and keep on board.
  2. Manage them closely and maintain support
  3. Refine communications to align with project goals.
  4. Leverage stakeholder influence.
  5. Use in project teams to deliver change.
  6. Reward their support.
  7. Use an interactive communication method – do not use a dictatorial tone with them. Make them feel that every idea is theirs

High Influence & High (Negative) Interest / Resistance

  1. Build Relationships when possible. Take time to know them.
  2. Understand the underlying reasons for resistance. Paint a picture of the future if things continue as is.
  3. Acknowledge their concerns.
  4. Compromise on strategy where it is possible – give and take negotiation
  5. Stand firm on principles and the need for change
  6. Involve other influencing people who are more positive in influencing them
  7. Use an interactive communication method – do not use a dictatorial tone with them. Make them feel that every idea is theirs

II Quadrant – Keep Satisfied

High Influence and Low Interest

  1. Keep them satisfied.
  2. Send regular information about project but not constant involvement.
  3. Ensure that they support the project.
  4. Target communications to align with project goals.
  5. Provide information to help them become supporters
  6. Enthuse about change and sell the benefits.
  7. Use an push communication method.
  8. Be cautious about events that can suddenly move them to the I Quadrant, i.e. High Interest / High Influence

III Quadrant – Keep Informed

Low Influence and Low Interest

  1. Manage relationship passively – not necessary to seek them out. Be courteous and genuine when they pass by the hallway or in the cafeteria
  2. Be cautious about events that can suddenly move them to the I Quadrant, i.e. High Interest / High Influence
  3. Use a push communication method – no interaction unless asked for.

IV Quadrant – Monitor

Low Influence and High Interest

  1. Consult or have a dialog
  2. Be cautious about events that can suddenly move them to the I Quadrant, i.e. High Interest / High Influence
  3. Empower them and protect their interests
  4. Consider their advice and opinions…no need to bend backwards to accommodate, unless they are really important to the project
  5. Remain in constant communication to ensure that no major issues are arising

Coming back to my situation

So, had I known the above stakeholder management method, rather, had I known its real significance, I would have realized that both my warring stakeholders – sponsor and business owner – fall under the I Quadrant. In hindsight, what could have saved the project is the following collaboration strategies:

  1. Involve both the sponsor and the business owner in all status review meetings (I used to involve only the sponsor)
  2. Facilitate communication between these two stakeholders to ensure that both of them truly understand each other’s worlds and both realize that neither is acting with any vested interest, rather, both want the best from the project
  3. Arrive at the Release Plan together, such that both stakeholders’ interests are optimally taken care of and that both understand what they are giving up, if at all, and why
  4. Create an atmosphere of trust that neither stakeholder give you any guidance/direction without the knowledge of the other.

Well…better late than never, right? I might have been partially responsible for losing the project, but I did learn a lesson from that.

Let me know what you think…

Don’t forget to leave your comments below.