Tag: Stakeholder

4 key activities for a Business Analyst in the Alpha phase

Written by Nick Stowers on May 14, 2020. Posted in Articles.

On one of my earlier blogs, I described what I thought are the 3 key activities a BA should be doing when they were in a Discovery phase of a project.

The feedback I received was positive so I thought I’d give, what I consider to be are the 4 key activities are for a BA in an Alpha phase.

So what exactly is an ‘Alpha’?

In the UK, the Government Digital Service (GDS) defines the phases in an Agile delivery lifecycle as; Discovery, Alpha, Beta, Live and Retiring the service. GDS also cover in detail how the Alpha phase works, but what’s not covered in the article is what each role in a delivery team does within an Alpha, including Business Analysts.

If you’re not familiar with the names of these phases, they are the same for pretty much all Agile project delivery. The most common themes I’ve come across are;

Concept, inception, iteration, release, production, retirement

Moving Discovery outputs in to an Alpha

Key outputs from the Discovery the BA should have been heavily involved in include:

Stakeholder analysis
Understanding and defining the problem
Starting the product backlog

Each of these outputs now need to be taken through in to Alpha by the BA and here’s how.

Stakeholder analysis – Use your stakeholder knowledge

An Alpha to me is the exciting part of the Agile delivery lifecycle as this is where you actually start putting ideas and concepts in front of users and you learn ‘how’ they will really interact with your product and get valuable feedback. To ensure you get as honest and realistic feedback as possible, it’s important to try and create as real-life scenarios as possible to test the prototype with users. To do this, the BA should use their knowledge of working with stakeholders in Discovery and take this in to the development of the prototype with the designers on the team. After all, if you were the BA involved in Discovery, one of your key outputs is understanding the users and their needs, and that includes the needs of the business. Therefore, armed with this insightful knowledge, you should work closely with the design team to ensure they also understand the users.

Understanding and defining the problem – Keeping the product vision in view

During Discovery, the team will have (or certainly should have) defined the problem that needs to be fixed and from that, a product vision should also have been defined. Roman Pichler has an excellent article on how to create a compelling product vision which I highly recommend you read as well as all the other articles he has on his website.

For me, the product vision is one of, if not the key outputs from Discovery and is something that should be visible and referred all the way through the delivery lifecycle. All too often I’ve seen the product vision put up on the team wall (or worse, in a folder on the Product Owners laptop) but no one seems to take any notice of it and it becomes just a part of the wall space along with user research findings, sprint boards, etc. To make sure the product vision stays in view, and you have wall space, have it beside your user story map (coming up in the next section). Pretty much everything that’s in your user story map should stem from the product vision, so keep them close together.

Starting the product backlog – Make sure prototypes stem from user needs (building your user story map)

How prototypes are developed is different for all teams but in my view, the quicker you get to an interactive prototype, the better. I’m all for sketching out designs to protect costs and save time, but only once a prototype is in the hands of users and seeing their interactions with it, will you start to get valuable (and workable) insights to develop the prototype further. And remember, as the BA, you’re going to start building the product backlog based on the findings and create your user story map. If you’re even half serious about being a Business Analyst, I don’t need to tell you the powerful impact of user story mapping but if you need reminding, here’s Jeff Paton (the guy who came up with the idea of user story mapping) showing you how to create one.

Help the team design iteratively

Having your user story map on the team wall (or online if you are a in several locations. I recommend www.storiesonboard.com as a user story mapping tool) is a great way to galvanise the team and ensure what you’re doing aligns with the product vision (hence having the vision next to the map). As we know, agile delivery focuses on building products in an iterative way and this principle should apply to designing prototypes in Alpha. I quite often see designers go off and start building complex, end to end user journey. For this very reason, having a user story map will encourage the design team to not think too far ahead. After all, your map will have an ‘MVP’ (or Release 1 if you’re not comfortable with the term MVP) swim-lane where you’ll define as a team what features will (or might) go in the MVP and this is what the design team should be focusing on prototyping.

And finally…

Don’t misunderstand me, and this is based on the feedback from my ‘BA in a Discover’ blog, these are not the only 3 activities a BA will carry out in an Alpha and you will no doubt carry out more than this (e.g. writing the user stories for Beta, working with technical architects/software developers to ensure what is being designed and tested with users can actually be built, continually developing the backlog, etc) however I’ve seen projects where the BAs have not been involved much in the design process and this which has led to problems further down the delivery process. Remember, you as the BA are the bridge between the design team and the developers/testers!!

An Alpha (or iteration) phase can last several weeks and if you as the BA follow these activities, you’ll ensure the product is designed with the users in mind, in an iterative way, and that when you get to the Beta phase (blog coming soon), your product will be delivering the value defined by the product vision.

Perspectives

Written by Srinivas Laxman on April 9, 2020. Posted in Articles.

As a Business/Systems analyst or Solutions Architects we are Technical Leaders for the systems we represent to the business.

We have incredible influence on wide range of stakeholders during the analysis, architecture and the end to end solution delivered. We hand hold the business as they try to unravel the incredible complexity IT brings to the table to help deliver the business value. And at the same time we can strive for simpler implementations and identify red flags that could help our development and operations stakeholders.

Here are some of the perspectives that an analyst must be aware of and can use it to further enhance his influence on the project.

Business Perspectives

I have been in several meetings with Business stakeholders where the business language they use for certain features or scenarios are completely different as used by IT stakeholders. These can cause back and forth discussions and confusions during solution reviews. Smart analysts understand this and acknowledge these discrepancies will always exist due to diversity of stakeholders. They will bring these up at the right time and align both teams – there by ensuring both teams are aware and can work around it.

Another of concerns of business stakeholders is the use of excessive technical jargons in the functional requirements which delay the sign off and add complexity. Thus, business greatly appreciates analysts who use the simplest language as possible and whenever required provide clarity on any jargons if used. That way they are not alienated and fully aware of the technical solution they are signing off. You may have seen the internal memo sent by Elon Musk banning all technical jargons at Tesla.

Finally, business always looks for an honest voice, one who brings to the discussion table issues or gaps or critical roadblocks at the right time instead of pushing it under the rug to be discovered later. Such analysts are greatly valued for their strong voice and to help business identify upfront mitigation plans and not at the tail end of the project.

IT Perspectives

Management of scope is one of the most important expectation from the IT teams is that analyst should spend enough effort on. Highly respected analysts do this regularly and continuously control the scope to push back when required and at other times steering them through change management process. There by shielding the development team members of the constant influx of changes.

Development/operations teams are always wary of the massive amounts of code that will be written and pushed to production as part of new projects. From their perspectives one of the main expectations is that the implementation should be simple enough to develop and maintain. Analysts can play huge role here by identifying red flags when things are becoming complex, making their stand and nudging business teams to think of reducing complexities to achieve their business goals. Finally, nobody wants to end up with a system that is too hard to understand and nightmare to maintain.

During implementation phase IT Development/Operations teams usually come up with highly relevant set of questions and important scenarios that need to be clarified with business. These are invaluable insights that when the analysts should make sure to track and close can hugely influence the quality of deliverable. I have seen projects where these when ignored usually end up as UAT issues, which could have been easily discussed and closed during the requirement/development phase.

Analyst Perspective

Analysts have to regularly ask what the technically right thing is to do in situations which require critical decisions. For example, there could be a quick fix that could solve business requirement, however highlighting that business rather wait and have long term fix which will ensure better technical solution and also save costs will be better appreciated by both sides of the stakeholders.

The analyst must continuously think several steps ahead and keep looking at big picture. Such analysts also push for proof of concepts and early integrations to happen since they are usually the gaps which are identified late in the project deployment stage. They may also influence in the receivables and deliverables of the project with the integration partners to ensure the configurations and touchpoints are well tested prior the launch.

Thus, such analysts have clear strong vision of the solution they are creating and in addition to catering to business and IT stakeholders also chart the right path for the project that is in line with the overall enterprise architecture.

AI and the Digital BA—What’ It All About? Part 2

Written by Elizabeth Larson on February 6, 2020. Posted in Articles.

This is the second of a two-part article written with answers to some of the most frequently-asked questions I get about artificial intelligence (AI).

In part 1 I addressed some common terms and issues relating to AI as it is used in a business rather than technical context. In this article I will focus on the various roles the BA plays to help organizations with their AI initiatives. As with the last article, I will use a Question and Answer format.

Quick Review of Part 1

What is AI?

AI is an umbrella term that encompasses all digital technologies, like machine learning and predictive analytics, which are used to make predictions and recommendations using massive amounts of data. In short, it’s machines doing human tasks that range from simple to complex.

What is a digital business analyst (BA)?

A digital BA is a trusted advisor who helps organizations with their AI strategies. Rather than developing the strategies, they provide their advice about impacts to and value of AI initiatives.

What skills does a digital BA need?

The skills don’t change, but the subject matter is incredibly complex.

How successful are most companies with their AI efforts?

Not very. Most AI initiatives totally miss the mark and result in all kinds of issues, not the least of which is financial. A recent Forbes article details some of the resulting issues.[i]

What is digital fluency?

Digital fluency is defined as “The ability to interpret information, discover meaning, design content, construct knowledge, and communicate ideas in a digitally connected world.” [ii]

Part 2

What is the role of the BA on digital projects?

A digital BA can be involved in many aspects of an AI initiative. Some of the roles that a BA may play include one, several, or all of these:

Strategic BA. In this role BAs help organizations determine the value and direction of the AI effort. Some of the specific outputs can include:
- Business case on the value of the AI initiative
- Recommendation(s) on the best strategic approach to the AI initiative
- High-level implementation plan
- Pitfalls to avoid
- First look at state of the data to be used
- High-level governance plan

AI coordinator who implements the AI strategies. In this role the BA coordinates AI initiatives across project and portfolios.
BA on a project(s) that is part of the AI initiative. Although this role is similar to any BA role, there are some differences. The BA will need at least working knowledge of, if not expertise in, AI.
Business data analyst. In this capacity the BA may
- Analyze the current data to determine how much is useable, how much needs to be cleansed, and how much needs to be collected
- Recommend an approach to cleansing the dirty data
- Help determine the data needed for predictive analysis and other AI functions
- Interpret statistical analysis resulting from AI functions
- Be an AI translator to facilitate communications between the data scientist and the business stakeholders.

What’s the difference between a data scientist, data analyst, and BA who works a lot with data?

These 3 roles can be confusing. At first glance we might not recognize differences or understand why the distinctions are important, but they are. I discussed the possible roles of the BA above, so here is a brief description of the other two.

Let’s take the easy one first—the data scientist. Not that the role is easy, it’s just easier to explain why this one is different from the other two. The data scientist is the most technical and needs the most expertise. About three-fourths have master’s degrees in mathematics and statistical analysis. Over half have Ph.Ds.

Data scientists create the predictive models. They determine what the machines need to do in order to meet the business objectives. They decide which algorithms are best given the objective of the AI initiative so that the machines can be trained to learn. Having said that, unless there is good governance and substantial input from business stakeholders and decision-makers, those algorithms have the potential to be created with built-in biases. Likewise, they may not be the best ones to solve the business problem.

The data analyst. This is really a subset of the BA role. I described some of the high-level functions above. On AI projects it’s necessary to focus on the data because it’s so integral to the success of the effort. Machines learn based on historical data. Issues like dirty and redundant data, as well as ownership of the data aren’t easy and require a strong facilitator and influencer to resolve. This data analyst role is such an important role that IIBA has created a new certification—the certification in business data analysis (CBDA).

What are some of the business and technical pitfalls that the digital BA should be aware of?

Here are some of the big ones:

Strategic

Beginning with AI as a solution without a defined problem
No real AI strategy
Unrealistic expectations of what AI can do for the organization

Data and technology

Dirty data
Business processes don’t support the technology
Weak security

Organizational and communications pitfalls

Siloed and cumbersome business architectures
Inflexible organizational structures
The data scientists create the business rules
The data scientists talk directly to the business and the business does not understand
Confusing roles on AI projects
Built-in biases in the algorithms

In Part 3 of this article, we will explore other aspects of how BAs can help organizations get the most value from their AI initiatives. Some of the topics we will cover include the need for governance on AI efforts, the recognition of the importance of the AI translator role, the digital PM, and more.

[i] https://www.forbes.com/sites/insights-kpmg/2019/12/10/data-governance-is-risk-number-one/?utm_source=TWITTER&utm_medium=social&utm_content=2937780067&utm_campaign=sprinklrForbesMainTwitter#90dd59b91c81

[ii] https://www.slideshare.net/RobinAshford/guiding-learners-toward-digital-fluency

Want better communication strategies? Mimic the airlines.

Written by Jennifer Bedell on January 22, 2020. Posted in Articles.

Yes, I said ‘airlines’. Air travel sometimes comes with unexpected “adventures”.

Instead of ruminating about your delayed flight or grumbling that your gate seems to be in another timezone, entertain yourself by spotting and analyzing processes. I used this adult version of ‘I Spy’ to reflect on how we can apply airline communication strategies to our projects.

Just in time communication

My recent flight from Toronto to Paris demonstrated the importance of variable communication methods and proper timing. As I was heading toward my gate, I heard a recorded voice say “Please have your boarding pass ready when entering toward gates x”. That prompted me to look up just in time to see a sign with the same message. Just beyond the sign was an automated checkpoint that would open only after scanning a boarding pass for an international departure.

As I was digging out my boarding pass, I reflected on how well this was done. I was informed just in advance of the action I needed to take. By receiving the message just in time, I knew exactly what I needed to do and I had context. Imagine if I had been told only once at check-in: “When you get to Toronto, there is a separate section for international travel. When you get there, you will see an automated checkpoint where you will need to scan your boarding pass. Please be prepared to have your boarding pass ready to be scanned.” After a few hours of flying and navigating my way through the airport, would I remember that? Would it have made sense without context?

By delivering a just in time message that was clear and concise, there were no delays at the checkpoint. People who weren’t ready simply stepped aside so they could prepare. Those who were ready, moved through quickly.

Do your stakeholders forget what is expected from them? Or do they complain that they didn’t have enough time to complete their tasks? Consider the timing of your request. Could it be delivered earlier or later?

Multiple communication channels

Before I heard that recorded message, I was walking with my head down, checking my phone for places to eat. I had lots of time between flights so I wasn’t worried about getting to my gate quickly and I wasn’t watching for signs. It was the audio message that grabbed my attention. The volume of the recording was perfect for me and played as I approached the area so I had enough time to prepare.

Another traveler may have been engaged in conversation or may not have heard the message clearly. The signs provided an alternative communication channel for those who are more likely to respond to visual messages.

By providing multiple communication channels, there was a better chance of reaching all people who needed to receive the message.

I recently heard about a project where many team members repeatedly asked about the delivery schedule. After the Project Manager posted a physical schedule visible to everyone, the questions stopped.

Have you been frustrated by stakeholders not being aware of the information you’ve delivered multiple times? Consider an alternate communication channel.

Content of the message

The message the airline communicated was short and told me exactly what I needed to do. Imagine if it included additional information that may seem appropriate, but not necessary at that time. Would you stop long enough to listen to this message? “Please be advised that we have recently installed an automated checkpoint for passengers travelling internationally. These checkpoints will streamline the security process. Please be advised that to enter this area of the airport, all passengers must scan their boarding pass and wait for the gates to open before proceeding.” While this information may be relevant, airport travelers are not wandering around reading long signs or stopping to listen to every voice that begins to speak. (Think about what happens during boarding. When the first announcement starts, everyone gets up to board, even though the announcement may have said “please do not line up as we are not yet boarding”)

By delivering a clear and concise message, people are more likely to hear and understand what is expected. Consider how you can apply this concept. Are your messages clear and concise? Do your communications convey the right amount of information in a clear manner?

Frequency of communications

Having successfully progressed to the international section of the airport, I was on my way to a European vacation. But, this was not the end of my recent air travel adventures.

I had the privilege of sitting in a plane while experiencing multiple flight delays – each with a different root cause. How do I know the root cause of each delay? Because we were informed at appropriate intervals in an appropriate tone with just enough information (and in both official languages).

The first announcement came before we left the gate advising that maintenance personnel were fixing a minor issue before we could take off (this explained the maintenance personnel on board). The next announcement assured us the issue was resolved and there would be another 15 minute delay while paperwork was being completed. This was followed by a few more announcements as we waited for a spot on the runway.

Under normal circumstances, we would have been on our way soon after lining up for the runway; however, this was just the beginning. Due to snow and ice, we switched runways twice with delays on each runway. During the delays, the pilot updated us every 15 minutes or when there was a change.

Communications were delivered as needed to keep us informed, but not so often as to annoy us. By delivering regular updates, all passengers knew what to expect and how much longer we needed to wait. It didn’t eliminate the wait, but it did eliminate any speculation about what might be causing the delays.

Does inaccurate information circulate through your teams? Consider timely and concise updates.

Tone of the message

As the delays progressed, the pilot became less formal and even began one of his announcements with an audible sigh showing us that he is also feeling the pain of the delays. It was met with laughter by most passengers. What a great way to put us at ease, give us a little chuckle and prevent tension from building. The final delay was a coyote on the runway. Our friendly, neighborhood pilot told us to look out the left side of the plane to catch a glimpse of the coyote as he darted away.

As the messages progressed and the situation allowed, the messaging became less formal. This built rapport with the passengers which made people feel more comfortable.

Are your stakeholders reluctant to share information with you? Would they be more forthcoming with a less formal approach as the stakeholder relationship evolves?

Appropriate to the audience

In the above communications, I am speaking from the perspective of a passenger. The tone, frequency, content, channels and timing of these communications would have been different for each stakeholder group (passengers, flight crew, paperwork, air traffic control, ground crew etc.) and delivered by the appointed messenger.

By tailoring the message to the audience, each stakeholder group receives information with an appropriate level of detail. The content and formality of the message delivered to the President of the company will be very different than what is delivered to a member of the project team.

While airport travel is not always as pleasurable as a trip to Disneyworld (unless your flight is to Orlando), we can still take lessons from those who spend their days moving millions of people. Imagine if project communications followed these same guidelines? All stakeholders would receive the right amount of information at the right time leading to a greater chance of success and on time delivery.

A New Twist On The Stakeholder Matrix

Written by Deena Chadwick on December 5, 2019. Posted in Articles. 1 Comment on A New Twist On The Stakeholder Matrix

Did you know that the word stakeholder is mentioned 1202 times in the PMBoK Sixth Edition and 1208 times in the BABoK v3?

It is mentioned this many times because building and maintaining a good relationship with stakeholders is one of the most important parts of any Project Manager, Scrum Master, Product Owner, or Business Analyst’s job. One of the key techniques for managing that relationship is the Stakeholder Matrix. It is also referred to in the PMBoK as the Power/Interest Grid, Power/Influence Grid, or Impact/Influence Grid.

Whether you actually draw it out or you do the math in your head, the purpose of this diagram is to help a BA, SM, PO, or PM understand how they should be interacting with or what they should be providing to a stakeholder.

High Influence And High Impact >>> You are told to engage this group regularly

High Influence But Low Impact >>> You are told to consult with them

Low Influence But High Impact >>> You are told to show interest in their needs

Low Influence And Low Impact >>> You are told to just keep them informed

Identifying what you should do for your stakeholders is only one part of the equation. You should also understand what they can do for you and your team. Let’s add a twist or a little “Disruptive Thinking” to the stakeholder matrix. How are these stakeholders or key people likely to add value to your project or tasks?