Tag: Training

Is a Multi-tiered BA Certification Program the Way to Go?

Written by Laura Paton on May 26, 2016. Posted in Articles. 1 Comment on Is a Multi-tiered BA Certification Program the Way to Go?

For anyone waiting for the unveiling of the new certification program from International Institute of Business Analysis™ (IIBA®), I have been wondering whether such changes will be helpful for organizations and the practitioner community as a whole.

The one thing I have learned over the years from the community was that the certification process, including how one applies and qualifies for these exams needs to be more straightforward and avoid complexity at all levels. Having been proposed for some time now, we still don’t know enough about the changes being made to the program to form an opinion – or do we?

Here are a few factors I have been thinking about with regards to these changes. I would love to hear what you have been pondering. In this post, I am simply putting the questions out to the community for consideration. I form no opinion, but as a current Certified Business Analysis ProfessionalTM (CBAP®) I am really interested in knowing what other certification holders are thinking.

1. Level 1 – Today knowledge based certificates in business analysis are plentiful as a large number of training providers already offer BA certificates. Will this new Tier 1 certification be a differentiator in the industry? Several years ago IIBA spoke with EEPs about providing a jointly branded BA certificate, and for many really good reasons Endorsed Education Providers (EEPs) did not want IIBA crossing the line into the training space. Has enough changed here? Do employers and practitioners believe Level 1 recognition from IIBA which assesses general BA knowledge (no experience) is more significant than a certificate from an EEP whose sole focus is on training?

2. Level 2 – The market for the Certification of Competency in Business AnalysisTM (CCBA®) has never really taken off, as of today after 5 years, there are only 850 CCBA holders. Are the proposed changes to scenario-based exam questions significant enough here to help IIBA grow this certification or are there other issues with this certification that if addressed would help the viability of the CCBA®?

3. Level 3 – The CBAP® used to be the gold standard, and those of us who acquired the CBAP® felt like we were demonstrating our senior level experience to employers. After all, the CBAP® has always been an experienced based exam. In the early years, many of us struggled to find employers who found the certification as a differentiator or who deemed it mandatory for employment. Over the years some awareness has taken place; although still not as widespread as the PMP.

CBAP® recipients felt the certification demonstrated their commitment to the profession and identified themselves as senior practitioners. With the proposed changes, CBAPs will no longer be the top tier. Are CBAPs ok with this? Do CBAPs feel an urge to run out and spend more time and money to get back on the top tier of the ladder? Anyone feeling like their credential is less attractive or valuable to you, to your employers or to the BA community? On the other hand, are the CBAPs excited about pursuing this next higher level certification?

4. Level 4 – Lastly, the new level geared to thought leaders. It has always been the case that thought leaders are recognized in the community by their contributions. Their credibility is achieved through the engagements they are completing within organizations, with the research they are performing, the articles, books, and other products and services they provide the community at large. If you look today, many very influential, experienced, top-notch thought leaders do not have a credential nor do they need it because they are already well-known in the industry for the work they are doing for all us. I am very curious to hear from the community whether our thought leaders require a certification to be recognized or acknowledged as a thought leader? If organizations are looking for thought leaders to be validated through such a process, is such a model scalable since level 4 will require an assessment?

Lastly, I want to ask about the idea of moving to a competency-based framework for certification. Back in the day when Angela Wick and her team developed the Competency Model, it was and still is an amazing product. The team spent countless hours building a framework to help articulate what skills and competencies define a novice business analyst from an expert business analyst, but it was a tool that must be applied along with a lot of other factors to be able to tell an accurate story of competency.

For example, if you are a business analyst in an organization and are not working on large, complex, transformational projects you may never leverage a lot of the skills in the upper categories of the competency framework. For your organization, for the role you have been hired into, does that make you less competent? What about the business analysts in financial institutions responsible for bringing their clients online with a standardized financial service, where each client is a new project, but the projects have little variation to them? These business analysts become very proficient working in their organization as a business analyst/implementation analyst without needing to leverage many of the top tier skills in the framework. Does this mean they are less valuable or less competent to their organization because their projects are consistent in type and size?

In my opinion, the role of the business analyst is defined by the organization based on a multitude of factors that really can’t be standardized across industries because there are an infinite number of factors that apply. To make an assessment of competency, consultants have to work with the organization to conduct interviews, look at templates, watch processes and practices first hand, and understand the project environment to assess competency within context. Knowing this ‘as-is’ state is very critical before conducting a gap-analysis to assess what competencies are missing. I have performed competency assessments for years in this fashion. My question here for the community is could a 3rd party working outside the walls of your organization assess competency without having this ‘as-is’ picture? Is this approach old school and is this 4 tier approach answering some newer needs organizations have today about the competency of their BA resources?

Lastly, I myself am interested in understanding the research completed to support a 4 tier certification. Typically I have seen a role delineation study conducted to provide the insight to align and structure a product like certification. I am not proposing it has not been done, but simply asking whether anyone knows. Since I don’t know, I am really interested in raising some dialogue in the community to hear your likes/dislikes to the pending 4 tier structure.

Please share your thoughts and provide different perspectives.

Fill Your Business Analyst Toolbox

Written by Janet Walker on April 26, 2016. 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.

Facebook using Business Analysis and Improvisation

Written by Kupe Kupersmith on January 19, 2016. Posted in Articles.

There are two things I really love. One is business analysis, and the other is improvisation (improv). Even more so, is applied improv. Applied improv is the concept of applying improvisation skills to other things besides acting. I focus on helping others apply improv skills and business analysis in a business environment.

So, when I read this article via Business Insider, How Facebook’s design team organizes its critique meetings so nobody gets offended and everyone has clear goals, I loved how they talked about business analysis and improv in one article. I thought they wrote this for me. Or maybe their Product Designer, Tanner Christensen, is my long lost twin.

Here is the catch, though. They never mentioned business analysis or improv in the article. Not once. Regardless, you can recognize it if you read between the lines. This phenomenon is a big issue in the business analysis space. I believe that business analysis is happening everywhere in organizations, and no one even knows it. We are also always improvising. When is the last time you had a conversation with someone and you used scripts?! Articles like this prove it.

In our book, Business Analysis for Dummies, Kate McGoey, Paul Mulvey, and I wrote a chapter about business analysis happening at all levels of an organization. We mention there is analysis at the enterprise level, organizational level, operational level, and project level. With books like ours, other experts in the field writing and speaking about this, and even some companies realizing it, the majority of people and organizations either don’t understand the value of analysis or see the value only at the project level.

To help break the trend of some not seeing business analysis happening at all levels, I will break down two key points in the article about Facebook. The article is covering Mr. Christensen’s design critique process his teams use to yield positive, useful information to create or improve products.

1) Business Analysis: The first step in their process is to make sure everyone understands and agrees to the problem that is trying to be addressed. At its heart, this is business analysis. If teams do not have a shared understanding of the problem or goal that is trying to be achieved, then the chance of success is limited.

The best business analysis professionals around the world do this day in and day out. Even if a solution is handed to them, they work to understand the problem that the solution is trying to solve. They use tools like the problem statement, impact mapping, etc. to draw out the problem and communicate it in a way that it is clear and visible to the team. In creative ways, they are asking the “5 Whys.” Since asking why can put people on the defense you can ask, “What does success look like” or “What will be different after we implement this solution?”

2) Improv: For the team members critiquing the proposed design for a product there is a general rule they should follow. In the article it is written, “To make a critique valuable to a presenter, it is advisable to begin with a positive note on something you liked about the solution and to pose your thoughts as questions. Doing so will encourage him/her to offer reasonings instead of being defensive.” I almost jumped out of my seat when I read that. It was music to my ears.

When I work with individuals and teams, I stress the need for having positive conversations. One way to do that is by having the “Yes, and” mindset. The mother of all rules in improv is never deny. Since there are no scripts used when you are performing improv denying just kills scenes. In improv if someone walks into a scene and exclaims “Wow, I love that you colored your hair yellow,” you never say “it’s not yellow.” That denial instantly puts the burden back on the other actor to come up with something else. If you deny like that on stage too often, the other actors won’t want to work with you anymore. The same applies to the work you do. If someone proposes something and you consistently deny them using words like “that idea is terrible” or “yeah, but I have a better idea” your co-workers won’t want to work with you much longer. And, no value is gained.

Improv actors practice the art of never denying by playing a game called “Yes, and.” One version of the game goes something like this. A topic is given, and one actor starts off with a sentence. The next actor says “Yes, and…” then adds to the conversation. Then is goes back and forth. The feeling is very positive and rewarding as you keep adding things and supporting your partner. And crazy ideas come out of those conversations. Try it!

When I am teaching this to business professionals the conversation around not agreeing with someone always comes up. In real life, you can’t just keep saying “yes, and…” Absolutely, you need to critique without putting others on the defensive.

The advice I give is exactly what Mr. Christensen gives to his team. One idea is saying, “What I like about that is…” You need to have the mindset of finding something good in other people’s ideas. The other piece of advice I share is to ask a question. Sometimes the ideas people have are viewed to you as crazy, wild, unimaginable, or maybe you know things like that have failed before. So instead of saying, “yeah, but that idea is crazy, what about this.” Ask, “Help me understand how that idea gets us closer to solving our problem. I just don’t see the connection yet.” Two things can happen there. One is the person may realize that their idea is crazy and does not work for this problem or two, they convince you the idea is good and will work. Either way, both parties have a positive conversation rather than an adversarial one.

One way to help others understand that business analysis (and improv) is happening everywhere is for us to highlight it when you see it. Read between the lines, keep your eyes open. When you see good business analysis and improv happening tell the people around you what is really happening.

All the best,

Kupe

BA Experience: Pay It Forward!

Written by Janet Walker on January 12, 2016. Posted in Articles.

As Business Analysts, we are always looking for missing information – making sure we have the whole story behind the business need, the truth about how we are doing things today and what our partners really want to do (No, really want to do.). We start with something to write on and hit the business with the big questions. Once we think we have it all, the truth and nothing but the truth, we start thinking about a technical or process solution. READY, GO!

What the Business Analyst often does is stop here, thinking they have the whole picture and are good to go. Analysis begins and then the task moves to IN PROGRESS.

What the Business Analyst seldom does is talk to other BAs about their challenge. They have a task to do, an aggressive, often crazy ETA and a story committed to THIS iteration so heaven forbid it should not be tasked out for success. Stopping to talk through the challenge is seldom seen as a valuable use of precious bandwidth. GET IT DONE!

Any of this sound familiar?

While mentoring some new Technology BAs, there were a few challenges where I assumed they knew what I considered to be basics. Why did they proceed without more information? Why did they think their requirements were complete when they were clearly (to me) not? The newbies went on to teach this oldie a lot when they said “Stop assuming we know this. We don’t think you know what you know.” What?

After chewing on that statement and some crow for a while, I came up with thoughts that may be attributed to experience – a lot of failures, trial and error and other learning paths. I will share them with you in case you too think every BA knows this stuff, and you don’t have anything special to offer. If you want to, pass this on (plus the things you didn’t know you know) to your mentees. I promise you will be happily surprised that this most basic knowledge share can make a difference in their growth and stress level whether the BA is in IT or in the Business.

Dear fellow BAs, What I didn’t know that I know …

Don’t assume Team Members (TMs) know what they are talking about when they ask for a change. They may be new users and new leaders. Help them out by diving deep. You may get some pushback, but either leave the meeting confident that your business partner is an expert or know who might be and ask that expert to a second meeting.

If you are dealing with changes to a previously automated processes, that automation may have been built with TMs who moved on. A thin understanding of an automated process can lead everyone down a rocky path. This means you will want to understand that current automated process, behind the scenes, to add your understanding to the “How It’s Done Today” discussion.

Start at the beginning and get to know your partners. As we are in an email, IM, HipChat, Conference call, Live Meeting world we have to work harder than in the past to get the whole picture. We don’t have the added advantage of body language to help us (the TM who looks down or away can speak volumes about not having a clue or disagreeing with what their Leader is saying) Don’t minimize the importance of reaching out and meeting your partners face to face or on one-to-one phone calls.

Expect your business to walk in the door with a technical solution. Everyone has a great idea, but requirements gathering needs Sherlock Holmes-type experience. Don’t be afraid of being the dummy in the room. I have been that dummy so many times I’m amazed the business still contacts me for help. Everyone started learning about your business at some time, and your partners will tell you everything about what they do and feel good about doing it.

Even if nothing else is clear, make sure you totally ‘get’ the business need. Why the heck are you in this meeting and not at lunch? What are you solving for? Wait! Hold firm. Tempted to talk solution? NO technical solution without requirements! We might be good at guessing, but without requirements, that’s all we can be, a good guesser. Actually, there might not be a technical solution. Maybe if your partners complete step A before step B, they won’t need an automated solution to find step A data while completing step B. Get it?

Who will be impacted can be a rattlesnake behind a rock. Assume your partners don’t know who else uses the same functionality. Ask. Send out a message to a wide distribution, if necessary, but watch out for those cool automated processes that other parts of your business jumped on for themselves and neither you nor your task partners know it You don’t want the noise from other TMs asking “Who changed our stuff?”

Now, the fun part, The Technical Solution!

There is a pro and con for every technical solution I have ever delivered. Remember to convey the ‘cons’ clearly for all parties and relay these cons when you officially announce the technical solution. Everyone knows what to expect. Right? Own it. The BA owns the solution, be prepared to explain the “why it is the right thing to do for everyone” – the business, technology, the company. P.S.: This is a great time to share a prototype or demo if you have something this early. Requirements may change (like you didn’t know that, but I had to write it down.), re-evaluate the technical solution when that happens.

Expect thorns in the roses. Knowing who needs to approve things can be tricky. Who really has the last word on saying the technical solution is good to go? Really. Nothing is worse that feeling you have a plan and find out someone read the email a week later and has the power to say “Well, I was thinking …”.

The same is true for when to start the tasks PLUS when technology prioritization says you can start. Don’t promise a start date until you have the date from the business and the date from whoever is tasked with making the changes. Everyone has different priorities and bandwidth.

I found that the sooner you can start talking to trainers and testers the better off you would be. Trainers and Testers, in my experience, are valuable commodities, and you want to pencil in their time early. Nothing is worse than making a big change and finding no one knows how to perform the new process. Don’t rely on your business to have training on their checklist. Have it on yours too.

ETA is the monster that the BA needs to battle. This is a truth. Once someone hears an ETA whispered over the wall, the BA is handcuffed.

Avoid verbalizing or writing an ETA if at all possible.
Since this is not possible, don’t act like a superhero. Be smart and keep a list of potential roadblocks (sunny days when everyone is always sick, etc.) on you at all times.
Be very clear about what will be accomplished by the ETA!

I don’t want to come off totally negative here, but more people than just the BA care about the start and stop. Even with the best planning software, the BA needs to tread carefully when talking about the ETA and be prepared for plan B and sound reasons for any delays.

Documentation – We hate it until we need it.

Simplify task names

Name your Project/Feature/Story/Task/Whatever using keywords that you can search on to find out why the change was made. Then, don’t forget to include the business need in EVERY task you create. The Why will make your life easier today and tomorrow.

Give a high-level explanation of what the task will do to reduce the questions you’ll get from interested, but not participating, parties.

Don’t forget to share your Task number(s) with all the business partners who will care about the changes. This MAY stop some noise about the status of your task(s).

Identify Go-To People and SMEs

Who asked for this change anyway? You know, that person now tied to you at the hip. Add their name to the list of Go-To people! Don’t forget to include a list of your SMEs too. Remember the tasks floating around yours. Is anyone working on a task that is needed by you or waiting for you? They deserve to be in your documentation. Keep them in the loop and you have a BA BFF.

One last thing about documentation – Know Your Audience. Write for the reader.

I admit I am Test Plan Challenged.

My BA friend, Marie, is crazy meticulous with her test plans, but for me, any test plan is better than none. Create a test plan and look at it daily while you are working on your task(s). You will be glad you did. You want to know when a step or task is “done.” Nothing feels better than getting to this moment so know how to recognize the moment!

If you make fancy test plans like Marie, you are special.

One more thing:

You know this documentation we were talking about here? Update it when you have any progress or road blocks. Be clear and concise. When things get hairy, your own notes will save you. I promise.

To make your Write Up the greatest story ever told. Here is the formula I wish someone told me about years ago:

Spend 1/3 of your time writing down the current situation.
Spend 1/3 of your time writing and re-writing why you are doing this.
Spend 1/3 of your time detailing the technical solution.

Lastly, if you found yourself saying “Duh” or “Pleeeeeze, everyone knows that” while you were reading my article, then you are a smart BA that assumes, as I did, every person with BA or Business Analyst after their name has as much experience as you have. Remember, some of our BA friends are just getting started (as I was kindly reminded) and can benefit from knowing what you didn’t know you know. Pay it Forward!

Implementing Change – Phase 6 – Reinforce New Behaviours

Written by Peter de Jager on December 4, 2015. Posted in Articles. 2 Comments on Implementing Change – Phase 6 – Reinforce New Behaviours

Doing something new means you’ll do it wrong at first. You’ll do it wrong until you learn how to do it right. This is period of low morale for most people.

There’s a sense that despite all the effort being invested, very little progress is being made. Being told you’re making progress motivates you. Even if it’s only a matter of learning what doesn’t work, that’s still an important form of progress.

Reward All Successes.

We all like to know our efforts in any endeavor are being rewarded with progress towards a goal. During the first stages of change, when we are learning to do new things, there is very little progress. Watch someone learn a new system and you will see them make error after error after error. At the bottom of the learning curve, progress comes slowly. At the bottom of the learning curve we make very few correct choices and many errors.

Reward All Attempts… and Failures.

During change, management needs to change their behavior from rewarding only ‘success’ to rewarding all attempts at progress. People need to hear their attempts to learn the new way of doing things are seen and appreciated.

Reward All Questions

When people ask questions during change, they are demonstrating involvement in the change process by seeking out additional information. Take the time, make the time, to answer those questions, no matter how busy you are. It does not take many instances of management not being around to answer questions, for people to get the message that management does not really care about the successful implementation of the change. Even, if that was not the message you intended to communicate.

Acknowledge those who Resist!

Sometimes the question will be ‘Why is this change necessary?’ This is NOT an indication of a bad attitude, nor is it an indicator of someone who is out to scuttle the change. The question ‘Why is this change necessary?’ is a legitimate question, by someone who is protective of the status quo they’ve already invested in. Do not mistake natural, normal, healthy resistance, as a subversive attempt to destroy what you’re trying to accomplish. Sometimes, a question is just a question.

Don’t Ignore those in Denial.

Denial can be defined as ‘the continued use of solutions, once appropriate to the task, no longer useful due to the introduction of the foreign element.’ It takes time for people to change old habits. Punishing people, because they learned the old lessons well, is not exactly a compelling incentive for them to learn new ones.

Editor’s note: We will be showcasing each phase of Peter de Jager’s methodology in weekly posts. Click here for phase 1, phase 2, phase 3, phase 4, and phase 5.

Check back every week to read the next phase.