In an age of digital disruption, when new start-ups are challenging incumbent market leaders from unexpected angles, when consumers and citizens are expecting more control over decisions that affect them, when the pace of change is still increasing, when we have to do more, with less, and faster ... we no longer have business as usual, so why would we do business analysis as usual?
When corporates, family businesses, and government bodies are progressively exploring new ways to do new things, why then are so many still applying traditional thinking and traditional approaches to the way they implement those changes?
Software development projects have gone through some serious remodelling, creating patterns of self-organising teams that build robust products incrementally and iteratively, getting fast feedback from customers to inform ongoing work.
Against this backdrop, why then does project management and business analysis still apply a planned sequential pattern of thinking to projects that require adaptive, divergent, and exploratory approaches?
Responding to this, in late 2015, Assurity’s Luke Johnstone announced the Lean Business Analysis Manifesto at the AgileNZ Conference, followed by me presenting this at the BA Development Day. The engaged discussion at those conferences led to sufficient ongoing interest to prompt an article explaining these ideas.
In a context of increasing disruption
How is the development of Lean Business Analysis a response to the ever-increasing pace of change?
Global trends
On a global scale, the history of humanity has been one of progressive change with moments of sudden innovation. Thousands of years in the past hunter-gatherers started settling down as farmers. Within the last few hundred years, land workers had to retrain to work in factories. Then around 50 years ago, computerisation led to a growth in the importance of knowledge workers.
Each of these shifts has led to changes in working patterns and possibilities. Gordon Moore found that technical capability doubles every year or so (Moore’s Law), describing an environment where change itself happens at an ever-increasing pace. We have now been through successive waves of digitalisation, leading to a world of wearable devices, an internet of things, and big data.
We are now in a time of ‘digital disruption’, of constantly shifting capabilities and expectations that cause a turbulent business environment. As soon as an organisation establishes how to serve its customers, the world shifts around them – with ever-more complex combinations of developments in technology, changes in regulation, natural disasters, global financial crises, and shifts in customer expectations.
Local problems
Within this larger global canvas, we had significant disruption taking place on a local scale too.
In September 2010 and February 2011, the South Island of New Zealand was rocked by two large earthquakes that resulted in fatalities and significant damage to infrastructure (utilities, roads and buildings) in the city of Christchurch and its surrounding area of Canterbury.
Through the initial response of the first 100 days, organisations needed clear guidance at speed—such as, when we helped insurance companies grapple with the thousands of claims that came in virtually overnight.
As the process of recovery began, people focused increasingly on producing what was needed when it was needed, on working with the right people at the right time, on building quality in from the outset, and on avoiding unnecessary steps that don’t add value. These four values became ingrained in how we approached our work.
For example, the recovery involved an unprecedented amount of demolition, repair and construction activity that needed to be coordinated to be successful. Land Information NZ initiated the ForwardWorks project, to build a map-based viewer for upcoming work—both above and below ground. The urgency, complexity and importance of the project meant that a fresh approach to business analysis was required.
Government-funded projects that involve third-party services should adhere to a formal Request for Proposal (RFP) process. However, this was a novel solution that could not be defined in advance. We used lightweight documentation to describe our needs, sufficient for the vendors to understand the value we wanted to realise and problems we needed to solve, without constraining their creativity.
The range of stakeholders was diverse: from construction workers, designers and planners, to local and central government. We had to involve them all on the journey to deliver, allowing that many had no experience of bespoke software development projects.
To ensure that quality was designed in, we produced functional prototypes to gain a shared understanding and to make minor adjustments as we went.
Finally, to keep reporting and governance to the bare minimum, we empowered key people to make decisions and insulated them from formal project management office (PMO) processes.
Coping with change
When experiencing any type of disruption, we need to be able to sense change, to speedily assess its impact, to discover the opportunities that arise, to explore what's possible, to select a solution and get it to market before anyone else, before the market itself changes.
While business analysis evolved to help change by being clear on what it is that really needs to change, it was born into a contract-driven world, where everything had to be established and agreed before anyone started work. This heavily governed approach slowed down the work of capturing the change required, of understanding the impact on people, process and technology, and of crafting an approach that delivers value while minimising impact.
As organisations adapted their approach to change and development to deal with the challenges and opportunities of digital disruption, they find that traditional business analysis and project management practices get in the way of delivery.
Against this backdrop, the concept of Lean Business Analysis found a ready home. Announced first at the AgileNZ Conference, the main tenets of Lean Business Analysis were expressed as four values (as a gesture of respect to the Agile Manifesto itself)—and this approach is now recognised as appropriate and useful on any type of project following any methodology.
'Lean' Business Analysis
Using the term ‘Lean’ was a mindful and intentional decision. The term itself originated in Lean Production approaches from Japan, where organisations adopt a systematic approach for eliminating waste by identifying activities that do not add value to the finished product. We have recast the original seven forms of waste (or Muda) in a way that made sense to a knowledge-based discipline like business analysis.
Unfinished work
Too much work in progress blocks new work being started and this has a significant impact on productivity. We need to ensure that work is ready for our teams to use, taking things to an appropriate level of detail on a just-in-time basis, leaving things to the last responsible moment rather than the last possible moment.
Unnecessary features
Working on unnecessary features takes time away from those that add value. Sometimes we are motivated to go the extra mile, to do something that will surprise or delight the customer. Nothing wrong with that if it is something they will use. Reports of what gets used indicate that nearly two-thirds of features are rarely or never used, while only one-fifth is always or often used. We need to focus on what will create a minimum lovable product.
Working in silos
When people don’t sit together to work, they typically have to hand the work over with accompanying documentation to explain what would be better covered face-to-face. Whenever we do this, we lose something in translation and cause delays. We need to be with our teams at least as much as we are spending time with stakeholders and customers.
Unnecessary process
Forcing work through steps that don’t add value slows down progress and productivity. Examples include unnecessary governance, inappropriate testing, or additional sign-offs. We need to be confident enough to call these out and advocate for simpler process (something BAs should be good at).
Context switching
Working on too many different things at the same time is inefficient. Each time we switch tasks from one context to another, we lose time in mentally putting down our tools for one area and mentally gearing up for the next. Some reports talk about losing as much as 20% of time for each major context switch, so if we’re working on several projects simultaneously, we risk having very little productive time. To make any headway, we need to organise our work so that we can focus on one thing at a time, for at least 45 minutes.
Waiting in line
We lose time when we are waiting for stakeholders to make a decision, for key people to become available, or for earlier tasks on a job to be completed before we can start our work. This is often results in people rushing to complete work too quickly leading to mistakes being made. We need to break work down into smaller chunks, improve the flow of work, and collaborate more so that no-one is ever left with nothing to do or with too much to do.
Rework
When quality is not built in from the outset, problems will arise. The later problems are detected, the more expensive it is to put them right. Bad requirements lead to bad design and ambiguous requirements could be untestable or inappropriate. This slows down delivery and affects our customers. We need to take enough time to get it right first time, Recognising that this is not solely our responsibility, we involve others in specifications so it is a team effort.
Knowledge hoarding
Finally, to these original seven forms of waste it is increasingly common to consider an eighth, knowledge hoarding. In work that is knowledge intensive, such as software development, organisation change, or process improvement, it is vital to share knowledge. To work collaboratively in cross-functional teams, we need to be open about our discipline, offering to pair up on work so that we can learn from one another.
What changes?
In implementing Lean Business Analysis in your organisation, these are the changes you would expect to see:
Last responsible moment
Our first Manifesto value is ‘Producing what is needed when it is needed’:
The practical impact of this is rethinking the timing and frequency of activities and outputs. Quite often, following traditional methods, we would do all the analysis up front, before any design is done. This typically led to a lot of rework when new areas or changes are discovered or from feedback once design, development, or testing has started.
Following the principle of the ‘last responsible moment’, we should focus on producing what is required just as it is needed. Sometimes, the last responsible moment to do something could still be right at the beginning of a project. An example of this might be a complex architectural decision that will have an impact on many dependent areas.
Timely collaboration
Our second Manifesto value is ‘Working with the right people at the right time’:
The practical impact of this is rethinking the timing and frequency of how we work together. Quite often, following traditional methods, we would work in silos, perhaps talking to a few key stakeholders in the business, but not talking to anyone else until we had everything ready. This often led to decisions taken in ignorance of constraints and dependencies, leading to further change and rework.
Following the principle of the ‘timely collaboration’, we should identify and bring together key stakeholders from the delivery area with those upstream and downstream from them too. An example of this might be inviting the product managers together with stakeholders from sales, marketing, billing, and customer support—plus representatives from the delivery team of course. This leads to more joined-up thinking and earlier identification and mitigation of risks.
Getting it right first time
Our third Manifesto value is ‘Building in quality from the outset’:
The practical impact of this is rethinking how we ensure that what we produce is fit-for-purpose. Following traditional methods, we would typically follow a template for requirements documentation and then perhaps get it peer reviewed before circulating it to a wider group of stakeholders. This often led to filling out sections for the sake of completing the template, rather than focusing on what to capture that represents value to the business.
Following the principle of the ‘getting it right first time’, we should clearly define our deliverable, the acceptance criteria, and who should be involved from the outset. An example of this might be how we capture what a solution needs to achieve — whether that is a requirements document or a backlog of prioritised features, epics and stories. In considering what we need to do in order to complete this, we should agree the acceptance criteria that would enable us to know it is complete. Finally, by involving key stakeholders earlier, we are able to have our work verified and validated as we go.
As little as needed and no more
Our final Manifesto value is ‘Avoiding unnecessary steps that don’t add value’:
The practical impact of this is rethinking the process we follow to support the delivery effort. Following traditional methods, we usually had to comply with a software delivery lifecycle that was defined by the project management office. This meant that we were often ‘going through the motions’ for the sake of appearances. Rather than challenge the status quo, we would prepare documentation for gate review meetings, only to find that the attendees had not yet read anything.
Following the principle of the ‘as little as needed and no more’, we endeavour to reduce or remove process steps that add no value. An example of this might be advocating for a risk-based approach to quality, so that specifications and testing can be lighter for simpler areas and more detailed for high-risk areas.
Beyond the principles embodied in the four Manifesto values, there are other areas you should expect to see changes in too.
Painting a picture
Business analysis has evolved into a word game, a balancing act of capturing what people have asked for as accurately as possible and communicating this clearly to ensure the end product meets those needs. This is why we often have such long requirements documents. However, the most successful business analysis practitioners are those that combine verbal with visual language skills.
Following the principle of ‘a picture paints a thousands words’, you can often communicate far more graphically in a more succinct way than you can with words alone. Good examples of visual facilitation techniques are impact mapping, context diagrams, storyboarding, value-stream or process mapping. Standing face-to-face around a whiteboard, we can record what we’re hearing and confirm our understanding immediately, then simply take a photo to capture the agreed outcome.
Seeing the wood and the trees
As our role requires us to think analytically, we have to think about the components of a system and how they should work together so that if a change is required we can understand the impact. However, focusing too deeply makes it harder to see the big picture, meaning we cannot sense trends or patterns and respond appropriately to them.
Following the principle of ‘seeing the wood and the trees’, we need to cultivate our capabilities to think holistically. We should endeavour to start with the big picture, even when people come to us with a specific detailed solution they say they need — as this is often fixing the wrong problem. We should also strive to maintain our perception of the bigger picture even while we are working at the detailed level. Good examples of holistic thinking techniques that can help with this are the purpose alignment tool, capability analysis, or business value definition.
Walking in the customer's shoes
Our stakeholders and sponsors are almost always people buried deep within an organisation. This means that changes or improvements are often based on making things more efficient, thinking ‘inside-out’ about how the system interacts with the customer. However, simply delivering a poor customer experience faster or cheaper will not ultimately help.
Following the principle of ‘walking in the customer’s shoes’, we need to encourage an ’outside-in’ perspective, thinking first about why customers choose to use us, what their experience is, where we need to improve that, and then identifying waste and opportunities to improve. Good examples of customer-thinking techniques are Kano analysis, personas, or customer experience journey maps.
Thinking outside the box
Following a well-trodden path, we often employ tools and techniques that allow us to zoom in, to move from big picture to fine detail, to find the right answer to the problem. All too often, this linear convergent thinking constrains us to options that fall within the scope of where we started.
Following the principle of ‘thinking outside the box’, we need to start in a divergent non-linear way, by exploring ideas adjacent to (or even outside) the obvious scope, collaborating with key stakeholders and bringing in uninvolved people for a fresh perspective. Once we’ve explored these in different combinations and see what emerges, of course then we should still adopt a convergent approach to narrow down on the problem space and prospective solutions. Good examples of playful-thinking techniques are business games like ‘time machine’, ‘scripting a TV show’, ‘brain swap’, or ‘show me the money’.
Moving towards Lean Business Analysis
If you find the values and principles outlined above compelling, that Lean Business Analysis is for you, you need to consider how to get started. Whether you are a contractor, a permanent member of staff, or are working in a consultancy firm—all journeys begin with a single step.
When looking to introduce this as an organisation-wide change, we highly recommend starting with establishing that there is an appetite for change. A great tool in considering how ready an organisation is for change is the ADKAR change management model. This model helps us think about whether there is awareness of the opportunity, whether there is yet a desire to change, whether there is knowledge of what needs to change, whether they already have the ability to make the change, or whether the change has started and needs reinforcing to sustain it.
Once we understand where people are in their readiness, we should find an event or purpose that helps everyone get a sense of urgency for change. Sometimes these will be massive external events, but often we have to look internally and find the evidence that makes the case. For example, when there is the perception that projects are too slow, is this because it takes too long to get anything into the hands of real customers?
Small steps and quick wins
Our strong recommendation is to take small steps and make quick wins. Even if you want to make major change, break it down into small incremental improvements that you can trial and get feedback.
It is important to celebrate the wins and to agree how to build on success. It is also vital to be transparent about what didn’t work, to understand how to roll it back and to consider how to adapt your approach.
Building a fan base
If you are looking to make substantive change, then you will need a sponsor, someone who will support and guide you.
Either way, it’s also important to find colleagues and others who also see the need for change and will happily contribute, even if it is just agreeing to trial the different activities and deliverables you will be producing.
Closing thoughts
Finally, it is important to keep going, to keep finding those next few tweaks you can trial. Talk about the success with your colleagues, promote what has worked so that it becomes more common practice, and advocate for a regular retrospective on how Lean Business Analysis is being received and how it needs to continue evolving.
For more information on the Lean Business Analysis Manifesto, please visit the Assurity website.
About the Author
David Morris is Principal Consultant with Assurity, a delivery consultancy based in New Zealand. He leads a team of consultants delivering on process, project, and portfolio analysis; advising on strategy, practice, and change management; and delivering courses, coaching, and mentoring. With over 30 years’ experience in project delivery, he has worked in and led teams and run his own business across strategic, business, and technical projects following structured, iterative, and agile methodologies. David has an MBA in International Business, is a Certified BA Professional, ICAgile Certified Practitioner, Certified ScrumMaster, Professional Scrum Product Owner, and is an IT Certified Professional. He runs study groups, professional development workshops, and bootcamps, helps organise events for Agile Auckland and IIBA NZ, and has spoken at conferences and events in Europe and Australasia. He has also written and contributed to several books (including Agile Project Management in easy steps, Agile Project Estimation and Planning, and the Agile Extension to the BA Body of Knowledge) and is an active blogger, tweeter, and Wikipedia editor.