Skip to main content

Author: Jarett Hailes

KISSing Complexity Goodbye

As I was reviewing the presentations from this year’s Building Business Capability conference, I kept running into slides that looked like the graphic below to describe frameworks which model how organizations operate (the details have been left intentionally blank to protect the innocent):

Hailes Nov18
The Everything Framework

In this one example there was no less than 13 different model components and 25 relationships defined!

One of the recurring themes I heard from presenters and attendees alike was the challenge in demonstrating the value of business analysis and related activities to their organization, particularly with business architecture initiatives. I think part of the challenge lies in trying to use big, elaborate frameworks to describe anything and everything within an organization. Sometimes we think we’ve developed the ultimate map of our organizations, but it just serves to confuse our audience when we try and have a conversation with them. It can be hard to explain, much less understand.

Complexity – the conversation killer Watch video here

Instead of trying to have every possible model and view of our organizations, why not focus on using what is effective and relevant for our audience and eliminate the rest. One of the primary purposes of modeling is to facilitate a shared vision of the present and/or the future, which supports informed decision making and improves change outcomes. The more complex we make the model the harder it is for all stakeholders, from executives to front line staff to solution experts, to get on the same page.

Every organization is different, so no one set of models is appropriate for everyone. Here is a sample of the types of models I usually use as a starting point with clients:

  • People: Org charts and stakeholder/actor/persona matrices
  • Capabilities/Processes: (Non-compliant) BPMN diagrams
  • Information: Entity-relationship diagrams, sometimes data flow diagrams, business rules catalogue
  • Technology: Systems catalogue mapped to the information each system manages and the processes it supports
  • Requirements: Text, diagrams, mockups/prototypes

This is the starting point that I use for everything from developing business cases to assessing solution performance. These are by no means the only models that can be used to maintain and communicate this information; it’s all about finding what works best with your stakeholders to achieve that shared vision and reduce the noise in your conversations.

So, what part of your business analysis practice do you consider overly complex? What challenges do you encounter due to the complexity? What can you do to simplify or eliminate items that are not having their desired effect?

Don’t forget to leave your comments below.

How Business Analysts Can Help Failed Projects Succeed

I recently completed a post-implementation review for an enterprise-wide project I managed that successfully achieved all its objectives. The client was very happy with the results and all stakeholders agreed the project was executed very efficiently and implemented with no negative impact on the organization’s regular operations. The best part? The project had been attempted twice before but had failed and been aborted both times. We were able to overcome the previous failures and deliver essential capabilities needed to prepare the organization for the future.

Overcoming previously failed projects (or ones that are near failure) can be challenging. If a project has been tried before and failed, a negative mindset towards the project can be established that presents a barrier for future success. Some companies may even convince themselves that they don’t really need what the project set out to accomplish. Luckily, business analysts can play an integral role in overcoming these challenges and ensuring the project is successful in its new incarnation. Below are the key areas where BAs can enhance the likelihood of success.

Understand the Reasons for Failure

As the often-used adage goes, “those who fail to learn from history are doomed to repeat it.” In order to avoid the same fate as the previous failures, you need to understand the reasons why they failed and learn what needs to change in order to succeed. Business analysts can perform root cause analyses on the previous failures and work with the project’s leadership and stakeholders to see what lessons can be learned. This can involve everything from document reviews to conducting interviews and assessing solutions currently in place. Some of the key areas to assess are:

  • Organizational: Did the project have the wrong people involved on the project from the leadership and the executive sponsor through to the project team’s personnel?
  • Cultural: Did the organization not have the right attitude towards the project or enough collective belief in its potential to succeed?
  • Technical: Did the project fail because the wrong technology was selected or built? Did the technology have insufficient capabilities to support what was needed?
  • Procedural: Did the projects not follow appropriate standards or methodologies to increase their likelihood of success? Were there critical errors in the execution or omission of certain tasks (for example, insufficient communications, ambiguous project planning or improper project change controls)?
  • Environmental: Was there something that occurred or was present in the organization’s market or political environment that made the project’s success untenable?
  • Iron Triangle Factors: Were the finances, scope and timelines originally set out reasonable, or were some of these factors inappropriate or too hopeful given other constraints?

Recognize What’s Changed

Once the root causes are identified, the business analyst can develop proposed approaches to avoid, eliminate or address the issues that caused the previous projects to fail. Part of this planning exercise should involve assessing and documenting which of the above factors have changed. For example, personnel changes with key stakeholder areas may have shifted the cultural attitude towards the project. Or perhaps the marketplace has changed and the need to accomplish the project’s objectives is more acute than ever.

For each item where there has been a material change, document whether the change has increased or decreased the likelihood of the project succeeding as well as if the project is now more or less needed as a result. Aggregate these results and use them to assess whether the time is right to go ahead with the project once again. Sometimes, not enough has changed to really improve the project’s chance of success. Provided the business analyst is involved in the new project’s early stages, this should be highlighted to management to help them decide if the project should be undertaken at this time.

Adjust the Framework

Review the scope and objectives of the previous projects and assess what components are still needed today. Where possible, remove items that are no longer necessary or that greatly increase the probability of failure. Some items may be able to be deferred for a future phase once the project has demonstrated that it can achieve some initial successes.

From a business analyst’s perspective, this can entail reviewing requirements, project charters, plans and close-out documents, and organizational strategic plans. The BA may also perform a current state assessment to determine if any of the previous project’s objectives are already met. Based on an assessment of what matters to the organization today, the project team can adjust the framework for the new project to increase the chances of success.

For my recent project, we removed all ‘nice to have’ elements from the scope to focus on the critical components that needed to be completed. This not only reduced the cost and timelines for the project, but also increased the ability for the project team to communicate the vision and nature of the project to the entire organization since the objectives were more concise. This in turn improved awareness and buy-in from all stakeholders.

Win Over Skeptics

Clearly communicating why this project’s outcome will be different than the previous failures will help address the natural tendency to be skeptical about resurrecting a failed project. Ideally, the project can be reframed in the current context so that it can be considered fresh in the minds of key stakeholders, while still demonstrating the lessons from previous failures will be used to make the new project successful. Stories are an excellent way to help convey this message in a simple but effective format.

For a previous project I needed to show the organization’s leadership why they should re-initiate a project after it had failed. I communicated to the organization’s leadership how critical the project was to future high-priority endeavours. There were over 15 initiatives they were interested in pursuing that all depended on the successful implementation of the failed project, which was easily communicated using a hub and spoke diagram. Additionally, the organization’s mandate had begun to shift, which increased the need to ensure the project was tackled again. I used analogies representing their typical customers to show why it was important to get this project completed. These helped the leaders see the need for the project and give it the green light.

Business analysts can also highlight the need for a project on the ground while they are performing their current state assessment. As pain points are identified, stakeholders often begin to realize the need for change.This can be reinforced when the pain points are summarized and communicated to all groups.

Get the Commitment Needed for Success

In order for projects to succeed, all the key players need to be committed to its success. This means that leadership needs to be active and visible throughout the project and are willing to put in the time needed to help guide the project through its lifecycle. Sufficient funding for people and technology needs to be in place as well. The people who will take the project’s outputs and ultimately realize the benefits of the project need to also be committed to working through the process even when challenges arise. Overall, a coalition must be built that will be responsible for working with less enthusiastic stakeholders to keep the project from losing its momentum.

Business analysts play a key role in this aspect throughout the project by maintaining an up-to-date and relevant stakeholder analysis. Sometimes the attitudes, influence and engagement of various stakeholders can change over time. When BAs interact with stakeholders, they can continually update their analysis and work with the project’s leaders to address changes that could negatively impact the project.

Achieving Success Through Business Analysis

Business analysts play a key role in helping previously failed or challenged projects reach the finish line. The ability to understand why something went wrong, what to address from the failure, how to adapt to changing circumstances and how to engage the right people and get them on board are methods that good BAs possess and can leverage in this situation. Instead of fearing a previously failed project, business analysts can look at the opportunity to use their skills to ultimately bring the project to a successful close.

Don’t forget to leave your comments below.

Change Management 101 for Business Analysts

FEATURESept25thChange is hard for most people. There are a variety of reasons why change is hard, from our inherent need for a sense of security to having to deal with too much change at once to not following a process to increase the change’s likelihood of success. I know I am personally not looking forward to having to adapt my hyper-productive processes when Windows 8 is released and I may have to re-learn or find new ways to do things efficiently.
As Business Analysts, we are often involved in projects or initiatives that cause a great deal of change within an organization. In some cases we are put on the front lines of the change, whether it is gathering requirements from skeptical stakeholders to supporting the review of a solution that was put in place too quickly and is now meeting strong resistance. In order to get our jobs done effectively in such situations, we need to understand how change is perceived by individuals and know how to help guide people through change within the context of our role.

All Change is Personal

In order to help people work through changes, we need to first understand that change occurs at the individual level. The overall organizational change that occurs is a result of the changes made by each individual. Every person will react to the same change in a different way based on their culture, worldview, understanding of the change, relevance of the change to their work, what is currently going on in their lives and other factors. On large change projects you might not be able to get a full picture of why each person reacts negatively to a change, but it is important to realize that often it is not about the nature of the change itself but it could be for many other reasons. Performing a root cause analysis with certain individuals can be helpful to ensure they get on board with the change.

Prosci, a leading change management research firm, has developed a model called ADKAR. ADKAR stands for Awareness, Desire, Knowledge, Ability and Reinforcement. It describes the sequential steps each person needs to go through in order to be able to accept and support a change. If a person does not have sufficient awareness about why the change is needed, it’s hard for them to support efforts taken to implement the change, even if they would otherwise have a desire to help out. Similarly, if someone has the ability to implement a change but doesn’t have enough knowledge about the particular actions they must take to make the change occur, may exhibit hesitation or fear towards the change. Business Analysts can leverage the ADKAR model to quickly assess stakeholders when they are encountering resistance and identify the step in the model’s process where the individual might be having difficulty.

The Implementation Team Does Not Lead the Change

On almost every project I’ve worked on the group that appears to lead the change is the project team themselves. The Project Manager is at the forefront engaging stakeholders along with the Business Analysts; working to define the need, establish the requirements and support the solution through implementation. The project’s sponsor and steering committee are in the background, reading reports and dealing with escalated issues but aside from their initial announcement about the project they rarely directly interact with the people who are impacted by the change.

Some literature has taken the term ‘change agent’ to mean ‘the person or group leading or driving the change’. This is not consistent with the term ‘agent’, which is defined as ‘a person who acts on behalf of another’. With this definition, the project team is the change agent, but that does not mean that they are the people who should be leading the change. The person or group who needs to drive the change are the true leaders of the change.

Prosci’s studies have found that active and visible leadership from the executive sponsor is the leading contributor to a successful change. People within an organization naturally look to their leadership for guidance on the importance of activities and to understand the need to perform actions. If the leaders behind the change are not seen to be continually engaged and supportive of the process, the change faces a higher likelihood of failure, as people will naturally believe that the change cannot be as important as it is made out to be if the executives are not regularly promoting its value or stepping up to personally address concerns.

When Business Analysts encounter resistance to change and identify that people are reluctant to believe that the change is really needed, this should be discussed with the Project Manager and escalated as soon as possible to the executive sponsor. While the sponsor may be busy, they need to understand the importance of being visibly engaged throughout the project in order for the project to be successful. Such visibility needs to translate not only into words but actions that help the project meet its goals.

While staff look to executives to understand the need for change and to get inspired to implement the change, the person they rely on the most to understand how the change will affect them and how to work with the change is their immediate supervisor. As a result the supervisors need to first be brought on board with the change, which means they in turn need to have supportive supervisors to explain the change to them. Projects often use broadcast methods of communication and training across all levels at the organization at the same time. As a result supervisors often don’t have any more information than those who work for them, which can result in the supervisor being less likely to support a change or be able to help their staff work through the change.

When Business Analysts are involved in implementation and transition activities, they need to evaluate the approach being taken with respect to supporting the people side of the change and made suggestions on how to ensure all relevant stakeholders are able to successfully effect the change. This may entail a staged hierarchal approach to education, training and support, but it will ultimately reduce the resistance to change and the costs that are incurred when individuals are ill-prepared for a change.

Change Management Goes Beyond Communication and Training

When most people think about helping people adapt to change the two most frequently used techniques are communication and training. Both are valuable tools that are needed to help people work through the change process, and help address the awareness and knowledge/ability areas of the ADKAR model. However, they are not sufficient in most cases to fully support the implementation of a change.

As I mentioned above, managers throughout the organization of the areas that are impacted by a change need to be sufficiently supported so they themselves can get on board with the change before they are asked to help out their staff. These individuals don’t just need training on the solution but need to know what to do to help their staff overcome any issues they face. As a result a coaching plan is needed to make these managers effective change agents with their staff.

Business Analysts often perform stakeholder analysis to track all the groups involved in a project. We often assess things like attitude, influence and engagement. These attributes can be used as part of a larger context to assess how individuals are dealing with change, and what to do if some of them are resistant to change.

A resistance management plan leverages the stakeholder information gathered and maintained to help plan how to successfully manage the people side of the change. An executive sponsor roadmap will focus the sponsor on engaging key stakeholders regularly to ensure they remain on board with the change. If such artifacts are not being produced on your project, the Business Analyst should discuss the need for such tools with the Project Manager based on the scale and scope of the change involved.

Business Analysts as Change Managers

Change management is a different discipline than business analysis, but the two are very complementary. While some organizations now have dedicated change management resources, Business Analysts will often be involved in the preparation and implementation of change management plans given their front-line involvement with stakeholders throughout the project. When there are not dedicated change management resources or defined change management duties, the Business Analyst has an opportunity to help the project successfully meet its objectives by understanding the basics of change management and applying them in their activities.

Don’t forget to leave your comments below.

The Power of Story in Business Analysis

Tell me if you’ve heard this one before – you’re on a project that was thrust on your stakeholder groups from high above.  They were insufficiently consulted during the problem definition phase, and they are now questioning everything during implementation. These stakeholders can’t get the project to be outright cancelled, but they can cause it to be ultimately unsuccessful if they don’t commit to putting their time and energy into ensuring that the solution being developed is appropriately used.

Sound familiar? Business Analysts can often be faced with reluctant or even hostile project participants. Sometimes this can be due to lack of sufficient involvement early on, other times it is because they do not see the value in your project. How can you work to overcome these powerful barriers and get your entire stakeholder group to work with the team to successfully implement change?

A few years ago I was working in the education space and faced this challenge. The government had decreed that a change was to occur and that all school boards within the jurisdiction needed to conform within a certain timeframe. As more boards became aware of the change and the impact it would have on their organizations, many naturally questioned why the change was needed. The project team needed an effective way to present the long term value of the change without boring people with facts or figures, or getting into long winded explanations. So we focused on the one common value driver that all the school boards had in common: the student.

We used a short two minute before-and-after video depicting a day in the life of a new student and how the change would positively impact their educational experience. Even seasoned educators had their heartstrings pulled seeing the video; they could immediately empathize with the student and recognize how the situation described was all too common in today’s world. We used this story to introduce nearly every presentation and dialogue we had with our stakeholders for several years, as it helped establish the reason for why the change was necessary and put everyone’s mindset into focusing on the common goal all stakeholders had – providing the best possible education to the student.

Stories can captivate an audience, give them the critical information they need to understand a complex problem in a concise package, and be used to get people with very different backgrounds and goals to relate to shared events and situations. Leveraging stories to engage readers is used in the educational setting to help students process new or challenging experiences. Danielle Lowe, an educator in the state of New York, has observed “story-telling is a timeless teaching tool. Expression through text offers readers of all ages the opportunity to find solutions through the characters and conflicts within a story, and thus within themselves.”

Business Analysts have several opportunities to leverage stories in their work:

  • Defining a business need: sometimes worthwhile projects are never started because the individual(s) who recognize the problem are not in a position to allocate resources to develop a business case. Many Business Analysts who are embedded in business units can uncover problems or opportunities that can have a massive impact on the organization. Stories can be a great way to convey the business need to potential executive sponsors and get them interested enough in the topic to have a business case commissioned.
  • Documenting/communicating requirements: as Scrum methodologists are well aware, sometimes requirements can be best described in the form of stories. These do not need to be long narratives, but rather simple, structured descriptions about what needs to be addressed and in some cases why. Stories can also be effective when you need to summarize detailed or complex requirements. When performing a current state analysis of an entire division, I analyzed over a hundred processes and documented hundreds of requirements. To communicate my findings, I used three simple stories to describe the main challenges the division faced in their daily operations. This gave me a starting point to show how these challenges could be addressed through changes in processes and supporting technologies.
  • Secure stakeholder buy-in: while this activity is not solely performed by Business Analysts (indeed, the responsibility for buy-in is usually assigned to the Project Manager or Change Management team), we often directly engage with the stakeholders that will ultimately make the solution being implemented successfully operate and realize its full potential. As a result we are the first to encounter signs of potential resistance, and can be put on the spot to justify why a project exists or receive criticism for how the project is going. BAs have an opportunity to put forward a succinct but effective description of why a project is valuable, and can use story to relay the message in a narrative that matters to the stakeholder at hand. This can be tailored by stakeholder, often by using problems that they are encountering in today’s world and describing how the project will address those issues. When working on an inventory management project, I used two examples of the biggest pain points the group was encountering to convince them that performing extra data entry up front was worth their time and effort.

You don’t need to have the skills to pen the next great novel to effectively use stories. Focus on the narratives that matter to your audience and think about what compels them to do a better job. For some groups or individuals, it’s the customer that drives their desire for doing good work. For others, it may be recognition or compensation. Like any good story, start off with a problem that needs to be solved and then have your hero (in this case, the proposed solution) save the day. Don’t over exaggerate what the solution can do for the sake of the story, or else you may lose credibility with your audience. Even if the story has a fictional character or problem situation, make sure the benefits the solution is shown to perform are something it can actually do.

Stories can be a powerful and effective tool at conveying information to audiences, and when done well can be used to give people with entrenched viewpoints a chance to look at another perspective without being bombarded with facts or differing opinions. Business Analysts can look to leverage stories to engage and expand the minds of stakeholders in working towards a common goal. 

Don’t forget to leave your comments below.

The Kaizen Business Analyst

As Business Analysts, we are often focused on helping our stakeholders improve their processes and operations. We have worked to understand their current state, identify requirements, and engage others to help deliver innovative solutions that set up our customers for success. Most Business Analysts I’ve met get a great deal of satisfaction in finding ways to help people or companies do their jobs more effectively. Sometimes we become so outwardly focused that it can be easy to forget that it is important to take the time to work on improving our own processes. By finding ways to make our own practices better, we can increase the value we deliver to our organizations and stakeholders.

When looking to improve ourselves professionally, we can identify and try to implement changes big and small. Big, sweeping changes are often the most difficult to achieve, regardless of whether you are a 10,000-person organization or a single individual. Big changes are met with fear, doubt, inertia, laziness, and many other barriers. Our initial enthusiasm can dwindle if we don’t start to see immediate results, and in the end we consciously or unconsciously decide to abandon the change. This is why so many of us fail our New Year’s resolutions; often they are big visionary statements that involve a large amount of change.

Instead of trying to make big changes, we can focus on implementing a personal development process that allows us to improve our services continually with small but meaningful changes. The Japanese term Kaizen means ‘continuous improvement,’ and methodologies have been developed to implement Kaizen in small, incremental, and purposeful steps to yield dramatic changes over time. Kaizen has been used in lean manufacturing methods at companies such as Toyota, Intel, and Lockheed Martin. While this methodology has been used mainly in manufacturing, it is focused on helping individuals and small teams become as efficient and effective as possible at the job they do.

Some of the main principles of a Kaizen approach to continuous improvement are:

  • Think of ways to make something happen, as opposed to reasons why something can’t be done.
  • Do not seek perfection; start change right away and build on that change over time.
  • When something doesn’t work as expected, take the time to understand the root causes of why things went wrong.
  • When faced with hardship, take the wisdom gained and look to apply it to your next task.
  • Measure your successes and failures so you can actually tell if you are improving.

This approach not only works for teams, but also for individuals. We can use the principles of Kaizen to ensure that we are always finding ways to make our work better, which in turn improves the lives of our customers. Here are some steps to becoming a Kaizen Business Analyst:

  1. Develop your mindset: when you first arrive at work, take 30 seconds to remind yourself that today is an opportunity to find ways to do your work better. Review what you will be doing today and your plan to get things done.
  2. Document your performance: while you are working, take the time to quickly jot down how long things take you to get done. For tasks that are part of a bigger multi-day goal (for example, having requirements reviewed), build a very simple spreadsheet or leverage your organization’s timesheet to track your total time on an activity. Aside from time spent on a task, find other relevant measures given the type of work you do; for example, how many rounds of review are required prior to requirements being signed off? Think of the relevant performance measures for your analysis activities and track them over time.
  3. Reflect on your activities: at the end of the day, take a quick review of the work you did and reflect on what went well and what didn’t go as ideal. Make some quick notes and associate them with the relevant tasks they belong to. For areas that didn’t go as well, write down one to two things that could have been done differently that would have improved the outcome. Take a look at your tasks for the next day, and with your history of ideas for improvement in hand, identify what you will try differently tomorrow. If you have identified ways that you could improve but need outside assistance to make them happen, plan who you will connect with to help get the ball rolling on implementing those changes.
  4. Experiment with new ideas: find interesting things that you think will help improve the quality or efficiency of your work and try them out. Whether it’s a new elicitation technique, a new conflict resolution approach for those two stakeholders who don’t get along, or a simplified model for your complicated business processes that you can share with executives, find an opportunity to test out your ideas. Make sure you record the results and compare them, both in terms of time spent and whether the desired outcome occurred.
  5. Share with others: this gives you a chance to contribute to the development of other Business Analysts while learning new ways to improve yourself. If you have a Community of Practice or a Centre of Excellence at your organization, there are usually opportunities for such collaboration. If your organization does not have such groups, start meeting with your peers informally; I’ve found BAs often like to talk shop and swap ideas over lunch every week or two. If you are the lone Business Analyst at your organization, find a local IIBA chapter or other Business Analyst community in your area to meet with colleagues. Various online Business Analyst communities have active forums that give you a chance to learn and share as well.

Having big goals can be an incredible motivator to help us achieve our potential and become successful. Sometimes it can be so easy to visualize what we want to accomplish that we attempt to make huge changes in order to reach our goal as fast as possible. However, as an old Chinese proverb reminds us, “It is better to take many small steps in the right direction than to make a great leap forward only to stumble backward.” Having a Kaizen approach to becoming a better Business Analyst gives us an opportunity to make small but purposeful changes each day that will make us key to our organization’s success and future.

Don’t forget to leave your comments below.

Jarett Hailes is President of Larimar Consulting Inc. and a Certified Business Analysis Professional. Over the past ten years, Jarett has worked in a wide variety of industries as a Management Consultant, Business Analyst and Project Manager. Jarett’s passion is to help organizations realize the potential of their staff through efficient processes and an open culture that encourages and rewards innovation at all levels.