I think there are several business analysts here if I remember correctly. I’d like your advice on how to best dig out use cases from people so that I can document them. The project I was assigned to sounded simple at first and it’s supposed to be fairly quickly delivered. It’s a brand new program so we’re starting essentially from scratch on this.
So I had meetings with my key users, documented the data elements they needed, identified which ones were mandatory and optional, designed the data entry screen and… a new key user popped up asking for more stuff who seems like a power user with different needs from the other ones, and now we’re completely redesigning the data entry screen.
I think I need to start back at square one and this time interview all the key users individually to dig out how they currently accomplish the business need and document their use cases. The challenge is that I need to get them to explain to me what they need without them getting too focused on what data elements they need or where they are on the screen since they’ve already started down that path I think that’s where their minds are going to go.
(After I clarify and document the use cases, then I think we’ll be able to return to group meetings to discuss/confirm the required/optional data elements.) So the big question is how to steer them to a discussion of their needs and keep them away from telling me how they want the screen designed?
Speaking as a developer, who frequently has to take user requirements since we don’t have real BAs, this sounds like you need a “general user” screen and a “power user” screen. We’ve done that in a few of our applications.
I think you have a handle on the use cases, you just need to accept that not everyone is going to have the same use cases so you may need to design your app with more than one kind of user in mind.
I could be wrong, but it seems to me that my power user is the one who needs to accept that not everybody has the same needs as him. He’s also the person I’m most worried about being able to get a realistic use case out of.
We can do two screens, but want to make it only one screen if possible that is usable by both contingents with clever use of layout and required/optional fields. But before I can even analyze for that I need clarity on the use cases.
Oh, yeah: after we nail down (and implement) this program for internal users only, we want to open it up to external users. So I have that in mind also. The power user could seriously over-complicate the screen for the external users if we’re not careful.
I have found it effective to have the users start from the end - tell me what output they need, what they are doing with the output and their assessment of the value of the end result. Is the power user requesting more fields to generate a detailed analysis of the process in order to streamline it increase efficiency? Or are they just a data hoarder who likes to have access to all this information “just in case”? Once you have that, you can look at it as a cost benefit analysis - it will cost us $x to redesign the screen and will negatively affect the user experience, what is the offsetting gain?
Ah yes, I have had those users also. “But the way that I do it requires that…”, just because you do it that way doesn’t mean it’s the right way or that everything revolves around you.
I think part of being a BA is being able to tell some people “no”. You have to do what’s best for everybody.
I’m going to echo Doctor Jackson that you would probably have better results asking what they want the end product to be, not how they want to get there. If you ask how they want to get there 90% of the time you just get “I want it like it is now, but better”, where ‘better’ is some nebulous term.
Thirding Doctor Jackson - start with your outputs, then figure out the inputs based on that. it also helps to focus on workflows, not screens. What are they doing, not what do they want a screen to look like?
As the BA, you need to drive the conversation. Decide what level of detail you want in a meeting, and hold the user to that. Ask more questions if they are staying too high. Cut them off (gently) if they are going to deep. I’m guessing here, but if you got different and unexpected answers from a power user, then you might be going too deep initially. Have quicker meetings initially to get the “lay of the land,” then follow up with more detail when you have more of the overall context.
I’ll echo the others; you need to get the goal down first- what they’re trying to do and why. Then worry about how you’re going to get there.
Beyond that, if everyone but this one is in rough agreement, I’d pull everyone together in one room, nail down the goals, and then review the requests/requirements in light of that goal, and let that guy justify his shit to everyone else. It’s entirely possible that he’s gone rogue and wants to make this thing his way, but it’s entirely possible that he’s the only guy who’s thought this thing out. Either way, the idea is to come out with a clear goal and a set of requests/requirements that support that goal.
Hopefully by getting everyone together, and your power-user is being unreasonable, the others can either peer-pressure him or even pull rank to get him to fall into line.
Not that this is bad in theory, but I have found that in practice, this just leads to hour long arguments and a lot of “well if Steve gets his thing, why can I have my thing?” and turns into a general waste of time. If you have a different experience, then I want your users
I really would say though, that unless your power user has a very compelling use case, he can jump in a lake if he’s a major outlier.
For use cases, you typically ask the users to walk you step by step through their typical business processes. ie:
Enter a new TPS report
Edit an existing TPS report
Forward completed TPS report to Lundberg
Also, keep in mind “Power User” means a user who has a specific role with extended rights and functionality. like a manager or administrator. It’s not just some PITA with a big mouth.
Who is the main sponsor/client partnerfor the software you are building? Right now it sounds like you are collecting what will ultimately amount to a giant wish-list of functionality. But ultimately there will need to be a conversation between your project manager, the main project sponsor (the business owner who is actually funding it) and probably your technical lead or architect to determine what will actually be in scope.
Otherwise, what you will have is every big-mouth end user who thinks their job is central to the operations of the company will continue to nit pick and otherwise delay and obstruct the delivery of your final project.
Also, is this an Agile project or a more traditional Waterfall style project where you get all the requirements up front? Because that may affect how you gather requirements from the users.
I dunno, “super-user” sounds like what you’re describing. I always thought a power-user was someone that preferred the advanced, please-don’t-hold-my-hand features.
I’d be really curious as to why the power-user guy needs such different requirements for a data entry screen than everyone else. He’s either doing something entirely different, and probably needs his own screen, or he’s going off the reservation and doing the same thing in some kind of f-ed up way, in which case he needs to get realigned with everyone else.
Typically we end up playing politics around the outlier guy, unless he’s the project sponsor or something like that. In other words, the trustworthy sorts in the meeting gets informed that the real purpose is as much to pull the outlier into line as it is to actually review requirements.
Ultimately though; if that guy becomes an unreconcilable hindrance, that’s when you take it to the project manager and project sponsor and explain the situation and have them let you know whether his crap is in scope or not.
One thing I see a lot of BAs forget to do is ask “why”. Why do you need this data? Why are you doing it this way? Why do you need this report? Ask why for everything. It is amazing how often you get the old, “because that is how we have always done things”, or “I don’t know”. If they can’t tell you why, they don’t need it.
I say this as a current BA and a current/former power user.
If you are a contractor who will be leaving as soon as the bill is paid, go ahead and ignore them. If not you will spend more time fixing the system after someone realizes that that “minor” nuance really does hinder your business operations if it doesn’t exist. The devil is in the details and the power user can tell you more details than you ever want to know… but need to.
Keep your eye on the end result, but when they say that something will work for most situations… but… sometimes… Remember that this “sometimes” may be for their biggest client with a tight deadline.
I actually really like the idea of dual screens. Most people don’t need 80% of what I need, but I need it all and if I don’t have it then it can cost the business bundles.
Power users can be a major PITA but you need that level of detail to turn out the best product IMHO.
So is business analyst now a common term for an IT person assigned to help business units handle their data and programs? Was really confused reading the OP because I didn’t see any inherent business questions that needed analyzing. I got all excited for nothing
I only ask because if I said I needed to hire a business analyst I would mean a recent business undergrad and would be very confused if HR sent me an IT major.
BA gets lumped in the project manager or product manager a lot in the software world. They might be asked to figure out the business case for features in software, and then generate the requirements for the developers.
IT likes to make people wear a lot of hats (not that we’re different from anything else).
This is very true - it’s why my first suggestion was two screens. But the thing to balance is that two screens may be more than twice the work, depending on how different the screens are (it may be more like 1.1x the work if they are close enough though). Sometimes you have to balance the programmer time/cost with the business need. If the need is there, great, make two screens. You’ve future proofed a bit in that case. But sometimes the business answer is “that would be nice but we don’t have the time or the budget for it”.
I ran into “We NEED it to look and act just like the current system but produce results not possible with current data”.
First: WHO is paying for this? Users are real good at adding costs - unless they are paying for it.
If the user is paying for it, any “desired” can be treated as required - but maybe point out that adding that this bell or that whistle will add x% and y% to development costs.
If a user tries to tell you about how the screens should look and work, keep them on target with a simple “Why?” “What good does that do”.
Another vote for starting with the REQUIRED vs desired outputs.
Ideally, you should already understand the application and have a good idea of how the data will need to be used. Now to convince them that they are the ones who figured it all out.
In IT, business analyst is the person who is a sort of liaison between the “business”, meaning the not-IT parts of the company, and IT, usually development teams. This liaison work mostly takes place through the medium of requirements documents, which are documents which codify and explain what the business wants with respect to a particular project/enhancement/etc… So the job requires the BA to be good with business people and IT people. They typically spend a lot of time asking questions, watching how things are done, and pestering people for sign-offs.
The ultimate idea is that when the business says “I want the system to do X”, the BA goes to the business and finds out why they want it to do X, what X actually means and how they think X will work, and writes it all down in the form of requirements that the solution must adhere to. They’re also responsible for communicating back hindrances and limitations to the business from IT.
When the solution’s done, the BA is involved in testing, usually at least through the practice of writing test plans based on the requirements.
In practice the BA does all that, and also fulfills the role of a sort of a non-commissioned project manager. He/she will ofteh be the person who’s doing a lot of the legwork getting the project done, even if the project manager is the person who’s actually responsible.
Business BAs are usually more concerned with process re-engineering and streamlining, as well as implementing new processes. They don’t really have that liaison role that the IT ones do, which is probably why IT BAs are usually fairly well paid, experienced workers, and business ones are often kids straight out of college.
Good explanation, Bump. That’s exactly what I am. I had a lovely 20 year career as a software engineer, which I parleyed into a new, second career as an IT business analyst. I got tired of the technology hamster wheel but didn’t want to completely throw away my CS degree and 20 years of experience to sell Avon products.
So to close the loop on this, I met with the power user last Friday and had him walk me through his process and his “whys”. Turned out he was very nice, generous with his time, and also communicated his ideas very well. It’s not that he’s doing things way differently from the other users, so much as he has the process better thought out than they do and they’re feedback was superficial.
The issue, if there is one besides Standard Operating Procedure for IT projects, is that the original business idea for the project is a light, fluffy “Let’s build a rainbow to heaven super quick and super cheap!” So we’re clarifying the scope of the project now, and while it’s going to be great, it won’t be super quick or super cheap.
Since you’re all here, am I the only BA who finds herself confused about the whole Waterfall/Agile paradigm? Waterfall has a clear need for BA’s while it slows a project to a crawl and is too rigid to support mid-flight changes. Agile is better, but I feel somewhat superfluous on some Agile projects. The developers seem to be able to code faster than I can gather and document requirements and the frequent changes seem to cause them a lot of confusion and rework. It’s a wonder they don’t kill me.
From what I gather, BAs aren’t really needed and nor are requirements in a true Agile framework. The idea is that everybody’s together in the scrum- business and IT, and they’re basically doing a whole bunch of rapid prototypes to get things working and clarify what they’re looking for.
This is opposed to the more traditional waterfall model where the BA has a phase all to themselves, with major downstream repercussions if they get it wrong.+
Waterfall vs Agile can certainly be confusing. Especially the way the projects of both type are often run, by people who don’t fully understand the process.
But I disagree somewhat with bump, a BA should not be superfluous at all in an Agile project and requirements are certainly needed. The big differences in my view are that you will be meeting with them more often for shorter periods but throughout the life of the project, and you won’t be handing them as much written documentation* as you would in waterfall. In a good Agile project, you’ll probably meet with them daily to flesh out requirements for their current task. The requirements will be more stuff you put on the whiteboard, or things you tell them in real time as they code it. But they still need to know the requirements, and as the BA, you’re the person to do it. Working with an Agile methodology doesn’t magically make the developers suddenly understand all the requirements.
A common slam against Agile is that “there’s no documentation.” But a tenet of Agile is actually only the documentation you need when you need it. So maybe you need full documentation of the requirements for QA or maintenance purposes, but a whiteboard is fine for the developers. Then write the documentation after the developer codes it - the developer can work faster and you don’t have to rewrite the requirements because things changed during development.
