BSG (UK) Business Analysts recently attended the Business Analysis Conference Europe 2013. Shortly after the conference, the BSG delegates collectively identified a number of trends which cropped up across the conference topics.

BAs and leadership

There were a number of talks focused on the BAs role in organisational leadership and / or how leadership skills can improve the capability of BAs to influence change. Naturally, these positions go hand-in-hand because they, in effect, a virtuous cycle.

Although – BAs and project practitioners – we’ve instinctively known this for some time, we take the view that this is really a brave step for business analysis as a profession. We’re collectively standing up and saying (1) we have a broad contribution to change in the enterprise supported by (2) a skillset influenced by, and in turn influencing, leadership within our organisations.

Which is a great segue to …

BAs need not be stuck in a traditional “requirements jockey” box

The BA discipline continues to equip BAs with a wide range of multi-disciplinary skills that can be applied across the entire change delivery cycle. As BAs continue to deliver meaningful change, our credibility as change agents becomes well established and so the opportunity for involvement becomes broader and more impactful.

BAs should be very comfortable taking up these new challenges in shaping of strategic initiatives and getting involved through to delivery. This may involve moving beyond the traditional BA role of bridging the gap between business and IT and playing more of a challenger of status quo and advisory role in delivering high impact strategic outcomes.

To illustrate this point, it was argued that perhaps the BA role (as it is typically imagined) is an anachronism and we should be looking to create a more meaningful, broadly impactful role that draws on our BA skills. The BA is dead. Long live the BA.

This is supported by a worldview which says …

BAs can should be on the forefront of innovation

There is a traditional perception that innovation is conceived and developed in some laboratory or that it involves assembling a number of creative people into a room and being left to generate new awesome ideas. Thankfully, this world view is changing.

Innovation is not necessarily about the next Facebook, Square or well known, publically facing website. Innovation is a mindset: a discipline of changing the way something is currently done in a way that brings about competitive advantage or drives impactful change.

BAs should be playing pivotal roles in driving impactful change in organisations; either through introducing ways of doing things quicker and cheaper, or identifying better ways of exploring existing solutions to make them less complicated and more targeted at real customer problems and needs.

BAs need to shape a role / voice that is positioned to play a bigger part in the entire innovation ecosystem as we can be involved from idea generation through to solution delivery and embedding the change.

Which requires us to be mindful of …

Solving the real problem or any old problem?

It would be very interesting to see how many projects still fail because a solution has been designed for the wrong problem. If we had a penny for every time our business stakeholders propose “solutions” to “problem(s)” that haven’t been identified or clearly defined, we wouldn’t need to raise an expense form for next year’s conference.

We also recognise that it is very easy for BAs to be blinded by attractive and elegant solutions. Of more concern, there are times when BAs somehow limit their own perceptions of their role in revisiting a problem statement (especially when they get involved at a slightly later stage on a project).

The conference advocated for a world where during the initial stages of any project some time is set aside to put together a problem definition mechanism: something which (1) clearly articulates the real essence of the problem(s) (i.e. the “WHY”) that a project is planning to solve and (2) also manages any changes as a result of the evolving business conditions.

The ability of BAs to discern and callout such moments where there is a need to take a step back to understand the essence of a problem can prove to be crucial in the success of projects. At times, it might call for recommending that a project is halted – this might not be the most popular recommendation, but, if it is the right choice for the organisation, this will definitely raise the credibility of the BA role.

Once we know what we’re solving, we need to be sure we choose a smart way to solve it …

The BA skillset is as important in the agile world as it was in the waterfall world

As agile becomes increasingly pervasive, there has been a lot of questioning about the role of a BA in delivery. There is no doubt that (where context is suitable) agile practices have come to stay, but it is very important that BAs understand how transferable and applicable their acquired skills are in this space.

The key message for BAs is that their roles within an agile team should be very much about scaling their existing toolset to meet the rather flexible and adaptive-learning approach. The business and / or the customer still need a voice in the design of the solution and the delivery of the change. BAs need to focus on applying their skills to extract key business benefit drivers and ensure that the changes with the highest impact are rollout out first to maximise value creation.

For most of the agile related presentations shared during the conference, the key theme was that the BA role is still very relevant in the agile team structure.

To reference the conference material, please visit http://www.irmuk.co.uk/ba2013/

We published a similar reflections paper last year – BSG (UK)’s reflections on the BA Conference Europe 2012.

The post BSG (UK) reflections on the IRM Business Analysis Conference Europe 2013 appeared first on BSG (UK).

We love to talk about this. Please make contact if you would like to discuss any of the ideas in this presentation.

In the run-up to the conference, David also authored a blog post talking about the role of trust and the transition from a specification/control world to a process/trust world. Read it here.

The post Did BAs become irrelevant when business learned to code? appeared first on BSG (UK).

In this episode, you will get to hear from a top-notch BA in UK, creating ‘Aha’ moments for his clients in every engagement. His passion for doing work that can goes beyond just being a ‘project’ can serve as a great example for us to learn from.He shares many insights and tips that can help practitioners understand that our profession is a social profession and that collaboration is at the heart of a project well done.

The post Help your stakeholders to get better ‘aha!’ moments – interview with David Reinhardt appeared first on BSG (UK).

• Three orders of business analysis: bridging the gap, introducing innovation and facilitating change
• Understand the notion of “Analyst” as a language with tools, techniques and constructs
• Appreciating dialects of “Analyst”
• Recognising the need to be unconsciously competent at speaking “analyst”

This presentation is about the mindset of analysis, it is not about specific methodologies or approaches. I will reflect on “speaking analyst” in the context of our experience as consultant practitioners at our clients.

Presented by BSG UK’s David Reinhardt at IRM UK’s Business Analysis Conference Europe 2012.

The post Learn to speak analyst appeared first on BSG (UK).

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).

Presented at an IIBA UK evening event in July 2011.

The post Managing BA careers appeared first on BSG (UK).