July 2013

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

Avoiding “junk shop” requirements

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?

Progress Bar at 36% with person asleep on top of it

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:


Person about to step on banana skin

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

I’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,… 

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!