Time really does fly! I can’t quite believe it’s just over two weeks until the start of the Business Analysis Conference Europe 2019 (#BA2019) in London. As I plan the final practice runs of my presentation which is entitled “Whose Perspective Is It Anyway? Practical Analysis Techniques for Understanding Tricky Stakeholders”, I can’t help but get a…
As anyone who has ever worked with me will know, I’m somewhat of an advocate of Non-Functional Requirements (NFR) Analysis. I’ve found that in some projects, sadly, the NFRs are left unexamined, with the Functional Requirements taking the lime-light. This is understandable, after all it’s far easier to talk about what needs to change, and far harder to talk about the quality attributes and other non-functional elements of that same change. Yet get the NFRs wrong, and you end up building a very shiny and expensive system that nobody actually uses. If you are in the UK and have been to a Post Office recently you may have experienced the ‘self-service’ booths. As Roland Hesz observed on Twitter, these are so complicated to use that they have a member of staff guiding people through the process….
For a whole variety of reasons, I’ve been thinking about NFRs a lot recently, and I came across three articles that really resonated with me, and made me think it’s about time we revisited the ‘standard lists’ of NFRs that we use. In particular, I think there are two sets of categories that we ought to add.
As I’m sure many readers will be aware, the International Institute of Business Analysis (IIBA®) recently launched the IIBA®-AAC. AAC stands for “Agile Analysis Certificate” and as you’d expect this is a certification program aimed at BAs working in an agile environment. I recently sat (and passed!) the exam, and since then a number of people have asked me if I have any tips. With this in mind, I thought I’d put together a blog post whilst the experience of studying was fresh in my mind. I hope that you find this useful.
Imagine the scene: You’re just about to start the analysis for a project which involves a large contact centre employing hundreds of people. The call centre manager hands you a dusty folder marked Procedure Guide. “Here you go, this is exactly how we do things here.” says the manager, “this will save you interviewing our busy front-line workers!”.
I suspect many of us have experienced this situation (although it’s far more likely to be some kind of electronic repository rather than a dusty manual) and when it happens we try and hold back a wry smile. Procedure guides are extremely useful artefacts, but so often they are not properly managed and maintained and they quickly fall into disrepair. In some cases, the work that is conducted on the shop floor often bares only a passing resemblance to the ‘official’ processes, and in many cases there are unofficial ‘enhancements’, ‘interpretations’ and ‘workarounds’ that have crept in over the years.
With this in mind, when we are carrying out business analysis and improvement work it’s important that we understand how the work really works. Elicitation techniques such as observation, apprenticing, scenario analysis and many others can help here. If the process hasn’t been well-managed and well-maintained it’s highly likely that we’ll find variation. Differences between teams, and even individual workers may have emerged. There may be entire new ‘steps’ in the process that have been created, or steps might have been removed, re-ordered or changed in some other way.
As many of you know, I enthusiastically believe in the value that good quality Business Analysis can bring, and I love speaking, writing and presenting on this and many other topics! In a break from my normal ‘blog’ style, I have a very quick update for you. I’m really excited to announce I’ll be speaking at…
Like most folks I know, I have a whole range of mixed memories from my years at school. Some fantastically ecstatic, others scary and traumatic, but I suppose the sum of those experiences were all ‘character building’. If you had met me as a school-age child, you would have found someone who had very strong ideological views, but who so often lacked the ability to express them clearly. Some would argue that little has changed 🙂
I did fairly well at school, but was also seen as a bit feisty at times—my strong views and beliefs weren’t always compatible with the power structures that existed in schools (those power structures, by the way, extend way beyond the teachers and well into the playground). One phrase that I remember people who perceived that they had power over me told me time and time again was:
“You’ll think differently when you’re older“
Within some organisations there seems to be a management mantra of “pursuing ruthless efficiency”. On the face of it, other than sounding like something that ought to appear on a “buzzword bingo” sheet, this seems like a sensible thing to aim for—I mean if we can hit the “sweet spot” of being more efficient (i.e. incurring less costs) whilst also being effective and delivering what our customers want, that has to be a good thing, right?
Well yes, this statement is probably true—to an extent—but there are some important nuances that are easily overlooked. Efficiency is crucial, but like most things in life, it becomes problematic when taken to an extreme. Balanced efficiency can be an excellent thing to aim for—it can actually mean you exceed customers’ expectations (“You can deliver quicker than I expected? Awesome!”). Ruthless efficiency, on the other hand, where an organisation cuts, cuts, cuts without looking and thinking holistically at the impact is far more problematic.
I was mulling this over recently when working out at my gym. I’ve been a member of this particular gym for over 15 years, and I’ve seen managers and gym staff come and go. The gym itself has changed ownership in that time, and in the past five years it’s pretty obvious that they have been cost cutting presumably with the aim of being “ruthlessly efficient”. In fact, a few years ago they even lowered their monthly subscription charges, to make them more in line with their competitors. Something that is pretty rare! So how has the drive for ruthless efficiency affected them (and their stakeholders)? Read on….
I am sure many people reading this article will have worked on one, or probably many, projects which involve migration of data from one IT system to another. One of the things that the data migration elements of these projects tend to have in common is that they are painful. It is not that migration of data itself is always tricky, it is more that the quality of data on the source system tends to be an issue. Data cleansing and data mapping can be tricky, particularly when there has been poor data governance and stewardship. In a worst case scenario, we might even find fields being used for different purposes by different teams, or there might be ‘debates’ over what specific data items actually mean (“Order date is the date the order is received”. “No! Order date is the date that the order is accepted, which means payment has also been made”).
There are so many issues that we could discuss, I’d like to zoom in on one: the granularity of data.
This is probably best illuminated with an example. My home insurance was recently up for renewal, which I purchased via a large online insurer. Technically, they are a broker rather than an insurer—but you wouldn’t know that to look at them (as the policies are branded with their logo, and you have to look pretty hard to find out which insurer actually underwrites them).
Close to the renewal date I shopped around and found some slightly better prices . I rang my insurer to see if they could price-match, and I was surprised as they asked me for a whole bunch of information that they already had on file. Concerned, I asked why, and the agent explained to me that they had migrated from one IT system to another, and he no longer had access to the ‘legacy’ data.
I have spoken to a number of people recently who are keen to get into the business analysis profession. This can be tricky, as many roles specifically require a certain number of years of BA experience before a candidate can even be considered. This can lead to a ‘chicken and egg’ cycle… without experience, it’s tricky getting a first role. But without a role, it is tricky getting experience! This blog post is an attempt to capture some thoughts on how to overcome this. It’d be great if you could add your own thoughts into the comments section—that way hopefully this will evolve as a useful set of ideas for those entering the profession.
One crucial fact to keep in mind when applying for roles is that you don’t have to have the title “business analyst” to be undertaking business analysis. The International Institute of Business Analysis® describe a BA as:
“Any person who performs business analysis, no matter what their job title or organisational role”
(IIBA® BABOK® v3)
This has an important implication: If you have a BA mind-set, there is a good chance that you are already undertaking some elements of business analysis in your role, and there might even be the possibility of expanding this to cover even more ground. Of course it’s unlikely that you’ll be undertaking the full breadth of a BA role, but you may well be undertaking some crucial parts of it. This can be true even in the most seemingly unlikely of roles—a call centre advisor, for example, may have gained significant experience of defining and improving processes alongside their ‘core’ job. It is worth actively seeking out these types of experiences, as well as cataloguing the experience that you already have so that it can be added to your CV or Résumé.
As with any profession, there are a whole range of approaches, techniques and even a common ‘language’ that BAs speak. It is worth becoming familiar with this, as this will help to gauge the areas where you already have experience (which is an advantage) and those where you don’t. It isn’t essential to have knowledge and experience of every conceivable technique, but there are a number of ‘core’ concepts that are useful in just about every BA role. There are plenty of blogs, webinars, courses, books and other resources out there that can help. It is also very valuable to consider a foundation or entry level certification programme. Whilst this isn’t essential, it might just give you the edge over other candidates.
I am a real fan of journey maps. They are a great way of cultivating a conversation about the value that a stakeholder is seeking and the types of experiences that will satisfy them. A few recent experiences have moved my thinking on journey mapping, and this blog post is my attempt to capture these thoughts.
You may have noticed that some practitioners talk about ‘customer journey mapping’, others talk about ‘user journey mapping’. Sometimes these terms are used interchangeably, but in terms of journey mapping I have found them rather problematic. For example: