Tag: Tools

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

Design Thinking in a Waterfall World

Written by Oluwakorede Asuni on June 24, 2020. Posted in Articles.

As much as we like to think we are now in a dynamic and agile world, most delivery initiatives are still some shades of agile and all shades of waterfall.

These initiatives could have adopted an agile outlook and naming convention, but the businesses they support are often still predominantly waterfall – going from one clearly defined task to another until realizing value. Think for example, order to cash, just in time logistics etc.

We often have some outliers, mostly modern businesses without legacy overloads and whose core business is digital or relies heavily on digital who may have cracked the agility question.

Waterfall is seen by most agile advocates as a relic of a time that had been and that should be forgotten and buried.

Waterfall is expensive, time consuming and unforgiving of errors.

Design thinking, on the other hand may be equally as expensive especially for organizations with legacy burdens switching over to an agile way of work, has picking up errors early built right into its DNA and offers opportunities to succeed quickly or fail fast.

A variation of the plan-do-check management methodology – the decision is easy to reach if one strips down the elements of the methodology into its bare bones fundamentals –design thinking allows the business or the delivery team to involve the customer for whom a product or service is being designed early on in the delivery effort. Design thinking offers up an opportunity to build a product truly needed by the customer and not one that was assumed the customer needs.

The question one ponders then is whether an enterprise or delivery team can only be one or the other? Or be both?

An important point of departure is that agility is a mindset, a mindset written into an organisations’ DNA and not only those of its project delivery teams. Agility does not rest solely on the tools and techniques that an organisation or its teams chooses to work with, rather it relies heavily on the collective agreement between teams and individuals; the capacity to work quickly, to experiment all the time, to learn fast and to be honest with itself all the time.

That said, with an agile mindset, design thinking techniques can be applied within each phase of the waterfall methodology.

For example, in the requirements phase of a waterfall project, the elements of design thinking’s empathise, define and ideate can readily be adopted. A bold team may and should also prototype and test their assumptions and some of the features of their product/service with real customers. Done well, the requirements phase of a waterfall project doesn’t then just end with a signed off requirements specification, but also the knowledge of what the customer truly wants backed with empirical data. And potentially the design and implementation phases have a ton of knowledge of the market to go on with – in essence most of the work in these phases of waterfall delivery would have been completed during the define stage as done as described above.

The actual waterfall phases of design and implementation then just becomes opportunities for refinements of the work done in the requirement phase using design thinking, and for honouring the legacy requirements of phase gates.

The refinement efforts in each of the design and implementation phases could also leverage design thinking. For example, the design phase of waterfall could leverage prototyping and test multiple user experience approaches – building on the work started during requirements. And in the implementation phase will build based on the output from the design phase which has determined with a high degree of accuracy what the customer truly wants.

The test phase of the waterfall delivery effort, may end up being systems’ tests (regression and systems integration tests) and confirmatory usability tests – as actual usability tests would have been completed upfront during requirements and design phases where the team had brought in the real customers to empathise with, define and ideate with, prototype for and tested with.

One can then safely conclude that waterfall can co-exist with design thinking (and really most other agile techniques) if the organisation’s mindset focused on agility and not processes for the sake of processes.

The Benefits of Mapping Benefits

Written by Anna Rajander on June 18, 2020. Posted in Articles.

It is generally accepted that projects should deliver benefits – it’s a projects raison d’etre.

Yet projects often focus on the delivery of products, losing the link between project activities and business benefits. As a business analyst working in the public sector, I find this frustrating – projects should focus on the delivery of benefits.

Benefits mapping is useful analysis technique for understanding the links between project activities and benefits. Benefits maps provide a visual representation of the links between project activities and the delivery of benefits. As such, they can be used to foster a benefits-focused approach to project delivery.

What is a Benefits Map?

A benefits map (or benefits dependency network) is a useful technique for understanding how a project will deliver business benefits. According to the BCS, a benefits map is “A diagrammatic representation of what needs to be done on a project/program in order to achieve its expected benefit”. The idea is simple – link project activities to the benefits they directly impact.

There is no clear ‘standard’ for producing benefits maps. There are numerous variations, many of which are relevant to specific types of project of business initiative. However, the following elements generally apply to all projects and/or change initiatives:

Enabling Changes – project deliverables/activities that support the delivery of a larger business change/deliverable
Business Changes – the changes that project/initiative will implement
Business Benefit – a measurable benefit that will be delivered as a result of a Business Change
Objective – the project and/or business objectives supported by the project
Strategic Goal / Business Driver (optional) – the overall goal, vision or threat that is driving the delivery of the project

Project deliverables and activities (or ‘Enabling Changes’) are mapped to Business Change deliverables, which in turn are mapped to the overall Benefits of the change. Benefit maps can then be extended to link Business Benefits to Project Objectives, which in turn should be linked to a Strategic Goal or Business Driver. As the example below shows, the result is a visual representation that clearly demonstrates the connection between project activities and an organisation’s strategic intent.

The relationship between changes, benefits and objectives is not always a one-to-one relationship. Below is a benefits map for a fictitious project to build and move a family into a new house. Although it sounds rather simplistic, further analysis of the changes, benefits and objectives shows the relationships between them are not clear cut.

Of course, this is my benefits map for my project to build a family home. My objectives and benefits may be different to someone else who is undertaking a similar project to build a house. Thus, while some of the project activities and changes may be the same, the benefits and objectives are likely to be different. The same logic applies to different organisations undertaking similar projects – you are unlikely to ever come across two benefits maps that are the same.

To get the most out of a benefits map, it should be produced early in a project/initiative, updated regularly, and reference throughout the project to keep the focus on benefits delivery.

Why Map Benefits

There are several reasons to map benefits. The most obvious is to assist in benefits planning and realisation – understanding what, how and when business changes are expected to deliver business benefits provides a basis for benefits planning and realisation activities. However, benefits maps can be used as a project management analysis technique to create a common understanding across several areas of a project.

Communication: Understand Why

Benefits maps are a useful technique for understanding and communicating the impact of a project from different stakeholder perspectives. Large projects/programs can consist of many moving parts, making it difficult for individual staff to see why certain activities or deliverables are considered important. It can also be difficult for business stakeholders to understand why they may need to change, and for managers to understand why certain activities are important. Benefits maps can support understanding across stakeholder perspective by allowing:

project delivery staff to clearly see how the activities they undertake impact the delivery of benefits and, thus, contribute to the overall success of the project
stakeholders to understand the benefits of change
managers to understand the link between project activities and strategic objectives.

Risks: Assess Impact

Benefits maps can be used as a tool for quantifying project risks. By creating a clear link between project activities and benefits, benefit maps allow for risks associated with the delivery of project activities to be quantified in terms of the benefits they impact. Benefits maps are also useful in assessing the impact of a change to a projects budget, scope or timeline, supporting the assessment of any project change in terms of the benefits delivered.

Plans: Deliver Benefits

Benefits maps can be a useful tool for planning project activities. In much the same way as a Product Breakdown Structure is used to deconstruct project deliverables, benefits maps can be used to deconstruct what needs to be done in order to achieve a business benefit. The main difference between a Product Breakdown Structure and a benefits map is that the focus is on the business change and the benefits, rather than the deliverable.

As a business analyst involved in the project feasibility and initiation, I find benefits maps a much more powerful technique compared with product breakdown structures. Linking project activities to business benefits is a good way to justify project work and cost estimates. Benefits maps can also assist in constructing a business case narrative that describes how a project links with an organisations strategic objectives.

Conclusion

Benefit maps are a powerful analysis technique for supporting project management. Benefits can provide a common reference point when prioritising project activities, quantifying project risk, and communicating with stakeholders. To get maximum benefit from a benefit map, the benefits should be mapped early and referenced often to ensure a project stays focused on the delivery of benefits.

Applying Maslow’s theory of Needs to Business Analysis

Written by Ashish Adike on June 17, 2020. Posted in Articles.

Having worked on multiple IT implementations and Transformation projects I have often found the evolution of user’s requirements follow the Maslow’s theory of needs.

Adoption of this theory in the requirement gathering process would turn out be fruitful for Business Analysts in efficient Requirement Elicitation from the Users.

Although most of us are aware about the Maslow’s Theory of needs, a quick memory refresh would be helpful:

Maslow’s hierarchy of needs displays the order of human needs in the form of a Pyramid with lowest levels made up of most basic needs moving on to the top of the pyramid with complex needs as depicted below.

Physiological Needs: The basic human requirements to survive would comprise the Physiological needs like Food, Water, warmth, and rest.

Security/Safety: Once the Physiological needs are satisfied, the need for security and safety arises. This comprises of financial, emotional, social security, and health and well-being.

Love/Belonging: These needs are driven by interpersonal relations like friendship, love, trust and acceptance among individuals.

Self-Esteem: The fourth level of needs arise out of the feelings of getting praised by others for self-accomplishments be it professional, academic, athletic, or personal.

Self-Actualization: The final level of needs reflects the realization of individuals to utilize the complete potential, so that they can do the best that they are capable of doing.

Now coming back to our original discussion on following the Maslow’s theory of needs for requirements elicitation, the below framework often works to elicit requirements from users starting from basic system requirements to the complex analytical requirements to explore the full potential of the system.

The 5 evolving stages of requirements are Data Capture, Data Security, System Integration, User Experience, and Analytical Capabilities. As we progress from bottom to top of the pyramid, the responsibility of BA to make recommendations to elicit the requirements from the users increases. Let us look at each of these stages by taking an example of a Salesforce CRM implementation

1. Data Capture:

The first stage is critical and forms the major portion of requirements as this serves as the foundation of the implementation just like the Physiological needs serve as the base for human survival.

In general, any IT implementation would start with a problem statement where the Business has an issue with missing data capture or users spending their valuable time on mundane repetitive tasks which could be automated. It is the responsibility of the Business Analyst to capture the basic needs from users in terms of data they would like to capture, and the level of automation required to perform their everyday job.

In our example of Salesforce implementation, the information that needs to be captured like Leads, Opportunities, Accounts, Contacts need to be captured at parameter level with respective UI forms for data capture along with validations. Also, the automations that govern the system functionality need to be captured. For example, updating a parameter in Accounts from the corresponding parameter on Contact.

2. Data Security:

Once the basic requirements are established with respect to Data storage, User Interface and automations, the security of the data recorded in the system becomes critical just like need for Security in human life.

Different sets of users would need access to different data elements and the level of access in terms of Read/Write would differ as well. The BA needs to carefully gather the requirements of Data Security from users and work on profiling of these users.

In our example of Salesforce implementation, the Sales team would needs read/write access on Opportunity data whereas the Finance team would only need read access to Opportunities to perform forecasting and the Operations team might not need access to Opportunity data at all. There would also be scenario when one Sales Representative would not want other Sales Representative to access his Opportunity data. Hence, the Security of the data forms the next level of User needs in order to feel secure while using the application.

3. Data Integration:

Once the data is recorded in the system and is secure within the system, the next need is to have communication with other systems so that there is proper exchange of information between the systems to complete the end to end transactions. This is like the need for interpersonal relations like friendship between humans.

Different systems serve as the system of record for different data elements within an IT Architecture. Also, in most cases there is always a Master data system where all the critical data gets stored. As a BA it is important to identify the need for the required data for an application to work as expected and identify the downstream systems which would use the data from the application. This information may not be directly provided by the end users, but it is the responsibility of the BA to study the IT landscape and identify the different source and destinations of data.

In our case of Salesforce implementation, the Customer Account information would generally be recorded in the ERP, so Salesforce needs to integrate with the ERP to get the Account information. The Order information from Salesforce was used by downstream order fulfillment application, so Salesforce needs to integrate with this downstream application to complete the Order fulfilment process.

4. User Experience:

Once a working system is in place with the required basic functionalities to fulfill everyday job of the user, the user experience factor comes in which would further drive the requirements to make the system more user friendly and intuitive, hence leading to appreciation of the system by the users. This is like the self-esteem needs of human life.

Now that the basic functional requirements from the user are gathered, it is the responsibility of the BA to drive the requirements for better user experience. This would encompass aesthetic requirements like the look and feel of screens, user guidance while using the system, mobile usability etc. Although this type of requirements might not sound critical during the initial implementations, they turn out to be critical once the users start using the system, and there have been projects purely focusing on improving user experience.

In our case of Salesforce implementation, the choice between using Salesforce classic which is traditional user interface as compared to Salesforce Lightning which has an advanced User Interface would be critical in determining the user experience.

5. Analytical Capabilities:

Once the requirements for a fully functional and user friendly system are established, the insights that the data stored in the system could provide to the user becomes important, as it would enable the user to utilize the complete potential of the system and make business decisions. This is like the need for realization of individuals to utilize the complete potential so that they can do the best that they are capable of doing.

The Analytical requirements would be predominantly in the form of Reports and Dashboards that could be derived from the data stored in a system. With the advancement in Artificial Intelligence, the data could be used to provide suggestions to the user as well. Many a times, the user may not be directly able to give requirements with respect to Analytical capabilities, so the BA needs to determine the KPIs for the business users and recommend the suitable reports and dashboards around the same.

In our case of Salesforce implementation, once the Sales users have a well-functioning Opportunities module in Salesforce, it would be great if they are able to generate reports on the Opportunity pipeline and even better if they have a dashboard depicting the Opportunity Pipeline which would enable them to make quick decisions.

Requirement elicitation is often complex with users not being able to articulate the exact requirements in a proper order. Following the bottom-up approach from the Pyramid would help to a great extent in eliciting the requirements from users, starting from basic to the complex requirements.

References:

1. https://www.simplypsychology.org/maslow.html

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.