Tag: Change Management

BA Evolution: New Leadership for New Times

Written by Traci Onkst on May 14, 2020. Posted in Articles.

The pace of change has been a topic of conversation the last few years.

We talk about digitalization and our need to constantly innovate to meet the expectations of our customers. At some point, we are those customers and must learn how to consume that flow of innovation. Add in the financial facing component and our need to respond to that ever-changing landscape and you can see why change is the topic of many conversations. But, did you for one minute ever expect a pandemic? A crisis of this magnitude wasn’t even part of our wildest consideration as we started to think about the changes facing us in 2020. In hindsight, the magnitude of the changes we thought were going to overwhelm us almost seem trivial in comparison to what we face now.

The way people react to all this will vary substantially. Some will be stoic and persevere as if little has changed, some will panic, and others will see it as an opportunity. Maybe I’m more of the latter. Change is here and we will probably be forever changed in so many ways going forward. The families experiencing loss of a loved one will surely never experience their old normal again. For that I am sad to my soul.

As we respect the threat this virus presents to our health and lives, we do have some choice in our overall response. It’s been said that in a time of crisis you can identify the true leaders. We need and appreciate people that provide vision, organize tasks and help us move forward. But leadership is so much more, and I have forever maintained that BAs are leaders by definition.

At the heart, leadership is service. As BAs, our service is to help solve problems by applying creative thinking and analysis and present those insights through visualization so others can gain clarity and collaborate around the issue. As the questions about the future mount, we need that service now more than ever. As a BA we should be reflecting on the future. Analyze. Be creative. Think outside the box. Where are the new needs, what are the new gaps and what will we do to fill them? Every time in history, major threats and change left new opportunities to provide service. Where are our new opportunities to serve? What outcomes can we influence for the better? Where can we add value to people and their new way of working? How does the BA role evolve in response to all this? While our BA purpose has not changed, the way we execute the role may. How will you serve and demonstrate your BA leadership as we march forward into our new tomorrow?

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.

Creative Dispute Α Business Analyst’s Personal Characteristic

Written by Giorgos Sioutzos on April 23, 2020. Posted in Articles. 2 Comments on Creative Dispute Α Business Analyst’s Personal Characteristic

A business analyst has to continuously ask questions and to critically translate the information he collects into clear needs and requirements.

It’s the inner trigger that has to lead a professional to find the deep problems and to reveal the actuals needs of stakeholders. A business analyst is not only a recorder of needs and requirements. He has to critically evaluate different needs and to confirm that the actual problems and their causes are fullfield by the suggested solutions. A pathetic view and record here is not enough. Critically judging and sometimes challenging the status quo can lead to meaningful solutions that will add value to all stakeholders and a win-win outcome will be possible.

Creative Dispute and asking questions can be applied across all the business analysis pipeline. For example:

Business Justification:

The business justification is the reason for the project and for the business analysis work concerning the project. Without it no project should start. If business justification is valid at the start of a project, but disappears once it is under way, the project should be stopped or changed. An analyst must have always in mind what is the aim of the project and which actual needs is fulfilling. He has to continuously ask if this action or step is aligned will the overall project scope and if it is meaningful.

Tailoring- Plan Business Analysis Approach:

Αs a business analyst you have to continuously ask where the standard methodology can be applied. What we have to tailor and what parameterizations are needed in order to have the best outcome? This is an ongoing question.

Business analysis pipeline involves selecting the appropriate business analysis processes, tools, techniques, inputs, and outputs for use on a specific portfolio, program, or project. The business analyst performs this selection activity in collaboration with the project manager, sponsor, functional managers, other business analysts, or some combination thereof.

Analyze Current State:

As a business analyst you need to describe accurate and realistic the current state. Assess Current State is the process of examining the current environment to understand important factors that are internal or external to the organization, which may be the cause or reason for a problem or opportunity. The key benefit of this process is that it provides a sufficient understanding of the existing state of the organization, providing context for determining which elements of the current state will remain unchanged and which changes are necessary to achieve the future state. Which are the current state and the non-obvious visible competencies that can lead to success?

Elicit Requirements- Confirm Elicitation Results:

Ηere you have to actively try to obtain information from stakeholders and confirm the results. It’s not only to keep notes of the information and to track the requirements. You have to critically evaluate the aspirations expressed by stakeholders and to form clearly the requirements in a way that support the actual business need(s). Confirm Elicitation Results activity involves ensuring that stakeholders have a shared understanding of the outcomes of elicitation, that elicited information is recorded appropriately, and that the business analyst has the information sought from an elicitation activity.

Business Analysis is the field where critical questioning and challenging is the basis of the everyday tasks. Challenging well established formulas and approaches is something that may lead to better outcomes.

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.

Needs Assessment Τhe start of BA Journey

Written by Giorgos Sioutzos on March 19, 2020. Posted in Articles.

Identifying the actual needs concerning a project is one of Business Analysis activities. Needs are requests for change.

A change that has as an aim to move organization from a current state to a future state. The future state must be aligned with the organization’s strategic goals and aspirations. Business goals and objectives align to the organizational goals and objectives, but are at a lower level because they specify stated targets that the business is seeking to achieve. Achieving the future desirable state implies needs and solutions to these needs. It implies actions that must be taken.

Clearly defined strategic long term goals are vital for alignment of the future state description which is expressed with lower level goals to the desirable one. The future state has to be a “dreamland” with the sense that fulfills in the best way the expectations of all parties connected directly or indirectly with the organization.

Let’s explore the steps a business analyst has to take in order to perform a need assessment:

1. Ιdentify Problem or opportunity:

Τhis is actually the trigger for initiating a need assessment activity. There must be a potential threat or an opportunity that can be converted to a really valuable situation. Observing environmental factors and continues informal or formal cross department discussions are necessary in this stage.

2. Assess Current state:

Current state assessments are performed to learn enough about the problem or opportunity to adequately understand the situation without the need for conducting a full analysis of requirements. Information about the current state may be obtained through various elicitation methods such as document analysis, interviews, observation, and surveys.

The difficulty here is to achieve a realistic depiction of current state. Different departments and teams may have a different image of the current state. Is the job of a BA professional to conclude to the most accurate and realistic description of current state. There is a first level current state which can easily be extracted by KPIs and other sources of information and a second level current state which can be detected only after deep understanding and specific elicitation activities.

3. Determine Future State:

Determining the future state involves conducting further elicitation and analysis to define the changes necessary to address the business need to determine which existing capabilities should remain or which new capabilities should be added.

Future state statement must be clearly defined and measurable. Goals must be aligned with the organizations long term goals and to be mirror the strategic high level objectives.

It is really import to achieve common understanding about the future state. Common understanding is different from common view. It means that all the parties understand which the future desirable situation is as it was formulated by all stakeholders with compromises and agreements.

Once an understanding about the future state is obtained, business goals and objectives are created to succinctly communicate what the business wants a portfolio, program, or project to deliver.

4. Define the Gap And Proceed to Recommendations:

The required capabilities and features identify the list of net changes the organization needs to obtain in order to achieve the desired future state. The capabilities and features listed do not prescribe a solution. Additional analysis is still needed to determine how these capabilities and features will be delivered.