Author: Kupe Kupersmith

Why Bother with a Business Analysis Center of Excellence

Written by Kupe Kupersmith on November 29, 2011. Posted in Articles.

In our profession there is a lot of talk about companies implementing or wanting to implement a business analysis center of excellence (BA CoE). At the Building Business Capability (BBC) Conference this fall there was a panel of five people that have implemented one or more BA CoEs. The panelists spoke about their successes and challenges related to setting up their BA CoEs. It makes sense for there to be a panel about setting up BA CoEs. Many people are asking how they get their own BA CoE started. Before I continue I want to define how I am using BA CoE for this post. I realize there are many variations of BA CoEs. I also know there are groups referred to as a business analysis community of practice. For this post, I am using the term BA CoE very broadly. Any BA group coming together in some form or fashion to try and improve the BA practice at a company is how I am defining BA CoE.

When I am asked the question ‘how do I get my BA CoE started?’ I often respond, “I have no idea”. Another common question that yields the same response is ‘what should my BA CoE look like?’ I am being facetious, but it is hard to answer that question without knowing more. So I follow up with a line of questions. The questions I ask help me understand what problem or opportunity will be addressed with the BA CoE. Simply, some form of why.

What is important to realize is a BA CoE is a solution to meet a goal or objective. It is not the goal or objective. Don’t you go crazy when a business stakeholder just asks you to implement some solution?! It is time to practice what you preach. Without knowing what objectives you are trying to reach with a BA CoE how will you get funding to move forward. You need to treat the creation of a BA CoE like a project. After uncovering the objectives you may even realize a BA CoE is not needed.

The objectives need to address improving project successes, improving results for the business. Just improving your BA practice is not enough if project improvements are not realized. The same concept applies to any business analysis improvement initiative. If you are thinking about implementing a requirements management and/or definition tool or addressing development needs for the BA team first outline your objectives.

Have you lead the creation and/or maintenance of a BA CoE? If so, this is your time to help some BAs out. What was the opportunity or problem you were trying to address with your BA CoE? Please share your thoughts in the comments section.

All the best,

Kupe

Don’t forget to leave your comments below.

Why Business Analysis Processes are a Waste of Time

Written by Kupe Kupersmith on October 18, 2011. Posted in Articles. 1 Comment on Why Business Analysis Processes are a Waste of Time

I recently read a sales blog post, Why Sales Scripts are a Waste of Time, where the author talked about the need for sales professionals to adapt their approach based on the customer they are selling to and not follow a standard script or process they learned through sales training. Rather than follow a process step by step a sales professional should use the steps as a framework.

The same applies to the business analysis community and a business analysis process. There are techniques, skills, tasks and approaches you have at your disposal. It is the collection of those that will help you adapt your approach for each project. The projects our community works on are not to build widgets. The Ford Motor Company requires a consistent manufacturing process. Ford wants to make sure every Ford Fusion that is built looks and acts the same. They fine tune their manufacturing process and make sure it is as repeatable as possible. There are steps that are followed A to Z with no deviation to ensure consistency. Yes, different lines of a model include different steps, but you get the picture.

In manufacturing following a process step by step is a good thing. In our world this is not the case. Following an A to Z process for every project is a bad thing. Every project is different. Different people, different risks, different priorities, etc. You need to adapt your process to meet the needs of the project. With that said there are two must steps. One, plan your approach for the initiative and two, conduct a retrospective to learn and adapt for future initiatives. There should be a consistent start and a consistent end. Everything in between should be flexible.

At the beginning of a project or iteration you and the team need to plan the approach. The team needs to determine what steps you’ll take during the project. You as the expert need to provide your thoughts and advice for the analysis steps, but you should not determine your approach in a vacuum. Your team needs to buy-in to the approach and ensure their needs will be met to ensure a successful project.

Things never go perfectly, so you should be inspecting your approach as you go and make adjustments. At the end of a project or iteration you should inspect and learn to improve for your next initiative.

Let me end by stating I don’t think you should have to make everything up in between your plan and retrospective for every project. You should have a base approach that you use as a framework. Just use that as a starting point to add and/or remove steps to customize your approach for the specific project.

All the best,

Kupe

Don’t forget to leave your comments below.

The Business Analyst’s Citizen’s Arrest

Written by Kupe Kupersmith on October 4, 2011. Posted in Articles.

The other day I saw someone pull out in front a school bus. The school bus was filled with children and was right in front of the school. I was irate at the driver and said to myself, “I wish I was a police officer so I could pull that person over and hand them a ticket!” Later I thought about why I didn’t pull that person over or at least get the car’s license plate and call the police to report reckless driving. In the United States and other countries there is the concept or law around a citizen’s arrest. Anyone, regardless if they are law enforcement or not, can make an arrest. This sounds great on paper, but is not as easy as it sounds. How would I get this person pulled over? If I did get him to pull over, what would stop him from laughing in my face and driving off? I was already late for work and had a lot to do. A citizen’s arrest would just put me even further behind. No one was hurt by the reckless driving so it became very low priority for me.

I bet you this same questioning and doubt goes through your mind when you think a project is headed down the wrong path. “I’m just the business analyst, I can’t stop the project. Who is going to listen to me?” “I have three other projects…I don’t have time to talk with the PM or business stakeholder about this little enhancement project.”

It’s time for you to make a citizen’s arrest by waving the red flag or shouting from the hill tops. Anyone on the team or involved in the project has the power and authority to question the direction of the project if it is not aligned with the objectives it set out to tackle. As a business analysis professional you are in a perfect spot to recognize when and where a project is getting off the mark. Companies have limited resources and need to be as effective as possible with those resources. If a project is on its way to failure you need to stop it. Even if you do not have the authority to cancel or change the direction of a project, you need to provide the necessary information to the people with the authority to help them make an informed decision.

I know this is not as easy at it sounds. A student of mine reminded me of a tip she received from one of our instructor’s, Pam Swent. Pam gives the advice to use the phrase, “I’m concerned about…”, when sharing your thoughts about a project being off the mark. Starting the conversation off with that phrase puts people at ease. It reduces the risk of people getting defensive. It shows you care about the success of the project and company.

Don’t be like me allowing reckless driving to happen. Don’t sit there thinking you need to say something, but never do. You have the power to make things right. Go make it happen.

All the best,

Kupe

Don’t forget to leave your comments below!

Stop the Multitasking

Written by Kupe Kupersmith on September 13, 2011. Posted in Articles.

During a report on CNN a doctor talked about why innovation is happening at a faster rate on the battlefield then back here in the United States hospitals and doctor’s offices. He said the fact that on the battlefield the doctors and nurses have fewer distractions than the doctors and nurses here in the States. Because of the situation they are thinking about how to improve day and night. They have a single focus. The sad truth is they don’t have the distractions of family life and day to day activities outside their work.

This led me to think about multitasking and how this hurts our productivity and innovation. We have so many things we are trying to juggle we feel we have to do everything at once. This leads to us being less effective. Just in case you need more convincing, here is a great article I read some time ago about why multitasking is a bad and dangerous thing, How (and Why) to Stop Multitasking.

It seems to me our society views multitasking as a good thing, it’s all the rage, it’s the “in” thing. I hear managers say they need to hire people that can multitask. I hear people claim their multitasking skills are above the rest. Multitasking is like a badge of honor. I just did a keyword search on LinkedIn and over 14,000 people had the word “multitask” in their profile and over 22,000 had “multitasking”. There is even a company name that includes “multitask.”

When it comes down to it, you don’t multitask. You switch task. Every time you switch, you lose focus on the original task and it takes time to get back into that original task. Not only do you take more time, you don’t do the task as well as you could.

I see consultants that come in to work on a project are more effective. Is it because the consultant is a better business analyst (BA) than the employee BAs? In some cases yes. In most cases I think the reason relates to the fact that the consultant is working on “a” project. They don’t have to multitask anywhere near the amount of an employee of the company. They can have a single focus on the project they are working on. I recently spoke to a group of BAs and BA managers and some folks said they were working on 25 projects. Talk about distractions.

The view of needing multitaskers and having BAs on multiple projects will not change overnight. So, what you can control now is your work. There are two areas I think you should try to eliminate multitasking.

Don’t multitask when you are in a meeting. Many of you have multiple meetings in a day and it’s hard to resist thinking about the next meeting while you are in a meeting. Give your attention to the meeting you are in. Stay in the present. This really holds true if you are leading the meeting!
Try to schedule your work and meetings around a single project each day or 4 hr chunks. The analysis part of our work takes time. You need to think through the information you are receiving in meetings and discussions. You need to review your work to see where you have gaps. Giving yourself 30 minutes here and there is not ample time to do your best work.

I think we can all agree we’d like to be more productive and more innovative. Try stopping the “multitasking” and see how you start to improve.

Don’t forget to leave your comments below.

Enough Business Analysis Already

Written by Kupe Kupersmith on August 29, 2011. Posted in Articles.

The topic of the week for me has been knowing what is enough or the definition of done. I attended a presentation at an IIBA chapter meeting where we discussed the importance of having one view of done for a task or deliverable. On a LinkedIn group a question was asked related to techniques to help BAs determine when you have enough requirements. There is one technique used to determine when you have enough requirements. That technique is… talking.

I am a big believer in doing what is necessary for a project to be successful. Most people, I hope all, agree you don’t follow a process just to follow a process. You don’t complete an entire template because there is space to fill in. You document what is necessary and you follow process steps because they add value to the project.

This is where talking comes in. Determining when you have enough requirements is not the sole responsibility of the business analyst. The team needs to determine how much is needed to move to the next stage. Defining done or enough is in the eye of the receiver of the information, not the one eliciting and communicating the information.

There tends to be a belief that a senior BA should know when enough is enough. Without interaction from the receivers of the information any BA is just taking a guess. If a senior BA knows when enough is enough on their own, they are mind readers. A senior BA knows what enough is because they talk with the receivers of the information to make that determination.

It all comes back to determining what needs to be done in order to meet the goals of the project. Together the project team, which includes the business stakeholders, makes that determination. Once an initial determination is made there should be continual discussions or check-ins to ensure you have the right level. As the BA you need to adjust and adapt as necessary. Maybe stopping before you thought or continuing to elicit and analyze more than anticipated.

That’s enough about enough…this blog post is done!

Kupe

Don’t forget to leave your comments below.