Avoiding “junk shop” requirements

Picture of a jam-packed shop with lots of furniture outside

A few weeks ago I was looking for a new set of lockable office drawers for my home office.  Not far from me, there’s an excellent second-hand shop that sells all sorts of assorted furniture, so I thought I’d pay them a visit.


Picture of a jam-packed shop with lots of furniture outsideI arrived at the shop, and there was every type of furniture item that you could imagine – plus a few items you wouldn’t expect!  There were tables, chairs, dolls houses, even shovels and forks.   The shop was utterly jam packed with all sorts of interesting and intriguing items.  In fact, it was so rammed-full of furniture, I couldn’t even get inside.   I didn’t even know where to start looking, so I gingerly peeked around the door.   After about five minutes, I managed to attract the shop owner’s attention. He clambered over the furniture to reach me, and I explained what I was looking for.   He immediately knew where I could find the exact thing I wanted, and pointed me in the precise direction of a practically new set of lockable office drawers.  I bought them and took them home. They were an absolute bargain too!


On the journey home, I was reflecting on this rather unusual experience.   The fact was that the shop was so jam-packed with furniture of every imaginable type that it was virtually impenetrable to the average customer. The only way you’d be able to find what you were looking for would be to ask the owner.  I started to think about how in some cases we might be tempted to treat our requirements like this.


What this means for requirements


On some projects, particularly those that require a high level of formality, we might create a large number of requirement artefacts.  We might create deliverables and artefacts including a context diagram, use cases, non-functional requirements, a logical data model, a glossary and so on.  We create artefacts that are jam packed with precise and concise information.  As the author, we’ll instinctively know where to find everything in our requirement set – but what about the recipients?  How do they know which artefact they need to look at to find what they are interested in?  How can we stop our requirements becoming an unregulated “junk shop” where everything exists, but stakeholders can’t find what they need?

Continue reading Avoiding “junk shop” requirements

The danger of project progress reports: An illusion of progress?

Change projects are critical

Progress Bar at 36% with person asleep on top of itIt’s often said that organisations need to continually examine their environment and adapt to survive.  This inevitably leads to a focus on implementing valuable and sustainable change within organisations.  Change isn’t always easy, and for many mid-size and large organisations with hundreds or thousands of employees, it can be extremely challenging indeed.  Organisations will often, quite sensibly, take a project-driven approach to assessing, defining and implementing business change.  They’ll examine the status quo, establish what needs to change, execute that change and then measure the benefits.


If you say it quick enough, it sounds simple, doesn’t it?  As anyone who has ever worked on a change project will attest, it’s anything but simple.  Balancing varying stakeholder needs, managing risks and issues, and understanding what the business actually needs is easier said than done.  There are many twists and turns along the way, and many places where projects could get de-railed.  It’s therefore quite understandable that senior managers and sponsors in organisations rely on dashboards showing them how their projects are performing.   These dashboards help them to see whether their strategic programmes and projects on track and whether the deadlines will be met.


Projects sometimes go ‘off the rails’… even when they are measured


Given this sensible focus on tracking project progress, I’m always amazed when I hear of projects that appear to have been on course to deliver until the very last minute.  Everything was fine until the project hit 99% — then there were so many complex problems  that all emerged at once. What on earth could have gone wrong so late in the project lifecycle?  And, assuming progress reporting was in place, why wasn’t it spotted earlier?  In some cases, there may be illusory status reporting taking place.  Let me explain…


One dynamic that can affect reporting is ambiguity in reporting metrics.  There can be subtle misunderstandings over what progress is being measured.   In fact, one significant question that needs to be asked early on when a project is being defined is how will we measure progress?


Take the following examples:


Continue reading The danger of project progress reports: An illusion of progress?

Free Webinar: Helping Stakeholders to Take a Step Back and Avoid the “Solution Illusion”

Person about to step on banana skinI’m pleased to say that, In preparation for the Business Analysis Conference Europe, I will be presenting a webinar.  The session is entitled Helping Stakeholders to Take a Step Back and Avoid the “Solution Illusion” and will be held at 1pm UK time on 29 August.  It touches on some subjects that I’m very enthusiastic about, and will be of interest to BAs and other professionals who are involved with change projects.  The webinar is arranged by IRM, and you can click here to register your free place.


A full description of the webinar is shown below.  There are limited spaces, so be sure to register early to make sure you can attend!  I do hope you can make it, feel free to contact me if you have any questions in advance.


Thanks, hope to catch up with you soon.




PS – If you enjoy my blog, please feel free to reach out and connect with me on Twitter (@UKAdrianReed), by leaving a comment, or by subscribing. Thanks!


Helping Stakeholders to Take a Step Back and Avoid the “Solution Illusion”


Register here for the webinar

Imagine the scene: you’re assigned to a project that’s entering its detailed requirement phase. You trawl the existing project documentation and discover that a decision has been made to buy a major new enterprise-wide IT system – and it’s your job to write the “system requirements”. Your heart sinks: No analysis of the underlying problem has been made, and it looks suspiciously like the decision over which IT solution to buy may have been taken extremely prematurely. Project failure seems inevitable!


This is a hypothetical example, but I suspect many readers will relate to it. Sometimes organisations get blind-sided by the “Solution Illusion” – stakeholders fall in love with a solution and run projects to deploy it without a holistic understanding of the problem.


In this webinar, Adrian Reed of Blackmetric Business Solutions asks what we can do to help our organisations avoid the “solution illusion”. During the webinar you will hear tips and techniques to:


• Encourage stakeholders to think more holistically
• Quickly establish the rough scope of a problem
• Elicit or validate the drivers of the project.


Register here for the webinar

3 quick tips for building a “benefits friendly” business case

Introduction: Business cases are critical for projects


Blue darts hitting green targetsAs regular readers of this blog will know, I’m a firm believer that organisations should progress business and IT change projects for the right reasons.  The harsh reality is that all organisations – whether mid-size or multinational—have limited budgets for change. Naturally their executives and sponsors look to maximise the value for money they gain from their projects.   Whether the project is to implement a new process, a new IT system, or launch a new product, it’s vital to know the likely financial consequences before making a decision.   In order to assess this, decision makers need a firm view of the feasibility, costs and likely benefits that a change project will bring. This is often expressed in some form of business case or as part of a feasibility study.  This becomes central to the change project, and should be revisited whenever there’s a material change in scope or when new information presents itself.


A clear business case enables senior decision makers to see the “size of the prize”.  Putting it simply, they can see the size of the bet they are placing.  How much money do they need to invest in the project? What return are they likely to get and over what period? And what other impacts might the project have.  This is all essential decision making information which helps executives and project sponsors to decide which projects to pursue.


The business case lives beyond the project… but watch out for the trap!

Continue reading 3 quick tips for building a “benefits friendly” business case

The Importance of “Occasional User” Requirements

I’m pleased to say that one of my recent blog articles has been published on “Techwell.com”, where I have contributed as a guest author. I’d love to hear what you think, so please take a look and add a comment on the site.

A short excerpt is shown below:



Black and white artwork showing a person leaning out of monitor providing help to the userOrganizations in both the public and private sector are increasingly providing consumers with the ability to interact digitally, rather than in-person or by phone. For the right type of interactions, online self-service can provide convenience to the customer while also saving the service provider money. The UK government’s stance of “digital by default” illustrates the weight that this argument is given.


When processes move to the web, non-functional considerations—including usability—become crucial. There is often a perception that certain sections of the community will simply refuse to use online self-service tools. This doesn’t have to be the case…


Click on the link below to read the rest of this article


How to Bring Requirements to Life

I’m pleased to say that one of my recent blog articles has been published on “Techwell.com”, where I have contributed as a guest author. I’d love to hear what you think, so please take a look and add a comment on the site.

A short excerpt is shown below:



Picture of a character holding an umbrella, with yellow and red cards raining down“One challenge that business analysts face is early solutioneering. There are times when stakeholders are reluctant to discuss their needs or desires in terms of requirements, but just love to outline the specific technological solution that they want.


Perhaps they’ve seen a great new application that will solve all of their problems, or perhaps they’ve concluded that rolling out tablet PCs will increase productivity. In these situations, it’s important to help stakeholders understand the root problem and the desired end state by acting as a critical friend through enterprise analysis.


It’s worth taking a step back to consider why this scenario presents itself in the first place. As a business analyst, you’re probably comfortable with conceptual and logical thinking. You can think in multiple levels of abstraction, and you’re comfortable dealing with ambiguity and working towards a vision for the future.


You can ensure that requirements are written in a solution agnostic way—perhaps writing requirements like “authenticate user” rather than “validate password”—as even using the word “password” pre-supposes that they’ll be a password. We might use a thumbprint, key, or retina scan instead.


While in many projects defining solution-agnostic requirements is important—particularly when the solution is not yet known—it can be a challenge to gain consensus and wider understanding. Take the following hypothetical mixture of high-level requirements…”


Click on the link below to read the rest of this article



How Requirements Can Help Avoid Project Failure and Waste

I’m pleased to say that one of my recent articles has been published on “Techwell.com”, where I have contributed as a guest author. I’d love to hear what you think, so please take a look and add a comment on the site.



Money spiraling down a black hole, symbolising wasteStudies and experience show that higher quality and better value solutions are achieved by projects that attain a thorough and unambiguous understanding of business and user requirements. Teams may choose to express these requirements in different ways and may follow different approaches—whether waterfall or agile—but requirements analysis is a key underlying discipline.


Yet some high profile projects still appear to ignore requirements engineering and the wider practice of business analysis. Take the revelations in Arstechnica, which refers to a case study in West Virginia.


The article cites:


“…an absolutely scathing report […] by the state’s legislative auditor [where] West Virginia officials are accused of overspending at least $5 million of federal money.”


The cause of the controversy was the purchase of routers for use in public buildings…


Click on the link below to read more: