Tag: Planning

The Power Of Scenario Planning

Written by Christina Lovelock on July 30, 2020. Posted in Articles. 1 Comment on The Power Of Scenario Planning

True busines agility is achieved by considering what might happen in the future, and developing an outline response.

No one could have PREDICTED the current global situation, but some organisations were better PREPARED for it.

Whether you are delivering projects, products or services, it’s all about the future.

Increasing profit/market share
Increasing customer loyalty
Improving customer experience
Improving quality
Developing and retaining staff
Diversifying the offering
Decreasing costs
Reducing complexity

Each of these aims can be followed by the phrase “in the future”, as that is where they all reside. Most organisations believe they are thinking about the future, but they are usually just extrapolating the present, and that’s not the same thing at all.

What is Scenario Planning?

Scenario planning is a strategic analysis tool which recognises the future is uncertain and unpredictable, and encourages us to explore how we can prepare for it.

There are three broad steps to scenario planning:

Consider what is the current reality for the organisation and wider world, and how that might be different in future.
Consider what those differences would mean for the organisation.
Act on this new knowledge. (This might be: develop a plan, mitigate a risk, explore an opportunity…).

There are many models that facilitate the process of scenario planning, which is usually run as a series of workshops with relevant stakeholders.

Advantages of Scenario Planning

1. Framework

Scenario planning provides an opportunity and framework for people to contribute their fears and ideas in a legitimised and structured way. It’s proactive, and removes some of the worry of being perceived as ‘doom-monger’.

2. Awareness

It encourages us to think outside of our organisational boundaries, and lift our heads from the day-to-day rhythm and routine of work. It asks: what’s going on in our organisation? our sector? the wider economy? in society? for our customers? for our suppliers? and for our staff?

How might this impact our organisation in the future, and what can we do about it?

3. Calm

Scenario planning allows options to be really evaluated, and decisions to be taken before a situation actually occurs. In the face of a crisis, organisational and individual biases can cloud could good judgement, speed of response can overlook better options and fear and blame can impact relationships. It creates the time for a ‘plan for a plan’. Scenario planning offers no certainties, but gives the opportunity to identify indicators: “If we start to see X happening, then person Y will do Z”.

(Yes, some people supposedly thrive under pressure and enjoy adrenaline fuelled situations, but this is not business agility.)

4. Competitive advantage

If we are considering the future and preparing for it while others are not, this gives us a clear advantage. We will be able to respond rather than react, move more quickly and demonstrate our organisational agility.

Common Traps of Scenario Planning

1. ‘Waste of time’

Because many, perhaps most, of the scenarios won’t actually happen, investing time in thinking about them may seem like a waste of time and effort. This may prevent a full range of scenarios from being effectively developed and discussed.

Most people have enough to worry about in their ‘day job’, and do not want to go exploring for further problems. This is narrow thinking and prevents business agility.

2. ‘Lack of imagination’

Some people cannot imagine a different world, and others can imagine it but are embarrassed to describe it. Many organisations do ‘financial planning’ by using a small number of variables (costs, predicated growth etc.) and model best, worst and most likely scenarios. This is safe thinking, and is unlikely to lead to any major breakthrough in organisation

3. ‘Overwhelmed’

It would be relatively easy for even a small group to come up with dozens of plausible scenarios, and generate hundreds of potential actions in just a few hours. Generating the scenarios, then narrowing them down to a manageable number is part of the processes. The discussion about the potential scenarios is often more valuable than identifying every possible future.

4. ‘File in the draw’

If no action is taken as a result of the scenario planning, then the value of the exercise will not be realised. ‘Action’ could range from agreeing options or decisions that will be made in certain situations to making significant changes in strategy or operations as a result of the information the exercise has revealed.

Conclusion

Organisations which can adapt will survive and thrive. The ability to adapt quickly is about giving people the time and space to consider how to respond to a range of scenarios, most of which will not come to pass. But for the ones that do – we ‘ll be ready. For the scenarios we didn’t see coming, our organisations will be more able to adapt because we recognise that the tomorrow cannot be extrapolated from today.

Reference:

Scenario Planning, Woody Wade, 2012

Forget SMART, Aim 4A Goal!

Written by Christina Lovelock on May 28, 2020. Posted in Articles. 1 Comment on Forget SMART, Aim 4A Goal!

The SMART acronym is considered best practice for objective setting, yet somehow objectives which are ‘made SMART’ become uninspiring and unintelligible.

We are told that individual, team and organisational objectives need to be SMART (Specific, Measurable, Achievable, Realistic/ Relevant, Timebound). For the most part, goals and objectives should be something we set because we want to achieve them, but when we cryptically re-word, strip back to the specifics, take out the inspiration by dialling down to realistic and attach an (often) arbitrary deadline, they seem to lose their appeal.

How can we create goals we are actually inspired to work towards? By simplifying the processes and asking ourselves good questions.

Aim 4A Goal

4A is Achieve/Avoid/ Action Analysis. By creating an engaging table or diagram we can frame a goal that motivates us, identify what we need to be aware on pursuit of that goal and identify the next steps towards achieving it. Notice that is next steps, not every step. It is impossible to predict the future, but we can usually identify the activities which are a step in the right direction of the goal, even if we cannot yet see every move we will need to make.

Here are some of the questions to help to understand the goal and how to get there.

Achieve

It’s difficult to work out what your goals are, it may need some dedicated time and a few false starts to get to the real goal(s).

what do you want to do?
when do you want to do it by?
why?

It’s ok to aim big, it can be broken down into steps, many of which you might not know yet. It’s also fine to have a very narrow scope, that can be achieved through a very small number of actions. The key is to be sufficiently motivated to do the actions!

Avoid

Most things can be achieved, with enough time and attention, but at what cost? In the pursuit of goals we must consider the things which might distract us, and also the things we are unwilling to compromise on to achieve the goal.

what are the potential pit-falls?
what might get in the way?
what might be the unwanted impacts (on myself and others)?
what do I need to ensure I don’t neglect, in pursuit of this goal?
what risks am I unwilling to take?
what behaviours am I unwilling to engage in?
who might prevent it? (be honest).

Just as important as planning the things we will do, is to identify the things we will have to give up or are unwilling to do.

Action:

Actions need to be tailored to address the goal, and avoid the issues identified. If we don’t highlight the things we want to avoid, we may take the wrong actions.

what can I do right now that moves me closer to my goal?
who can help or advise me?

For every action we take, we can ask “Is this contributing to my goal?” If not, we may still choose to do it, but consciously rather than inadvertently. Add actions to the list as they become apparent, and the next best step to take.

Example Goal

Achieve: Speak at a conference or event in the next 12 months.

Avoid: Excessive travel costs, impact on my project work.

Actions: Identify local events, find out submission process and deadline, develop sessions ideas at weekends.

When these actions are complete, identify the next steps which move towards the goal.

Decision making

Achieve/Avoid/ Action Analysis (4A) is also incredibly useful as a decision making framework. It helps keep everyone on track – “what are we trying to accomplish with the outcome of this decision?”, “what impacts don’t we want”, “what possible actions achieve the outcome and avoid the impacts?”. Often group decision making is difficult because people are not trying to achieve the same thing from the decision. Using 4A give the opportunity to build consensus on what we are working towards, address concerns via the ‘avoid’ list and jointly agree the actions which best hold the ‘achieve’ and ‘avoid’ elements in balance.

Example Decision: “Shall we reduce the training budget to save money?”

Achieve: Cost savings of X in this financial year

Avoid: Impacting staff morale, having people who do not know how to do their job, impacting customer service.

Actions: Investigate online delivery options, prioritise the training needs, defer some of the training, use train-the-trainer approach.

Conclusion

SMART has had its chance, and it wasn’t helping. Set goals that inspire and motivate you, work out what you need to avoid in the pursuit of those goals, then develop a plan to achieve them.

We also need to accept that we may need to change our goals. We may decide we don’t want to achieve what we once thought was important. Don’t work towards something you no longer want, just because you wrote it down or told a few people. In that case, Aim 4A New Goal, work out what that looks like, what you need to avoid, and what next step you can take.

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.

What your burndown charts are telling you

Written by Nick Stowers on April 2, 2020. Posted in Articles.

When I was introduced to scrum, the burndown chart was a tool that was highly emphasised however I feel the purpose has changed

from it being a tool to predict (to a certain level) timescales for delivery to a tool that measures a team’s productivity…..in other words, the focus is on the number of points cleared which in my eyes, drives some adverse behaviours.

In this blog, I’d like to show some example burndown charts I’ve come across in teams I’ve been part of as a Business Analyst and what they should be telling you about how the team is operating. I’ll also offer some suggestions to fix what could be barriers to becoming that high performing agile team we strive to be.

So what is the purpose of a burndown chart?

A couple of quotes:

‘Burn down charts are a run chart of outstanding work. It is useful for predicting when all of the work will be completed’- Wikipedia, 2019 <“>https://www.mountaingoatsoftware.com/agile/scrum/scrum-tools/release-burndown>

We can take it from both of these quotes that the purpose of the burndown chart is to be able to visually see progress through a sprint, however I’d like to emphasise Mike’s point in his description that it ‘is a way to clearly see what is happening…during each sprint’. On many of the teams I’ve worked on, if not most, burndown charts are not reviewed at all but only looked at if someone outside the team wants to see them.

I’m well aware every burndown chart will have its own unique story behind it so when I give what I think are reasons behind the chart in the examples below, I’m only hypothesising from my own experiences. And while the burndown doesn’t tell the whole story, in my experience the analysing of them (with the whole team of course) has always improved the ways of working and that is the purpose of this blog.

Note: in the examples below, each sprint is 2 weeks long with the grey line depicting expected burndown with the red line the actual.

Example 1

The ‘Manhattan skyline’ burndown

Possible reasons

Ok, it’s not exactly like wonderful Manhattan but you get the idea (up and down peaks across the sprint). I think the two key parts of this burndown are the long flatlines at the beginning and midway through the sprint and the spike 3 days in. While this doesn’t affect the sprint points (what points/stories have been added have then been removed), it suggests the team weren’t confident of completing what was going in to the sprint for a significant increase (30 points). Or possibly, the stories weren’t ‘ready’ for the sprint. Also, have the team bitten off more than they can chew during sprint planning as there are 10-20 points left on the table at the end of the sprint?

How to fix

During sprint planning, ensure all the stories that are sprint candidates have met the team’s ‘Definition of ready’ and the team are confident that those stories that are being taken can be completed within the sprint. This may take some time for the team to get to this point as estimation and sprint planning (for me) are the two areas of Scrum that take most time before the team are comfortable with both aspects. And in my experience, if the team get these elements right (well estimated stories and confident planning), sprints tend to go pretty much as planned.

Example 2

The burn down-up-down-up chart

Possible reasons

I think it’s fair to assume this team is clearly having problems as you can plainly see but what might be the potential cause of this erratic burndown (or burn across!!)? Firstly, it’s clear the team have taken on way too many points for the sprint. Of course, there could have been an issue near the end of the sprint that caused the team to stop developing but even so, to fall short by 30+ points should be saying something. Long flatline periods suggests stories weren’t small enough to deliver incrementally. Large increases in points mid-sprint suggests the team have not been disciplined enough in saying ‘no’ to new stories being added. If these stories had not been added (20+ points), then the team may have achieved its target.

How to fix

Don’t be fixated by how many points can be done in a sprint. Just because the team did 60 points in the previous sprint, don’t assume the team can do it again the following sprint. I’m a big fan of Mike Cohn’s ‘Capacity-driven planning’ and I feel it’s the team’s responsibility to confidently be able to say, ‘yes, we can commit to everything in this sprint’. In velocity-driven sprint planning, I tend to see the thought process of what was achieved last sprint and therefore what stories can we cram in to achieve the same number of points or more. I think this approach is counter-productive and brings wariness to the team’s ability to confidently commit to the sprint. Therefore, ask the question, ‘what can we confidently achieve in this sprint?’ as opposed to ‘how many points should we do in this sprint?’

Example 3

The Flatliner

Possible reasons

My first thoughts on seeing this burndown was, ’should you even be using agile as a framework for delivering your project?’. I think you’ll agree that from day 1 of the sprint, 35 points have been added before work’s even started. Then there are no points (or virtually no points) cleared for 8 days before a big drop of 20 points and with still 40+ points left on the table. It could be this team is very early in its agile journey and therefore are unclear on their velocity (hence so many points) but still, loading up a sprint with no idea as to velocity suggests immaturity of an Agile delivery framework.

How to fix

In my view, the type of work being carried out by the team might suggest they’re unable to deliver iteratively and therefore may be better suited to a Kanban than a sprint approach. It could be they require the use of an Agile coach or Scrum Master for a period of time to set them on the right track and start from a position where they can clear what stories they take in to sprint and build up their velocity.

Conclusion

I hope those reading this are familiar with these types of burndown charts or if you’re new to Agile and you’re utilising burndowns, my point here is to make sure you use them to analyse how the team is performing and how that performance can be improved. Of course, your retrospectives are the perfect forum to do this.

I should make a couple of points though. Firstly, don’t look at a burndown chart in isolation. I’d look at the last 3-5 to see if there are patterns emerging before you embark on working to improve. Do they look the same or do they look completely different over a period of sprints?

Secondly, don’t place too much emphasis on them. You might think that’s odd as that’s what this blog is about however, as I mentioned, each sprint is unique and each burndown will have some sort of story behind it so use them as a discussion point for the team to improve, and not the be-all and end-all to improve the team’s performance.

As a Business Analyst, I nearly always find the reason why teams don’t deliver in small increments during a sprint, and therefore creating the burndown chart examples in this blog, is down to the user stories. No that user stories are the be all and end all but invariably I find it comes down to the stories either not following the INVEST model or them not being ‘ready’ for the sprint. If you get this part right then your sprints should run smoother and your burndown chart will reflect that.

So don’t ignore your burndowns (or burnups if that’s your preferred method), and if the team’s struggling to complete its sprints, spend some time analysing them to see where the team can improve.

Measuring Business Analysis Efforts: The KPIs That Matter in 2020

Written by Jennifer Hahn Masterson on March 6, 2020. Posted in Articles.

Not so long time ago, the business analysis used to refer to a job of a person employed as a business analyst, mainly in a corporate setting.

However, we often forget that business analysis is a whole discipline that includes tasks and techniques that analyse the structure, policies, and operations of a company so it can recommend solutions that lead to achieving its business goals. To be effective, though, business analysts need specific KPIs (Key Performance Indicators) that include criteria on which individual performances are evaluated.

Process optimization KPIs

The percentage of Business Process Productivity Increase is observed as the actual increase in productivity after a new system was implemented. The percentage of Cycle Time Reduction is a cycle time reduction after the system was implemented. Unit Cost is defined as the reduction of unit cost within a 6-month period after the new solution is introduced. Increase in Revenue as a Result of Solution is the fourth indicator that refers to the actual increase of revenue as attributed to the solution.

Project value KPIs

The first one is the Deviation of Planned ROI, which is the difference between the actual ROI and ROI in the planned baseline. Deviation of Net Present Value (NPV) is the deviation in value between the planned baseline against the actual net present value. Deviation of Planned Break-even Time is defined as the differences in time between the actual break-even time and the planned baseline, in which the business costs are equal to the generated income.

Quality effectiveness KPIs

Percentage of Rework Attributable to Requirements can be expensive, amounting up to 40% of the total budget, while up to 70% falls on inaccurate or ambiguous requirements. Percentage of Projects with Prioritized Requirements identifies which projects to prioritise to ensure that only high-value items are taken into consideration. Percentage of Requirements Fully Implemented allows business analysts to track requirements through testing, proper designs, and accurate deployment.

Percentage of Approved Requirements Not Implemented evaluates the performance of the overall user experience and satisfaction with the result. Developer Requirements Satisfaction Index allows developers to express their satisfaction with requirements in the form of a survey. QA Requirements Satisfaction index includes survey results from QA that maintain the testability of requirements. Requirements Tested (%) shows what percentage of requirements were actually tested and which ones were not.

Digital marketing KPIs

Digital Marketing KPIs are quantifiable goals that help you track and measure the success of your marketing campaigns. By creating a specific digital marketing KPIs such as web traffic sources, cost per lead, online conversion rates, and customer lifetime value, analysts can identify targets and goals, but also measure business performance based on those value. Monitoring and reporting on so many KPIs aren’t only stressful, but also time-consuming unless analysts are using digital marketing reporting software that automates the process by integrating multiple data access points into real-time dashboards that are easy to read and report.

Project management KPIs

These KPIs are used to measure the performance of project management. Deviation of Planned Expenses is the difference in total costs between the actual budget and the planned baseline. Cost of Managing Processes is described as periodic process managing costs typically based on the number of Full-Time Equivalent (FTE) personnel involved in management functions of processes, which is then compared against the percentage of FTEs actually engaged in a project that were not initially assigned.

Budgeted Cost of Work Scheduled (BCWS) defines the cost of activities that are planned and scheduled for completion. Sometimes the ‘planned value’ term is used. Actual Cost of Work Performed (ACWP) is the sum of the actual costs of completed activities. Budgeted Cost of Work Performed (BCWP), also known as Earned Value is the sum of the planned or scheduled budget for completed activities. Cost Performance Index (CPI) defines the earned valued divided by the actual costs, while Cost Schedule Index (CSI) multiplies the CPI by SPI (Schedule Performance Index) to measure the likelihood of recovery for a project that has breached its budget or timeline.

Project portfolio KPIs

Alternatively, business performance analysts may evaluate the KPIs by looking into the project portfolio. The Percentage of Initiated Projects Without Business Case identifies projects that have missed important milestones, while the Percentage of Challenged Projects defines those that have either exceeded budget by 15%, delivered two months after the deadline, or failed to deliver the major scope of the project.

Stakeholder engagement KPIs

Stakeholder Satisfaction Index is defined as a series of interviews that determine overall satisfaction with the requirements. On the other hand, the number of Stakeholder Comments Received shows the total number of concerns and comments given by stakeholders with respect to the given requirements. Stakeholder Lifecycle Participation results from the total number of stakeholders who take part in lifecycle events and is usually shown as a percentage.

Further on, it’s important to determine the number of Key Stakeholders Not Identified or only identified in later stages of the project, as well as the number of Participating Stakeholders Interviewed or taken part in focus group discussions and events. The percentage of Stakeholder Attendance is defined as the percentage of stakeholders who turned up during meetings against the number of stakeholders invited. The number of Needs Recognized by Stakeholders identifies the number of needs that were successfully reconfigured as requirements.

Defining the essential KPIs is an important skill for anyone working on business improvement analysis. These indicators are usually captured or received from a combination of reports, surveys, spreadsheets, and charts where a developer determines target performance levels and identifies the variance from those target values.