Image Credit: © Ezume Images – Fotolia.com #91099334
I have never been good at predicting the future. In fact, I suspect all of us find predicting future trends difficult—and predicting medium and longer term futures is even more difficult. As Steve Davidson observed:
“Forecasting future events is often like searching for a black cat in an unlit room, that may not even be there.”
Yet, inaccuracy and uncertainty doesn’t stop predictions being useful for some applications. If nothing else, predicting (one) possible future creates the opportunity for a conversation, for agreement, disagreement and refinement. My intention with this article is to do just that—to set out one possible future and to create debate. So once you have read this, I’d love it if you added a comment below! What do you agree with? What do you disagree with? Be sure to let me know.
So here goes. My top 6 predictions for Business Analysis in 2020:
1. Increased Focus on Intersections and Connectivity: No one discipline “owns” strategy. No one discipline “owns” change or execution. Organisations work as a complex web of intersecting disciplines. Too often, today, there are useful (but ultimately academic) arguments about where BA finishes and other disciplines start. There are interesting discussions about How Business Architecture does (or doesn’t) overlap with Business Analysis, where analysis stops and design starts and so on. The irony is that our customers almost certainly don’t care where the boundaries are. They just want their problem solved, their solution(s) delivered and—crucially—their value to be co-created.
Image Credit: © Djahan – Fotolia.com #51472721
Of course, these conversations will continue. But over the next few years, as a community we will move the conversation on. I predict there will be an even greater focus, particularly amongst senior BAs, of reading the context and blurring the edges of the discipline. Boundaries become less important, and collaboration and co-operation (with a mutual appreciation of other disciplines) becomes crucial. Our analysis becomes a crucial strategic enabler for organisations to survive and thrive. We are one of the disciplines that appreciates the micro and macro levels, and can ‘create’ the complex web of professionals that is necessary to deliver. We become connectors, helping to create networks between disciplines and professionals that will get the job done. And in doing so, our discipline becomes more and more sought after.
2. Job Titles Will Evolve (But They Won’t be Standard): Currently, the term “Business Analyst” means many things to many people. Some BAs work purely on requirements. Others do everything from strategic analysis right through to delivery (and beyond). Organisations and BA practice leads will realise that you need both—but often the best Requirement Engineer is a different person with different aspirations to someone that works predominantly pre-project on Strategy Analysis. That may happen to be a different person again to someone that has experience throughout the whole analysis lifecycle. Rather than calling all three people a “Business Analyst”, we’ll see a resurgence in other titles: “Requirements Engineer” might be used to describe someone that just works on requirements, for example. Yet there still won’t be standardisation. And it won’t matter, the variety will create an awesome opportunity for people to carve out their own career path. All roles will exist within the broader definition of ‘business analysis’.
3. People Will Talk About Projects Less: I suspect most of us spend a great deal of our career working in projects. It is easy to think that a ‘project’ is a natural thing that has to exist to get change initiated. Yet, the underlying idea of a project is (ultimately) an imaginary construct. “Projects” (in the normal sense) only exist because we think they exist. Other cultures at other periods in time would find it very curious that we hang Gantt charts around our offices and organise our work in this way!
Of course, business analysis exists outside of projects too. As the business environment gets even more volatile and fast moving, organisations will continue to look for alternative mechanisms of co-creating value and achieving outcomes. Indeed, the #NoProjects community on Twitter is one that has already emerged. Proponents of Systems Thinking would argue that Systemic Inquiry is a viable alternative to projects when the environment is complex. We’ll see a continued discussion and subtle shift to other ways of conceptualising work, which will require us to ‘un-learn’ as much as we ‘learn’!
4. Job Hopping Will Be Fine: As a new generation of BAs gain experience and seniority, attitudes towards longevity of tenure will change. Employers will cease to look for “ten years’ experience in the Financial Services sector” and instead will look for the right type of BA with the right complement of experience. Job hopping won’t be looked down on. Those who have job-hopped will have different exposure than someone who has stayed put—they will have seen a wider range of situations, delivery approaches and industries than someone who has stayed put for 30 years. BA Leaders will appreciate that you need both types of individual in a team.
5. Creation (as Well as Consumption) Will Be a Pre-requisite For Senior BAs: As the profession matures, more and more senior BAs will set out to create content for the global BA community (as well as consuming it). We’ll see more and more articles, blogs, case-studies and books. We’ll help each other, and in providing this peer-to-peer support we’ll find that our community will gain a critical mass that we can only imagine now. Employers will come to expect that Senior BAs need time to ‘create’ and will encourage (and expect) them to do so. The global pool of knowledge and practice will grow, and the informal network of likeminded practitioners will grow.
6. Purists Will Be As Prevalent (and Irrelevant) As Ever: Pragmatists will continue to adapt methods and methodologies to fit contexts. Purists will continue to argue that we should always refer to a method/methodology/framework/text and never deviate from it. Whilst there is a time for purism (and I am certainly not arguing against standards), contextual pragmatism will continue to deliver. But this won’t stop Internet Forums being filled with purist/pragmatist debates—which (I’m sure) we’ll continue to engage in 🙂
I hope you have found these predictions thought provoking and interesting. And if you have, please do go ahead and add a comment below—I would love to hear your thoughts!
What are your views and perspectives, do you have anything to add? Please add a comment below, and let’s keep the conversation flowing!
If you’ve enjoyed this article don’t forget to subscribe.
About the author:
Adrian Reed is Principal Consultant at Blackmetric Business Solutions, an organisation that offers Business Analysis consulting and training solutions. Adrian is a keen advocate of the analysis profession, and is constantly looking for ways of promoting the value that good analysis can bring.
To find out more about the training and consulting services offered at Blackmetric, please visit www.blackmetric.com
Hello Adrian,
I am interested in your last paragraph on purism…What do you define as contextual pragmatism? Whose pragmatism? Isn’t this a very subjective concept depending on experience, approach to analysis etc etc? How do you marry different perceptions of reality? And how do you cater for the problematic tendency to mix simplification for simplism, that potentially skews pragmatism?
And how do you define purism? Do you see as a purist (therefore irrelevant as you write), one who argues that on any given methodology or framework, the principles should always be followed no matter what (although questioned, despite the fact that this is sometimes unrealistic for a practitioner)? A bit like the PRINCE2 discussion on following the principles but adapting everything else around them depending on organisational context.
Hi Spyros,
Thank you so much for your comment. You have asked some very thought provoking and valuable questions, which have led me to reflect further on that paragraph! In fact I have been thinking *a lot*about what you have written. It is always so valuable to get another perspective.
My reply below is rather lengthy and quite abstract in places, I hope it makes some kind of sense!
I think I’d start by differentiating a ‘purist’ from a ‘theorist’. What I am definitely *not* arguing against is the need for theory. Indeed, as a (global) community of practitioners, we gain a lot by abstracting the successful practice from one area and applying it in another. Theory is one way of doing this (or, if we were being more specific, then we might say ‘heuristics’ either as part of or as well as theories. And we could have a good debate about what constitutes a theory and how (or if) this differs from a method, methodology or framework… But I am probably over-thinking things now…!).
So with ‘purism’ in the context of the article, I am really referring to what might more accurately be referred to as ‘single-minded purism’ or (more provocatively) ‘dogmatic purism’. The type of purism that searches for (and ascribes) absolute truths in a complex system, where (potentially) none exist. For example, we might say that a specific methodology, let’s call it <> has a definition of ‘project’. But that is only *one* of many possible definitions. It is possible that a situation exists that falls within the < > definition of ‘project’ that isn’t treated/perceived as one… perhaps because it is happening in a very specific context that precludes, or because the team involved have deliberately chosen another construct. Or indeed, someone else might use a different definition—or might adapt the definition for their situation. A ‘purist’ who sticks rigidly and dogmatically to the *letter* of < > ‘s text irrespective of the situation or context is what I’m arguing against.
This is all very abstract, so some hypothetical (and potentially provocative) examples;
Person X “Waterfall is *always* better than Agile and we should only ever use XYZ’s version of Waterfall”>”> and < >; they are by separate standards organisations!
Person Y “You’re only Agile if you’re using <
Person Z “ You can’t ever mix <
The irony, in my view, is that sometimes purism leads us to miss the point. It is one of the misconceptions of the BABOK, for example. BABOK is (deliberately) entitled “A **Guide** to the Business Analysis Body of Knowledge”. It doesn’t *purport* to be the be-all-and-end-all of business analysis, but it sets a suggested (and increasingly permeable) boundary and suggests commonly used techniques. This is interpreted (unfortunately) by some as “If it’s not specifically referenced in the BABOK it isn’t business analysis” – which wasn’t the intention and sets us into a prison of our own creation. But I digress!
You also asked about ‘contextual pragmatism’ – Here I am talking about what (I suspect) we all do without thinking much about it. We have a toolkit, we have templates, we have methods and methodologies… and we pick the “best” ones for the job. We read the landscape, and adapt. But if something doesn’t work, we change it, we pivot. We focus on the business objectives, as these are key. We might have a map, but if the terrain has changed, we respond to it.
But, building on from this, the curious thing is that there is a relational dynamic between the ‘situation of interest’ and the practitioner… i.e. by practising well, we not only *change* the thing we’re changing , we also *change* ourselves; we learn, grow. Hence Business Analysis being something that one ‘practices’…. ? And by connecting with other practitioners, we grow the global pool of knowledge and experience.
Your other points are equally valid and interesting. “Pragmatism” is, of course in the eye of the beholder. Yet we get a sense of pragmatism by understanding others’ perspectives on the situation of interest.
I hope this makes some kind of sense. Drop me a line offline if you’d like to continue this discussion, it’s a very interesting one (and branching into Systems Thinking & Systems Practice) but one that is almost certainly better continued over a coffee sometime 🙂
Thanks again Spyros for your thought provoking comment, I really enjoyed reading and thinking about it!
Hi Adrian,
Thanks for your interesting and thought provoking article. I’m interested in your comment “Some BAs work purely on requirements. Others do everything from strategic analysis right through to delivery (and beyond)”.
My experiences have proven that requirements always exist throughout the whole organisations from a high level (strategy) to low level delivery and business as usual. For a Business Analyst the competencies are slightly different with managing requirements at different requirement levels.
Would be interested in your thoughts.
Rgds
Tim
Hi Tim,
Thanks for your comment, and I’m glad you found the article interesting/thought provoking.
I think it depends very much on what we mean by ‘requirement’. I would draw a distinction between an objective, a need, desired value and a requirement. But of course all of this depends on context.
Take an example: Imagine a city council has a problem with traffic. They have signed off a project to invest in complex new traffic lights, and a BA is assigned—but that BA works with the decision makers to establish what their transport strategy is, and what their vision is. Are they looking to become a ‘car free city by 2050’? Are they striving to be ‘the friendliest city for motorists in the world’? And how would these things be measured? And do any of these things actually need new traffic lights? Perhaps the BA convinces the sponsor, that on reflection, they should delay buying new traffic lights and to examine other options first, to ensure that value is enabled for as many stakeholder groups as possible.
This is all about eliciting and understanding perceived value, and drilling in to how that value is measured. Of course, this leads on to understanding value from the perspective of different stakeholders—a cyclist’s lobbying group may have a different view to a motorist’s lobbying group. And a balance has to be struck.
The point being that yes, any change to people, process will need us to talk about requirements. But when carrying out, say, an analysis of the competitive landscape of an organisation—is a BA working on ‘requirements’? I would argue that they are focussing on assessing the current state—then of course they can help define the future state, assess the gaps and then the requirements come into focus.
Although, of course, the essence of your statement is quite right. The reality is that requirements exist whether we know about them or not. A requirement can be implied, stated, known or unknown. Knowing when to focus on them (and when not to) is crucial.
But, as a whole, I think we use the R-Word far too much—which has historically led to some stakeholders thinking you only need to engage a BA once the needs, value (and in some cases solution options) have been nailed down. Yet, as we know, the definition of these things are where a good BA will save an organisation time and money, and ensure that the organisation achieves awesome outcomes.
Thanks again for your comment, which was very thought provoking 🙂
Kind regards, Adrian
Hi Adrian,
You are correct it does depends very much on what we mean by a ‘requirement’. I agree with your distinction between an objective, a need, desired value and a requirement.
Maybe looking at the IIBA Core Concept – Need, Change, Solution, Stakeholder, Value & Context will help people to see the connection between the many moving parts within an organisation that need to be traced together for success.
The messaging we may need to express to senior manages is that a BAs performs elicitation, analysis, specification and manages needs, value & requirements?
Rgds
Tim
Tim, thanks so much for the comment.
I agree, indeed the BA core competency model is useful and helps to illuminate these types of discussion.
Messaging is a tricky issue isn’t it? I think, on the whole, we need to focus on the benefits of business analysis (rather than the tools or techniques). To draw a (deliberately) left-field analogy, if an airline said “We maintain, fuel and fly aircraft and also issue and validate tickets, specialising in transatlantic flights” that may well be accurate. But a far more compelling message is “We can fly you from Heathrow to JFK in 7 hours”.
Although articulating the value/benefit of analysis will vary depending on the stakeholder. There’s so much we bring to an organisation:)
Thanks again for the comment, which I found very thought provoking!
— Adrian,
Adrian, I think we need to message both benefits of business analysis and our the BAs unique tasks, techniques, tools and competencies. The “We can fly you from Heathrow to JFK in 7 hours” message is more compelling but many stakeholders contribute to that customer journey not just the BA so what is the BA point of different (POD) or unique selling proposition (USP)? My thought is that “We can fly you from Heathrow to JFK in 7 hours by managing needs, value & requirements”. Many other professions elicit, analyse & specify but I don’t know any other profession that manages needs, value & requirements.
Rgds
Tim
Tim, that I agree with entirely. Plus, of course it depends on the stakeholder that we are communicating with (a CEO is likely to have a different perception of value to a front-line worker, for example…).
Now I understand what you mean about using the BACCM 🙂 That’s a really nice approach.
The problem, from my perspective, is there are some in the BA community that are very ‘deliverable-centric’. E.g. people talk about business analysis as “The people that write requirements”… whereas nobody *really* wants requirement artefacts; they want delivered, valuable, operating change. And so it’s about aligning the breadth of what we do (which, of course includes requirements discussions or artefacts as well as many other things) with the value they help to co-create. And, as you have quite rightly pointed out, the BACCM is a great way of framing that.
Thanks again Tim 🙂 Hope you’re well & hope to chat soon,
Adrian.
Adrian, I agree that the BA community can be very deliverable-centric rather than value centric. However, it is important as we change to not throw the “baby out with the bath water” & we keep our POD (manages needs, value & requirements) while describing the value we bring to organisations.
Hopefully we can get our messaging better to make the transition into 2020!
Rgds
Tim
A bit late in responding to this… but hey it’s not 2020 yet so maybe not.
The question about where the BA profession is going is one that I’ve been mulling over a lot recently. I agree we are going to see a blurring of job roles and I’m pretty sure the buzz words of the next five years are going to be collaboration, collaboration and collaboration.
However while the BA job title may become an endangered species, the BA skillset most certainly will not. In fact, I think Agile makes business analysis more relevant than ever, alongside the trend of having smaller projects and piecing together multiple technologies from multiple vendors. The real value add is going to lie within the skillset that best enables organisations to extract value from their investments across multiple technologies. i.e. the skillset that can bring it all together and make it work from a user perspective.
So perhaps we’re going to see more generic “change professionals” for whom business analysis is one of the critical skills that such professionals must have.
Whatever happens, I certainly hope that the BA profession as a whole starts to get the recognition it deserves – I’m afraid there are still a lot of people out there who see BAs as note takers.
John, thanks so much for the comment. I completely agree. In many ways,the title is not the most important thing (IMHO). It’s the *analysis* that matters.
The ‘note taker’ perception can be challenging, can’t it? I like to think as a professional global community we all contribute to changing those attitudes, one stakeholder at a time 🙂
Thanks again — Adrian.