Tag: Change Management

A Business Analyst’s CRM Labrynth

Written by Tom Lyttleton on December 6, 2018. Posted in Articles. 1 Comment on A Business Analyst’s CRM Labrynth

C-Suite executive level information systems, report, and dashboard requirements are evolving rapidly with IoT and digitization.

I am often asked to provide business process analysis for corporate CRM solutions. Many times, these requests are to review stalled or a “problem” information system project. I provide these on a one time, annual, semi-annual or quarterly time frame.

Firstly, the review process is best performed by someone not connected to the internal team or any software or vendor of the company. It is well worth the effort and cost to bring a 3rd party consultant into facilitate the elicitations and provide any recommendations. This seems obvious, but many organizations try to save money by performing system reviews internally. Most Subject Matter Experts and team members respond very differently when chatting with supervisor’s vs an outside consultant.
I use an approach that starts with business process analysis integrated with Gemba (the actual place) mapping. Then following the actual process flows from initiation to completion. The process of observing and documenting the actual workflow is very enlightening. I will walk you through it.

You began by sitting face to face with C-suite executives to determine the basics. The basics would include their view of the background of any internal Team’s SME’s (Subject Matter Experts).

If there is an internal team supporting the system, such as an Administrator or Architect, meet with them to determine their approach to providing functionality for the users. Does the Architect primarily have a buy, or build approach? Is there an internal roadmap with documentation of any major customizations or configurations? How do they communicate with end users?

With this high-level view in hand, one would start working with each operational role in the company. I like starting with the persons or processes that answers the phone. Observe and document what happens. (I use MS Visio to provide a living document.) Take note if the CRM system does integrate with caller id to display the caller’s information or into a CRM record, if already in the database?

An inbound call is a request for personal assistance. It may be for an appointment, a complaint, a lead wanting more information etc. Follow all these requests through the organization’s processes, observing and documenting as many steps as reasonable to determine efficiency and potential areas of concern. Does the user’s primary interface, or software home screen, allow them to perform all tasks for their area of responsibility? If not, what functionality is not being provided within the system?

You may observe CRM users entering data in other, disconnected tools, such as an excel spreadsheet or cloud application. Make sure to document these occurrences. Also, document suggestions from the users, defining how a system or process, could be made more efficient, from their perspective. User feedback is critical to any improvement. The best workflows are ones that follow the “Toyota Way”. They are continuously improving and monitoring, to eliminate waste, including waiting time, over processing, motion and of, course errors or defects. The process should be easy to use, intuitive and provide guidance through help screens and notes.

After gathering information from each role in the company, 3 categories of fixes may come to light. User interface issues, missing functionality, and user training.

A work screen for a user/role should be intuitive in that the work tasks should be easily performed and guided by the system. As an example, a role that inputs a new lead should be able to process the information required in an efficient manner and if necessary, with prompts from the system. The input screen should be limited to those fields that are required to move the newly inputted lead to the next step. In most cases, the required are name, email, phone, the lead’s reason for calling code, product type, service, more info etc.

Missing internal functionality is exhibited by using external tools. This is an area for risk analysis on a number of levels. Error, data corruption, and/or duplications are possible issues that may occur as there may be limited cross checking between external tools and an internal to the CRM system, record.

User training and disconnections from the system architect(s) is one of the potential issues with remote development or configuration, the disconnect between what the architect thought was intended and what the user really needed. As an example, a user was not aware that picklist fields were available to select attributes for a new lead. The fields were not placed in a highly visible area nor were they made required fields. Consequently, the user(s) elected to place this information in a text field. This created records that are not as useable or referenceable for other roles or workflow rules. Any system error checking or field validation is lost. This exemplifies two failures, one to train, (Documentation?) the other not providing a simple, easy to use, data entry screen.

We learn a great deal from these sessions. After accumulating all the information found and documenting the current state, we document from the team, all possible improvements. With using the same tools, the potential process improvements are documented, and GAP analysis performed.

The current state model may expose some decisions that were made when other options weren’t available. Perhaps decisions were made as functionality development, vs configuring an existing tool, were done unintendedly without understanding the risks. The model may also expose poorly executed or incomplete modifications and implementations.

With the gap analysis complete, the Business Analyst can provide further clarity by evaluating potential improvements for effort vs gain to the organization. Many times, they will find that an easy, fast, configuration wins in this area. In turn, this will improve team and user’s morale. I like to prioritize those.

Present 3 possible solution and/or improvement paths for the stakeholders to debate where there isn’t a clear single path. It is critical that the stakeholders determine which path to take. Change management will be monumental without user buy in, ahead of any proposed changes. The fact that the users have been involved from the discovery process on, helps immensely.

The Independent Business Analyst must remain unattached to the decision, assuming as much of the risk or reward as possible to be exposed to the decision makers. Document the decisions and deliver the report.

What’s in a name?

Written by Julian Coady on November 29, 2018. Posted in Articles.

I just got back from the Building Business Capability conference in San Antonio.

It was the first time I’ve attended that particular conference, my first time presenting to that sort of audience, and my first time visiting the United States.

My head is still spinning.

Lots of great speakers and tutorials, a larger-than-life venue, and an entire community of business analysts – I was lucky enough to meet people from all over the world, many of whom share my particular way of looking at a problem, of trying to make sense of complicated landscape of information. It was a revelation.

There were a couple of themes that just kept popping up – Agile Agile Agile (of course), AI and new tech and what that might mean for BAs, the ever constant struggle to connect strategy with execution, the importance of a customer-centric view, and the need for business analysts to adapt to these, and other tectonic shifts in the marketplace.

All this had me reflecting on what it means to be a BA, and how I got here. I remember being incredibly relieved when I discovered that there was a name for the sort of work I had been doing all these years. Solving business problems, particularly solving them in a way that works for the customer, is something I’ve been doing in one way or another for more than a decade. Whether it was putting together grant applications for a not-for-profit, designing a better back-of-house process for a restaurant (there is no better playground for process improvement than hospitality and commercial kitchens), or refining requirements for large IT infrastructure projects, the common theme was a need to solve a business problem in a constrained environment while maximising outcomes for customers.

Discovering that this had a name, that I had a capital P Profession, was a powerful thing. I joined my local IIBA chapter, and thoroughly enjoyed the opportunity to talk with people from diverse backgrounds that had a common way of making sense of the world.

I can’t help but wonder if the challenges we face as a profession mean we need to do things a bit differently to stay relevant. If we take a customer centric view, does the title ‘Business Analyst” still make sense? Does it in fact confuse the issue? Many of my colleagues complained about not getting the sort of access to the C-suite they needed in order to provide real value for the companies they work for. A number of people asked me last week how to become a trusted advisor to the people who ultimately make the big decisions – I’m amazed that they seemed to think that I had some secret formula for this, that I had cracked the Da Vinci code.

Perhaps the problem (or at least a part of the problem) is the way we describe ourselves. Our customers don’t care about our job titles. I don’t care how Apple is organised internally, I just want my phone to work the way I expect it to – I want a solution to a problem (although many of my Android using friends would claim that Apple is the problem rather than the solution, but that is an argument for another day). If we apply some customer-centric thinking, what does our profession look like? How do we best describe our value proposition? When my mother-in-law asked me what I did for a living, and I told her that I’m a business analyst, her eyes glazed over. I made the mistake of saying that I worked in IT – it’s hard enough to describe this in English, let alone my somewhat limited Swedish – at which point she asked me to fix her laptop.

Like many other industries, we are under pressure. New technologies, increasing customer expectations, shorter deadlines, a general sense of uncertainty et cetera ad nauseam. There is of course an opportunity to be seized here. Who else is better placed to help our customers navigate these challenges than a great BA? But how would they know this?

A friend once told me that I if couldn’t effectively explain the value I could provide a client, no one would bother engaging me. Does ‘Business Analyst” do that? “Strategic Analyst”? “Digital Advisor?” “Technology Expert”? “Business Consultant”? All these and more have been suggested.

To be clear, I don’t know what the answer is. I used say that I worked in Change Management, but this means different things to different people depending on where you are in the world. And my brother claims that change management is the act of emptying the coins out of your pockets at the end of the day.

What I do know is that we need to get better at explaining what Business Analysis is, and how truly valuable it can be, especially to those people that make the big decisions. Otherwise we will be stuck in the loop of delivering projects that just don’t make sense. One comment from the closing remarks of the conference has stayed with me:

“We are all doing business analysis all the time, what people call it is irrelevant.”

What is relevant is that good business analysis is more important, more necessary than ever.

The Business Analyst and the approach: A catalyst for change

Written by Andrew Burton on October 2, 2018. Posted in Articles. 1 Comment on The Business Analyst and the approach: A catalyst for change

My wife jokes with me that she still doesn’t understand what I do. Any time we meet someone new and they eventually ask me what I do for a living, she has to try not to giggle when I look at her.

Often the easiest explanation is to say where I work, or that I work in I.T. or that I do analysis stuff. Occasionally someone takes more of an interest and I found myself explaining more and eventually getting to what I think the core of what a business analyst is: being a catalyst for change.

It took me some years to get to that understanding. Moving into business analysis from more technical roles, it took me a while to move from having a more technical or systems-focused mindset around requirements specification and requirements management to focussing on the whole point of my job. While many employers do have a fairly clear idea of what a BA does or should do – and that is mostly centered on requirements – many employers also come to understand that the BA often comes fills a role that means a lot more than that. Thus the BA role has evolved.

The BA is placed in a role in a workplace in any variety of situations or problems. A broken process, an idea for a new project, a system integration, the test phase of a large vendor product implementation, and many more. It’s no surprise most BAs feel overwhelmed by the expectations that come with the role. The

IIBA’s BABOK is also a bit overwhelming. How can one person wear all those hats? Job descriptions from recruiters for BA roles can include head-spinning lists of selection criteria that stop just short of:

Faster than a speeding bullet
More powerful than a locomotive
Able to leap tall buildings in a single bound

Take a breath and relax. When you start in a role, most employers know you’ve been given a big task, and also that you’re not Superman (unless you are of course). They want you to get things to happen, to take responsibility for something others in the organization are not currently available or able to do, to be a catalyst for change.

An analyst can take a problem and break it down, work out an approach to solve it and plan the steps needed to realize the desired change. A business analyst can do this with the guidance of the BABOK. And really that is all the BABOK is – a guide. No BOK can cover the myriad situations and problems organizations face; their culture, attitudes, level of maturity, unique operating environments, or the ideal way to approach them. What the BABOK does is guide you to apply some structure to the way you work in your employer’s environment.

The most valuable step early on is to validate with your employer your approach to the problem you’ve been tasked with. Be prepared to revisit and tailor your approach as you learn more. There may already be accepted approaches or “ways we do things” in place in one way or another. Make sure you understand these and communicate any concerns or conflicts with your view of how to approach a task. If there is nothing in place, then you have a scary blank canvas to work with! Draw on your experience, your contacts, colleagues, the multitude of information out there to sketch out an approach. Be assured that the approach you develop is already bringing about change for your employer. It will help to develop early trust and confidence in the work you will deliver and set a transparent direction where there may have been no direction previously.

Don’t be disheartened if you find your approach travels a bumpy road – the BA is often the one sent along a bumpy road in the first place. Validate with your requirements stakeholders as you go, gather feedback about each task, technique, and deliverable in your approach.

Are stakeholders comfortable with the approach?
Is your approach starting to bring about positive or negative change?
Are there any ways the approach could be improved?

Catalyst: a substance that increases the rate of a chemical reaction without itself undergoing any permanent chemical change. A person or thing that precipitates an event. Perhaps catalyst isn’t the right analogy. Your approach will almost certainly change as you receive stakeholder feedback, and change isn’t simply an event, it’s more enduring. The other part of the change equation is you, the BA.

One of the intimidating things about the BABOK is the underlying competencies section. Now we are talking about Superman. If I was to highlight any of these to focus on it would be interaction skills. Your ability to change; your attitude, your understanding, your approach is dependent on how well you interact with your stakeholders. Interaction skills are also the most critical skills in a successful business analysis approach, so let’s look at some of them.

Facilitation: You will struggle to apply many elicitation techniques without being able to facilitate stakeholders well. Facilitation is a skill that requires a lot of practice, and as it is challenging, you have to cut yourself some slack. Learn from your mistakes; the awkward moments in a workshop, the lack of preparation time, the misunderstanding of a stakeholder motivation. When you hone your facilitation, you will earn respect early in any workplace.

Leadership and Influencing: Your ability to lead and influence is key to enabling change, from seeking funding for a new project to improving stakeholder buy-in. Leadership mostly requires confidence, with a good dose of humility. Don’t take credit, instead encourage your colleagues with praise for their work and if you deserve it, they will credit you.

Teamwork: This is how most of us change and mature as professionals. It is through the thousands of interactions with our team members that we learn and develop ourselves. The humor, the conflict, the expert advice, the human mistakes; all of these and other experiences trigger little changes in ourselves.

In summary, a BA can be a boffin, an exceptional thinker and problem solver, passionate about correct technique and rigor in requirements management. However, if a BA isn’t transparent as well as pragmatic in the way their work is approached and adaptable to the needs of requirements stakeholders, they will struggle to effectively bring about change. Furthermore, the BA’s interaction skills will be critical to the change effort. Consider your interactions with others – how might they perceive you? How do you make them feel? Are you developing trust through your interactions? Are you using your sense of humor (and humility) and being human (not Superman)?

Up, up, and away!

The BA Skill Set – Influence – The Targeting Approach

Written by Jon Derbyshire on July 18, 2018. Posted in Articles.

The concept for this article came from something I read a number of years ago. It’s something that has remained and resonated with me throughout the years.

I see at as a blueprint for targeted influence at all levels of the business, and something I’ve been thinking about more and more on more prominent projects I’ve been delivering.

Influencing others is a primary skill of the business analyst. Influence will take many forms and needs to be skilfully tailored to the audience, whether it be a project team, the end users, or even the board of directors.

It is our responsibility to be able to positively influence throughout the organization. It’s even more important always to remember that when influencing others it is our responsibility to sell the concept or vision. It is not the others responsibility to buy.

Without influence, we simply cannot lead from the front and this can mean we have less ability to deliver what we feel is required from a strategic or analytical perspective.

It’s also important to remember that as a BA, objectivity is key. We need to present alternate views. This always should include the negatives and downsides, not just the positives. Presenting balanced arguments is a key factor in achieving authenticity and enhancing our reputation for the excellent analysis.
When influencing it is often stated that we must ‘win hearts and minds’.

The issue here is that trying to win both hearts and minds at the same time can split the impact of the message we are trying to convey.

Winning Hearts

Winning hearts relies on gaining emotional buy-in and bringing others along for the ride. It is often most appropriate when influencing colleagues to go that extra mile or to motivate others when their motivation is diminishing. Persuading others to deliver more and rallying the troops in times of need requires influencing skills that rely heavily on feelings and emotions.

Connecting with others on a personal level, understanding both their needs and their fears is critical to ensuring your needs can be bought into by others. It requires skillsets often associated with more extraverted individuals but is also a critical understanding for an experienced BA to have.

It’s also a great way to paint pictures in the minds of others. Great storytellers thrive when influencing through ‘winning hearts’.

Winning Minds

Winning minds, on the other hand, can often be achieved through strategies directly in conflict with winning hearts. Winning minds tend to rely more on tangible facts and data, and taking a more analytical approach to influencing with datasets rather than storytelling.

There is a fantastic TEDx talk entitled ‘Data Storytellers’ which bridges the gap, but I won’t get into it here as from personal experience, achieving both tends to be the exception, rather than the norm.

At the heart of scientific persuasion lies logical reasoning and well thought out arguments. Often times the crucial factor boils down to being able to anticipate questions that could be raised and having a well structured and presented answer ready in advance for these.

When winning minds we often need to take a step back and look at our arguments more strategically and try to pick holes in them. Anticipating the weaknesses allow us to answer analytically and to help guide the person asking the questions through their doubts, until all they have left, is to reach the very conclusion you had been leading them towards.

Winning minds is often a great strategy when presenting to senior managers who have no pre-bias or emotional investment in solutions put before them. Harvard business review studies have shown that strategic thinking is one of the most sought-after skills for companies looking to promote to the ‘C-suite’. At this level, senior managers tend to think both strategically and financially. Appealing to the logical side of their decision making lends itself to the strategy of ‘winning minds’.

Winning minds is also a great strategy for reversing decisions made on gut feelings or emotions, often with little fact or evidence to back it up. It’s hard to refute facts backed up by the numbers, and offering this type of information is a great way to influence the reversal of biases. By presenting them with evidence they can get behind, you have effectively demonstrated your ability to manage up.

Tailor Your Message

Trying to appeal to both hearts and minds can often lead to a weakened position. You likely won’t have the same level of connection you would by targeting just one and tailoring it.

It’s important to know your audience. Presenting the most powerful and persuasive argument can be the difference between buy-in and indifference.

Our reputation as an analytical but objective expert is critical, so understanding the power and science behind influencing can lead to important decisions being made on the side we believe in pursuing. We are often subject matter experts, and the experience we have gained can be crucial to helping guide others to the finish line and towards success. Combine your knowledge of your audience with a targeting of your message and you will see your influence grow.

5 More Tough Questions Business Analysts Face on Tech Projects

Written by Brad Egeland on June 7, 2018. Posted in Articles. 35 Comments on 5 More Tough Questions Business Analysts Face on Tech Projects

I cover tough questions that business analysts may face on an earlier article here entitled “Top 5 Top 5 Toughest Questions Faced By Business Analysts On Tech Projects.”

It seems to have been fairly popular with our readers here so I wanted to address more potential questions that can arise for business analysts on the projects they are helping to lead. Customers have lots of needs, and the business analyst is likely their most frequent communication point on a daily basis – especially on the more complex technical projects.

This can probably be a never-ending list, and I will probably address more in a couple of months, but for now here are my next five tough questions for business analysts…

Can this be hacked – is my data safe with you?

Everything can be hacked – and in this age that can go for just about any data on any project you might be managing or working on at any given time. I know that sounds like a mouthful and probably sounds like a bad trailer for a low budget horror film, but it’s true. If they aren’t going after you, then it’s because they don’t care about the data you are managing or that your customer has in their data solution you are working on. Yet. But it can happen. 25% of my past and current customers have been hacked in the past year and affected in some way… though thankfully not due to my oversight and none have been very damaging to them… so far. But that can change overnight, and it is likely they will ask you on every project going forward that has some data element. Be aware, always manage hacking as if it is a real risk. You can’t likely ever fully prevent it, but you can take precautions, you can make your organization’s security team or CSO part of your project team that checks in from time to time and you can consider mitigating actions to take in case of a hack. Do it.

Am I going to get slammed with change orders?

Nearly every client worries about getting slammed with change orders even if they don’t always mention it. You need to convey from the outset what your change management process and methodology is, and help them to understand the guidelines that will result in change orders being presented to them. And most of all, you must do a very good job of requirements definition and documentation and scope management. Yes, overall that is a project manager’s responsibility. But who is managing the ongoing development work on a daily basis in the real world – beside the tech lead? That’s the business analyst. Manage it well and keep the customer up to date on any potential needs that could result in change orders. They never like surprises of this kind.

Do you have the right skill set on the project team to pull this off?

The project customer is paying the bills for the project – so they need to know that those expensive resources have the right skills to pull this off. Especially if you are dealing with new cutting edge technology. The best you can do is comfort them by providing background information on the team and keeping the customer up to date on a daily basis on the project tasks and progress – especially the more difficult project tasks. Don’t let them get that unsettling feeling that their solution is in the hands of questionable talent… even if at times the team may be learning as they are going. You can know that, the customer should never hear that.

Why isn’t my project more important to your organization?

Your customer is going to want their project to be at the top of your organization’s priority list. If they feel like – in any way – their project is less important than any other project in the organization or on your project plate, that can cause them great anxiety. Never let them think that you are being pulled away to other projects you are working on or that any of the team members are overloaded on any of the other projects they may be involved in. You can know that and juggle whatever you need to juggle to make the work happen and help the tasks get completed. But that needs to be behind the scenes and not apparent to the project customer at all times.

How can I effectively test this solution?

Project customers and testing on tech projects. It’s a difficult mix at times. In my early project management days I was tossed into the fire right out of my role as an application developer to oversee most of a $50 million government tech program with very sensitive data and very necessarily deadly accurate output as it was always financial in nature. Part of that management was overseeing the testing portion of the program and system on an annual rollout basis. Preparation was long and thorough, requirements and acceptance standards were ridged, and the incoming government testing team was needing and opinionated. A difficult combo. I learned early on that not all testers are created equal. You can not do the testing for them – that would be unethical and a definite conflict of interest. But it is everyone’s goal to get through it as painlessly as possible so help them. And when they ask this questions show them how to write test cases and test scenarios, be available 24/7 to answer questions and hold hands and never be afraid to steer them back on track. They know you’re the expert. And most customer end users don’t care about the details, they care about the correct outcomes.

Summary / call for input and feedback

Again, the bottom line is we want to turn over successful projects. Our project customers are nervous and inquisitive if they are involved. Be ready with the right answers to keep them confident and keep them from micro managing.

Readers – especially business analysts – how do you feel about this list? Does this match your experiences? What would you add at this point? Please share and discuss.