Skip to main content

Tag: Career

The Transformational Enterprise Business Analyst

Why do we keep talking about the Enterprise Business Analyst (EBA)? Because it is quickly becoming the pivotal business/technology role of the future.  The EBA is a business-driven strategic partner and integrator, an enabler of organizational change, and the driver of business success.  As a strategic partner, the EBA often becomes an internal consultant – a business relationship manager at the top of the food chain of the BA profession. 

Operating at the enterprise, strategic level, the EBA engages in radical collaboration, as the Stanford University Design School refers to it.  The EBA understands that today’s complex projects demand an unprecedented amount of teamwork and cooperation among all key business and technology roles in a critical project.  Indeed, shared project leadership is replacing old project management models.  Perhaps the most valuable partnership when operating at the enterprise level is the one between the project manager and the business analyst.  

hasssept

The BA and PM work together to ensure projects are launched to bring about innovative solutions, value to the customer, and wealth to the bottom line.  All decisions are made with the customer in mind.  Changes that add value are not only welcomed but sought after.  

Related Article: The Future is Now: The 21st Century Enterprise Business Analyst

THE RISE OF THE ENTERPRISE BUSINESS ANALYST

The rise of the EBA marks a significant departure from business-as-usual business analysis.  The EBA is a strategic asset to decompose strategy into valuable change initiatives.  The EBA plugs the gap conducting the burden of analysis that is too often missing from business/technology project prioritization and selection.  

EBAs work up front and personal, in support of an investment framework based on business value.  The EBA performs the due diligence that is so often missing during project initiation. This due diligence includes competitive analysis, problem/opportunity analysis, experimentation, creative brainstorming, early complexity assessment, and captures the results in the form of a business case to propose a new change initiative.

hasssept2

TRANSFORMATIONAL PRACTICES

The EBA employs transformational practices to bring about value-based decision making and project management practices.

hasssept3

TRANSFORMATIONAL ROLES

The EBA fulfills many strategic roles, essentially putting a finger in the dike for many areas that have been woefully inadequate in organizations today, from business relationship manager to internal strategic consultant.

hasssepttext

Business Relationship Manager and Internal Consultant

As business relationship manager, EBAs fully understand the needs of the business, from vision and strategy to execution of operations.  EBAs build executive level relationships as well as relationships with lower level managers and practitioners.  They decompose strategy into valuable projects and programs.  They lead creativity sessions to ensure we conceive the most innovative solutions.  They create business cases to propose new initiatives.  They conduct competitive analysis to understand where their industry is headed.  They coach project teams to ensure the teams understand the business need and the value expected from the initiative.

Strategist

The EBA often has a seat at the table with the executive management team, participating in strategy sessions, facilitating the management team through problem analysis, alternative analysis, and opportunity analysis.

Innovator, Designer, and Architect

The EBA understands that creativity is a skill that can be learned.  Understanding and using design principles enable EBAs to lead sessions to design the transformation prior to examining alternative solutions.  Using architectural techniques, the EBA makes the future visible through models and rich pictures.

Business/Technology Optimizer

World-class EBAs stay ahead of trends within business analysis, technology-enabled business practices, and in the industry of their choosing.  However, staying up with trends is a difficult undertaking because of the amount of information that is out there; it is voluminous and can be overwhelming. The trick is to concentrate on keeping abreast of business and technology trends at a high level, and go deep in a just-in-time learning manner.  That is educate yourself on areas of interest at the time when you need to apply them to your current endeavors.  

The EBA thinks holistically about the business, the ecosystem surrounding the business, and about the technology supporting the business.  The EBA understands where the industry is headed globally, and how that will impact their organization.  In addition, effective EBAs understand the current technology infrastructure, and trends that are emerging.  Some of the contemporary areas of focus include:

  • Collaboration and productivity
  • Customer & operations support
  • Cyber Security
  • Digital, wireless, and mobile spheres 
  • Software
  • Open technology
  • Internet of things
  • Compute
  • Networks
  • Social media

Leader, not Manager

In performing all of these roles, the EBA becomes a value-driven strategic resource for the organization.  The EBA has mature influence skills, collaborating with project managers and other key change agents.  The EBA understands how to build and sustain high-performing teams.  In a given week, the EBA might serve as:

  • Strategy and Competitive Analyst
  • Strategy Executor
  • Value/Benefits Manager
  • Creativity and Innovation Enabler
  • Transformational Designer
  • Cultural Change Manager
  • Team Leader

Lead through Connections

The world is hyper-connected. EBAs leverage the collective intelligence that resides in the untapped knowledge of their network. EBAs can embrace the dynamic tension between creative disruption and operational efficiency. EBAs cultivate organizational creativity in an age of complexity.

TRANSFORMATIONAL PROJECT SUCCESS MODEL

The traditional measures of project success have been on time, cost, and scope. Even with advances in technology and the project management and business analysis professions, superior project performance remains elusive. The CHAOS Manifesto 2013 reveals that 61% of IT-enabled business projects continue to fail to meet project cost, schedule, and scope goals.

In the 21st century we need to achieve 90% of projects on time, cost and scope through smaller, incremental development of solutions. And at the same time, our focus needs to be on innovation and value. Companies that fail to innovate will get lost in the dust of agile, fast-moving competitors. So, our new project success model needs to look something like this:

hasssept4

Clearly, the business analysis profession needs to step up to the plate to close the gap in project performance, and the EBA is emerging as that transformational role. EBAs are drastically changing the way we manage projects. EBAs adopt a more holistic view of change initiatives so that we:

  • Focus on delivery of business value and innovation vs. requirements management,
  • View change initiatives holistically, understanding that critical projects will likely impact the entire business ecosystem of people, process, organizations, rules, data, applications, and technology
  • Embrace architecture and design to help temper complexity and uncertainty, and
  • Strike a balance between analysis and intuition, order, and disruptive change.

Look for us at the Building Business Capability Conference in Las Vegas in November.

i Leading Through Connections, Insights from the 2012 IBM Global CEO Study (www.ibm.com/services/us/en/c-suite/ceostudy2012/‎
ii THE STANDISH GROUP, “CHAOS MANIFESTO: THINK BIG, ACT SMALL,” 2013. ONLINE AT versionone.com/assets/img/files/ChaosManifesto2013.pdf‎ (accessed January 2014).

It’s Not Personal – It’s Only Business

As business analysts we’ve typically all been exposed to the process of a document peer review. A well-structured and dedicated peer review process is not only a sanity check to maintain healthy documentation practices; but also be a great continuous training exercise for business analysts to learn new ways of approaching their documentation and also learn from the seasoned expertise of their peer counterparts. It provides a pulse of where improvement can occur across your enterprise and provide strong evidence for where strengths exist. 

Business Analysts are by-and-large very meticulous about document review and will find the smallest error or inconsistency and use it to pull the document apart methodically piece-by-piece; leaving nothing but the draft version smeared in redline corrections and comment bubbles in the margin. It’s kind of a gift we all have. The ability to find fault in a document not our own is far easier than writing a document in which others will not find fault. 

Don’t Take it Personally

One of the most common responses to peer review critiques I have encountered in my experience is the frustration and outrage caused by the document author believing that the review comments are in some way personal. As business analyst professionals, we can never assume that document criticism is a personal attack or that the critique has been made as some form of vendetta for a previous transgression; known or unknown. As a business analyst, this is an unhealthy practice that will only cause constant frustration and tension between you and your peers and adds no value to the team or your advancement in business analytics. Opportunities for improvement come in many forms; peer review is one of those forms; even if the comments sometimes reveal difficult truths about documentation weaknesses. 

A Real-Life Example

When I first started, I was so eager to do a good job and prove that hiring me for a business analyst position was the right move; I worked tirelessly on my first assignment, dotting every ‘i’ and crossing every ‘t’. When I sent out my first document for review, I thought I did pretty well and was quite proud of the work I had done; until I got the comments back from my peers. Some were very positive; others were simply clarification questions and others were (what I thought at the time) downright mean. I received some incredible advice from my then boss (now colleague) who suggested I reassess and think about it not from my perspective, but from the reviewer’s perspective. I did this and realized that none of their comments could possibly be personal, and I was being completely irrational. I reevaluated my document and addressed the comments. Some I agreed with and corrected and others I responded to with justification as to why they should not change. My own ego, vanity and desire to do well blinded me from seeing the validity of the contributions of others and gave me the initial feeling that I had somehow failed. 

How Peer Reviews can help

Now that I have been in the analyst realm for a while, one of the things I look forward to with having my documents reviewed by peers is the experience and insight I gain from others who may have been at this game longer or have a different background or perspective that can add to my own and provide me with additional information to add to my documentation. Documentation audiences range in comprehension, so the more concise documentation is, the less misinterpretation will occur with the content of any documentation. In my years as a business analyst, systems analyst and solution analyst, I have never seen a first draft document go through a peer review without encountering some kind of comment, question, grammar correction or suggestion to content. No analyst is perfect, and no document is ever going to be perfect. Someone will always have something to say about the document; whether it is content, layout or even something as trivial as font type, there’s always a way to improve or something to elaborate on and there will always be someone who has something negative to see; even if it is minor. 

How to set yourself up for success

There are a number of steps we can take as analysts to avoid those minor criticisms and provide confidence that our documents are of high-quality the first time out; while maintaining the understanding that comments and criticism are inevitable. 

  1. Spell Check – If you’re using MS Word, it’s a button…Just click it. 
  2. Grammar Check –MS Word has a feature; it’s not entirely accurate all the time but catches common mistakes. 
  3. Make a checklist of common things people forget to change in their documents and start checking off items. Some common mistakes are:
    1. Version Number
    2. Page Numbers
    3. Revision History
    4. Table of Contents
    5. Formatting
  4. Consider your audience – Sometimes you have to tailor your document to a different level; whether higher or lower. What type of voice are you using; passive, assertive?
  5. Put your document through the process of questioning every requirement. Is it clear? Is it unambiguous? 
  6. Avoid using acronyms without first defining them
  7. Do your process flows match your requirements (if applicable)
  8. Look at your document objectively
  9. 9. Put it down for a while, do something else and revisit it. A fresh mind can lend perspective

There is no definitive list that we can put together than can aid us in writing a perfect document. While we can review our work over and over again, we will always have the potential of missing something. Sometimes it will be something so minor it’s hardly worth mentioning and other times it’s a valid contribution we must consider revising our documents, making a higher quality, more concise final product. We must remember that there is always going to be someone with more experience or someone that is a radical grammar cop or even someone who doesn’t quite understand and needs clarification. We can always do things better, and we must continuously find new and better ways to get through our work and find success. Learning from each peer review session and remembering those comments and critiques for the future, shows that we are improving and making an effort to evolve as business analysts. I am sure there are plenty of things forgotten in this article, and this topic has been well lamented in the analyst community. Through all of the perils that a document review session with our peers can present us with, we cannot allow ourselves to believe that it is ever personal. It’s not personal, it’s only business. 

Nine Key Skills That Every Good Business Analyst Needs

Being a successful Business Analyst means you have to have a variety of different skills and be adaptable to a changing environment. Every Business Analyst will bring their unique blend of skills and experience to the role, of course, but I’ve highlighted below what I think are the most common skills that a good BA will need. Feel free to add in the comments any other skills that you have found helpful in your BA career.

1. Understand your objectives.

Being able to interpret direction is important. If you don’t fully understand what and, more importantly, why you are being asked to do something, there is a risk that you won’t deliver what’s required. Don’t be worried about asking for further information if your brief isn’t clear.

2. Good verbal communication skills.

It is essential that you are a good communicator, regardless of the method of communication. You must be able to make your point clearly and unambiguously. It is also important that you know how to ask insightful questions to retrieve the information you need from stakeholders. For example, if your stakeholder isn’t a technical specialist you may need to ask your questions in plain English – avoiding jargon and acronyms. Being able to communicate information at the appropriate level is vital – some stakeholders will need more detailed information than others.

3. The ability to run stakeholder meetings.

Although using email provides a useful audit trail, sometimes it is not enough to communicate with stakeholders via email. Don’t underestimate the value of face to face meetings to discuss problems in more detail and clear up any queries. Often you will discover more about your project from a face to face meeting where people tend to be more open about discussing situations. You can always follow up a meeting with written confirmation if an audit trail is required.

4. Be a good listener.

Listening skills are key to being a successful BA. You must be able to listen and absorb information. This will allow you to analyse thoroughly the information gathered to specify requirements. It’s important that you don’t just listen to what’s being said, but are able to understand the context of what’s being said – the motivation behind it, the circumstances behind what’s being said, and even what’s not being said. Voice tone and body language can help you understand the message behind the words.

5. Hone your presentation skills.

It is likely that at some point in your career as a BA you will need to facilitate a workshop, or present a piece of work to a stakeholder or project team. Consider the content of your presentation and make sure it matches the objectives of the meeting – there is no point in presenting information about implementation methods if the meeting is being held to discuss requirements gathering. These presentations are not only for you to present information. They can also work as an excellent way to extract more information or clarity from stakeholders if you are unclear on something or are looking for more detail on a particular area of the project.

6. Be excellent at time management.

A BA must have excellent time management skills to ensure that work is completed on time and the project does not fall behind schedule. Multi-tasking is an important skill, but you must also be able to prioritise activities – understanding which are more critical than others – and concentrate on them. Remember that you need to manage your own time and activities, but you may also need to manage other people’s time if you are dependent on them for information. Make sure that they know when you need them to deliver.

7. Documentation and writing skills.

Requirements documents, reports, specifications, plans and analysis. As a BA you will be required to deliver a range of different types of documents. You will need to ensure that your documents are written in a clear and concise manner, and at a level that is appropriate for your stakeholders. Avoid nuances specific to a particular workstream as they may not be understood by all stakeholders. As an inexperienced/beginner BA, it is unlikely that you will have experience writing requirements documentation, however, strong writing skills are an excellent starting point. Experience will lead to clear and concise requirements documentation.

8. Stakeholder management.

It is essential that you know how to manage all of you stakeholders and know how much power and influence they have on your project. Stakeholders can be your strongest supporters or your biggest critics. An experienced BA will be able to analyse how much management each stakeholder needs and how they should be individually managed. Do they need face to face meetings and detailed information or are they content with high-level reports? Are they supportive of your project? Knowing the answers to these key questions will help you to manage your stakeholders and the wider project. Can you influence them directly or do you need to influence someone who can influence them.

9. Develop your modelling skills.

As the saying goes a picture paints a thousand words. Techniques such as process modelling are effective tools to convey large amounts of information without relying on text. A visual representation allows you to get an overview of the problem or project so that you can see what works well and where the gaps lie. A typical process model will have several different levels of detail to allow a BA to engage with stakeholders in a language that they understand.

Don’t forget to leave your comments below.

BABOK Version 3 vs. Version 2 – Taming the New – Guide Part 1: Knowledge Areas and Tasks

Most people in the BA field know that the IIBA® has produced an important update to its definitive Business Analysis Body of Knowledge, the BABOK® Guide. Released in April 2015, the BABOK® Guide includes major upgrades, ranging from the BA Core Concept Model™ (BACCM), to changes to most Knowledge Areas, the addition of 16 new techniques, and the addition of an all-new section containing five perspectives on Business Analysis.

By IIBA’s estimation, the BABOK has grown 50% from version 2 to version 3 and now has more than 500 pages. It has a richer and more complete set of information about the practice of Business Analysis. It also means the CCBA will have a greater amount of knowledge on which to test aspiring CBAP and CCBA candidates. Both points are good for the profession in our opinion.

Most comparisons of the two versions cover the major changes and ours is no different. However, we begin with the familiar aspects of version 2 and how they change in version 3. Part 1 features changes to Knowledge Areas and Tasks. Part 2 covers the expansion of Techniques, and Part 3 presents the two major BABOK additions: the BACCM and the Perspectives.

BABOK VERSION 3 KNOWLEDGE AREAS AND TASKS

We are starting the BABOK differences with the Knowledge Areas (KAs) and tasks instead of the Core Concept Model for two main reasons. First, most people are familiar with the KAs and their tasks, so it makes the jump to v3 a little less of a leap. Second, the BACCM surrounds the KAs and for each KA the BABOK Guide version 3 shows how the BACCM applies to it. Our view is that v3 is not as big a change as one might think when doing a KA to KA comparison.

Below is a table we compiled to show the differences in tasks. After finishing a draft we then consulted with the BABOK Guide’s table of differences and the result is shown in Table 1.

Some tasks have not changed much or at all, such as “Plan Business Analysis Approach” or “Verify Requirements. “ The task names of some 10-11 tasks have remained the same, which means roughly 21 tasks have been changed, added or deleted. There are now only 30 tasks compared with 32 in v2.

BABOK® Guide Version 2 Knowledge Area and Task Names BABOK® Guide Version 3 Knowledge Area and Task Names (additions/changes in v3)
 2.0 BA Planning and Monitoring – v2.0 tasks  3.0 BA Planning and Monitoring – v3.0 tasks
 2.1 Plan Business Analysis Approach (content for prioritization and change management moved to Plan BA Governance)
 2.3 Plan Business Analysis Activities
 3.1 Plan Business Analysis Approach
 3.3 Plan Business Analysis Governance
 2.2 Conduct Stakeholder Analysis
 2.4 Plan Business Analysis Communication
 3.2 Plan Stakeholder Engagement
 2.5 Plan Requirements Management Process  (see note for Plan BA Approach)  3.4 Plan Business Analysis Information Management
 New Task:  3.4 Plan Business Analysis Information Management
 2.6 Manage Business Analysis Performance  3.5 Identify Business Analysis Performance Improvements
 3.0 Elicitation – v2.0 tasks  4.0 Elicitation and Collaboration – v3.0 tasks
 3.1 Prepare for Elicitation  4.1 Prepare for Elicitation
 3.2 Conduct Elicitation Activity  4.2 Conduct Elicitation
 3.3 Document Elicitation Results
 4.4 Prepare Requirements Package
 3.5 Communicate Requirements
 (Note: ours is more complete than the BABOK comparison)
 4.4 Communicate Business Analysis Information
 3.4 Confirm Elicitation Results  4.3 Confirm Elicitation Results
 New Task:  4.5 Manage Stakeholder Collaboration
 4.0 Requirements Management and Communication –
 v2.0 tasks
 5.0 Requirements Life Cycle Management –
v.3.0 tasks
 4.1 Manage Solution Scope and Requirements  5.1 Trace Requirements (Especially relationships)
 5.5 Approve Requirements (Conflict and Issue Management; Approval was formerly an element)
 4.2 Manage Requirements Traceability  5.1 Trace Requirements (“Configuration Management System” becomes “Traceability Repository”)
 5.4 Assess Requirements Changes (Impact Analysis moved here)
 4.3 Maintain Requirements for Re-Use  5.2 Maintain Requirements
 6.1 Prioritize Requirements (from Requirements Analysis)  5.3 Prioritize Requirements (Moved from Requirements Analysis in v2)
 4.4 Prepare Requirements Package
 4.5 Communicate Requirements (both become part of “Communicate BA Information” in Elicitation and Collaboration)
 4.4 Communicate Business Analysis Information
 New Task:  5.5 Approve Requirements
 5.0 Enterprise Analysis – v2.0 tasks  6.0 Strategy Analysis – v3.0 tasks
 5.1 Define Business Need  6.1 Analyze Current State
 6.2 Define Future State
 5.2 Assess Capability Gaps  6.1 Analyze Current State
 6.2 Define Future State
 6.4 Define Change Strategy
 5.3 Determine Solution Approach  6.2 Define Future State
 6.4 Define Change Strategy
 7.5 Define Design Options
 7.6 Analyze Potential Value and Recommend Solution
 (Note: ours is more complete than the BABOK comparison)
 5.4 Define Solution Scope
 7.4 Define Transition Requirements
 6.4 Define Change Strategy
 5.5 Define Business Case  6.3 Assess Risks (was an Element in v2 Business Case task)
 7.6 Analyze Potential Value and Recommend Solution
 (Business Case is also now a General Technique)
 6.0 Requirements Analysis – v2.0 tasks  7.0 Requirements Analysis and Design Definition –
 v3.0 tasks
 6.1 Prioritize Requirements (Moved to Requirements Life Cycle Management)  5.3 Prioritize Requirements
 6.2 Organize Requirements  7.4 Define Requirements Architecture
 6.3 Specify and Model Requirements  7.1 Specify and Model Requirements
 6.4 Define Assumptions and Constraints  6.2 Define Future State
 7.6 Analyze Potential Value and Recommend Solution
 6.5 Verify Requirements  7.2 Verify Requirements
 6.6 Validate Requirements  7.3 Validate Requirements
 New Task:  7.5 Define Design Options
 (pulls together v2 Determine Solution Approach, Assess Proposed Solution, and Allocate Requirements)
 New Task:  7.6 Analyze Potential Value and Recommend Solution
 (pulls together v2 Define Business Case and Assess Proposed Solution)
 7.0 Solution Assessment & Validation – v2.0 tasks  8.0 Solution Evaluation – v3.0 tasks
 7.1 Assess Proposed Solution  7.5 Define Design Options
 7.6 Analyze Potential Value and Recommend Solution
 7.2 Allocate Requirements  7.5 Define Design Options
 7.3 Assess Organizational Readiness  6.4 Define Change Strategy
 7.4 Define Transition Requirements  6.4 Define Change Strategy
 (Also see Requirements Classification Schema)
 7.5 Validate Solution  8.3 Assess Solution Limitations
 7.6 Evaluate Solution Performance  8.5 Recommend Actions to Increase
 Solution Value
 New Task:  8.1 Measure Solution Performance
 New Task:  8.2 Analyze Performance Measures
 New Task:  8.4 Assess Enterprise Limitations

Table 1: BABOK v2 vs. v3 KA and Task Differences (table modified from BABOK Guide® version 3)

BABOK VERSION 3 KA AND TASK SUMMARY

The changes to BABOK Knowledge Areas and their associated tasks on the surface may seem to be significant. Only one KA name (BA Planning and Monitoring) survives intact from v2 to v3. Only nine task names are the same or roughly the same. This article does not cover details like inputs and outputs, and many of those names have changed from one release to the next.

Upon closer examination, though, the changes are actually not so dramatic. We can summarize a few observations.

  • Even though most KA and task names have changed, in many cases they are merely refinements rather than significant changes. For example:
    • The Elicitation KA in v2 is now Elicitation and Collaboration. Most tasks in that KA are the same with the addition of the “Manage Stakeholder Collaboration” task.
    • The v2 “Conduct Stakeholder Analysis” task in Planning and Monitoring has been changed in v3 to “Plan Stakeholder Engagement.”
  • The Requirements Management and Communication KA and Requirements Life Cycle Management (RLCM) are essentially similar. An important addition is that prioritize Requirements is placed in RLCM.
  • Enterprise Analysis has become Strategy Analysis, essentially broadening its scope. It now includes devising change strategies, transitions, and organization readiness.
  • Requirements Analysis is similar in v2 and v3, despite the addition of the concept of “Design.”. An important distinction has been made by IIBA between requirements and design, which boils down to the distinction between business needs and solutions to those needs.
    • Requirements – the usable representation of a need (see our forthcoming article on the BA Core Concept Mode).
    • Designs – usable representation of a Solution. A new task “Define Design Options” has been added to focus on the BA work in designing solutions. Another new task “Analyze Potential Value and Recommend Solution” actually pulls together facets of two tasks from v2.
  • Solution Assessment and Validation has been renamed as Solution Evaluation. There are three new tasks as the table shows. They were added to clarify the work of evaluating solution performance over its lifetime including organizational constraints.
  • Out of the 32 tasks in v2, only eight have been added, a 25% change. That means 10 have been removed since there are now 30 tasks in all.

In short, BABOK version 3 is better organized than its predecessor, and with refined KA and task names contains a structure that better reflects the practice of business analysis.

In the next part of this article, we explore changes to BA techniques in BABOK version 3.

Don’t forget to leave your comments below.

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

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.