Author: Adrian Reed

Adrian Reed is a true advocate of the analysis profession. In his day job, he acts as Principal Consultant and Director at Blackmetric Business Solutions where he provides business analysis consultancy and training solutions to a range of clients in varying industries. He is a Past President of the UK chapter of the IIBA® and he speaks internationally on topics relating to business analysis and business change. Adrian wrote the 2016 book ‘Be a Great Problem Solver… Now’ and the 2018 book ‘Business Analyst’ You can read Adrian’s blog at and follow him on Twitter at

Think “Re-use” When Writing Requirements

When working on a project or product development initiative, the focus is usually on getting the product ‘over the line’ within a defined timescale. There can be immense pressure to create requirements artifacts quickly, creating just enough to communicate the key business needs to developers and other stakeholders.

This is completely understandable, but it can lead to somewhat of a ‘groundhog day’ like scenario where requirements that are very similar (or even the same) are written multiple times by multiple teams. When the pressure is on, there is less opportunity to think about re-use. Yet requirements re-use, when executed well, can save time in the long run.


Dispelling Myths: “Re-use” doesn’t have to mean copying & pasting

One common misconception is that because no two projects or products are exactly the same, there is no way that any requirements can be reused. However, re-use doesn’t have to mean literally copying & pasting—sometimes it can mean that a set of requirements are used as a starting point to build from.

Imagine that you write a set of non-functional requirements for a customer-facing web application. If, in the future, another team elsewhere in the organization needs a web app, then surely the NFRs that you’ve written would be a useful inspiration? The requirements might only be 80% similar, but the existing artifact means that there’s no need to start from a blank page.  Of course, this doesn’t remove the need to ask the right questions and engage the right stakeholders, but having an existing document to build from can save time.

In fact, there can be a benefit in having a “standard” set of NFRs for particular types of systems. Many organizations have their information security policies defined, their brand guidelines defined and so forth. Why not bring all of these policies together, adding other types of NFR, to create a corporate standard?  This will likely vary by context, but certain patterns will be relevant for particular situations. Clearly, building or maintaining an internal application is likely to attract different types of requirements to one that is exposed to the outside world.  This is just one example.




High level artifacts

It is also worth keeping high level artifacts that show the broad scope of what a particular system or product does. Context diagrams typically show the adjacent systems/actors that are relevant for a particular work area, and the high level data flow.  One day, someone is going to want to replace a key IT system… having an up-to-date context model would provide a massive head start. The same is true of business process models. If a new process is implemented, this is an opportunity to identify a process owner. The process owner is typically responsible for keeping the process model up-to-date. Imagine having a central repository with all (or even some) of the organization’s processes stored. This cuts down the effort of ‘as is’ modeling. (I say ‘cuts down’ and not ‘eliminates’, because it’s usually still necessary to see how people are actually undertaking the work, which may or may not be exactly as it is documented!)


Teams and Individuals

Another way artifacts can be reused is as examples or exemplars. When a new BA joins the team, they will often need guidance over ‘how we do requirements here’. Of course, experienced practitioners will bring their own views, but it is useful to have an expectation of what ‘good’ looks like. Too often organizations simply have templates or written standards. These are useful, but alone they are rarely enough… templates or standards with examples are far more useful. This doesn’t just apply to written documents, it can apply to models and requirements stored in repositories too.

These examples can also be used when a BA needs to show a stakeholder examples of business analysis work. Imagine trying to convince a skeptical stakeholder to engage with the BA team. Having a successful case study to show them, along with some fragments of requirements artefacts, prototypes and a working solution to show them might just help set the context. Stakeholder testimonials from the project will help even more.


But There’s No Time!

I know, I know, at this point you’re probably thinking “we’d love to do that, but there’s no time!”. I get it, deadlines are harsh and nobody wants to work even longer hours. There might not be time within the project, but there might be time afterwards or during natural periods of downtime if you are lucky enough to have some of those. Taking time to spruce up requirements artifacts, putting them somewhere central, and cataloging them so they can be found will save time in the long run. It is a short term effort for long term gain.

If you are a BA manager, you might consider building in an ‘air gap’ between project assignments for individual BAs to wrap-up their work and consider re-use (amongst other things). In many ways, this is building a sustained repository of knowledge for the whole team… and isn’t that an effort worth pursuing?


Constructive Conflict Is Better Than False Agreement

Over a decade ago, I was in a workshop with a range of different stakeholders.


Everything seemed to be going well, and people seemed to be agreeing and we were even running ahead of the meeting schedule.  Around halfway through the meeting a particular issue was being discussed, a conclusion was going to be drawn and a stakeholder interjected strongly and firmly with two powerful words.  They simply said:

“I disagree”

I remember being taken aback by the bluntness.  I live in the UK and our communication style is somewhat indirect most of the time.  It’s far more normal to say “Hmmm, interesting idea, or what about…?” which is code for “That’s a crazy idea”.  Or often the temptation might be to revert to the ultimate British stereotype and apologize “Sorry to be a pain here, but I’m not sure I entirely agree”.   I’m sure British culture is not the only one that has such indirect nuance.

The reason I remember this meeting so vividly, even more than a decade ago is that those two words initially made people visibly uncomfortable.  Someone was breaking the consensus; they were “creating conflict”.  Yet that wasn’t the intention, and of course they didn’t just say that, the stakeholder went on to explain the source of their disagreement, and what they proposed instead.  Thirty seconds later (once the stakeholder had explained themselves) any feeling of discomfort gently dispersed.  What’s more, other attendees of the meeting started to question things, interject and show disagreement.   One stakeholder questioning a decision had the apparent result in creating perceived permission for others to do so.  And you know what? I am convinced that the output of that meeting was better as a result.


Don’t Let Conflict Fester

Many of us have been taught to consider conflict as bad and consensus as good.  I suppose that is true in an ideal case, but if you’re working on any kind of large scale change how realistic is it that every stakeholder is really going to be ‘on the same page’ and in total agreement?  If a government implements a new type of tax and requires businesses to submit more information, there’s unlikely to be a standing ovation from business owners.  Yet that doesn’t mean that their input isn’t valuable—I would go as far as saying it’s essential!

Our fixation with consensus can lead to a situation where we achieve illusory agreement, a veneer of satisfaction.  Dissenting voices get marginalized, as they’ll never agree (so why spend too much time asking them?). We carefully facilitate meetings so that there aren’t big disruptive arguments, as we’re desperate to hit all of the aggressive (sorry ‘ambitious’) project deadlines. Yet this dangerous glossy veneer is very quickly broken when people start to interact with the product or service that we deliver. All we’ve done is defer the conflict to an even less convenient time, often a time when there’s so much political capital riding on the ‘solution’ that’s been designed that there’s no appetite to change it.

Cultivating Constructive Disagreement

As business analysts, we can help avoid these situations.  We have the opportunity to create space for constructive and respectful conflict, and we should certainly avoid us or others sidelining people just because they have contradictory views. In our analysis activities we should encourage constructive and respectful disagreement.

Taking an example, when setting up a workshop we have the perfect opportunity for creating the opportunity for a robust and respectful discussion.  We can lay down an appropriate set of ground rules that allow for differences of opinions to surface.  I’ve found myself opening workshops saying things such as:

“This is a controversial topic, and there are bound to be some differences of opinion.  That’s to be expected.  With that in mind please do speak up at any time and add your view, but please do be prepared to elaborate on it. Keep in mind I’ll be facilitating fiercely but fairly—and there might be times when I need to ‘park’ your item for later discussion. It absolutely won’t be lost, we will come back to it, but please don’t be offended if I need to do that.”

When we facilitate, we can actively prompt, asking questions such as:

“We seem to have complete agreement here; are there any contradictory thoughts. What have we missed?”

Ensuring that stakeholders have the ‘air time’, and ensuring that the most bombastic attendees don’t steal the limelight is crucial.  Using a range of tools and techniques in the workshop to consider not only what we want but also what could go wrong can be useful too.  Even just asking a question such as “That seemed too simple, might we have missed something?” can help.

Most of all, cultural nuances aside, we shouldn’t be afraid of the concise clarity of an expression such as “I disagree”.  When someone says it they provide us with a gift, an opportunity to better understand them.


Analysis Efficiencies: Turning The Mirror On Ourselves

As analysts, typically we’ll spend a lot of time examining and critiquing the processes of other departments. We might be looking for ways to make an operational process slicker, quicker and ‘better’, or we might be looking to solve particular problems. There are a whole set of elicitation, problem analysis and process analysis techniques in our toolkit that help us do this. Yet how often do we turn these tools in on ourselves to examine our own practices to see if there are ways that we can improve? As practitioners of change, surely we should be looking to continually improve ourselves too?

I suspect we all intuitively do this, at least to a degree, but I wonder if it’s an area where there’s room for improvement. I’ve included some examples to whet your appetite below:


  1. Deciding How To Decide: Have you ever got to an approval gateway in a predictive (waterfall-type) project and it’s unclear who needs to make the approval? Or the approver shirks responsibility? This can manifest differently on adaptive (agile/evolutionary) initiatives, for example with wrangling over the ‘definition of done’ with different stakeholders having different (and unresolved) perspectives. These things can fester if unresolved, perhaps stakeholders concede in the short term and sign on the dotted line, but resentment builds and bubbles up, only to explode out later at the most inconvenient time.


This creates friction and drama that takes time to resolve, and when it comes to organizational change, time is money. It’s therefore beneficial to spend a little bit of time up front agreeing how these types of decisions will be made. This sounds so obvious doesn’t it? Yet, so often in the blind rush to “just get going” it isn’t discussed… and it is only as the decision emerges is the omission spotted.  Practical tools such as the RACI matrix can be extremely useful here.




  1. Planning the Requirements Architecture: When BABOK® v3 was released back in 2015, one of many significant additions was a more explicit recognition of requirements architecture. If you have ever found yourself mid-project with a whole set of useful, but disparate requirements artifacts (“These process models are great. But how on earth do they relate to those user journeys, these scenarios and those wireframes?!) you’ll know what I mean.


Taking time up front to quickly and roughly sketch out how it’s anticipated that the requirements will fit together helps avoid this. Of course, things change, as requirements emerge, new types of artifacts suddenly become relevant (“Ah, so statuses are important… I think I’ll include a state transition model…”), however having a starting point to deviate from when appropriate is better than fumbling around in the fog.

On a legislative project, you might write a quick problem statement to act as a high-level goal/outcome, and define some critical success factors/key performance indicators which will act as desired outcomes. These will all link to the organization being compliant with a piece of legislation, that’s another (external) artifact, but one which some rules can be derived from. Those rules will include internal decisions about how the legislation is interpreted; so those probably need to be captured too.  Those rules might be automated or orchestrated via processes, and there might be steps in a process which will be automated via some detailed functional solution requirements.  You can see how these different concepts relate to each other here; and of course there will be other types of artifacts too.  The point is that creating a quick sketch showing how the concepts map together before creating them will prevent artifacts from being created that don’t clearly relate to each other.


  1. Planning How To Store/Manage Requirements Artefacts: If you’re lucky, you’ll have some form of requirements (or story) management tool. If that’s the case, does everyone actually know how to use it? Is there a common agreement around how things like priorities/statuses and other metadata will be used? If not, will this create noise and friction as the initiative progresses? If so, a short discussion up-front is likely to yield significant benefit.

If you are using documents and a shared document repository (e.g. word processing tools, drawing tools, spreadsheets etc.), decide things like naming conventions and version control conventions up front. It can be very confusing when someone in the team is using a file naming convention that uses “v0.1”, “v0.2” then “v1.0” when it’s signed off, when another person is using “FILENAME v1.0 (Updated) (Second Updates) (Final) (Really Final This Time) (Updated Again).docx”


  1. Plan For The Analyst And Stakeholder Of Tomorrow: Stuff you’re creating today will be useful for the analysts and stakeholders of tomorrow. That process model you’ve created? If it’s detailed enough, I bet the training team would love to use it, and the operations team might too. It might be the catalyst to the creation of a single, unified process repository (if that doesn’t already exist in your organization).

Those performance non-functional requirements for your customer-facing website?  You know, the ones that were like pulling teeth to elicit, that required benchmarking and speaking to the technical folk? They might be a useful baseline and starting point for others producing customer-facing web applications within your organization.

As we create artifacts, we ought to be thinking not just about how they can be used today, but how they might be used tomorrow and how we can ensure they will be found.  This is a much bigger, organizational, question—however it’s one of the many areas where BAs can nudge the agenda. By creating common pools of knowledge, and by encouraging information sharing we open up channels for these types of artifacts to flow. This has the advantage that information flows in both directions and also that there will be a wider range of documents available at the start of projects too.

Of course, these are only four suggestions, there will be many more. The key is that we shouldn’t rest on our laurels; as BAs we should be looking to hone our craft and improve the efficiency and effectiveness as much as we can. This involves not just “speeding to get the job done”, but also thinking about the stakeholders of tomorrow!


Just Because It’s “Obvious” to You, Doesn’t Mean It’s “Obvious” To Me…

I can still remember the elation of passing my driving test here in the UK.  As is the case with many skills, I often say that I really learned to drive in the six months after passing my test—these were the times where I found myself in unexpected situations that you just don’t encounter during driving lessons.

I still have a very vivid memory of going to a petrol (gas) station for the first time. This is something that they just don’t teach you how to do when you learn to drive. I’d seen people fill up thousands of times before, how hard could it be?  Well, after trying to work out which of the confusing array of variants of ‘unleaded’ would be the best one to pick (Regular? Premium? Performance?), I eventually put the nozzle into the fuel tank and pulled the lever. There was an empty clunking sound. Nothing happened, and certainly no fuel flowed..

I tried again, and again a clunk followed by nothing. I could see the queue of people behind me getting increasingly irate as I tried to operate this baffling pump that just didn’t want to work (while simultaneously trying to look like I knew what I was doing). Eventually, a kind fellow-motorist whispered to me from the opposite pump: “You have to press the button to say whether you’re paying at the pump, or paying at the kiosk”.  Right! Got it! This was one of the (then) new-fangled pumps that accepted credit cards. I was back on track.

To this day, I think it’s weird that you can pass a driving test without ever having to have pulled up onto a filling station forecourt, but I suppose there’s an assumption that it’s ‘obvious’ and everyone can do it.  If you’ve been driving for a few years, it really is second nature. You probably know which side your car’s fuel tank is on, roughly how much it costs to fill up, and exactly how close you like to pull up to the pump.  These things are “obvious” to you, but to a new driver they aren’t “obvious” at all, even if they’ve seen the pump used a million times before.


The “Obviousness” Trap

There’s a similar pattern in business analysis and projects. Stakeholders will often omit to say things, not because they are deliberately trying to hide something, but because it’s just so obvious that they don’t even think of it!  This is sometimes referred to as ‘tacit knowledge’ and it can prove a real issue in change initiatives if it is not teased out.  Not least because these ‘tacit’ areas can stop entire processes working if they are not addressed (much like the gas pump example above).

As business analysts we are tourists in the processes and situations that our stakeholders live in daily. We ask questions, we elicit information, but rarely do we know the finite detail —for that we rely on the talented Subject Matter Experts (SMEs).  However, in our role of process-tourist, we need to remain curious, ask probing questions while observing and listening carefully. We need to watch out for the ‘obviousness’ trap—where stakeholders skip over something that is actually important.

A particularly good way of overcoming this can be to observe and shadow stakeholders, gently interrupting them when necessary to ask what they are doing and why.  Observation itself is not enough, as we’re unlikely to understand the nuance, so interjecting when appropriate to ask follow up questions is crucial. Of course, this needs to be done with prior knowledge and agreement of those involved, and it’s important that they are briefed on the nature of the project or initiative (and the role of the BA, else they might worry about why they are being observed!).

Additionally, sitting with relevant stakeholders and creating process models or business use case scenarios can be extremely helpful. These help us to elicit and capture the flow of work, and ask questions about anything that is missing. It can also be helpful to ask what exceptions occur, or whether there are any other alternative flows.  When combined with observation, it is a very powerful technique.


Whatever techniques are used, being aware of things that are obvious to one person but not another is key. Tapping into the tacit knowledge is key!


Project Gateways: Land Or Abort?

A while back, I heard an airline pilot interviewed on the radio. There had been hurricane force winds, and the pilot was explaining how pilots deal with having to safely land aircraft in situations like this. One key decision is whether to continue to attempt the landing or whether to abort and ‘go around’ (attempt the landing again).

I was really intrigued to hear that pilots are taught to teach every approach as if it will end up being aborted. In fact, the pilot explained that they are taught that even in good conditions they should plan for an aborted landing as the default response, and this only changes once the relevant conditions for a safe landing are met.  Even though aborting a landing is the exception, it is considered so important that they plan for it on every single approach.


Project Landing Strips

As a BA, it struck me that there is a parallel to be drawn with the project world. There is often an understandable and admirable optimism on projects, with a genuine desire to get the delivery ‘over the line’ in the required timescale and within the required budget. Yet history shows us that being ‘on time’ and ‘on budget’ alone are not enough… delivering a solution that doesn’t actually solve a problem or meet a need (or is not aligned with the organizational strategy) is unlikely to achieve the required benefits.  With few or no benefits, what was the point in the first place? Spending good money after bad on a project that should have been canceled months ago is crazy, but it happens.

Now, I’m no PM, but I would expect that any good project method will require regular benefit reviews and there will be approval gateways where the project could (in theory) be stopped. Yet we have probably all experienced how this becomes harder and harder as time passes and as the budget gets spent. It would be a brave sponsor that aborts a project that has been in execution for a year and has spent millions of dollars. The ‘sunken cost’ fallacy comes into play here, along with the political ramifications of making a decision like this. Yet there may be times when it is the right thing to do… if the choice is to write off the existing spend or continue and commit another ten million dollars to deliver something nobody wants or needs, then surely the logical thing to do is to hit the ‘stop’ button?


This is perhaps where a subtle change could help. Project gateways and reviews are, in my experience at least, often progressed with the assumption that the project will continue unless it is proven that there is a major problem. As long as everything can be shown to be within agreed tolerances, it’ll pass through with flying colors. What if that perspective was changed so that the default is to stop—or at least pause—the project unless it could be established that the benefits will still be achieved?  If the emphasis changed from “prove it won’t work” to “prove it will work”? If red lines or “key failure indicators” were defined up front and examined too?

Ironically, this was probably the original intent of project gateways. They ought to provide efficient, fast and robust scrutiny on project investments. However, I’m sure we’ve all worked in situations where they are seen as somewhat of a ‘tick in the box’ exercise. I remember hearing a colleague report that they’d found benefits being double-counted in a business case. They were shocked with the response “oh, don’t worry, we need to get this one through—we’ll leave it in as we can always find some benefits elsewhere if we need to”. I feel sure they will have escalated the matter, but this illustrates the types of challenges that practitioners face.


But Don’t Go Too Far!

There is one additional aspect that should be considered here. As Christina Lovelock argues in her excellent article “Practicing Practical Optimism”, there can be a tendency to place too much emphasis on risk. These things are always a balance, but just as the pilot plans for an aborted landing even though they don’t expect to need to do it, perhaps project reviews should prepare for pausing/stopping projects even though they don’t expect to do so very often.  After all, you probably buckle up your seatbelt every time you drive your car even though you don’t expect to have an accident. A good project gateway could perhaps be seen as the project’s emergency brakes, seatbelt and airbag. Where braking is necessary, it’ll be much more comfortable for everyone involved if it’s done early and gradually!

If your project gateways are already working like this, that is fantastic. If not, perhaps this is food for thought