Skip to main content

Author: Janet Walker

The Allure of the Technical Solution

Written by Janet Walker on . Posted in Articles.

Faced with a business challenge, it seems we want to get to the technical solution as soon as possible.

You’ve been there. The business reaches out with a problem and tells you exactly what they want you to do. Because we are team players and always ready to show our business some love, we take the chance that the business knows why their current process isn’t working and knows enough to come up with the way out.

Why do we do this? Why do we hand over the most important role a Business Analyst plays in Technology (business process analysis) and let someone else dictate the technical solution? Could it be because we can’t wait to start figuring out how to create something new?

“You think you need what?” or “Sure, we can do that.” then …… zoooooooooom! Let’s code!!

Why does everyone have a technical solution before we know what we want?

Thoughts:

1. There is always the urgency created by the requestor that compels us to jump over the logical steps to solve a problem. It is enough to hear that the business needs it now to make the sanest among us lose control. We react with our required sense of urgency, then too often do the wrong thing. We assume what we hear is all we need to know. We move on little information. Instead of responding to the requestor “I’m sure we can help so let me ask you a few questions, we just say ‘OK’ then come back later with nothing or the wrong thing.
Why do we go along with that? When we want to understand what our business does, we know to reach out and shadow the business.

Take a breath and ask about the current process. Show interest, build a relationship and let that technical solution wait until you know what you are solving. You are a Business Analyst and this is your area of expertise.

2. Then there’s the programmer or developer who gets a great idea (and it is great!). A new technical development will fix everything and make the business so much better. Unfortunately, their understanding of where the solution fits with the business process is often a partial understanding, hearsay or old school. Just try asking the developer to wait a minute to make sure IT and the business is talking apples to apples and be ready to hear how you are in analysis paralysis. You just stepped on their technical solution parade.

Why do they do that? With that kind of passion behind improving our business process, imagine the results when we are providing a technical solution that fits.

Advertisement

Take a breath and go out and document the current business process. Bring the requirements back to the techie and watch a remarkable technical solution come to life. You are a Business Analyst and this is your area of expertise.

3. Let’s be honest here. We all have the well-meaning leader who just came out of a meeting after volunteering the team to fix a business issue. The only thing left for the leader to do is delegate and convey the fast eta they promised. You get all the details that came out of that meeting so your leader is positive you are ready to take action. Get it done!

How does this happen? There’s a good chance that no one who actually uses the broken process was in the meeting so you need to find that one person who can give you the full story.

Take a breath and let your leader know you are on it and know exactly what to do next. You are a Business Analyst and this is your area of expertise.

4. The worst culprit, the one who jumps in with both feet before knowing how deep the water is, is the BA who spies a process breakdown. We spot it and know our business partners will love what we can do for them. We want to show them now how much better things can be. In the short run back to our desk, we have the solution built in our heads. We are so excited! Let’s email them to let them know a fix is on the way!!

Why do we do that? We’re passionate about our business and about being a BA. That’s good, right? We’ve been around our business and know them better than just about anyone else. Does this mean we lower our standards and forget the skills that got us here? The skills that made our business successful?

Take a breath. Fill out a requirements doc and show yourself what you don’t know about the process you are fixing.  You are a Business Analyst, after all, and this is your area of expertise. No one knows the business, the business need, what makes the business ROCK like the fully engaged Business Analyst.

Yes, the technical solution is the coloring book and crayons for anyone in IT.

Yes, it is fun, exasperating and extremely rewarding when you see the plan in action, but we are the keepers of the technical solution proposal! Don’t let the allure, that sparkle, of the technical solution blind you to accepting a technical solution from anyone else. Manage the technical solution, the BA way!

A Project Full of Business Analysts

Written by Janet Walker on . Posted in Articles. 2 Comments on A Project Full of Business Analysts

If you are your company’s only Business Analyst, you might have it easier than the rest of us.

You make the BA rules and you are always on the same page with yourself. You read all the articles on how to gather requirements and you have the documentation down pat. From beginning to end, you have all the answers, you understand the business need perfectly and you know things will go as planned. In your “the only BA” world, there are no surprises for you unless you forgot something or you assumed something or the change failed. My point is, you have the control and the full responsibility.

When BAs share a change or a project, things can get tricky … fast:

  1.  Get the BIG picture: If all of the BAs who will be involved in the project do not know the why, what and when, problems are a sure thing. For this reason, we want to avoid coming in late to a project or miss a kick-off meeting at all costs. We may not be good at having the right people in the room, so BAs need to be aware of initiatives coming down the road and make sure we are included day one. Every BA involved needs to start on the same page and begin communicating with each other right away. “Here are my take-aways” and “My change starts when you are done, but before ….” etc. I know, the big picture changes, but multiple BAs need to know where they fit in relation to different requirements. Chase that moving target down!
  2. It’s all about Bandwidth: We are assigned to the same project, but I am ready to go and you are still finishing a different project. This means we have to talk about our bandwidth and our calendars – business and personal. We can agree on a date to start, but if you are OOO two weeks later for four days, I need to know this. My testing may need to be put on hold, I may start another task early while waiting for you to return. Share calendars!
    3. Advertisement
  3. The Multiple requirements: Our individual requirements may be different in why we need to make a change or build a new process, but we know for a fact that we are linked together by a common project. BAs that try to run alone during a multiple BA project end up taking everyone down because the loner was positive their changes did not impact anyone else. We need to look for those points where our process starts, updates, communicates and hands off to the next step in the big picture process. Meet with the BA that is making changes that flow into yours or just before your changes. Document this info. If you are updating, find the BA who supports what you are updating/adding/cancelling/communicating and make sure the format is expected and the timing is correct. Document this info. Understand what happens when your personal process change ends. Find the BA who takes it from there and make sure they have what they need from you. Document it.
  4. We got test plans! : My test plan tells me I have my ducks in a row, just the way I planned. What it doesn’t tell me is how my changes fit in with anyone else’s changes or an existing process. Reach out to the other BAs on the project and ask them to let you know when they are ready to test with you. Don’t be surprised when that BA who is used to working in a silo pushes back. This is our opportunity to make all the BAs better by saying we want our project to run smoothly. 😉
  5. Uh-oh: Such a great feeling when the changes move to production and things are working as expected! Yes, but when something goes wrong it is also a great feeling having BAs working together to solve the problem. Nothing is your fault. You worked together and communicated about the why, what and when. You all built the new process together and a hiccup anywhere along the line means everyone has the hiccups. You can hear the conversation now – “We tested this piece, right?”, “What did we miss here?” and (my favorite) “Umm, I never heard that was a must have, did you?”
    A team failure is quickly another team win when the group solution is found and the lessons learned are discussed after the fix is in. This kind of win is huge!

So, get on the same page, communicate regularly, support each other and provide a second set of eyes. Know your peers that are involved and what kind of knowledge they can share with you and let them know you are available to return the favor! BAs working together on requirements and changes make for a strong project.

The Others on BA Island

Written by Janet Walker on . Posted in Articles.

I sure enjoy the articles and whitepapers that are available online about business analysts and business analysis, don’t you?

We have our bases covered, don’t we? Articles, whitepapers, seminars, and conferences. Sometimes I can spend a full day reading and thinking about us!

Related Article: An IT BA on a Cross-Functional Technology Team

Clearly, the business analyst has a very complex role to play in both innovation and process improvement. Our business analysis is critical for any company hoping to grow or be successful. Yes, it is easy to think that one good BA and a Word doc is all it takes to make the world go ‘round, but sadly, not true. We know from experience that it takes partnerships to make a new process spin. It takes people who write code, and people who test for quality.

Yes, there are “Others” on BA ISLAND.

Recently, I slipped outside of my BA world to find out what these Others are doing, thinking, and saying about what I view as our common goals. Do they even know that we, the BAs, exist? If so, have they liked having us around, communicating with the outside world for them? Using our mad meeting skills so that we can tell them why they do what they do, and how to know when they’re done? Is it presumptuous of us to think that we can guide them to a successful finish? I had to know!

I started with the ever elusive engineer

The world of the hardcore application engineer can get scary. I remember when I crossed into the engineering world for a while. I can tell you the mind plays tricks on you when in the “dot” or “hashtag” world. It’s a place where one idea, even one thought, can result in pinpoint focus, a furious battle of techniques, and a mad desire to figure it out now! Need help? No! I got it! I’ve never met a lazy engineer, although they can often look that way, slumped back in their chairs, a bedhead over eyes that live in display screens. These creatures-of-the-code amaze me.

I’m going to introduce you to some IT engineers I’ve met over many years and let you know what they are saying about us, the business analyst. “Why?” you ask. Why care about what the engineer thinks about me? Because, my Fan of Business Analysis and Process Improvement, it is this engineer who judges what you bring to their table and who looks to you if there are rewrites or production issues. It is this engineer who is taking you at your word and follows your instructions. It is also this engineer who may often run alone and do their best to figure out why they are doing what they do and really, really, need your help.

Here are some engineers with different programming and corporate backgrounds. Some were old-school professionals, and others were new-world geeks. What I found they all have in common was the understanding that they don’t code in a vacuum. They know that some pieces to their code puzzle must come from elsewhere.

On Business Analysts

When asked if they work with BAs on all of their tasks, the engineers’ answers ranged from “I don’t always work with a BA on my tasks” to “I haven’t worked with a ton of BAs. My team is full of legacy apps, all technical team ownership” to “I always have a BA available on my engineering tasks.” Those who include BAs in their tasks said the BA is underappreciated. “Some people think anyone can do this job, but that is not true.” “I can tell a BA in the room by the questions they ask.” There are BA imposters, though. “Leaders and others are helpful, but their info may be dated. Still, they act like the BA.”

“I love BAs!” (This is how I heard it, folks).

Engineers noticed that BAs are different from each other. I heard it is difficult to bounce around between BAs. BAs have different approaches, and the engineer likes knowing what to expect. BAs who only know their own system are a challenge as we are all connected these days. All BAs should care about the code, but not necessarily understand the code. What is a real plus is that the BA knows how to test with others – the business, other BAs, engineers. BAs are great at communicating, and this is the number one challenge for the engineers. I heard it is a real plus to work with a BA.

What the Engineer Needs

What can the BA do for me? Well…

(I admit I was pleasantly surprised to hear most of the engineers had already given this some thought. I told you they were smart.)

The BA can see what’s on the horizon, reach out and meet with system peers, run interference with teams, be the communicator, and do some BA testing. The BA should ask me (the engineer) questions, work with me, work with the business, and clarify everything else.
Gotcha! We can do that.

The BA must understand that I need to be kept in the loop. If you give me clear specs, provide clarity and scope, I am good. In a nutshell, CLARITY is crucial – in specs, scope, and any communications. (This is why the engineers like the BA to go to the meetings.) With complete clarity, the BA and the engineer can work together on the technical solution. One engineer without a BA for his team said if he had a BA just to go to meetings and provide his team with clarity, he would be fine.

The requirements doc was brought up in every conversation between an engineer and me. One engineer said he can guess what is needed, but would rather code. (No guessing, please.) Another engineer made the point that engineers often struggle without requirements. There will always be questions, even if just for acceptance criteria. While the “why” certainly matters, it’s nice to know my code is helping the business move forward, but the “what” is critical to me. What do you expect me to make happen? Requirements make for success. Who could ever have a problem if we are documenting what needs to be changed or built? (Again, clarity.)

Another common thread among Engineers was the need for communication assistance. I heard over and over that the BA should see what’s on the horizon, or the BA needs to reach out and meet with system peers, or run interference with teams and then be the communicator. I heard “the engineer is so solution driven, they are not good communicators.” Also, engineers often take things literally and communicate literally. This can cause confusion regarding expectations. The engineer probably thinks they are communicating well, but the BA excels at communication with the business. BAs should know the engineer is often too technical and focused to notice the details hidden in discussions.

My takeaway: Less than full requirements that result in changes is not a good thing. Period. Give the engineer the necessary requirements, failure cases, known holes; do full regression testing and you have one happy engineer.

What about rewrites?

One engineer deemed rewrites the worst mistake an engineer can experience.

The majority of engineers I spoke with said that rewrites would not be needed if a BA was on the task to tie the threads together. The BA simplifies the process before the coding begins by providing clear requirements and communicating with everyone involved. I liked hearing the BA could help here, and felt the pain the engineers went through when they did all that work, only to find out they were on the wrong track. Unfortunately, just being wrong may often be determined after the automated process is in production.

I heard, “The worst time was working without a BA and just not getting the big picture.” It led to a rewrite, causing delays and frustration. Business use cases would help us understand how the code will be used. I even heard that a BA could save a task by their requirements, running the requirements by the engineer before publishing them, and by collaborating with the engineer on the documentation.

My thought here is “Why haven’t the engineers said something to us?” Is it because using a BA on a task has never been an option for their department or team? I remember being the first BA in a systems and programming environment. After a short time, engineers were lining up to ask me to talk to the requestors for them to clarify some specs. Engineers visiting the other side of the island is a good idea!

Has your code ever been part of a production issue?

With no one really answering my question, the common response was, “In today’s world, everything talks to everything. Get the wrong people in the room or work with outdated documentation or no documentation and production issues happen. Miscommunicating or not knowing all the pieces to test equals failure.”

Lack of experience was mentioned by a few as a possible root cause. Then a comment was made saying someone tying the threads and communicating effectively would cut down on the unexpected happening in production and mitigate this lack of experience. One engineer’s comment about going to production and having a problem was that a BA would understand the current state, and know when the task is done and ready for production.

Here are the common threads about production challenges that I heard: business-use knowledge and communication. I say no one manages these threads like a business analyst.

After the Interviews

The engineers spoke with me about where they see room for improvement in their engineering world. While giving and receiving productive feedback, I heard a lot about a place for the business analyst. The BA never came off as the savior for implementation slips or test omissions. The engineers I spoke to seemed to appreciate the special skills associated with the business analyst role.

One thing new to me and I heard it many times during the interviews – It seems the engineer learns a lot by failing. While I accept this is a component on the engineer’s path to success, failing over and over for the same reason is not. Add to this, the engineer who is too busy forgetting requirements and things start going downhill fast.

What did not surprise me was hearing that engineers who started including a BA on their team projects said they can’t go back now. I was told the full impact of a BA communicating and documenting has been remarkable. I heard that BAs need to keep doing a good job. That was nice. Clearly, there is value added by operating as a cross-functional team, rather than simply an engineering team. One engineer just asked his leader for another BA for his team before he and I sat down to talk.

I feel a great responsibility after all of these conversations, and I hope you do as well, so I can’t help but ask:

• Why is an engineer dealing with a different quality of BAs?
• Do we all have standards in place for our BA skill level?
• Are we seriously working on our communication skills with not only the business client but the technical teams around us?
• Are we working in a silo, or are we gaining knowledge about the systems that our clients and teams are talking to?
• Finally, why isn’t the business analyst a role on every engineering team? Why would we not include this valuable skill?

Now, I gotta go. I think I spotted some QAs on the island!

Fill Your Business Analyst Toolbox

Written by Janet Walker on . Posted in Articles.

Every good mechanic has a toolbox, and that toolbox literally gives the mechanic the confidence and capability to do whatever it takes to get the job done.

Here’s an example. The mechanic gets a call during business hours, sometimes on weekends, from a customer requesting a need or want. What is the first thing the mechanic does? The mechanic asks questions about what’s broken, what isn’t working as expected, or what the customer wants and why. The mechanic needs to get to the bottom of the challenge before offering a solution. This diligence is, in fact, the most important tool the mechanic has – the skill to dive deeply and fully understand what is needed.

Related Article: Business Analyst Experience: Pay it Forward

The next thing the mechanic might do is ask to see what is wrong. The mechanic pulls the offending auto into the shop, or if the request is for something new, the mechanic might see how the manual process is being completed today.
Observation is the mechanic’s second most important tool. Not everyone has the skill to look around at all the moving pieces, check things out, put it up on a hoist, and look at what connects to what.

After the mechanic fully understands what the customer wants or thinks they need, sees what the customer is doing today or can’t do anymore, the mechanic is now ready to begin. The mechanic rummages through those stored items in the toolbox that can resolve, highlight, measure, clarify, explain, visualize, assist, poke holes, slice, or make things run smoothly. The toolbox might start out kind of light, but as the mechanic becomes more experienced, the toolbox get heavier and more valuable with the tools needed to get the job done.

Does any of this sound familiar?

Now, the business analyst gets the call – “I need, I want, I can’t, I wish.” You pull out the first tool from your toolbox. OK, virtual toolbox. This is the beginning of the deep dive.

You want to know everything about the situation, and can’t stop or move on until you have all the details and know exactly what your client is so concerned or excited about. This particular tool doesn’t ever wear out though. Notice that? It actually gets stronger and more accurate the more it is used. Business analysts are lucky this way.

Next, you need to see the challenge or your client in action. Your second tool helps you here as you’re confident about taking things apart, holding them up to standards, checking out metrics, and evaluating performance. You understand any systems that are impacted or needed, can copy down to lower testing environments, and your sign-ons are still active. You have the investigative tools that you need.

Ready to make a difference? Let’s pull out some other tools of the business analyst trade.

Most business analysts need to know how to use the desktop applications in their toolbox, such as Word, Excel, PowerPoint, and Visio. Being able to use these tools comes in handy when it’s time to document notes and findings. This is the toolbox tray where you find your test plans, and the names and numbers of every Subject Matter Expert (SME) you will ever need. That process flow you just figured out is here for anyone who asks, and when you have to explain how you are going to fix something, that PowerPoint you had the skill to do is going to get you through.

Can we have too many computer skills in our BA toolbox? I think not, so we’ll discuss a wide variety of computer skills in another article; they will fit into your toolbox nicely.

Another set of tools you want in your toolbox (and kept sharpened) are those that let you schedule, call meetings, and get everyone on the same page. Sure, the whole BA package (BA 360!) is far more than being a requirements gatherer and meeting caller, but being able to get the right people together, show them your plans, and organize the conversation in a room is critical.

Here are some ideas regarding meetings:

1. Whether the meeting requires a conference room or call-in number, you don’t want to fumble around when you can finally get the right people in the room or on a call. Have the call-in number saved where you can find it quickly; and make yourself comfortable with Meeting Planner, Reservation Maker, or plain old Outlook for meeting requests.

2. I mentioned getting the right people in the room. Being able to figure this out is a key skill to have, and from my experience, it can be a challenge. I still get half way through a meeting and wish I had invited someone. (I even get half way through a meeting and wish I hadn’t invited someone.) Now that you have mad meeting-scheduling skills in your toolbox (right?), you can spend time thinking about who the players are for your task or analysis.

a. What process is downstream and will be impacted?
b. What upstream process has expectations?
c. Who asked for the change or new functionality?

I personally don’t like the “mass-meeting,” but if you are up to herding these cats, go for it. I prefer a room of SMEs. They don’t want their time wasted, and neither do I. Plus, they have all the information you need.

3. Another skill I believe needs to be included in our BA toolbox is whiteboarding. Don’t underestimate the skill it takes to draw straight lines and print legibly! Once you see a BA show amazing whiteboarding skills, you may never want to write on a wall or poster board again due to pure embarrassment. Seriously, try holding a marker over your head, writing the alphabet, and drawing tic tac toe boards. The attendees may not say it out loud, but everyone appreciates whiteboard talents.

There a lot more tools to talk about and we can do that another day, but now, are you ready to list what you have in your BA toolbox? You’ll be surprised at how much you know!

Find some tools missing? Sign up for an in-house training, ask the business analyst sitting next to you to teach you, or, of course, there is the Internet.

Nothing missing? Then now is the time to refresh your old skills using new technology, or challenge yourself and take on a task that requires you to dust off those old skills.

Even virtual tools can get rusty.

An IT BA on a Cross-Functional Technology Team

Written by Janet Walker on . Posted in Articles. 1 Comment on An IT BA on a Cross-Functional Technology Team

If you, like me, have spent most of your BA life sitting amongst other BAs or inside a cluster of business partners, you can appreciate the “shock and awe” I experienced moving into a workspace filled with engineers and QAs.

Half of our IT team re-orged into system-specific cross-functional teams. The business analysts combined with the QAs, system engineers and even a database engineer (DBE) or two to form a cohesive group of support, brainstorming and execution. I went through this transformation last year and can say the experience has been nothing less than eye-opening.
Keeping the engineering side of your business in focus is important for any BA, but when our business wants to turn left and our engineers – developer, programmers, DBEs, etc. – are diligently working on how to use the latest technology to turn right, we find out how painful it can be!

The engineers (I lovingly refer to them as my Geeks) are as committed to driving our business as I am and are always looking for the inches of improvement around us. Suddenly, the total commitment to our business partners involves some tough choices for me, the BA.

One day I’m in a devoted business partnership, the next day I’m in a devoted partnership of driving the business during system upgrades and failovers!

The first thing that shocked me on the Geek-filled team was finding out I was actually skating on thin ice all those years as I was driving our business forward on top of new technology. Yes, I understood how the system worked and what some of the possibilities were, but all that time the engineers were looking for better ways and innovating like crazy. Suddenly, I understand why the engineering response to my change requests was often “WHAT?”, “WHEN?”, “WHY?” and sometimes “Wait!” I was driving the business on top of a system or systems the Geeks were constantly improving. Understand, our company culture is deeply ingrained in all team members, but sometimes during those days as a business BA I wondered if the Geeks and I worked at the same place. Getting on the same page, or not colliding on the same page, was the source for a LOT of discussions, but, the real challenge had been making the business better on top of the ice and how to make the system better below.

{module ad 300×100 Large mobile}

The second “wake up” moment was when I spent the first month with my Geek team and realized we had been meeting and making decisions over the years while saying the same words and meaning completely different things. For example, I have used the term Doc Type for about 14 years and never knew the engineers supporting my system have been mentally translating it to Doc Type Number. Only when I physically joined their world did I hear the comment from one to another “She means the number.” A simple difference, but really got me thinking. Geeks talk differently. In my part of the world, they speak English, but a different kind of English. There I was, thinking I was an expert at translating technical changes into business-speak, and I found myself needing to come up to speed on translating geek-speak to technical changes to business-speak.

Thankfully, I landed on a team with patient engineers and QAs. I think this patient Geek may be few and far between, but if you find one – listen and learn! My experience with Geeks is that they run fast and when they get an idea – watch out! A discussion can go from clear and orderly to “Wait, what if we do ….” and “No, I heard about something that ….” REAL fast. Your BA skills are needed like no time before. Remember how you led that meeting with business big shots and their conflicting agendas? Child’s play. Now you need your special skills, as I like to say, to herd cats. You are dealing with super-smart, ready-to-execute, get-it-done individuals and what we don’t EVER want to do is stop that innovation and passion for execution.

You just want to figure out how to do what our business needs us to do and make it to your next meeting (or lunch) on time. Remember how I mentioned I work with patient engineers? Well, even their patience is limited when it comes to asking them to remind me (again) what a thread is. You will want to decide what questions you need to ask during a meeting like this and what questions can wait.

My suggestions, if you find yourself gifted with an opportunity to work on a cross-functional technology team:

  1. Concentrate on just listening during your first few team meetings. Ask an engineer or QA afterwards to translate what you didn’t quite “get”.
  2. Slowly start asking questions to find out if anything on the agenda will affect your business partners. This is a way to bring the business closer to your engineers, QAs and DBEs.
  3. Add something to the agenda that is pure BA, pure business. Get ready for odd looks, questions and maybe even some chuckles. This is where you find out how wide the chasm is between what your Geeks think the company does, and what you know it does.
  4. Make an effort to educate your team members as you get educated yourself. Share your current business meeting challenge, your thoughts on acceptance criteria for a task or other things in your typical BA day. Pretty soon you find the discussions become mutually informative, and the action items have you all on the same page.
  5. “BA” for your engineers! Give them the support and input they probably didn’t know they could ask for. Do the analysis, contact the subject matter experts for any clarifications, and learn to test something from the very bowels of the code. Show your cross-functional team what they have been missing all this time and why they need you in their lives!
  6. Lastly, enjoy the most exciting team experience you have ever experienced. Dive deep, sweat a little and celebrate the big wins as a cross-functional team.
  • 1
  • 2