The Cost of Busy Work: A Guide to Business Analyst Waste

A week or so ago I was asked to spend some time documenting a particular piece of functionality in a system that my team supported. Now, if I were a little less obstinate, then I probably would have just done it. I’d have created the Confluence page, taken the screenshots, linked the development tickets.

Probably added some emojis for a sprinkling of pizzaz too. 👌

But that I couldn’t see how the document was going to be helpful really bugged me!

So I (successfully) convinced my boss that it would be a waste of time.

As I am wont to do, this got me thinking about waste in general. Not just the unnecessary busy work I managed to avoid in this case, but the everyday, unacknowledged waste in all our work and practices: the kind of work that takes up time, cost, effort, attention, space, and energy, but doesn’t deliver any real benefit.

Busy work.

I hate doing things that are just busy work. Truly despise it. If the choice is between busy work, and nothing, I’d choose nothing. And of course by “nothing” I mean I choose doomscrolling my LinkedIn feed.

The challenge is that we business analysts are stuck in the middle, never the specialist, never the manager, never the bride, always the bridesmaid. We cart information around. We sort through information from others. We play a support role in design activities. We’re the piggy in the middle.

If we’re honest, much of our work is pretty indistinguishable from busy work from an outsider’s perspective. The worst part of the productivity/hustle/work-harder/work-better cult thing we have going on is that there is significant pressure to appear busy.

And what better way to appear busy then to be, well, busy?

But … to what end?

If we don’t ask that question frequently, then we are at serious risk of achieving very little productively. We’re at risk of just being busy for busy’s sake. And we’re at risk of creating more waste in our systems and processes.

Now this article won’t help you answer the “to what end” question – that’s contextual and depends on your environment. Instead, this is a deep dive into all the different kinds of waste we business analysts can create, what that waste can look like, and what to watch out for.

Overproduction is aptly and plainly named – it is the kind of waste that is the result of producing more than is needed. We have all experienced the creation of an artefact that was unnecessary. There’s something especially and uniquely painful about pouring your brain-power, heart, and hours into something that isn’t read or used.

Those completely wasteful endeavours are easy to recall.

Far harder to spot is the casual overproduction waste in the everyday. It is adding that page to the wiki that isn’t answering a clear need. It is elaborating that feature request and adding it to the backlog before you know it will be built. It’s adding detail to that ticket when we know the team will want to unpack it collaboratively anyway. It is adding another dashboard when no one asked for it.

Watch out for: creation of documents that weren’t read or used; production of reports that aren’t checked; writing a 50 page detailed spec for a feature that might not be developed; creating twenty user stories to refine when the team only has capacity to work on ten; adding features to the backlog that aren’t approved for build!

Making sure there is a clear and current need to do something before you get stuck in is a good way to avoid overproduction. And don’t get so involved in an activity that you forget to check that that there is still some unmet need continuing will address.

And if you’ve met the current need, simply stop!

Ask yourself: Is there a clear and current need for this thing I’m doing?

Waiting is when things cannot progress because they’re waiting for something. If your career has been anything like mine, waiting is certainly something you will have experienced. Waiting for feedback, waiting for approval, waiting for access to a system or to a set of information, waiting for a response to an email, waiting for a decision.

Waiting is simply wasted time. And we all know that time is money!

Watch out for: long delays waiting to get feedback, or have a decision made; unnecessary wasted time in meetings; lags between a request for access, and access being granted.

Some of this waiting is simply out of our control, but we do have some influence.

A good way to minimise waiting time is to prep recipients prior to needing their input so they know when to expect the request, understand why the request is important, and comprehend the impact of any delay.

That last one is the kicker. People are weirdly comfortable with delay; they don’t think of it as a cost. But it really is, not least on attention. The more things on your plate, the less effective you can be on any of them. Waiting is a type of stopped.

Ask yourself: how can I minimise waiting? And how much time do I waste waiting for responses?

Under-utilised talent is when particular skills aren’t used most effectively . For business analysts this occurs most commonly when we are assigned low value tasks such as data entry or basic reporting work.

We business analysts like to help. And sometimes that “help” can become nothing more than admin work for the team. While it isn’t hard to book a meeting, or schedule a follow-up, it isn’t the core value-add of having a BA on the team. Thus, it is a form of under-utilisation.

Watch out for: being lumped with the ‘team admin’; doing data entry; not having the tools to do your job effectively.

You can’t always control what tasks and activities you are assigned, but you can be careful about what tasks you take responsibility for. I’m not saying you should avoid all admin work, but you should certainly avoid it if it undermines your ability to do business analysis for the team.

The aim here is to provide the highest value support to the team. And typically that means bringing your best business analyst self to the table, not by loading Jira tasks!

Ask yourself: Is this the best way I can support the team?

Transport is a type of waste that people don’t think applies to knowledge work but it really – really – does.

What is your work email if not information transport? Reports, emails, dashboards, meetings, almost everything we do as business analysts is about transporting information and delivering it to the people who need it. And because it is a huge part of what we do, it is one of the places where we have the most wasteful practices.

One of the most common and most problematic types of transport waste is our habit of creating the need for it in the first place. We’re sneakily good at this – we have a small meeting with a select group, and now we need to hand-off that information to a second group of people. The need for the transport only exists because we didn’t include all the necessary parties in the first place. We create this waste!

There’s a subtle difference between facilitating information transfer, and acting as a interface. The latter is at high risk of generating transport waste.

Watch out for: forwarding emails onto someone else; uploading information from one system, into another; long email chains discussing something that could have been resolved in a quick chat; meetings to convey information to people who simply could have been included in the first place.

Always question the value of information hand-offs! Meetings to update someone on a topic are frequently a waste of time. Matching the channel to the communication need is key to reducing transport waste; if a topic is simple, grabbing a quick chat is always easier than creating a long and convoluted email chain.

Ask yourself: How many times does information change hands before it’s used?

Over-processing is perhaps the most common of all the business analysis “wastes”. It covers all manner of things from unnecessary detail added to a ticket, to elaborate processes that don’t reduce risk or enable team-work, to excessive review cycles for low-value and low-risk requirements, to just generally over-thinking stuff.

One of the bigger changes that has happened to the business analyst role over the last decade or so is that it is more common for us to work in a cross-functional team. That means that instead of the BA single-handedly and valiantly chasing down detail long before there’s someone technical on the scene, we are collaborating with other experts to understand and unpack the detail.

And unless you’re working with inexperienced zombies, good delivery people will want to understand both the problem space and the proposed solution before implementing anything.

Which means that unless you’re careful, that detail you’ve added to the ticket is very likely to be unnecessary!

Watch out for: creating intricate diagrams when a simple white-board scribble would do; adding excessive detail into backlog items; imposing elaborate approval and review processes when there’s limited risk; using complicated tools (Jira, Microsoft project) when the task could be more easily done with simpler methods (such as a whiteboard & post-it notes, digital or otherwise).

Avoiding over-processing is an everyday challenge for business analysts! We tend to love process! We also tend to love detail! That makes us an over-processing risk!

There are two framings that have helped me to avoid over-processing:

1. Framing my role as responsible for minimising risk. If additional detail or process doesn’t reduce risk, it’s unlikely to be required.
2. Taking a just-in-time approach to creation of artefacts. This keeps you really focused on the consumer of your work and tends to make it clearer when you’re taking a piece of work too far.

Ask yourself: Are these steps in this process really necessary? And is there a simpler way to tackle this?

Inventory is having stuff piling up. You know, like in a backlog (hint, hint!). Inventory in our context is the accumulation of outdated project artefacts, multiple versions of documents, or the maintenance of a large backlog of “nice-to-have” requirements.

And if this sounds similar to over-production you’d be right! These two types of waste are different, but tightly coupled. Over-production creates inventory. Solving over-production is key to reducing inventory waste.

But you can have inventory waste in the absence of overproduction. For example, maintaining documents beyond their use-by-date is inventory, and therefore waste.

Watch out for: large backlogs of features you might not even develop; huge folders full of outdated project documentation; stockpiles of document versions (just in case, no?).

But “just jotting that down for later” sounds so innocent!

It does sound innocent, but be very wary about the value of an inventory. Those “burn the backlog” folk are actually onto something … If something is important enough, it will come up again. Information needlessly languishing in a massive list that someone needs to maintain is simply wasteful. And all that inventory makes it harder to spot the things that are actually valuable in all the noise.

But it’s an easy trap to fall into – it’s almost too easy to create a backlog ticket for “safe keeping” nowadays.

Ask yourself: Does this really need to be added to the backlog? And is there actually value to maintaining this document?

Motion is the unnecessary movement of people or equipment. And in our context that means meetings and context shifting.

Nowadays meetings tend to be the default go-to for information sharing. But think about it: requiring everyone to stop what they’re doing, gather in a room or online, and context switch to the topic of the meeting is frequently a waste of time and energy!

It is well established that context switching is an absolute killer of productivity.

Watch out for: unnecessary meetings; high work-in-progress and lots of context switching.

Develop a habit of questioning your attendance at meetings that don’t seem to be adding value (trust me, it’s a power flex!). And minimising meeting faff will only be celebrated by the team!

Ask yourself: Do I need to be here? And How can I make sure I have time to really focus on my work? Or even better: Is this meeting even necessary?

Last, but by no means least, is defect waste. Defects are errors or mistakes in products or processes. In our context, they are unforced errors in our work that cause issues down the road. These Issues could be as small as a miscommunication requiring a clarification, or as large as an incorrect solution making its way into production code.

We can contribute to defects in many ways, but misunderstanding is the most common way.

Watch out for: ambiguous documentation; Inconsistencies between artefacts; ongoing conversations about (supposedly) settled topics; product defects due to incorrect specs.

A lot of this is avoided simply by diligently doing your job and taking care of the details!

In most environments, defects are the most obvious kind of waste, and therefore the most managed. I’ve even heard managers imply that defects are a kind of quality metric of the business analysis work done up to that point. That’s a weird and dangerous position to take, but the point remains that it’s unlikely that you aren’t already aware of defects, and are probably actively working towards reducing them.

There’s some risk to that as I’ll explain, but in the meantime, ask yourself: Are these errors avoidable?

Now, I could have simply rattled on about waste in a sort of general and vague way, but I dug into the details of all the different types of waste for good reason.

Thinking of waste in a general way is likely to have untended consequences. That’s because the different types of waste have complicated and complex relationships with each other. In some cases eliminating one type of waste can often generate waste in another area. In other cases, creation of one kind of waste makes another much more likely.

For example, if you work hard to eliminate defect waste completely (which you’re probably under pressure to do), then you’re at far higher risk of creating waste. Why? Because all the surface level approaches to reducing defects have unintended side effects.

Such as adding more detail and documents to work items, or adding additional steps to your delivery process. Both could be over-processing waste. And just as booking new meetings to really make sure the team has the information they need could be motion waste.

Exclusively focusing on defect waste won’t necessarily get you the result you want.

Conversely, over-production and inventory are positively correlated. Inventory is a symptom of over-production. This makes it difficult (impossible?) to tackle inventory without also tackling production levels.

The upshot is that thinking about waste in a vague way is dangerous – you’re at risk of actually causing more problems than you’re solving.

So what can you do?

Move slowly, and be careful and considerate about the actions you take.

Advice that works for waste, and for living!