I recently announced that I’m not a Business Analyst, I’m a Business Analyst Designer. A job title is all very well, but it’s not much use without a job description. I have already waxed philosophical about the designer mindset – there’s no such thing as a requirement and it’s all design. But I haven’t said explicitly what a Business Analyst Designer actually does.
In this article I introduce the Business Analyst Designer Method – the method I follow as a Business Analyst Designer. I’ve been evolving it over the past few years, and it’s now stable enough to be worth sharing.
Business Analyst Designer Method (BADM) is a method for designing business change, especially where there is a significant component of IT system change.
BADM embodies agile principles – it is lightweight, encourages incremental delivery and collaboration, embraces change and prioritization, and focuses on delivering maximum business benefit as early as possible.
That said, BADM is applicable to both agile and non-agile projects, although it leans more towards the former. On agile projects (XP/Scrum in particular), it fills a gap by recognising that it is important to spend some time and effort deciding what to build before building it. On non-agile projects it empowers business analysts to add more value than they would by merely “gathering requirements”. It also allows non-agile projects to adopt some key agile principles without “going agile”. Put another way, it provides the opportunity to introduce agile by stealth.
BADM introduces a new role – that of the Business Analyst Designer. On agile projects, the Business Analyst Designer role replaces/extends the Product Owner role. On non-agile projects, it replaces/extends the Business Analyst role.
BADM is prescriptive, but in a good way, in that it explains what to do, in what order, and includes templates for the various deliverables.
BADM is centred around the concept of features. A feature represents some useful component of business change, and is also the unit of delivery. Features go through a micro-lifecycle in BADM – they are requested, defined and designed – and subsequently allocated to increments and delivered, as illustrated below:
The most important part of BADM is the Define phase, and this is where the Business Analyst Designer adds most value. In particular, it includes two very powerful concepts:
- Options engineering – discovering the underlying business objective and thinking of alternative ways to fulfil it
- Feature splitting/phasing – avoiding or delaying delivery of low priority capabilities by splitting features into “the important stuff” and “the rest” (maximising the amount of work not done)
The key benefits of BADM are:
- It is more predictable than XP/Scrum
- It delivers business benefit sooner than waterfall, and is cheaper overall (by approximately 30% in my experience)
- Its focus on conscious design results in higher quality outcomes than the alternative approach of “gathering requirements”
Why Another Method?
I’m a big fan of agile software delivery. Well, I’m a big fan of the principles of agile software delivery. But the de-facto standard agile method (XP/Scrum) has something of a blind spot when it comes to analysis and design. XP/Scrum seems to assume that deciding what to build is relatively quick and easy. In particular, it assumes the following:
- Business stakeholders (or product owners) know what they want well enough to be able to articulate it as a user story
- What a business stakeholder thinks he wants is actually a good idea
- Developers all have the requisite communication and design skills (and the inclination) to work with business stakeholders to agree good quality acceptance criteria for user stories
- Agreeing acceptance criteria with a business stakeholder is quick and easy, and waiting for answers won’t hold up progress in a sprint
In my experience, the above assumptions are false at least half of the time. Business stakeholders don’t always know what they want, and sometimes what they think they want is either not the best way to achieve the underlying objective or else it is just a plain bad idea. Some developers are good at communicating with business stakeholders. Some are good at functional design. Some are lucky enough to be good at both. But not all, indeed, not many.
It takes a combination of skills, and most of all it takes time, to decide what to build. For me, the approach of putting developers together with stakeholders, under the tight pressure of a sprint deadline, and expecting a good design to emerge, is not the ideal approach.
So over the past few years I have developed a method that “plugs the gap” in XP/Scrum and provides a relatively agile process for feeding well-defined user stories to agile delivery teams to build.
To my surprise, the method also appears to work on waterfall projects. It has just enough rigour to keep the quality/method police happy, but opens up the possibility of introducing agile principles by stealth, without officially “going agile”. One project I tried it on was saved from probable doom by introducing BADM part way through.
The method has evolved over the course of several projects, to the point where it is fairly repeatable and seems to handle most of the business analysis scenarios that I have thrown at it.
All in all, I feel the method has been successful enough to be worth sharing.
A Partial Method
BADM is not a full software delivery lifecycle. It primarily covers what I call the design phases – from the point of receiving a request for business or system change to the point of having decided what to build at a detailed level (system functional design).
If you are familiar with agile (XP/Scrum) software delivery, the best way to think of BADM is as a process to manage the product backlog and to feed well-defined user stories (including acceptance criteria) to the delivery team to build.
If you are familiar with more traditional business analysis tasks and techniques, think of BADM as the process of “eliciting requirements” up to and including the delivery of a functional specification which developers can use to build software, but with an emphasis on incremental delivery and conscious design.
The Business Analyst Designer
I recently declared myself to be a Business Analyst Designer. It’s a role I invented because none of the existing roles in common usage (Business Analyst, Solution Architect etc.) quite seemed to fit how I work.
A Business Analyst Designer is somewhat analogous to a building architect. He (or she) works with the client to understand the project objectives and then designs something that meets those objectives. He does not gather or elicit requirements and then hand them over to a (separate) solution team. He is both the listener and the designer. He challenges. He sketches out alternatives, highlights the pros and cons of each, and helps the client decide which option they prefer.
The Business Analyst Designer Method is, as its name suggests, a method for Business Analyst Designers.
On agile projects, the Business Analyst Designer role replaces (or extends) the Product Owner role. Unlike the Product Owner, the Business Analyst Designer is explicitly responsible for functional design, not just for managing/grooming/prioritizing the product backlog.
On non-agile projects, the Business Analyst Designer replaces (or extends) the Business Analyst. Unlike the BA, the Business Analyst Designer is explicitly responsible for functional design, not just for “eliciting the requirements”.
Incremental Delivery, Prioritization and Change
A key feature of BADM is that it supports and encourages incremental delivery and prioritization. It adopts the XP/Scrum concept of the product backlog – a prioritized list of “things to build”. XP/Scrum calls the things to build stories. BADM calls them features. There is a reason for the difference in terminology which I’ll explain later.
BADM takes the product backlog concept a step further by emphasizing the importance of feature splitting – the conscious process of splitting features into sub-features in order to delay (or avoid) the delivery of low value functionality. This is similar to the XP/Scrum practice of splitting epics into individual stories, but with a very specific aim.
BADM embraces change. As with XP/Scrum, this is done via the product backlog – features can be added at any time and are prioritized relative to other features.
These techniques can also be be used on waterfall projects, but need to be applied in a slightly different way to tie in with project phases and change control processes. If you are looking to introduce agile by stealth, this is your way in!
For more details on the importance of prioritization, and why incremental delivery is so useful, see my article on how to prioritize requirements.
Close to my heart is, of course, the concept that the process of deciding what to build is a process of design. There is no distinction between “gathering requirements” and “designing solutions”. It’s all design.
BADM encourages conscious design by including specific steps for identifying alternative options, evaluating the options and selecting a preferred option (including the option to do nothing). This might sound like a trivial point, but it’s all too easy to take a stakeholder “requirement” at face value.
BADM also encourages conscious design by forcing you to write acceptance tests, not merely acceptance criteria. Much like (written) use cases, acceptance tests make you think through the dynamic behaviour of your system and, in particular, identify how to deal with alternative flows and edge cases.
It is often said that the role of the Business Analyst is bridging the gap between business and IT, allowing effective communication to occur. But done badly, Business Analysts can actually widen the gap by becoming an inpenetrable barrier to communication. I have seen this many times in the form of requirements documents written and approved with little or no involvement from the technical team.
In line with agile principles, BADM recognises that the better designs emerge when teams collaborate – in particular, when developers and business people are in the same room.
BADM encourages collaboration in the following ways:
- Requiring business stakeholders and technical folk to be involved at all stages
- Capturing designs in slide deck format (as opposed to document format) – which is much more conducive to round-table discussions than off-line review
Repeatable and Prescriptive
BADM has evolved to a point where it can be described as “repeatable”. In other words, each time I execute it, I perform the same steps in the same order and produce the same types of output. I have used it enough times to know which steps are optional and which ones aren’t.
I have deliberately tried to make BADM as prescriptive as possible. The idea is that you should be able to pick it up and actually use it, like following a recipe in a cookbook. I’ve tried not to skimp on the details. I’ve included templates for the various (lightweight) deliverables, and a number of worked examples.
There’s a caveat. Design is, of course, a creative process – some might even say an art. BADM doesn’t mechanise the creative process. It provides a structure in which the creative process can operate. In my experience, good design itself comes only with practice!
Overview of the Method
OK, that’s the preamble out of the way. Let’s take a look at the method itself. BADM consists of three phases, as illustrated below:
Don’t be fooled. BADM is not a waterfall method. Rather, each phase is executed in turn on individual features to be delivered. At a given point in time, different features can be at different phases in the process simultaneously. And there is likely to be a gap between phases for a given feature (hence the clock symbols). Judicious use of prioritization and feature splitting ensures that people are always working on the most valuable things. Hence, BADM is waterfall on individual features, but the overall method is incremental/iterative, as illustrated below:
Any agilists reading this will immediately be horified by the idea of a waterfall process, even within the context of individual features. But hear me out. Here’s what’s bad about waterfall delivery:
- Needing to complete a given phase for all scope before being allowed to start the next phase
- Heavyweight documentation
- Lack of collaboration
But waterfall does have one excellent property: deciding what to build before building it. BADM captures this benefit of waterfall whilst avoiding the downsides. We work one feature at a time, the documentation is lightweight, and the approach forces collaboration.
Let’s now have a look at the individual phases within BADM.
Phase 1: Request
In the Request phase, a business change is requested. Requesting a business change is deliberately very easy. Anyone can request a change – a business manager, a business team member, a business analyst designer, a member of the technical team. All they need is an idea. At this point, it doesn’t even have to be a good idea – bad ideas get filtered out later in the process. In fact it doesn’t have to be a concrete idea on what to change. It might merely be a desire to improve some area of the business, perhaps to “fix” a perceived “problem”.
A requested change can also be of any size. It might be a small change to an existing business process and/or IT system, or it might cover the delivery of a completely new IT system. Large changes get broken down into smaller sub-changes later in the process.
A requested change is added to the Product Backlog and given a unique ID for tracking purposes, at which point it becomes a feature. I have deliberately avoided the term user story because it has a strong association with XP/Scrum and thus has negative connotations for anti-agile managers. Either term will do.
Optionally, further information about the requested change is documented in a Feature Request (a simple one page document). This is useful on larger projects or if, like me, the Business Analyst Designer has poor memory.
The Request phase also includes a brief triage of the feature to determine, where possible, a very rough estimate of size (using T-shirt sizes – small, medium, large, extra large etc.).
The Request phase finishes with an initial prioritization of the feature, which determines how soon (if ever) it will proceed to the next phase. Getting the priorities right is very important and, in my experience, extremely hard.
Click here for more details on the Request phase.
Phase 2: Define
In the Define phase, a feature is transformed from an idea into a scoped and sized business change. This is the most important phase, because it’s where all the clever thinking occurs, and where the Business Analyst Designer adds most value.
In this phase, the Business Analyst Designer asks the question, “what are you trying to achieve?” Traditionally, BAs refer to this as finding the underlying business need. I prefer to refer to business objective rather than business need (calling it a need implies that it is non-negotiable). Once the objective is understood, the Business Analyst Designer works collaboratively with the stakeholders to generate as many design options as possible to achieve the objective. Each option is weighed up for pros and cons (or benefits and costs) and a preferred option is selected. If none of the options has benefits that outweigh the costs, the selected option might be to do nothing. This is where bad ideas get filtered out.
An important part of the Define phase is feature splitting. Large features are split into two or more sub-features – the first sub-feature consisting of the highest priority component(s) of the feature, and the remainder being added to the Product Backlog to be prioritized and looked at later. This process is similar to the XP process of splitting epics into individual stories, but with a specific focus on delaying (or avoiding) the delivery of low value functionality.
In the Define phase, the selected option is elaborated to a point where it is possible for the delivery team to be able to estimate its size. This size is measured in feature points, and indicates the approximate effort required to deliver the change, relative to other features (similar to XP story points).
Finally, with the benefits and costs in hand, the feature is the re-prioritized against other features to determine whether and when it should proceed to the next phase.
Click here for more details on the Define phase.
Phase 3: Design
This is the easy bit. If the Define phase was done well, then the Design phase is simply a matter of filling in the details. It involves producing a detailed functional design for any IT system changes and, where relevant, business process designs for any business process changes.
Similar to XP, the functional design for a feature consists of a set of acceptance criteria that define what constitutes “done”. Specifically, the acceptance criteria are written as acceptance tests, in a form very similar to (written) use cases or BDD scenarios, and are used directly for both build and test (thus avoiding the need for separate test scripts). Supporting information such as data models or user interface designs/prototypes are also produced where appropriate (and only if they add value).
The output of this phase is a functional design (and business process design) that is agreed by all parties.
Click here for more details on the Design phase.
After BADM: Build and Test
BADM is primarily intended to be used within the context of an incremental delivery lifecycle. Features are grouped into increments for delivery in much the same way as they are in XP/Scrum – based on the duration of the increment, the team’s “velocity” and the size of the features.
Using BADM within a waterfall context is possible, but the benefits of feature-splitting and prioritization are lost, or at best, reduced. BADM is a good way to introduce incremental delivery by stealth onto waterfall projects – the Business Analyst Designer initially claims that they are merely prioritizing their analysis/design work, and then, at the point where some features are ready for build, suggests to the project manager that the development team could get ahead by starting early on those features, thus staggering the delivery. It’s not an easy sell, but it’s worked for me in the past.
Either way, sooner or later, it will be time for build and test to start.
In terms of build, developers code directly from the functional design, rather than from some intermediate “technical design” document – in my experience, such documents are a re-hash of the functional design and add very little value. That’s not to say there’s no need for technical design – architectural patterns, structures and patterns are important, and might be written down, but just not a technical interpretation of every single function.
In terms of test, exactly how the functional design is used for testing depends on the project’s test strategy. My preferred approach is to use the acceptance tests directly for system test and then achieve user acceptance by showcasing the system testing, rather than having a separate phase of user acceptance testing. For XP/Scrum teams using TDD/BDD, the acceptance tests in the FDD are converted directly into automated acceptance tests.
BADM does produce some documentation. In line with agile thinking, the documentation is designed to be barely sufficient. In particular, the documentation produced is so minimal that it forces collaboration because it cannot easily be used without some form of verbal explanation.
The four key documents are as follows:
- Product Backlog (spreadsheet) – the log of all features, their current status, priority and other meta-data. Features are added in the Request phase and updated in the Define and Design phases.
- Feature Request (document) – a simple proforma that can optionally be used to capture details of a requested feature in the Request phase.
- Feature Scope Definition or FSD (slide deck) – the main output of the Define phase – a slide deck presenting the opportunity space, all design options considered and the option selected, as well as its estimated size. Any feature splits are also identified.
- Functional Design Document or FDD (spreadsheet) – the main output of the Design phase – a set of acceptance tests that define what “done” looks like for the feature.
The process does include some very lightweight document approvals. The FSD is approved by three people: the business owner, the Business Analyst Designer Lead and the Technical Lead, and this approval is done in a meeting following the presentation. The FDD is reviewed collaboratively in a meeting and approved in writing (i.e. by email) by a single business sponsor and a single technical lead). This might seem like overkill in these agile days, but my experience is that some form of lightweight approval has a number of useful benefits, not least of which is to force both the business and the technical team to commit to what is to be delivered, and thus reduce the risk of spurious mind changing (we embrace change, of course, but we want to avoid constant changes in direction). It does also allow for the possibility of fixed price (per feature) delivery.
BADM revolves, of course, around a key role – the Business Analyst Designer. But there are some other important participants in the method. The following diagram illustrates who they are:
Here’s a bit more detail on the roles:
- Business Analyst Designer – for a given feature, this person executes the vast majority of the steps in the method and owns the deliverables.
- Business Owner – for a given feature, there is a single business owner. This person represents the business for the feature, and is actively involved in the high level and detailed functional design.
- Technical Owner – for a given feature, there is a single Technical Owner. This person is actively involved in high level and detailed functional design, and is responsible for ensuring the design is technically feasible. They also provide the feature point estimate in Phase 2.
- Business Analyst Designer Lead – has overall ownership of functional design for the system under construction. Owns the product backlog. Allocates BADs to individual features. Peer reviews FSDs and FDDs for consistency and overall design coherence. On smaller projects, a single person might be both BAD and BAD Lead.
- Business Sponsor – for a given feature, there is a single business sponsor. This is typically a budget holder i.e. the person who is paying for the work. Ideally, there is a single business sponsor for all features on the product backlog, but if the system under construction caters to multiple business areas, there are likely to be multiple business sponsors. The main job of the business sponsor is to prioritize their features (and in particular to agree/argue priorities with other business sponsors). Their other job is to formally approve for FDDs. They also allocate business owners to individual features.
- Technical Lead – this person has overall ownership of the technical design of the IT system under construction. Responsible for allocating technical owners to features and formally approving FDDs.
As mentioned above, BADM is a method I have evolved based on my own experience, on both agile and non-agile projects. It has worked for me so far. It might work for you.
I’m not saying it’s universally applicable. I’m not saying it’s all new – I’m aware that many of the concepts I use are already described (perhaps using different terminology) in other industry-standard references (such as the BABOK). But I have yet to find an existing method that emphasises the importance of conscious design (as opposed to “gathering requirements”). This is embodied in BADM’s Define phase and, in particular, in the activities of option engineering and feature splitting/phasing.
I’m sure BADM will evolve further as I continue to use it. It has evolved already over several years’ use so there’s bound to be more. But for now, this is it. I hope you find it useful. As usual, feedback is very welcome – especially if you’ve had a go at using it!
The following articles provide further details on various aspects of BADM:
So glad to see you putting forward a method that is both lightweight yet pragmatic given the typical minimum requirements in corporations. It’s a testament to your experience and insight. We tried implementing scrum in a large corporation and what we ended up with was very similar to BADM.
AA: GOAL IS THE KEY
The agile principle of “(Doing something)-(getting feedback)-(acting on feedback)” works only when there is a GOAL. Unfortunately I do not see any mention of “Goal” in any version of Agile, including BADM.
BB: CHAIN of GOALS
Even this will NOT always succeed unless GOAL is clear and beneficial. Goal cannot be clear and beneficial unless there is a Super Goal which is clear and beneficial. This is the real problem and there is NO sure way of having a PERFECT Super-Super-Super…..Goal and it is NOT worth spending time on defining it and working backward.
CC: GOAL, SUPER-GOAL and MEANS to MEET the GOAL
If this is realized and the team of stakeholders and developers are conscious of and agree on the GOAL and SUPER-GOAL, then they can work on the MEANS to MEET the GOAL.
Planning, design, testing are phases in the above chain. The time and effort to be spent on them is locally defined by the team involved.
DD: Where does BADM fit?
The description provided is too long for me but if it is consistent with CC it should work.
23 JUN 14
Thanks for your feedback. In response:
AA: In BADM I have used the term “objective” to refer to the GOAL. Each feature starts out as a request (Phase 1), and in Phase 2 (step 2.2 – Identify Opportunity Space), the Business Analyst Designer works with the Business Owner to understand what they are trying to achieve and why.
BB: BADM talks about understanding not only the objective but also the benefit (which I guess is the super-goal) – the process of asking “why?”. I agree that there is a potentially infinite chain of super-super-goals, and it’s difficult to know whne to stop. Not sure I have a good answer on this but I certainly agree on the problem!
CC: In BADM, the first steps to agreeing the MEANS to deliver against the objective (GOAL) are to identify options, cost them up and then select the preferred option. This is all part of Phase 2
DD: BADM goes all the way from receiving a request for change (an idea), through what I call elaboration, to the point of having agreed what the change will be down to the point of IT system functional design (including having agreed acceptance tests). It does not include build or test.
Hope that helps.
Tony: That brings your proposal very close to what I consider to be a sound life-cycle of development of a product / process / system BADM.
Sorry for not detecting it by reading your description. My ability to read and understand was never good and it is diminishing. It is particularly bad if the length of what I have to read is all text and is more than a page! Your drawings help but only partly.
I appreciate that you have separated out testing and building. I agree they are different and distinct steps. If there is a way of knowing what a design does or how what is designed works, there is NO need for building and testing. That is why I am skeptical about Agile doing everything from inception to construction.
“Business stakeholders don’t always know what they want, and sometimes what they think they want is either not the best way to achieve the underlying objective or else it is just a plain bad idea. ”
I can’t believe it’s August and only now I had the time to check this article whose link you send me back in March, Tony! Thanks for sharing this work.
Lots to talk about here — I’ll probably need to write an article (or a series!) to have space for all my comments :-). To me, this is the most important statement in your article: “I’m not saying it’s universally applicable.”
See, my biggest disappointed with most published models is the fact that rarely authors talk about the circumstances under which it can be successful, and when it may provide limited results due to the salient characteristics of the change in question. This would be a great topic to cover in the future. I can think of situations in which the model you describe would work very well (even because that’s how I saw teams deliver highly successful solutions in the past). But I can also think of cases in which this would be a risky model to adopt without some serious adaptation.
In any case, I think that there’s a lot of value in discussing models like yours to support incremental delivery and achieving maximum business benefit as early as possible. You have motivated me to write more about the methods of discovery and definition that I’ve used in NANW (non-agile, non-waterfall projects)–with a promise to be very explicit about which types of business change they have a bigger change of being successful with ;-).
Hi Adriana, I completely agree that we need to consider applicability carefully before selecting a method. I have used BADM successfully on a few projects now so maybe I should write some case studies to give an idea of the sorts of projects I know it works on.
Pingback: BADM Phase 2 - Define | its-all-design.com
Pingback: How to Prioritize Requirements - its-all-design.com
Hello Tony, i enjoy reading your articles, regarding the quote above, i think you can’t find a specific title might be because you’r trying to be a Business Analyst and a Designer at the same time?
Many companies struggle with this, for example, PM vs UX, PM’s requirements may overlap with UX work when PM start drafting wireframes without the empathy, and vice versa, UX work might overlap with requirements when UX overweight the UX input on requirements.
Both need to overlap in a healthy way in order to achieve efficiency and harmony.
Each role has his unique “core” work, knowing the limits try not to touch each other’s core too much, may keep things cooler and healthier.
But IMHO, the problem in knowing too much about the other and stay humble enough and supply the needs so both can work in harmony instead entering each other’s shoes.
Hi Tony, thanks for your comment.
In my view, anyone involved in defining business change is a designer. Business processes are designed. IT system functions are designed. Logical data models are designed. User interfaces are designed. Java code is designed. Physical data models are designed. IT system infrastructure is designed.
As a BA I am most concerned with IT system functional design (think use cases) and logical data model design. The functions of a new IT system must be consciously designed – the design doesn’t pre-exist so I cannot go and “gather” the “requirements”. If I ask the business stakeholders what they want, they will tell me their proposed design. I can either take this as gospel, or I can offer up alternatives and improvements. When I do the former, I am “gathering requirements” (being a scribe). When I contribute to the effort, I am being a designer.
In short – a BA who is not a designer is a scribe. No BA thinks they are only a scribe, so really we are all BA Designers – I’m just trying to make us realise that.
Tony Heap, I think that many of us share Tony Bathich’s conclusion in large part because of what you have in articles like http://www.its-all-design.com/requirements-versus-design-its-all-design/
In that one, you describe an exchange between BA and stakeholder that is indeed mostly about design – data design, for example (“OK, so that’s first name and last name – what about middle name?”). In my projects, this would never happen during the initial requirements phase. As a requirement, what I’d be capturing is simply, “webstore visitors will have the ability to register and save elements of their personal data so that they don’t have to enter the same information each time they make a purchase”.
Details about precisely which data elements would be captured, whether name would be captured as one field or 2 or 3, etc., would come later, during UX and data design.
So, in the requirements phase of DESIGN, I’m focusing on what capabilities the system must provide (in this case, ability for webstore visitors to register and save personal data). During the next phases of DESIGN (data design, UX design, technical specification, etc.), the team would go from the more abstract description of a need to decreasing levels of abstraction, including system components and how they fit together, detailed module or class design, etc.
Everything IS design. Milton Glaser, the graphics designer behind the iconic ‘I Love New York’ logo, recently offered an insightful definition of design for Inc. Magazine:
“Design is simply moving from an existing condition to a preferred one,” he said. “That’s it. It covers all cases. Nothing else is involved. It has nothing to do with beauty or effectiveness.”
And because everything in an IT project is about moving from an existing condition to a preferred one, I don’t think it’s very useful to call what a BA does “design” (of course it’s design, but the project manager, developers, architect, QA team, etc., etc. are all doing design too). My most recent title was “product manager”, but based on your logic I might as well say “product manager designer”… Which would just sound a bit weird and not change anything really.
I take your point that it can be a little confusing if we call everything just “design”, because people won’t know what level you’re working at – is it the “requirements” level (which I would call features, by the way), or the detailed functional level, or have we moved into under-the-covers technical design? Or it could be business process design.
Hence I always try to qualify the term “design” by saying business process design, high level functional design (sometimes I call this “define”), detailed functional design, technical design.
I just have this problem using the word “requirements” to mean “the set of features we have decided to include in scope” because of the connotations and behaviours that come with it (especially from project managers who don’t understand that it’s all design and think that my job is to gather requirements that are already in business people’s heads – but also from learning or aspiring business analysts – and also from “solutions” people who keep telling me to stop solutionising – it’s *all* solution!). Using “design” and “Designer” as much as possible raises awareness and, hopefully, changes behaviour.
Tony, I get the problem you’re trying to solve; I just don’t think your solution is the most effective (even though I see no harm in you continuing to call yourself “business analyst designer” :-).
I’d like to believe, though, that more and more teams are getting smarter than what you describe.
Just to give you an example, for the last year there wasn’t even a “project manager” in my projects, and nobody thought my job was to gather requirements that are already in the minds of someone. We had a tech lead, and a release manager (to allow multiple teams to put their “cargo” into a release train to add value continuously to customers), and as the product manager I was in charge of bring knowledge from the market, customers, and competition into the company, and transform them into insights and from there requirements for improving my component of the product (improvements that in many cases had nothing to do with building new features, but rather improving performance, making workflows more efficient, etc.).
I’m wondering if when people say “stop solutioning” to you, what they mean is “stop creating design constraints” (for the data model, UI, etc.)? I like to avoid as much as possible getting into these details during the “requirements phase”, because working with specialists in UX and database, I feel it’s better to include them in the conversations about, say, “how personal information will be captured” — in how many fields, how the online form will look like, etc.
When you say you use the word “requirements” to mean “the set of features we have decided to include in scope”, it wouldn’t work for me, because my requirements typically include not only features, but UI design constraints (e.g. “all submit buttons must be green and placed on the bottom right of screens” – because the hospital nurses are used to this convention and changing it for one application will just generate cognitive overload without any benefits), technical constraints (e.g., “app must prove it is protected against data exfiltration performed by malware” because it’s a government requirement), etc.
The whole point of calling them “requirements” is that these are all conditions for a solution to be considered “fit for purpose”, and those conditions typically go way beyond just “features”.
Wow, where has this post been? I love it!
I, too, have discovered some of these same steps, but I have never assembled them like this. I love that that you are taking what works, combining it with other ideas that work, and then building a complete framework! You’ve showed us there is more we can do, and paved the road ahead. Thank you.
I want to encapsulate some of the concepts resonating with me; letting you know more about how it lands out here with another thinking practitioner.
1. I’m not a fan of the Business Analyst Designer title. It takes a moderately defined and misunderstood role and adds another word, one filled with different implications, and combines the two. It just doesn’t work for me. I get your objectives, I don’t like how you solved the problem. Also, no one wants to say “I’m a BAD.” It opens the conversation to a lot of jokes no one needs while trying to do serious work.
I would much rather see something like “Feature Designer,” or Alistair Cockburn’s “Value Manager.” I think both of these closer to what you are doing and easier for our business partners to understand. (Interestingly enough, I don’t think our development partners care a whit about what we call ourselves.)
2. I really like the change in focus from requirements to features. “A feature represents some useful component of business change, and is also the unit of delivery.” Preach on, brother!
Yes, oh yes, BAs are too often caught up in the minutia of details and lose sight of the what we are delivering and why.
3. “Options engineering” is a great term. As soon as I read this phrase, I have a better way to explain Chris Matt’s and Kent McDonald’s Feature Injection. Genius.
Later on you talk about how this works and I am reminded of Gojko Adzic’s Impact Mapping. Bravo.
4. I’d like to see some more about how you determined the benefits. I don’t disagree, it rings true with my experience following parts of the BADM in my own career, but we really need to start showing folks concrete projects to get more buy in.
5. You nailed this one, too. “(XP/Scrum) has something of a blind spot when it comes to analysis and design. XP/Scrum seems to assume that deciding what to build is relatively quick and easy.”
6. I like that this is a partial, and partially agnostic, methodology. Did you know the same is true when documenting requirements in the BDD format?
7. I like how the method is iterative. That is, “each phase is executed in turn on individual features to be delivered.” The combination of a defined process, that works on a potentially changeable backlog is part of what makes this palatable for agilists, and therefore a good thing.
8. POs and BAs who don’t ask, “What are you trying to achieve?” are notetakers. Sigh, there are too many of those. That being said, there are pockets of greatness all over the place, quietly doing extraordinary work. And even more, those who could be great if given the right opportunity of environment. My deepest question is how do we enable those folks?
And with this, I say thank you for sharing. I will be sending folks here to read your proposal and, I hope, start sharing their resulting success stories from trying this out.
Thanks for your feedback – glad you’ve found it useful and thought provoking. Please do spread the word and let me know how you get on trying it out.
On your specific comments:
1) Coming up with a job title that works for everyone is a nightmare! Whatever you choose, it either has existing connotations and/or people don’t like it. Business Analyst Designer is a mouthful but at least it does what it says on the tin – it’s a BA with a designer mindset. I don’t expect people to use that specific job title, I just want them to have the designer mindset. And the key point is to promote the debate. Tick!
4) I don’t have any magic formulae for determining benefits – and really the first step is to even get people to consider what the benefits are for a give feature i.e. ask them why they are doing it. Usually the answer is qualitative, but just posing the question is illuminating (classing “5 whys” BA technique).
6) To me, the BDD notation is very similar (semantically) to Cockburn-style use cases, which I’ve been writing since way before I got into agile, so yes I can see that you could easily use BDD in a variety of situations, even if you weren’t going to write automated tests. At the end of the day you are just describing system behaviour – interactions between the system and its actors/users.
8) What I like about BADM is that it forces me to think about objectives, benefits and options for every single feature I work on. And because I’ve baked those steps into the method, it should be possible for others to do the same. It worked for the other BAs on my team – once they learned the method, they all got into the hang of asking “why” at every possible moment. Ironically, a lot of the value we added to the project was making the business realise that they actually didn’t need or want half of the the things they were asking for – either the benefit didn’t stack up or else there was a much simpler option to achieve it. I would say we made around 25% of the features “evaporate”!
I’ve been following your posts for a while now ever since reading your post about “there is no such thing as a requirement” really resonated with me. I for one love the business analyst designer title because it so explicitly pushes the envelop and challenges many business analysis practitioner’s to re-consider their role.
The third version of the IIBA’s Business Analysis Body of Knowledge was released earlier this year and it is very clear that the IIBA has also had to grapple with the notion of requirements vs design and the role of the business analyst (designer!).
Below just a few extracts from the BABOK v3
The BABOK know often use the phrase “Requirements and Designs”. Some key extracts:
…it is important to recognize that business analysts are also responsible for the definition of design,
at some level..
The distinction between requirements and designs is not always clear.
A requirement leads to a design which in turn may drive the discovery and analysis of more requirements. The shift in focus is often subtle.
The classification as a requirement or a design may become less significant as the
business analyst’s work progresses to a greater understanding of and eventual
fulfillment of the need.
The tasks in the BABOK Guide such as Trace Requirements (p. 79) or Specify and Model Requirements (p. 136) may refer to requirements, but the intent is to include designs as well.
Thank you for your contribution in terms of the pragmatic methodology you’re fleshing out. It’s great to see a clearly define methodology that actually represents how the job is done in real life by experienced people. I think teaching your methodology is a far better way to learn the trade and high sounding theoretical constructs.
Thanks for the feedback Giovanni, it’s good to hear from kindred spirits. Spread the word – and eventually maybe everyone will be a Business Analyst Designer
Your article is great and it is nice to see other ideas and frameworks surrounding BA work.
I come from a Product Design background myself and it was a breath of fresh air to read about a similar approach to Software Development within a Design ideology.
As a current BA, I use a design approach in all areas and seling the visualisation of the solution to stakeholders is a nice ability to have. As they say, a picture is worth a thousand words.
Here’s some links / reading material that I have also found useful in this approach.
Total Design by Stuart Pugh
Business Model Generation
Simon Wardley;s blog, Value Mapping is a cracker http://blog.gardeviance.org/
Feel free to link up on LinkedIn
Totally agree with this approach and I’ve been using it lately.
I’ve found out that half dozen basic wireframes helps a lot to think about user Stories. In simple Apps i’ve simply gone to Power point drawing the the UI and with orange callouts I give the instructions on Queries or what tasks the system may perform and with blue callouts I give the instructions to both Designers and programmers with error treatments and instruction messages that should be shown to the user.
I’m now developing a big system and decided to combine Use cases, wireframes and process diagrams. I’m working with Excel and trying to automate and integrate documents that are shown to clients/stakeholders and programmers. I mean: If product owner request another text to be shown based on the wireframes, one change in the document should reflect on the User Story Details.
My conclusion after many projects is: Depending on the requirement, a simple sentence “As a…I want to…” is not enough to make a programmer visualize all the tasks and sub-routines that should be performed. And based on experienced, most programmers don’t enjoy to be analysts (although the best programmers are the ones who are great analysts)…but not always you’re lucky to have good programmers who also enjoy to work with process analysis…So the wireframes, diagrams and error messages sometimes provide the additional “juice” to expedite the programmers work as well as having a clear communication with the product owner about the system performance.
You have been able to elicit my “organic” Analytical Design Process in terms that relate to the corporate jargonists even down to the obvious core question of ” What are you trying to achieve and Why”. By Organic I mean logic that dictates and encompasses Outcome Objectives, Processes and Deliverables.
It would be nice to think there was a Golden Template for Success for Projects but its just not possible. Business processes and objectives are as individual as fingerprints and there will never be a single solution as available resources and constraints multiply that exponentially so what works for one business may not work for another of the same type. That would be like taking parts from a VW and putting them in a Chevy on the premise they are both cars.
Because I have not formally learnt Project Management Methodologies and feeling the available options are bloated with superfluous protocol its nice to know I’m more aligned with an efficiency approach than just winging it through logic. I say this because not everyone works in a larger scale environment where they employ the multiple people required to fulfill the relative roles for the project. This results in having to assume multiple roles within the project which again can sway the outcomes positively or negatively depending on people involved, their skillsets, awareness and (if applicable ) level of underhanded career enhancing tactics in play 😉
I know it’s an old article but are you sure that you introduced a new thing here? I don’t think so. System Analyst/Designer role was there for a long time as far as I remember. Changing the “System Analysis” role to “Business Analysis” role in Agile methodology, which I really don’t know why, made no difference at all. It was there for a long time and yes, I agree with you that we need it in some projects where the requirements would be limited compared the volume of software design we should conduct.
Thanks for your comment.
I Agree – systems analysis/design has been around for a while, but when agile came along and stripped out all the upfront design in favour of just getting on with it, I feel like we threw out the baby with the bathwater. So really what I’m proposing is we bring back the systems analysis & design but we do it story by story, not all up front, and we do it in as lightweight a way as possible, remembering that it is a means to an end, not an end in itself.