The post Tackling the fallacy of agile appeared first on BSG (UK).

The post Stop guessing! appeared first on BSG (UK).

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

Talk to the customer

Our world is shifting and decisions are no longer made behind closed doors between Business and IT. At least they shouldn’t be. Customers are increasingly using online channels and leaving their footsteps in the front-end systems of every organisation. If IT people can observe these steps they’ll get a better understanding of the customers.

Profiles, personas and behavioural pattern data is growing, ready for analysis. If we ask the right questions, we can validate customer need for almost every improvement. Moreover, customers demand the online presence of the companies who should take advantage of this. Social channels create context for cheap two-way communication and you can easily hear the voice of the customer directly.

BAs are well positioned to champion these. Let go of the traditional gap between Business and IT and open the bridge to the customer. Emerging methods, like User Experience Design and the influence of lean startup principles, provide direction on how to do that. With the new insights gained, BAs will have more opportunity to influence strategy as well and guide the organisation on a customer facing journey.

BAs and agile delivery

Agile: a word shaking the world within IT circles. As a “new” philosophy which has been here for more than a decade, it still causes controversy. While some praise it and others fear it, the agile way of working is leaving an indelible mark on the software industry. Recently it has a huge influence on the business side too. We hear corporate sponsors asking their projects to be agile, because it’s “better by definition” (a turn of phrase which, itself, demonstrates a lack of understanding).

Although the agile methodologies were created to be more adaptive, a poorly designed agile project will underperform a well-managed waterfall type delivery. Projects are delivered in context and agile is a way of configuring resources to meet the business need. The agile approach calls for greater collaboration between between business and IT, and, we would argue that the voice of the customer needs to be directly represented as part of business.

So, do BAs have a role in the agile world at all? Surely business folk can simply meet with developers and spitball requirements? Thankfully (for us BAs), it’s not that simple. Projects still need to be shaped, benefits cases created, requirements sought from wide stakeholder groups (including the customer) and documentation created (to an appropriate level of detail).

BAs need to step up from being merely authors of requirements to being agents of change. As the agile methodologies require much more trust and collaboration, BAs could and should be the glue which holds the whole system together. But because every environment is different, BAs have to fully understand their responsibilities to be able to bring value for the organisation.

On the edge of business analysis

In this profession we can’t simply restrict ourselves to a thin slice of the business we work for. We are responsible for understanding the operation of the whole mechanism, time to put our systems thinking hat on. The conference included some topics that, on the surface, wouldn’t typically be considered in the BA’s area of responsibility however, as they were discussed further, the links became clearer.

One such topic is reputational risk management. Customers are increasingly using online channels for communication and expect their beloved brand to use them too. The most important aspect of reputational risk is how your actions appear in the eyes of the clients and this is central to how you communicate with them. Customers ideally expect you to be online when they are, or, as second best, at least manage their expectations about your online availability. These expectations need to be built into the enterprise’s process as central to their customer relationships.

Notes

David Reinhardt, a BSG (UK) principal consultant, delivered a presentation titled “Did BAs become irrelevant when business learned to code?”. The talk focuses on the evolving role of the BA in response to a narrowing business-IT gap (including the “introduction” of the customer into this gap). The presentation material can be found here.

BSG has previously published a paper on the role of BAs on agile delivery teams. Read it here.

The post BSG (UK) reflections on the UNICOM Business Analysis Conference 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).

At the outset of every engagement, we spend time architecting the project to ensure that there is alignment between the organisation’s strategy, the proposed deliverable of the project and the approach to be adopted. Over the years, we’ve seen many, uhm, less than optimal practices across the industry. We decided to write them up in a “cheat sheet” for project architects.

Project architecting for anti-progress

Make roles and responsibilities unclear. In fact, why even consider them at all? Just assign people to the project and hope that they will get on with it. This way, the real “diamonds in the rough” will get a chance to shine. It’s Darwinism, project style.

Make your documentation as long as possible. Long documents are proof that you’ve consulted widely and thought hard. Stakeholders really appreciate them because they get a chance to be sure that every single conceivable exception, no matter how unlikely, has been considered. They also look really impressive on the desk. Aim for at least 250 pages (excluding models, these should be in a separate appendix).

Ensure that there are dozens of people engaged in review cycles. Surely it is better to get insight from everybody in the organisation? And customers. Not to mention suppliers and regulators. If you research and review requirements with a massive stakeholder group then you’re sure to be able to deliver a fantastically thick requirements document.

Everyone needs to agree on everything before progressing any single decision. This is a project, not an autocratic government. It needs to be setup so that every decision is consensus driven across a wide stakeholder group. Especially the little decisions, those are most important. Documenting the never-ending email chains as decisions progress provides great content for your appendices.

Encourage teams to operate as functional silos during delivery. Talking to each other only slows things down and gives people the illusion of being involved. It’s much better to ensure that different parts of the project team are minutely focused on their own work at the expense of anything else. This will allow you to write documentation much more quickly.

Waterfall. Only. Forever. Thinking through different delivery approaches will only slow down the project. Why waste time planning how to do something when you could be having meetings and writing documents? Those new fangled approaches are only a fad anyway, everyone knows the space programme / banking platform / other important thing was built using a waterfall approach.

Keep it big. Breaking up the scope into small manageable chunks only demonstrates an inability to be a big picture thinker. Also, you never know whether you’ll get budget again so be sure to use it all in design and delivery. With all the analysis you’re doing, it’s almost certain that your design will be totally accurate.

Make change within the project complex. Don’t let stakeholders fool you with changes to business priority and process. The point of the waterfall approach is to draw a line in the sand. There’s no point in a line if you don’t police it. Make it exceptionally difficult to cross that line. This will demonstrate how serious you are about meeting the project ambitions and win you respect across your stakeholder community.

Paper, paper and more paper. Don’t be fooled by tools that allow either better management of requirements throughout the project or collaborative working environments. These too are a fad. There are many detailed spreadsheet templates that will allow you to track traceability across a complex design making for value-adding work on the project team. Paper will never go out of fashion.

Make workshops cover as much ground as possible. Your stakeholders are busy. And they need some time to be available to review your thoroughly written documents. Be sure to make workshops cover every angle – the more you can cram into a single whiteboard session, the better. Don’t worry about focusing on the details, stakeholders often get this type of stuff confused anyway. It’s your job to address this as you write out an activity diagram, use case and associated notation for every single process.

Measuring benefits is like counting up your old Italian Lira. Benefits only begin accruing after the project is complete. By then, you should be focused on some other important project or change. You want to be a forward thinker, not stuck in the past.

Do you have any more rules to architect projects for anti-progress? Let us know in the comments.

The post Project architecting for anti-progress appeared first on BSG (UK).

This tool helps identify (and track) traceability from strategy all the way through to the change delivered by a specific project.

The post Benefits pyramid appeared first on BSG (UK).

The post BSG’s reflections on the UK IIBA Survey 2012 appeared first on BSG (UK).