Let me share one of my more humbling experiences as a business analyst. To be perfectly blunt, the developers did not like my requirements specifications. It was hard to realize that I had failed to communicate requirements in a way that was meaningful to them. But the hard truth was sitting right there in front of me.
I could cite many reasons for why this happened. There were some legitimate challenges, one of which is we are all in separate locations, so we relied primarily on phone and email for communication. But the hard truth is that I forgot to simply ask the developers what would help them most.
I got started quickly and got lost in my own assumptions about what would be good requirements spec and where my role would fit into the development process. I relied more on my prior experiences of what has worked in the past than on what would work in this situation. I mistakenly assumed that because my way of doing things had worked before, it would work now.
I realized that no matter how similar a situation seems to a prior experience, there is one variable that is different: the people. And the people count big time. Because as people we do unexpected things and have unexpected perspectives and expectations.
What do you do when your development team tells you (directly or indirectly) that the way you specified the requirements is not working for them? How do you respond? What do you say?
I think you have to start by taking 27 steps back and setting aside all assumptions, frustrations, and, most importantly, your ego. As Cecilie Hoffman told me in a recent interview “check your ego at the door.” Or, maybe, you need to put your ego in a locker and give the key to a trusted friend who has a heart of steel. You are going to feel pretty battered as they tell you exactly why the requirements you pulled together won’t work for them. Embrace the feedback. Remain open, non-confrontational, and non-defensive.
Take the time to figure out exactly what it is that will make them successful. And then go about figuring out how you can make that happen. Just like code, requirements can be refactored to make them more usable and extensible for your situation. It will take much less time to do this than you think.
And on your next project remember: Ask the developers first, write the requirements specifications second. Because at the end of the day, if your developers won’t or can’t build the solution to your requirements, you’re not going to be successful as a business analyst.
Thanks Paul and Marc!
Paul, sounds like you have a great plan. Just by asking your team what they need and getting their buy-in on what you produce, you’ll go a long way toward building trust and raising the potential for delivery. This is a nicely thought out plan for next week and I look forward to hearing how things go.
Laura
-WOW – is this on the money!
I swear everyone on this BLOG is working in my shop – LOL.
We have been trying to do a better job at requirements elicitation/analysis/management but the one thing that is never right is WHAT the developers receive….adding to the multiple locations scenario, we also have an ‘off-shore’ model….and throw in the language barrier (and I’m not talking about program language) and it only exacerbates the problem.
Management needs to recognize this is a problem state and provide their support. You can create all the fancy documentation you want…do all the feedback sessions you can stand – but if you don’t know WHAT the receiver (i.e. developer) really NEEDS – then what’s the point?
To that end, next week I will suggest we, the ‘BA community’, run this like any another project… identify the Stakeholders (Designers & Developers included) have a BA lead effort getting agreement on the PROBLEM, then on to Requirements elicitation (focus on WHAT is needed)… take the NEEDS & FEATURES move on to the next step of Functional/Non-Functional…Use-Cases…etc, etc – so just like any other project, we now we have the Stakeholders/involved parties contributing to solving the problem – and recognize we are all benefactors of the solution
Kind of SOP for a BA, no?
We’ll see where this all goes next week
Jenny,
It sounds to me like you did the right thing, providing the requirements in a new way in context to ensure communication is clear. I actually do not think it’s a weakness to admit that different people will need different types of communication and that you might not know what that is upfront. Sometimes it is a matter of trial and error before we learn just the right mix of documentation and verbal communication for each of our implementation team members.
In an ideal world, the question to be addressed would be “how can we all communicate better in the future to ensure that this doesn’t happen”? It might also help to share a bit of your perspective about why you thought a particular detail should have been clear from the documentation you provided — not defensively, but just from a learning stance. The feedback you receive from that kind of question might help you see your documentation in a new light or might help others see their oversight. Whatever the result is, everyone learns a bit that way.
Best,
Laura
Showing weakness is a fatal error. They’ll eat you up.
You should make it clear that you understand there’s probably a Goldilocks zone somewhere between the first version where they missed the requirement and the second version where you hammered on it so they could not possibly miss it. Also explain that, in the interest of not missing anything, it’s better to say too much than not enough, so in future you’ll probably err on the side of the epic.
I’m revisiting this because I just had a similar experience this afternoon. I often work in situations where I support operational development work — tweaking this, adjusting that, small features, etc. I really enjoy that kind of work because I feel that I am good at it. But from the perspective of how to add value as a BA, it is sometimes a hard role to fill appropriately. Sometimes the developers know a heck of a lot about the current systems and don’t feel that they need you to tell them too much about it. On the other hand, because of that, developers assume too much or gloss over the information we do give them. So how much to document, especially about the existing capabilities and functions of a system?
My experience this week involved a missed requirement in a feature that we worked on last week. I felt, actually, that the requirement was missed by the developer, not by elicitation and documentation. Nonetheless, I conceded that perhaps that requirement wasn’t made clear enough or perhaps a use case (or test case) or two would have illustrated it better. So, I updated the requirements document to better call out the missing functionality. The updated requirement was simple and, yes, I could have just stated that single update. Perhaps I should have. But instead, I included the subset of requirements around that updated requirement and drew attention to it, by highlighting it as new, as well as calling it out in the introduction of the request.
The feedback I got was that I should be more concise, since what I had put in was “epic.” So, I’m torn between being concise (where perhaps not everything gets stated explicitly and things get missed) and being complete and providing context (which gets interpreted as “epic”).
I know it is my job is to be helpful to developers and testers, so I need to provide them what they need in a way they need it. And I admit, it’s a blow to my pride to be criticized for my efforts. So I sucked it up, said “ok” and I will check in with both the developer and tester who both use the requirements in different ways to find out how to meet their needs.
But thanks for letting me vent my flustration (can I make that a word to explain how I feel?) to my compatriots.
Anand,
Thanks for your input. I think one of the challenges BAs face in terms of getting developers involved early as they are often very dedicated to other projects. When you are going about trying to discover the business requirements, there is a lot of churn. If the pressure is on for the development team to deliver the next project, then it can often be seen as a waste of time to involve them too early, especially at the business requirements stage.
I do, however, see the need for targeted communication as things get defined and before you move too far forward into the solution. In fact, just today, I was reading the EA section of the BABOK and the implementation SMEs are listed as a group to be involved in understanding the current capabilities and defining the solution approach. Those seem to be to be good touch points to work on and clarify some best practices for.
Bernard, I think involving potential end users or potential customers is also a great practice. I believe in formal BA, this would be considered some sort of focus group. The risk of involving them directly with your SMEs is that they may lack the domain knowledge necessary to fully engage in the discussion. Often the elicitation techniques and questions you would use with potential customers is different than the projects internal stakeholders, but they are definitely a group to consider as part of your elicitation efforts.
Best,
Laura
This topic is worth a debate – a developer definitely needs to be involved from the beginning phase where the business requirements are chalked out.Even though , it wouldnt make much sense to the developer in the initial phase ,being involved from day 1 gives an a complete picture on what the project is all about and why it is critical for the business.
This also makes discussions b/w the BA and the developer easier as the project is kicked off.
The BA on his/her part should ensure that the developer understands why a requirement is involved and also lend a helping hand in cases when the developer is stuck.
Being an application developer myslf for the last 3 years , I have realised , that at certain points ,you just cannot carry on with the development without getting a strong understanding of all the scenarios involved.This is where the BA needs to take charge and ensure that the bottle necks are resolved.
Laura (and all), thank you. Thanks @jonbab1 via @joyce_hostyn for the pointer.
Referring to Marc and the definition of stakeholders: The other day I volunteered as an amateur analyst for an innovation project in education. In drawing for them a Stakeholders / Expectation / Resistance / Action Plan table, I realized it might help to include a few of the parties that we usually presume disinterested. In this case, students _not_ taking the elective curriculum, and parents of such students. Although formally not a stakeholder, they influence opinions and rumors as well.
Interested in how this would translate to a BA’s professional setting.
Hi Marc, I think you raise some great points. The BA can often fill gaps that others can’t or won’t. I am sure your experience is not atypical or, maybe, it shouldn’t be atypical. As a BA, especially one without a lot of technical expertise, I find myself much more confident on the business side of the equation and ensuring their requirements are understood and filtered through. But this does leave the potential for gaps if a strong tech lead / architect is not in place.
You know, regarding the audit requirements, I was thinking of “the auditors”…there are a few reporting requirements that would probably fall into the auditing category.
Cheers,
Laura
Hi Laura,
It’s probably appropriate for the tech lead to negotiate the details with DBAs and maintainers, but I’ve always made it my responsibility to make sure their use cases are on the list along with those of all the other invisible people who tend to be forgotten.
My favourite case started with going to the DSO and asking him whether he needed anything in a planned HR application. It turned out no one had ever asked him that before. By the time we were done, we had the essence of a very nice enterprise-scale identification and access control use case set that IT liked enough to prioritize.
I think forcing collaboration amongst the implementation team often falls to the BA as the only rep for the client–about as often as the project manager’s authority extends only to the programmers, and not the DBAs or Operations. This leaves the BA (or technical architect in those rare cases that there is one) as the only one with the big picture. As a consultant I often find myself carrying messages between people who would otherwise never communicate. It’s most the case in a TA role, but it’s not uncommon in the BA role. Of course, my experience may be unusual.
A project with no audit requirements?! I’ve never had one. Must be nice.
Cheers,
Marc
Hi Marc,
Interesting question. Just to be clear (and I hope not too defensive) it’s not that I forgot the developers, it’s that I imposed a structure for requirements on them and it didn’t work so well. They were definitely included in the process.
Completely agreed with your definition of stakeholder. I think some of these are interesting from a BA perspective. As a senior-level developer, I think I might be a bit annoyed if the BA went to the DBA and asked for their requirements and perspective and then fed them to me as requirements. I think this would clearly fall in the tech lead’s domain. Same for maintainers. As the BA, I could help encourage that discussion and bring these stakeholders into the mix, but if I try to use requirements to force collaboration amongst the implementation team, I think I’m treading on some iffy waters.
Luckily we don’t have auditing requirements for this project (I checked).
Laura
Sorry to be late to the party. This is a good issue to raise. At the very least you need to be sensitive to the amount of detail the developers need. I’ve done projects where use cases and business objects were all they needed, and others with more junior people that had me designing at the method level.
One thing to consider: “stakeholder” is _anyone_ who can impact or be impacted by the results. If you forgot the developers, you may have missed some easier-to-miss stakeholders. Do you have use cases for the auditors, the maintainers, the DBAs, security…—all those folk who aren’t usually thought of as users, but who are actors with use cases nonetheless?
All great input. I can see all of us have different ways of handling these sorts of challenges, which of course is interesting to learn about!
@Angela, I agree, you go from requirements to design. And yes my focus is on requirements. However, we are using a fairly light weight process here and I think that’s part of what caused the difficulty. The way the specs were organized did not well serve the design process as it has happened in the past.
@Adriana, Thanks for inferring a bit of talent. It is always a bit difficult to share humbling experiences, even when you want to help others learn from your mistakes. I appreciate the vote of confidence!
@Jenny, There was just one face to face meeting. We did kick-off the project, but focused more on scope and less on process. This is another part of the learning experience for sure.
Laura
I’m curious now, how often have you had any face-to-face meetings with the developers? Did you have a kick-off when you came on board?
“I mistakenly assumed that because my way of doing things had worked before, it would work now.”
This is exactly why talented, successful BAs are even more likely to make this sort of mistake than beginners. Once you get used to receiving compliments and having both the business and technical team consistently happy with your deliverables, it becomes very easy to forget that people and other peculiarities may affect the type of specification that will be most useful for the team.
(This in addition to what Alex said – with so many things going on at the beginning of a project, it’s definitely hard to remember to ask the team things like that.)
I think that this is an item that everybody should include in their project checklist. Thanks for the reminder, Laura!
Laura/Doug/Alex,
Interesting post and I kept thinking to myself while reading this that developers should not be able to code from requirements, there needs to be a collaboration of design between the requirements and development.
So with that if the developers are saying that they cannot interpret the requirements well enough to begin collaboration on design details, then I am with you all on the expectations and stakeholder management pieces.
However, sometimes developers (usually inexperienced ones) are used to being fed Design specs, and if as a BA we give them requirements instead of design specs this can be a shock to a developer whom does not have design skills. Then there needs to be some further collaboration and influential leadership on the part of the BA to guide the developer through the design process.
The requirements delivered to the developer should be requirements, not design . . . requirements are capabilities and what is required of the solution, not specs on how to build the solution.
I have always found the answer to this challenge in better understanding the skills of the developer, their design process, and what they are used to receiving and developing from.
@Alex, Glad to be of help! I agree, it is easy to forget. Especially with time crunches and big expectations. But remembering nearly always saves a bit of time, albeit unmeasurable savings (since you can’t really measure the impact of a mistake you don’t make). I also believe you were the one who told me that the BA should always try to find the very specific gap that needs to be filled in a specific situation and then go to work filling it. Related advice to the context of this post.
@DougGtheBA, Also agreed. All stakeholders definitely deserve to get to answer the question. As of late, I think I’ve focused quite heavily on what the business stakeholders need and can work with, and in the process overlooked what will work best for the development team. Ironically, my development team wants LESS pictures in this scenario, so all the work I’ve done to make pictures part of the process in previous roles came back to haunt me, so to speak.
There’s probably a follow-up post in here about balancing multiple needs and validating that what different parties want is actually what they need to be successful. Out of the situation I describe from this post, we’ve actually gone through several iterations of “what about this” to find what will work best from a process perspective. Things have definitely shifted from what was originally requested and will probably continue to do so until things stabilize.
Laura
I’d say that your advice is well worth a proverbial slap in the face at the start of every project just to ensure that as a business analyst I ma paying attention. To take it a step further, this step is important for not just developers, but any audience. If any member of any audience skims over the content I write or his/her eyes roll back due to incomprehension…then I have failed to deliver in whole or part.
This is part of a broader struggle that I have been dealing with over the last year or two, as well. The do we document everything out or give them pictures argument is slowly beating me down to give them (development, that is) what they NEED to perform optimally. Sure I have my preferences as to what is right, but so do they and if they can garner what they need from less verbiage in half the time and I don’t get my way then so be it.
Ego checked at door.
Thanks Laura
Great post Laura. I’m just writing a business operating model.
That is to say, I’ve been doing the research on how to introduce new processes and now I need to produce a document for signoff.
I’ve just been drawing a mindmap to capture my thoughts on how to do this and what to consider.
Having read your article, I’ve just added something else – ask the stakeholders what they want/are expecting!
For what it’s worth, it’s easy to forget this in amongst all the other stuff we have to remember (and I have done, many times)!!