Last week I posted Part 1 with discussion on what a business analyst is. You may be more confused than before on what it is you are. I will quickly clarify a few points by addressing a couple of common questions.
Question 1: I am a project manager that is responsible for business analysis on my project. Is this wrong?
Answer: It depends on the project and the situation. If it is a small project with a small team and you are familiar with the business then it may make sense. The test is if you are effectively and efficiently juggling managing the project (planning, tracking, risks, stakeholder management, etc.) with the business analysis tasks (eliciting requirements, creating models and documentation, working with stakeholder to prioritize, translating for the technical team, etc.). However, if you are not able to manage both roles effectively within a normal workweek it means you are working two full-times jobs, rather than two half-time jobs. Getting a BA on your project will allow you to focus on one job and lead the project, project team, and influence stakeholders much more easily.
Question 2: I have worn many hats on my projects. How do I know if I am a business analyst?
Answer: The answer lies in where you natural aptitude and desire are. Answer the three following three questions to help you find the answer. (Disclaimer: this is not a scientific aptitude/skills test)
1) When it comes to solving a problem, I tend to want…
- To lead a team discussion to find potential solutions
- Research what other companies have done and see if any of those solutions would work in our situation
- Put a likely solution into action
2) When I waiting for service in a long, slow line I tend to…
- Think, “Where is the manager?” These people need to be motivated to work faster.
- Watch the processes to see if I can identify a change in process or a tool that would speed up the service.
- Look for the manager so that I can tell him to bring more people on to serve
3) When told to do something that I do not quite understand I respond by…
- Clarify what is needed and begin a plan of action
- Question who, what, why, where until I understand the value or negotiate for a task that does make sense to me
- Do what I am told. I can make anything work and it’s not my job to question the reason
Here are the results to this three-question assessment. If you scored mostly
- You have an aptitude for project management. You prefer to lead others through proactive planning and motivation to allow a team to accomplish great things.
- You have an aptitude as a business analyst. You like to solve puzzles by taking the time to get a thorough understanding the core of the puzzle and analyze many solutions to know your recommendation is indeed the best.
- You are a doer. “Get ‘er done” is your motto. Time spent planning and analyzing is time that you could have been actively doing something to make the situation better. You recognize there may be a different or even better way, but getting something is place is the contribution that makes you feel valuable. You would be a great technical lead.
You may truly have a mix of aptitude and preference of these roles. That is okay. However, you need to define your role for each project and stick to it. This allows you to focus on your responsibility and give the autonomy to others on the team that they have earned and deserve.
Continue to Part 3 for steps on making the shift from someone who does business analysis tasks to a business analysis professional.
Image courtesy of chanpipat / FreeDigitalPhotos.net
As the Seattle Chapter President of the International Institute of Business Analysis (IIBA®), I often get questions about how someone can learn more about becoming a business analyst. Often times those asking have been doing business analysis work realizing it for some time; only they have not yet realized it. This three-part series is to help you understand what business analysis is (part 1), how to know if you are a business analyst at heart (part 2), and offer the first steps to advancing your career as a business analysis professional (part 3).
I will start with the definition of Business Analysis. The IIBA® defines this as
Business analysis is the set of tasks and techniques used to work as a liaison among stakeholders in order to understand the structure, policies, and operations of an organization, and to recommend solutions that enable to the organization to achieve its goals (Business Analysis Body of Knowledge [BABOK®] Guide, Version 2.0 Page 3)
The following two lists offer some more context to “tasks and techniques” by listing tools used and items developed and delivered by the business analyst as documented in the BABOK®.
- Document analysis
- Focus groups
- Interface analysis
- Requirements analysis
- Organization modeling
- Process modeling
- Business case/ statement of work
- Business analysis plan
- Communication to stakeholders
- Data dictionary or glossary
- Data Flow diagrams
- Metrics & Key Performance Indicators
- Scenarios/Use cases
- Sequence diagrams
- User stories
- Requirements package
These lists show that many roles do business analysis activities and deliver business analyst results. Some common project roles include data analyst, project manager, technical writer, and developer. Many people do “business analysis.” So what is a business analysis professional?
The project manager, developer, and data analyst may use some tools and deliver some of the same results as the BA as it relates to their specific role. A business analysis professional works with all the business analysis tools and techniques to deliver work that supports defining, managing, and evaluation the solution or resulting product (“to recommend solutions that enable to the organization to achieve its goals”.) The project manager, data analyst, technical writer, or developer rely on the work of the business analysis to provide clarity on the solution and allow project work to focus on steps needed to most efficiently deliver the desired result. The business analyst is responsible for defining is what will bring value to the business, ensuring the requirements are fully vetted and understood, and that the solution meets these expectations. This allows the project manager for focus on the project process, progress, team, risks, and all those other aspects that make project management a full-time job. Read more on this in The Project Manager vs. the Business Analyst. Further, the business analyst frees the technical people up to design and build the solution to meet the need the first time.
You likely play a combination of roles if you are reading this article. Next week we will discuss how to know what you are when you wear multiple hats.
Find out if you are a BA at heart in Part 2.
Image courtesy of chanpipat / FreeDigitalPhotos.net
The role of business analyst falls under many job descriptions. I talk to people all time that are business analysts, only they don’t know it. Maybe the have the job title of “technical writer” or “program manager”, but in reality, they are analyzing the business. Here are some signs you might be a business analyst..
- If you create a weighted score card with evaluation criteria to select your next new car…
- If you ask “why” so many times that your peers start to talk to you like a two-year old…
- If you spend your time in line (queue) thinking of five better ways to do business and speed things up…
- If it takes you longer to document your BA history for the CBAP then you actually do working…
- If your partner is upset with you on their birthday and you suggest celebration requirements were ambiguous…
- If you visit a brewery and document the brewing process on a napkin…
- If you make a process flow chart for your trip to the supermarket…
- If you write down the proposal discussion with your parents about girl you love on a Visio diagram…
- If very few people know what you do, but you could add value to any company on the planet…
- If while standing in a single line you count the people in front of you and divide by the number of cashiers serving customers to figure estimated waiting time..
Do you want to join in the conversation? Visit the Business Analysis Times LinkedIn group!
Last weekend I attended the Cirque Du Soleil show, Amaluna. While most of the audience was mesmerized by the beauty and awesomeness of the feats, I was mesmerized by the demonstration of what great teamwork can accomplish. Here is a quick run-down of my observations on the benefits of great teamwork.
Trust in Others
The troupe is truly putting their lives in each other’s hands. With high-flying acrobatics and water stunts, the impact of something going wrong can truly be life threatening. It takes a huge amount of confidence to entrust your life into your co-workers hands, but the results are astounding. When thinking of who needs to trust whom, it goes beyond other performers who are putting their safety at risk, but also the engineers and riggers.
What could you accomplish in your current project if you had that much faith and trust in your teammates? Would the project have better flow and less resistance? Do you give your teammates the trust they deserve? We are each experts in our own rights of our own domain. Trust in that and keep conversations on using the various areas of expertise to achieving the goals of the project. Identify underlying issues to deal with the root cause to address team members you believe not to be trustworthy.
Slips happen…recovery gracefully!
Don’t think for a second that every show goes off without a hitch. I saw a couple of “slips” (some obvious, others not) and am sure I missed many more. What keeps the show amazing is the graceful recovery. The most obvious slip I noticed, the performer just kept going and tried again. She succeeded and the audience was amazed. Other slips were covered by their team performers adjusting their movements to minimize the impact on the show, the performers, and keep the show entertaining for the crowd.
We often experience slips in projects. Maybe there is a slip in schedule, defects in code, or risks that turn into issues. It is okay. Our project plans help us decide the graceful recovery in advance. There may be an unforeseen issue that affects the project. The issue is what is it is. Focus on the graceful recovery in support of the project. Refer to point number one and trust that your teammates will contribute to the graceful recovery.
Here is a quick side note. The music in Amaluna was live. It would be very difficult to recovery gracefully if reliant on a soundtrack that prevented needed corrections.
Bad things happen when you are not trustworthy. A performer in Amaluna would not feel safe to give a 100% on feat where their safety was in my hands and I’m not trustworthy. I may lose opportunities to perform. The show would lose a great deal of awesomeness with the troupe not trusting in each other to give 100%. Signing up to perform a feat that one is not ready for, performing when physically compromised, or not being reliable in showing up for rehearsal could destroy valuable trust and compromise the show.
Are you trustworthy when it comes to your projects? Do you make meetings on time, participate fairly, complete assignments as agreed? Do you refrain from gossip, always give honest status on the project, and help your teammate recover from their slips? The person who can do this with integrity, consistently will be a very important contributor to the project. Only when all teammates, including yourself, are trustworthy will you have the level of trust needed to pull off amazing acts. It is the rare project that is delivered on time, on budget, and with promised scope that brings value to the business…a truly amazing feat.
Here is a short promo video of Amaluna to amaze you. A fourth secret follows.
A fourth observation? Yes, risk management. Telling you this is admitting to what a nerd I truly am. The video shows the scene with the contortionist in the water splashing all around. My mind realized that water on stage could be deadly to those that follow her act. Brilliant risk management is at work here.
- Large cloths blanked the stage around the bowl.
- After they moved the bowl and blankets, they had performers performing wiping the stage down with towels
- The next act was the high wire, not conducted directly on stage but the high wire with cushions below
- Then intermission
Four strategies to mitigate the risk of water on the stage endangering the performers.
Please share your stories and thoughts on what makes for amazing teamwork.Photo by Cirque du Soleil at http://www.cirquedusoleil.com/en/shows/amaluna/default.aspx
How often have you been called upon to remember past projects? Are you prepared to respond to “tell me about your favorite project and why it was your favorite”? If you are pursuing professional certification, a new job, or promotion, be ready for this question. If your brain is like mine, it is an overflowing file cabinet with some of the best material buried in the back corner. It is not always easy to access the things you have done in the past, especially when new projects are always sitting on the forefront of the mind. As a result, you will likely shortchange yourself by relying on the more accessible recent experiences that may be less relevant in the context of the position. Perhaps you come up short on needed hours experience for that professional certification because you had forgotten about that part time project you worked on when in a different position. There is a remedy for this. That is your Project Portfolio History.
I created my Project Portfolio History when applying from Professional Project Manager Certification from the Project Management Institute. It was a necessary step for completing the application, but I quickly saw a multitude of uses for this listing. The list includes:
- Project Title
- Start Month
- End Month
- Number of Months
- Project Description
Customize your Project Portfolio History to meet your specific needs. You may add a column for percentage of work time spent on the project, the project sponsor, team members, project methodology…whatever makes sense to you. This is your reference and a supplement to your resume, not a replacement. You may opt to share with recruiters in which case it might make sense to keep a “private” version in addition to the “public” version with the private including key words or signals that you want to remember without sharing. My private version has notes to remind me of my favorite projects, least favorite projects, projects where I learned the most, and many of those other common asks when discussing your project past.
The project description should help describe each project and what made each unique. What technologies and methodologies where used? What was the team structure? Who were the users of the solution and how the accessed it? You do not need to answer each of these questions – rather you are looking for what about this project sets it apart from others.
This document has helped me in describing experience in resumes, cover letters, and in interviews, as well as document hours for both the PMP and the Certified Business Analyst Professional (CBAP®) certification. I use it when customizing my resume to the job I am submitting for, developing my cover letter, review prior to an interview for a fresh look, and I even request to keep the document out and handy during an interview. I have yet to be refused to have my “cheat sheet” handy. Recruiters and interviewers have requested a copy. Remember to have a public version available. One recruiter I worked with said, “This is great! Every project professional should have this.” Start putting your together today. I have linked a Project Portfolio History template so you can get started on yours today. Start with your current project and work backwards. You can always add rows to fill in gaps if you miss something along the way.
Please share your experiences with this or a similar document by commenting on this post.
I had the great honor of being interviewed by Samad Aidane for Guerilla Project Manager. Catch the interview on-line at http://www.guerrillaprojectmanagement.com/care-feeding-of-business-analysts.
I am thrilled to announce ModernAnalyst has published my article on Achieving Business Value – check it out and pass it on. I look forward to your comments on the ModernAnalyst site or here.
Business value is a new indicator for project success. Huh? You may be wondering what ever happened to the good ole scope, schedule, and budget. They are still there and measured, but what the 2012 trends have been pointing to is that a project completed within scope, schedule, and budget and not be successful. The opposite is also true. Read complete article
I just ran across this excellent supporting video on Twitter.
I have a new appreciation for a specific project need after teaching a Mastering Requirements course earlier this week. I had asked the participants to come up with examples of goals or requirements for a situational software product. However, I did not offer them the two most important pieces of information, the project vision and objectives. It was an oversight on my part. I erroneously thought that they would automatically have the same vision as I if I provided a clear project title such as Classes Registration System. Two things happened.
They had a hard time getting started on who the users and their goals would be for the system. There wasn’t a clear place to start without knowing whose problem they were trying to solve or what the objectives of the project were. Instead they would tentatively put an idea out and look for clues that they were on the right track. The ideas were rolling once I said “the project is…” and “the objectives are …” You could see the light bulb turn on, “oh, so that’s what we’re doing.”
Another exercise was to take a stakeholder statement “I want full details on students” and interview me to get to the real need. I inadvertently tripled the size of the project by adding requirements related to a Customer Relations Management (CRM) system. Lucky for all of us, one clever participant spoke up, “I thought this was a class registration system. It sounds like you want a CRM solution for marketing.” Oops…busted! Yes, I was the scope creep.
It is much easier to call “creep” on an instructor in a classroom setting then it is an executive manager within your organization. You are likely to run into “just do it” even if you do say something. Your best defense…a clear, documented vision and objectives for the project to serve as a guide and negotiation tool.
Vision – a description of how the world looks after project implementation.
Students will be able to sign up for designated classes and the organization will have a record of who has attended what classes.
Objectives – expected measurable results from project implementation.
- Reduce overall staff time required per student registration by 75%
- Time to complete inquiry of student participation is not more than 10 minutes (from opened to responded)
Responding to ideas outside of the vision and objectives become much easier with this context. Now the BA can respond with “how will that help us meet the objectives of the project?” when the business owner says “I want the student’s home address so that I can send a Christmas card”. While having other features may be nice and add value, it clearly does not fit into the intent of the funded, schedule project. Scope creep diverted – schedule and budget saved.
How many “quick, little projects” have you worked on where the vision and objectives were assumed rather than documented? I’ll admit it, I’ve seen a few. It won’t happen on my projects, or in my class, after seeing the difference that simply documenting and agreeing to these makes. That doesn’t mean I won’t try to trick students so that we can practice scope negotiation in the future.
More information on this class is available at http://project-pro.us/2012/04/17/master-requirements/. Contact me to bring this class to your area.
I have a hard time deciding whether “versus” is a good word to compare the two roles. On one hand, the project manager and business analyst should be working collaboratively. On the other hand, the two roles do offer a healthy contest in project related decisions. The issue at hand is that there is a lot of uncertainty about the difference in these roles. The result of this uncertainty is cases where one person plays both roles without enough skills for each, and other cases where the team members do not know who is responsible for what. Hopefully, we can clear this up.
The core of the difference is in the title.
- The Project Manager manages the project – “The application of knowledge, skills, tools, and techniques to provide activities to meet the project requirements.”
- The Business Analyst conducts business analysis – “The set of tasks and techniques used to work as a liaison among stakeholders to understand the structure, policies, and operations of an organization, and to recommend solutions that enable the organization to meet its goals.
One source of confusion is the activities in both sets of tasks according to the relevant Body of Knowledge[i]. The intent is that planning and monitoring tasks within the BABOK® are limited to business analysis activities as indicated by the task title.
|PMBOK® Task||BABOK® Task|
* Thank you to Elizabeth Larson for review and advice to the PMBOK® / BABOK® process mapping.
Stakeholder analysis is one good example of collaboration between project manager and business analyst. The business analyst focuses on stakeholders specific to the requirements and scope of the project. The project manager is looking beyond this to stakeholders whose interest is outside of the project scope. Perhaps the project manager is recording a competitor as a stakeholder to aid in the identification and tracking of potential project risk. The stakeholder analysis is a joint effort. Assign items resulting from the stakeholder analysis to either the project manager or business analyst based on stakeholder interest and influence.
Another point of confusion is in the PMBOK® task of Collecting Requirements. It looks as though the project manager is responsible for collecting requirements. When you look further at the PMBOK® tasks you also find Perform Quality Control, yet we know the project team has members responsible for product quality. The intent of the PMBOK© is that project managers take responsibility to ensure activities for collecting requirements are covered in the project management plan and monitored along with the project. Not the project manager collects the requirements.
Section 5.1 of the CBAP® Handbook does a great job of differentiating “analysis” activities from other activities. Download the CBAP ® handbook from the Certified Business Analysis Professional™ (CBAP®) website for detailed examples of these activities.
Volunteers from both the International Institute of Business Analysis (IIBA®) and Project Management Institute (PMI©) joined in a collaborative project to “facilitate a shared understanding of the roles.” You can read more on this effort and results at http://pmchat.net/2012/06/the-bapm-partnership/. The conclusion –
Both the PM and BA play leadership roles—the PM for leading the team and delivering the solution and the BA for ensuring that the solution meets the business need and aligns with business and project objectives. And both roles, equally, are required for project success.
You will get decisions based on full information of the impacts to the project and the benefit of the solution when you have both a strong PM and BA playing leadership roles on your projects. The result is a project that brings greatest business value to the organization.
I had the distinct pleasure of joining Elizabeth Larson, PMP, CBAP, CSM, as guest experts on PMChat (a weekly Internet radio show/Twitter web chat) to discuss the BA and PM roles on June 1, 2012. Listen here to catch our interview hosted by Robert Kelly and Rob Prinzo for more on this subject.
[i] Project Management Body of Knowledge (PMBOK® Guide) 4th Edition
A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide) Version 2.0
- The BA/PM Partnership: An IIBA/PMI Joint Collaboration
- Certified Business Analysis Professional™ (CBAP®) website / handbook
- #PMChat – Project Manager vs. Business Analyst
- Mindavation Podcast: In My Judgment, the BA Reports to Who? (2:30 minutes)