When I first began business analysis work, we’d focus intently on process and data requirements. After rounds of analysis and reviews, we’d have a detailed sense of what it is the system needs to do. In the planning we’d make some time available for designing reports towards the end of the requirements phase. We’d use this time to identify some logical counts of activity, aggregations relative to business structure, etc.

At a macro level, it is clear that our design focus was very much focused on what the system needed to do. If we got the system’s ‘what’ right, and counted those meaningfully, we’d provide handles on the levers that management needed. Or so the theory went.

Those days are gone. Or at least they should be.

Today’s designers should be focusing on a system’s ‘why’. Why does this system need to exist? Why is it important to solve this particular problem? How does solving this problem contribute to our organisation’s strategic ambition?

A top-down focus changes the design perspective entirely. The focus of the team becomes ensuring that processes and transactions are designed with an end-to-end outcome view rather than just addressing specific transactional issues. With that in mind… what does this system need to do?

An example – let’s take a point-of-sale system. It’s pretty obvious that a store needs a point-of-sale (POS) system to process transactions. Most stores stop there, roll-out any number of off-the-shelf POS solutions and don’t give it a second thought. Apple’s why is about being a disruptive innovator with a focus on simple, beautiful solutions. If you go to an Apple store, the till comes to you. If you’ve got an iTunes account, you’ll have a receipt in your inbox before you’ve even left the store.

It is my fervent hope that at some point in this process, the design team said to themselves ‘How can we make this process consistent with Apple’s strategic ambition?’ shortly followed by ‘It is essential that we delight customers, how do we do that?’ Sadly, I wasn’t there to witness it but I can be sure that if they’d started with the question ‘How long do we want the average queue to be?’ the outcome would’ve been vastly different.

About those reports

This post isn’t really about reports. It’s about how we’re recognising the need to flip the design process on its head. Rather than starting by identifying key transactions, we should frame a design in the context of why the solution is important. Reports are a useful metaphor because they used to measure the outputs of a process. Now we can use them as a framework for contextualising the organisation’s strategic ambitions by imagining the requisite management levers and using those to inform the design process.

An early analytics design session can even help inform the detailed process design as it will give the analysts considerable insight about what information management need. This information will ultimately need to come from somewhere within the operational processes. It should be designed-in from the outset rather than added on as an afterthought.

In this world, the reports don’t need to be an afterthought. Instead, they should demonstrate how the transactions that the system performs are / aren’t enabling the transactional performance required to meet the organisation’s strategic intention. Understanding what could affect the performance (next month’s unforeseen event) can also help design more robust processes (within reason).

What should we be doing differently?

There are two primary takeaways from this reflection.

1. All systems projects should be ‘why’ focused rather than ‘what’ focused. Starting with why provides broader context and enables design decisions which will be consistent with strategic ambitions. Systems are just enablers after all.
2. With this in mind, an initial conversation around identifying the important data points to which measure the ‘why’ will enable a more thorough design process when it comes to designing specifically what the system will do.

The “start with why” mindset is based on the inspirational work of Simon Sinek. Here he is at TED explaining it although I wholeheartedly recommend reading the book.

This article originally appeared on the BCS Guest Blog on 16 June 2012 Click here to view the original article.

The post Taking a ‘start with why’ approach to design – David Reinhardt appeared first on BSG (UK).

It amazes me how often this perspective gets overlooked, never at the outset of the project of course. In the heady early days, it’s all about benefits models and the associated business case. It’s usually once the project gets underway that the focus slowly shifts from talking about why something is being done to what needs to be done.

We should know better

It’s not as if we – as a collective industry of change practitioners – don’t know what constitutes best practice. PRINCE2® teaches that projects deliver outcomes, not benefits. At the outset of the project, it is important that the benefits case is clear around when benefits are expected and – the bit most often overlooked – how they will be measured and reported on in the absence of a project structure.

Once the project gets underway, a collective madness ensues. Project plans are baselined and the team begin focusing on the deliverables. Little-by-little the deliverables of the project become the end themselves, rather than a means to an end. The project team gets caught in the trap of focusing on completing project products (i.e. the what) rather than remembering the project’s cause (the why).

All too often we see stage gates reviews that the relevant documentation has been produced on time and to some notional quality standard. It’s not often that I’ve seen gate reviews do a genuine and meaningful assessment of whether the content of the documents is meaningful in the context of the project benefits.

Time is of the essence

Is it a matter of time? Typically the effects of a new system will be felt in a specific cycle. There will be an initial surge of activity driven by the project and the newness of the implemented change. People will take it for a test drive and kick its tyres. After a time, some sort of normalisation will take place when people either feel it is in their best interests to continue using the new system or they will fall back on old habits. The nature of the project will determine the length of the cycle.

The actual realisation of the benefits only comes much later, typically once the project is already shut down. The project team have packed up their laptop bags and moved onto bigger and better things and there’s no-one around to look after post-project activities. In reality, this is the most sensitive time in determining a project’s success. It’s only now that it can be determined whether the project has begun to deliver the benefits it set out to deliver.

Fooled by the plan

Strangely, the buyers of change don’t seem to be hopping mad about this either. They too succumb to the focus on deliverables. Delivery becomes the measure of success rather than objective review of whether the project has delivered the benefits it set out to achieve.

Hopefully buyers of projects have made their investment decisions based on the value of proposed benefit against the proposed project cost. Why aren’t they demanding evidence of value for money? Frankly, I don’t know. I do know that in the bulk of clients I’ve observed in 10+ years of IT consulting, benefits reviews are very rare. Rarer still are those that bring conversation around benefits, design imperatives and project objectives into the daily culture of the project.

I’m not against good planning. I’m not even against sticking to the plan. I’m just against task focused project teams perceiving the need to deliver product x against deadline y as more important than delivering the benefits that the project set out to achieve.

Key takeaways

So what should be done differently?

• Ensure that the project is based on a robust benefits case;
• Ensure that stage reviews have meaningful assessment of the content in the project products;
• Ensure that the benefits case includes a mechanism to monitor benefits after the project completes, and that this mechanism has an owner who takes accountability for operating it;
• Ensure that the BA, PMs and project sponsor create a culture where there is talk about the benefits of the project rather than just the deadline;
• Ensure that project sponsors hold the delivery team accountable for delivery of the benefits (this requires post-project monitoring and appropriate mechanisms for holding people accountable);
• Ensure that benefits are measured after an appropriate time is allowed to ‘bed the change’ rather than as part of the project shut-down activities.

This article originally appeared on the BCS Guest Blog on 22 June 2012. Click here to view the original post.

The post Blinded by the plan, ignoring the benefits – David Reinhardt appeared first on BSG (UK).