“On a scale of one to ten, how resilient would you say you are?”, I was once asked in an interview.

I responded: “ooh – a seven – maybe an eight”

“Really? Why not a ten?” came the reply.

“Because, whilst I’m an optimistic person and will always bounce back after a setback,  I’m also a born analyst. That means I see things at many different levels of abstraction, and as such I’m sensitive to things others perhaps aren’t, which means I’ll always see more threats. And actually, for precisely this reason, I think a BA always needs to harbour a healthy element of self-doubt in order to be effective”.

It impressed my potential suitors, and is, I think, what clinched the role for me.

But within that answer – and even the question itself – is a fundamentally important point:

Change is risky, and risk undermines confidence. Therefore successful change is ultimately about generating and maintaining confidence.

Confidence is that reason why, in a waterfall environment, the requirements need to be documented and approved before the design starts. It’s the reason why we plan projects, test solutions, RAG-status updates, and gain approvals to proceed. When we manage the change, we need to give our stakeholders confidence in the to-be state – not only that it will be better, but that nothing will break in the process.

It’s why, as analysts, we draw diagrams to allow stakeholders who are otherwise ‘in’ the change to be able to work ‘on’ the change. It’s why our documentation needs to be manicured – all the ‘i’s dotted and the ‘t’s crossed, the grammar correct – because nothing exacerbates the nervousness associated with change quite like a mistake in the document describing it.

“If you can’t even get that right, what are you going to do to my business area?!”

So in a waterfall environment, promoting confidence means taking extra care (and often extra time) to make sure everything is correct before it goes public.

This is a real challenge for BAs – because Agile and product management have turned this dynamic on its head.

In a fast-moving, ever-changing digital environment, the very concept of waterfall has been invalidated: by the time you’ve dotted the ‘i’s and crossed the ‘t’s, the ‘i’s have become ‘j’s and the ‘t’s have become ‘u’s! It’s quite literally impossible to project out what future needs will be from a static point in time.

Notice how I just used the word ‘project’ as a verb rather than a noun? Actually the noun comes from the verb – not only is the waterfall methodology inadequate for today’s change environment – the same applies to projects (literally named that way because they ‘project’ out a future state). The logic is now fatally flawed.

Hence, Agile and product management: we won’t know exactly what we need, so let’s start with something quickly and see how well it works in reality; then use that feedback either to decide to pivot onto something else, or evolve it to make it better. We build confidence, not by thinking of everything up-front, but by doing something and using the facts it generates to react accordingly. Generating facts from real users is far and away the most effective requirement elicitation technique.

It’s much more effective because in a digital world, often customers don’t know what they will want, because they don’t necessarily know what they can want. Consider current affairs – have you ever noticed how everyone’s a critic, but nobody seems to be able to imagine and articulate a better system for running the country? It’s human nature – we’re extremely bad at ‘projecting’ out what we will want in the abstract, and much better at deciding whether we want something when we see it. Basically, we’re better with buffets than we are with menus!

Again, this is about confidence.

If you’ve ever read a book about self-confidence, you will know that it’s defined as the belief that you can do something, and if you do it something good will happen. And how do you build self-confidence after a knock? By setting and achieving small goals – little and often. And what really helps with this is a growth mindset, where setbacks are recharacterised as learning opportunities; where the desire to get things right every time is replaced by the knowledge that you won’t know what right it until you get real feedback.

For a BA this can be an uncomfortable space. I used to write manicured 250-page business requirements documents with detailed processes and sculpted prose to explain the requirements, before sending out to a list of 50 – often very senior – stakeholders. Every time I did that I’d get a dramatic increase in heart-rate immediately prior to pressing ‘send’ on the email – just one more check of the document and the grammar on the email before I send it! And often required a lie down in a dark room afterwards to try and ‘latibulate‘ from how exposed I felt in those agonising moments waiting for feedback, such was the potential risk to my self-esteem!

But this is very much waterfall. Closed mindset. The expectation of perfection, and the fear of failure.

In an Agile or product environment, I open a blank document on the shared drive. ANYBODY can see what I’ve written at ANY TIME – all those silly first drafts, all those misunderstandings and mistakes! To an oversensitive BA mindset, that’s worse that ‘the fear’ from sending out a document!

But herein lies the required paradigm-shift.

Feedback on something real is far and away the most effective requirement elicitation technique, because it’s based on fact. That means ‘putting yourself out there’, warts and all, for other people’s judgement, knowing that it’s not you being judged, it’s your work. Nobody expects perfection, because it’s an impossible ask.

Developing the growth mindset to get comfortable with this is the single biggest thing a BA can do to adapt to an Agile or product environment.

Coming soon!

Prioritisation

A few years ago, I went into a comprehensive school to do a talk about careers in technology – specifically, as a business analyst – with a view to encouraging participation in science, technology engineering and maths subjects as the pupils chose their options for GCSE.

It was a fascinating experience, not least because finding the words to articulate what we do in terms that meant something to 13 and 14-year olds proved to be a delicious challenge. It’s amazing how much jargon we use in our trade, and how little of it means anything to people outside it!

I opened up by taking my iPhone out of my pocket: a 256GB iPhone 5 at the time, then the 128GB iPhone 4 it has just replaced, and pointed out that I’m carrying around 384 million K of computer storage in my pockets. I then contrasted that with the 48K BBC Micro we had on my Dad’s desk when I was their age and pointed out that what I had in my pocket was 8 million times more powerful. And that in my head, I’m still 13 – I remember it like it was yesterday. It was a point that seemed to grab their attention.

Moore’s Law states that the number of transistors in an integrated circuit doubles every two years. This exponential rate of growth is also a powerful symbol of the rate of business change itself, given that pretty much all organisational activity is now underpinned by these rapidly evolving computer systems.

There was a time when the received wisdom of the business analysis profession was to ensure that the computer system reflected the business process, but the digital revolution has turned that dynamic on its head – because as customers, we need to be able to interact with organisations on our mobile devices. Which means business needs to be ‘digital’ – distilled into something you can do with your fingers (or ‘digits’) on a 4.7-inch screen.

So the key challenge for all organisations everywhere is prioritisation. But in every organisation in which I’ve worked, the word ‘priority’ has been used as a synonym for ‘importance’, so I’m sure that the scenario of having 30-50 top priority business changes on the portfolio is familiar to you too!

However, linguistically, the words do not mean the same thing. The clue is in the word ‘priority’ itself – we know everything is critically important, but if you chase two hares you catch none. So, what would you like us to do prior? What would you like us to do first? To begin with?

And herein lies the challenge for organisations: how do you compare the relative priority of a market-disrupting digital product with a new parcel-processing hub, and then again with creaking core system infrastructure and an imminent change to personal data legislation with the risk of massive fines? It’s undeniably difficult.

And it gets more difficult when you consider what you’re working with: ideas that have little definition. You can take a stab at how much effort they will take to deliver, and how much value you will get from them – but you’re likely to be 400% out on the effort, and maybe 1000% out of the value because you’re comparing ideas. And it takes time and resources to turn those ideas into concepts, and exponentially more time and resources to turn them into delivery plans. Before you cut a single line of code.

So how do you prioritise in a meaningful way when you know little about an idea? Not just the delivery, but the analysis of the idea itself? Because it’s unlikely that an organisation has only four strategic changes to pursue: a former employer of mine usually had between 300 and 400 portfolio requests a year to contend with in its portfolio. So even if each idea were dedicated 3 days of attention to understand where it fit in the overall priorities, analysing all of them would require 6 full-time-equivalents (FTE) – half the team at the time (who’d do nothing else). That’s to say nothing of the fact that, even with the investment of 6 FTE, it would take up to 12 months to get to some of them – unacceptable in any organisation.

And yet, somehow, a relative priority is absolutely required for an organisation to start analysing, planning and delivering any of it. Often, in the absence of an alternative, this becomes the subjective view of a ‘star chamber’ of stakeholders – and with that subjectivity comes resistance and political infighting, ultimately elongating the time to value for all of it.

There are, however, a couple of powerful techniques for solving this problem: filtering ideas based on their strategic alignment using a tool called VMOST (Vision, Missions, Objectives, Strategies, Tactics), and WSJF (Weighted Shortest Job First) to prioritise them in terms of which of the ideas we think will take the organisation furthest fastest towards its desired strategic outcomes (which favours ideas with a shorter time to value).

VMOST

VMOST stands for Vision, Missions, Objectives, Strategies and Tactics. So let’s unpack that a little bit:

Vision

A vision statement describes, in evocative terms, what the destination looks and feels like – ideally in 3-5 years’ time. Most organisations have a vision statement, although the better ones tend to represent something beyond ‘develop better products, scale the business, keep costs down and keep customers happy’, which – besides being objectives – are generic descriptions of what every organisation is looking to do.

A great example is Hellman’s mayonnaise. Rather than a generic vision that involves ‘sell more mayonnaise, at higher prices to more people and do it more efficiently so we can make more profit, theirs is:

“We want to help people to make any food delicious, so they don’t have to waste any. That’s why our brand vision and commitment is to inspire and enable 100 million consumers every year until 2025 to be more resourceful with their food, and waste less.”

This is great because it articulates a cause with a real sense of purpose, albeit without any information about how to get there. But it’s enough to articulate the values of the company in a way that encourages people to buy into them.

A vision is necessary to galvanise people behind a shared understanding of what the future looks like and motivate them accordingly. But because it’s a statement of few words, it tends to be vague and open to interpretation.

Therefore, it needs to be broken down into:

Missions

Missions are the big changes to the status quo that are going to take the organisation from where it is today towards its vision state. The language is drawn from a military context, and in that context missions generally require the coordination of numerous people across several different organisational units – and it’s no different in a business context.

Missions are your highest-level objectives, and VMOST works best when the vision can be distilled into 3 or 4 of them.

I’m guessing here, but Hellman’s missions might be “educate consumers about food waste”, “ensure availability”, “maintain quality” and “differentiate brand” or some such.

But because they are high level, how does an organisation know it’s making progress in each mission?

To do that, missions need to be broken down into objectives that can be used as yardsticks to measure progress.

Objectives

The objectives layer of VMOST is where vision and strategy collide. The vision and the distillation of the key changes required to get to it are usually set by an organisation’s leadership. But objectives, set correctly, enable an organisation’s delivery mechanism to focus and prioritise scientifically.

Objectives break down the missions into Specific, Measurable, Action-oriented, Realistic and Timeboxed (SMART) targets to enable teams to focus.

Since the likelihood is that the organisation will already have many existing ideas for improvement to contend with, often the objectives come after the ideas – and represent the outcome of the ideas. But VMOST works best when the objectives measure the achievement of the missions – that way, in achieving the objectives, the organisation knows it is progressing towards it vision state, so achieving the objectives becomes the main area of focus for management.

Strategies

Probably the most problematic layer of the VMOST framework because the word strategy means so many different things in so many different contexts. But in this context, a strategy is a focus area: what are we going to focus on specifically to achieve the objectives?

I like to use a footballing analogy here: the objective might be to win the game by two clear goals. There are different strategies that might achieve that: the team could play a high pressing game and keep the pressure on the opposition, which will consume a lot of the players’ energy over the 90 minutes. Or they could sit deep, keep their structure and play defensively – a more conservative use of players’ energy, but relying then on scoring ‘on the break’ from fewer chances.

But they can’t do both. So which will they focus on? Strategies are these choices.

And then within the strategies, the only level of VMOST at which any work is actually done:

Tactics

Tactics are the specific activities that will be done within each strategy, to achieve the objectives, which tell the organisation it is progressing in its missions towards its vision state.

Using this framework ensures that tactics are strategically aligned because anything that doesn’t demonstrably contribute to an objective can be filtered out. It also enables prioritisation within each strategy on that basis of what is going to take the organisation furthest fastest, to ensure a balanced change portfolio.

Here’s how it works in practice.

Boxes and lines

 A few years ago, I joined an organisation to head up their business analysis function, and whilst making my introductions to the BA function’s key stakeholders in the first couple of weeks, one of them said this:

 “I spend half a day in a workshop with one of your BAs and they come back six weeks later with a process map, so I don’t really see the value of it”.

It’s a quote that’s always stuck in my mind.

OK, so the stakeholder in question (I subsequently discovered) had a bit of a reputation. I think the politest way to put it is that he was someone unencumbered with the ability to let thoughts go unsaid (although he’s now a CIO, so it’s obviously stood him in good stead). But it resonated with an insecurity: namely, that BAs will always struggle to articulate their value while this perception prevails, and it’s something BA functions need to be cognisant of.

It was certainly something I felt I needed to dig into, and actually, it’s what gave rise to my characterisation of ‘Type A’ and ‘Type B’ BAs: Type A being someone who’s technique-driven, viewing the necessary interactions with stakeholders as an interruption to their real job of applying a BA tool; Type B being people-driven, who would be able to do the role effectively even if they knew no specific BA tools because they’d invent their own. (There’s an article about this here).

There were three key issues encased in what he said:

• For starters, it was difficult to argue that a period of six weeks between eliciting the information and presenting it back was reasonable. Granted, there were mitigating circumstances such as difficulty getting time with the other stakeholders that needed to be consulted, plus a heavy workload that had expanded to fill the available space for the BA in question, but none of that resonates with a stakeholder who’s made a significant investment of time in the activity.
• It turns out that the output was sent out for stakeholder review by email with no ‘wrapper’ to set its purpose and outcome in context. BPMN2 is a fantastic method for articulating how work flows through an organisation, but it’s not meant to be consumed unsupervised. To a stakeholder, it just looks like words in boxes connected by lines (which is what you tend to get when the business try to map a process themselves).
• There was also no obvious desired outcome from sending it out, beyond validating that it was accurate. (Even that is difficult to establish over email because it’s rare that an organisation has levels of process compliance that make an process diagram true in all cases).

 These three issues give rise to three fairly simple rules:

• If a stakeholder has invested time in your workshop, you need to ensure the output is sent out as quickly as possible. Sometimes you do need to validate that what you’ve captured is correct, but if that is the case it needs to be as instant as possible, ideally within a day or two of the workshop itself.
• Always walk through a process map. If, for practical reasons, you can’t be there in person to do with, provide a narrative flow to accompany the process.
• Always articulate why you’ve mapped a process – to drive out the requirements for the solution? If so what are they (even at a high level). In an of itself, a process diagram isn’t much use.

The fact is, all business change is about improving organisational performance. And since everything an organisation does is either a business process or part of a business process, if you want to effect organisational improvement, it’s in the business processes that you’ll do it. IT solutions exist to enable an improvement in business processes. And requirements – whether expressed as ‘big hairy audacious goals’, stakeholder requirements, user requirements, functional/non-functional requirements or transition requirements are all requirements of the business process.

Mapping business processes is therefore the spine of organisational change – at any level of detail. The requirements hang from the process, the org design hangs from the process, the data and information flows that an IT system will underpin hang from the process.

A good BA, therefore, needs a strong elevator pitch for process mapping in their toolkit.

VMOST in Practice – Ten Top Tips

When everything you see needs to be improved, where do you start? Well, you start with a VMOST. 

This is a fantastic tool for getting your stakeholders to agree on a common direction, because done properly, it enables everybody’s thoughts – at whatever level they happen to be – to be captured and contextualised. Nobody gets overlooked or left behind – everyone’s contribution is equally valid.

I’ve had a variety of different experiences with VMOST workshops, so here are ten top tips drawn from those experiences aimed at those considering using the tool for the first time:

1) The invite

If you want your workshop to deliver the desired outcome, you need to make sure the attendees are primed to help you. The workshop invite is your opportunity to do this. 

Let them know what you’re going to do (but not how you’ll do it – more about that later), what you want from them, and why they need to be there. Sell it to them as an efficient use of their time to get an outcome that will move things forward. Everyone has a common interest in the initiative delivering, even if, at this stage, they’re not even sure what the initiative is.

And the likelihood is, you’ll probably need some help with the facilitation. A good rule of thumb is to have one facilitator for every 6 attendees. A productive workshop takes a lot of energy to achieve – so get a colleague or two to help you.

Your biggest enemy here is the meeting. This isn’t a meeting, it’s a workshop – the clue is in the word – you want them to do the work. You’re facilitating their work into a usable format for the initiative. They’re the boss(es), figuratively as well as, for some of them at least, literally!

2) Room setup

This can be a critical factor in the success of your VMOST workshop. My organisation’s best meeting room has a huge conference table built into in its centre. So when the workshop delegates turn up, the room is set up for a meeting. People sit down, flip open their laptops, get comfortable, and start tending to their inboxes.

But if that happens, it’s too easy for the workshop facilitator to lapse into managing the canvass – writing and placing every Post-it. Great from a legibility point of view, because it means the Post-its can be placed neatly on the canvass in perfectly perpendicular rows and columns, and the words they display remain meaningful and legible.

But crucially, it can encourage the view that the output belongs to the facilitator, not to the delegates in the room.

A far better method is to get the delegates stood up around the canvass – remove the chairs if need be! And to get them to write the Post-its themselves, and not to think too much about what they’re writing. The thinking should be directed towards the sentiment the Post-it conveys, and where it fits into the overall direction.

Another tip here is to get them to write in capital letters to ensure what they’ve captured is legible! Illegible Post-its can really upset your rhythm!

3) You need time

A VMOST workshop for a reasonably-sized initiative will take at least 2 hours to run – probably 3. But for you as the workshop facilitator, it’s a day’s work at least.

Book out the meeting room for an hour before the start. You’ll need that time to set up.

Because of the likely room set-up in point 2, you need to establish this as a workshop, not a meeting. So put brown paper on the walls, and make sure there are plenty of Post-Its and pens available for people to use. A well-chosen selection of biscuits also gives this a sense of an ‘event’, and signals your commitment to making it work!

If you show that you’ve put the effort into preparing the workshop, it’ll be easier to get the delegates into the right frame of mind to get the outcome you need.

4) Explaining the tool

It seems logical to introduce the workshop by explaining what you’re doing, and why you’re doing it. However, this is not advisable – because it put too much focus on the tool itself – at the expense of the outcome you’re looking to achieve by using the tool. 

Imagine you called an emergency plumber out to your house to fix your boiler. On arrival at your doorstep, the plumber proceeded to explain to you that he was going to use his new ‘extra-wide jaw wrench’ to get at the water-valve assembly. You’d probably be thinking “I don’t really understand – or care – just make it warm please!”.

The likelihood is, that’s also what your delegates are thinking.

Use of a tool like VMOST works best when it’s done ‘by stealth’. It is, at its essence, a method for taking the unstructured thoughts of a room full of people with different perspectives, and building a framework to enable each of those perspectives to be reconciled – in a way that everyone can agree on. Which is quite a feat!

So start by asking people to capture their thoughts on the Post-Its, and get them to physically stick them up somewhere – anywhere – on the canvass.

5) Starting from the top

Starting with the vision is a mistake I’ve made a couple of times. Although this is how you’d read the finished article, unfortunately, that doesn’t mean it’s the best place to start.

If you do start here, the vision is likely to be “pretty much what we do today – only more so”, and the missions, objectives, strategies and tactics then become the means to describe how the organisation is going to stay the same. A wasted opportunity.

Most people are not visionaries – and it’s difficult to encourage radical thought in the workplace.

One colleague of mine is actually courageous enough to start his workshops with something that has nothing to do with the topic of the workshop – but designed specifically to stretch people’s minds, so that they apply their new cognitive dimensions to the task at hand (it’s a neat little video that zooms out from sub-atomic particles in the first instance, to phenomena in the universe in the second – and the sense of scale is incredible!).

But whether you choose to do this or not, don’t start with the vision – start by capturing the attendees’ ‘unqualified’ thoughts to get the ball rolling.

You can find homes for the thoughts in the next stage of the workshop.

6) Do it in stages

So you should by now have a cloud of Post-it notes on the canvass.

The next stage is to start to split out the different levels. Some of the words might relate to how something might look – so sound more like desired outcomes, which would naturally sit at the Vision level.

Other words might relate to actions – which might end up being Missions, Strategies or Tactics, depending on what they represent when the Post-it author has explained what they meant by it.

Anything with numbers in it is likely to be either an objective, or something you can build an objective from.

7) Sharpen it 

Take the Vision section. You’ll probably have a number of different Post-It notes, each containing single words or phrases that describe a place or a result. Gather these together at the top of the canvass, and challenge the room to try and articulate as many of these words as possible into a statement.

This is your Vision statement, and it describes what the outcome of the initiative looks like.

Next, look at the Post-its with numbers, or quantitative phases on them. These are your Objectives.

What you’re left with is a cloud of potential tasks – the things that actually need doing. And the likelihood is, there will be quite a few of them left once the vision and objectives have been extracted.

So get the room to group the Post-its together into similar themes. 

In each theme, pick out the Post-It that best summarises the theme. If there isn’t one – challenge the room to think of a name for the theme, and capture it on a new Post-it. These are your Missions.

Continue to follow this method to group together the Post-Its within each theme. When you have a logical grouping, choose the Post-it that best describes it – or if there isn’t one, capture an additional Post-it to summarise each new grouping. These are your Strategies, and they contain groups of Tactics.

8) Get someone form the group to summarise where you’ve got to so far

So you’ve created a VMOST – and in doing so, you’ve done what diplomats the world over have been trying to do for centuries! You’ve reconciled everyone’s viewpoints – at least, on what you need to do, why, and how it fits together.

Now you need to make sure they own it – and a good place to start is to ask one of the delegates to walk it through.

The next workshop will be to size and scope which tasks you’ll deliver when, but for now, you’ve reached a natural breakpoint. You’ve reached a point where everyone’s agreed, so if you leave it here, you’ve set the right conditions to get the best out of your next workshop.

9) Take photos

Another natural tendency to try and avoid is to immediately rush back to your desk to document the output in a neat Visio diagram and send it out.

Whilst this undoubtedly helps to cement the output and crystallise the activity, you risk claiming it by putting your creative stamp on it.

So don’t forget to to take photos of what the room has achieved. And if you can get away with it, take a couple of ‘action’ photos of the delegates too, in order to remind them of the forum in which they agreed the direction of the initiative.

You want the delegates to own their output, so include it in a form they’ll immediately recognise.

9) Don’t get disheartened

The truth of the matter is, some workshops go well, others don’t. But if you didn’t feel a workshop went as well as you’d hoped, that doesn’t make it a failure. On the contrary, there’s always something to be gained by undertaking this process, even if you need a follow-up.

But remember this – there’s no such thing as the perfect workshop – there are too many unpredictable variables. But that doesn’t matter – the value is in making a concerted attempt to define the initiative – to start a productive conversation. And that’s the hardest part!

What are Requirements?

Requirements are a mechanism to enable design; they represent the terms of reference of the design.

Typically, when a business area has a business problem it wants to solve, it will request a particular solution by name – likely a state of the art IT system that they know other successful companies are using.

There are two problems with this:

• The first is one of human nature. Nobody walks into the Apple Store to ask for the most cost-effective solution for storing and accessing music and photos, from which they can access the internet at appropriate speeds, capture and share videos and monitor their calorie consumption whilst they’re doing it – and then attends workshops to unpack how many songs and photos they have, how many they’re likely to have, and their typical travel habits. They ask for the latest iPhone, because they’ve seen the adverts, watched the Keynote, caressed its sleek engineering with their own hands in the display area, and had their human desires invoked by a multi-million-dollar marketing campaign.

A consumer has every right to buy whatever they like with their hard-earned income, but in an enterprise, a solution in one area of the business is likely to require a further solution in another – and either a significant increase in the scope of the project, or a further project to deliver it. 

This creates a ‘footprint’ of the change in the business.

For example, a new feature on the website might require more people in Customer Services to answer the additional questions from customers trying to get acclimatised to it; and Customer Services might in turn require a piece of software that enables contacts to be distributed across sites to cater for it. One of those sites might be outside the EU, so a privacy impact assessment is required, and that in turn means changes to the contracts, which impacts the Procurement function; so…

• The second is one of perspective. Since the business area is only really concerned with factors within their direct accountability, in order to allow an organisation to stay in balance, we articulate the business needs as requirements which allows specialised solution designers with a broader perspective to solve the business problem holistically – as far as possible, keeping cost, risk, impact and everything else in balance.

For this reason, a business analyst must understand the ‘needs’ behind the ‘wants’ – the requirement behind the solution idea. And the best way to do this is to understand how the business area operates in relation to the business problem, how it wishes to operate with the solution, and what the desired outcome looks like in situ.

This, in turn, enables a business analyst to identify the changes to people, process and technology necessary to ensure the solution achieves the desired benefits – and, as far as possible, take the risk out of the change.