Skip to main content

An Examination of BA and PM Skills Profiles

Written by Cynthia Low on . Posted in Articles. 1 Comment on An Examination of BA and PM Skills Profiles

In the previous article I set the stage for additional comments on the inevitability of the morphing of the business analyst (BA) and project manager (PM) into a single professional that I labeled the “BA/PM” for lack of an appropriate position title. Requirements gathering and management was the thread in that article that inextricably links the BA and the PM in the Agile Project World.

In this article I want to look under the hood of this new professional that I am calling a BA/PM. Using the PMI PMBOK and the IIBA BABOK I will list the skill and knowledge profiles of the BA and the PM. A comparison of those two profiles will show remarkable similarity between the two. This should come as no surprise to anyone and will further support the creation of the BA/PM professional, at least in the agile project space if not the entire project space.

My hope is that I will have captured your interest and attention enough for you to share your thoughts and ideas whether you agree with me or not. I welcome opposing positions and the opportunity to engage in public discussions.

BA and PM Skills and Competencies

The following table presents a high-level comparison of the skills and knowledge of the BA and the PM as derived from the BABOK and the PMBOK.

skillschart.png

Is it any surprise that the two lists are nearly similar? From the perspective of the BA all of their work is done as part of a project and so they must have all the skills of a PM to match the complexity of the projects they manage. From the perspective of the PM, not all of their projects will have a BA component but they must have at least a working knowledge of the BA skills.

Assessing Proficiency Levels

Once a BA/PM position family is in place, the BABOK and PMBOK columns will be replaced with the position family,  and the column check marks will be replaced by the minimum proficiency levels as defined by Bloom’s Taxonomy, which is shown below:

Level 0:          I never heard of it.

Level 1:          I can define it.
1           Familiar with the terminology
2          Understands the basic concepts

Level 2:          I understand what it can do.
1                    Knows how it is used
2                    Can explain key issues and benefits
3                    Understands organizational relevance

Level 3:          I have limited hands-on experience.
4                    Has a working knowledge of basic features and functions
5                    Aware of relevant standards, policies and practices
6                    Requires assistance and supervision
7                    Can apply it in a limited (homogeneous) environment

Level 4:          I have extensive hands-on experience.
8                    Knowledge of operational issues and considerations
9                    Understanding of benefits and drawbacks
10                Working knowledge of relationships and integration
11                In-depth knowledge of major features, functions and facilities
12                Awareness of usage in other environments
13                Can work without assistance or supervision

Level 5:          I can adapt it to a variety of situations.
14                Theoretical background and understanding
15                Expertise in all major features, functions and facilities
16                Experience in multiple environments (heterogeneous)
17                Knowledge of and contribution to “best practices”
18                Ability to consult and coach others

Level 6:          I am recognized as an expert by my peers.
19                Extensive experience in multiple/complex environments
20                Industry and marketplace perspective
21                Historical and future perspective
22                Influencing wide or high-impact decisions and initiatives
23                Leadership on architecture, policies, strategy and “best practices” 

In order to be proficient at say, level 4, there must be visible evidence that the 10th through 15th behavioral characteristics are present in the person’s work habits. Neither the BABOK nor the PMBOK offer enough detail to assign a minimum proficiency level to each skill. Until there is a standard BA/PM position family, the need for a skill is just noted without a proficiency level assigned. In constructing this table, I started with the PM skills profile I developed, beginning with PMBOK and factoring in client contact for the past 20 years, and supplemented it with added skills and knowledge as noted in BABOK.

Professional Development of the BA/PM

With the need for the BA/PM professional firmly established let’s take a quick look at the BA/PM professional development program. The first piece of this puzzle is to define the BA/PM position family. Neither BABOK nor PMBOK has anything to contribute to defining the BA or PM position family. Here is my first take on that definition.

  • BA/PM Team Member
  • BA/PM Task Manager
  • BA/PM Associate Manager
  • BA/PM Senior Manager
  • BA/PM Program Manager
  • BA/PM Director

I intend to define these more precisely in a subsequent article and to suggest a professional development program structure for consideration.

Putting It All Together

I would certainly like to hear your thoughts on the BA/PM professional. I’m sure we could have a lively discussion. I promise to respond personally to every email and to incorporate your thoughts in succeeding articles.

Robert K. Wysocki, Ph.D., has over 40 years experience as a project management consultant and trainer, information systems manager, systems and management consultant, author, training developer and provider. He has written fourteen books on project management and information systems management. One of his books, Effective Project Management: Traditional, Adaptive, Extreme,3rd Edition, has been a best seller and is recommended by the Project Management Institute for the library of every project manager. He has over 30 publications in professional and trade journals and has made more than 100 presentations at professional and trade conferences and meetings. He has developed more than 20 project management courses and trained over 10,000 project managers.

Getting Back To Basics: Third Fundamental – Identifying Your Sources

Written by Cynthia Low on . Posted in Articles.

In April, I began a series of articles devoted to helping professionals wade through the sea of available business analysis information currently flooding the marketplace and focus on just the essentials. I like to think of it as Business Analysis Unplugged, my own personal back-to-the-basics world tour. 

April’s article discussed the importance of understanding your organization’s overall business goals, and May’s piece covered how to create a common vocabulary among your project team. This month, for my third in the five-article series, I’d like to discuss something that can often get overlooked in the business analysis process: properly identifying the sources from which you will eventually extract your requirements.

Labeling
When we’re kids, we’re told that labeling people is bad. Well, this is good advice in life, but not necessarily in business analysis. The fact is, properly identifying and affixing your sources to specific categories is essential for planning and successfully extracting requirements. Although there are none that are set in stone, three common categories that I’ve used to label sources on past projects include: Customers, Users and Additional Materials and Experts. In this example, all of your sources would fit into one or more of these three buckets:

Customers
A customer is the person or group, internal or external to your organization, likely to pay for the products and services produced. This category can be further refined to include subcategories such as sponsors and champions, or domestic and international customers. The further you’re able to refine your categories, the better.

Users
A user is the person or group who is ultimately responsible for interacting with the products or services produced. Like customers, there’s definitely room for further refinement here. For example, direct users may touch and manipulate the system on a daily basis, while indirect users may simply request monthly or quarterly reports. Both groups will yield distinctly different requirements.

Additional Materials and Experts
This category is more than just a fancy name for Other. It could include additional individuals or groups with influence on the project, such as third-party vendors and subject-matter experts. It’s also important to note that your sources don’t necessarily even have to be humans. And no, I’m not talking about robots-at least not yet. There are many non-human sources that would fit into this category that you can leverage when extracting requirements. These could include existing systems, both hardware and software, or existing documentation, such as governance documents, previously captured business architectures, training manuals and service agreements. 

A One- or Two-Person Job
In my last article, I encouraged group thinking for the development of a project’s glossary of terms. For labeling and categorizing your sources, I recommend essentially the exact opposite strategy. Like building a glossary, categorizing sources is busy work, but it’s busy work that should be taken on by as few people as possible; I’d recommend just the business analyst and, if he or she is feeling collaborative, the project manager. Too many opinions too early can lead to roadblocks of disagreement and the always dreaded analysis paralysis. 

Within the categories, the business analysts should also identify each source’s role and then the benefits that each source will realize from the completed products or services. The phrase “no stone shall go unturned” applies well here, because eventually everyone on your list-from the daily direct users to the software developer at your partner company to the CEO of your organization-will be affected by what you’re creating. So, start with the big picture, and then become as specific as you can. Inevitably, you’ll find that some of your sources fall into more than one category. This is not a problem, and is to be expected.

Once you’ve created your detailed list of categorized sources, you should share that list with the team for feedback

Is It Worth It?
In our need-it-yesterday business culture, your temptation may be to just start calling and e-mailing your sources and asking them questions about their requirements. But remember, business analysis is about planning, preparation and clarity. By going through the process of labeling and categorizing your sources, you and the project manager will begin to get a clear picture of the scope of your project and the amount of time, money and effort that will be required for successfully eliciting requirements. You’ll also be able to identify the risks involved.  For example, if you find that 60 percent of your sources are located in another country and many of them don’t speak your language, well, you’re going to have some extra work to do.  It’s best to realize that from the beginning as opposed to three months in.

Next Month-Choosing the Best Elicitation Techniques
How’s this for a cliffhanger? Labeling and categorizing your sources is also essential for helping you identify the best techniques to use for requirements elicitation. Of course, this just so happens to be the topic for the next article in this series, which will appear here next month. Until then, remember, the more specific you are in your labeling and categorizing, the more valuable the information you’ll have at your disposal later. 

Glenn R. Brûlé has more than 18 years experience in many facets of business, including project management, business analysis, software design and facilitation. At ESI, he is responsible for supporting a global team of business consultants working with Fortune 1000 organizations. As the Director at Large for the International Institute of Business Analysis (IIBA), Brûlé’s primary responsibility is to form local chapters of the IIBA around the world by working with volunteers from organizations across various industries, including financial services, manufacturing, pharmaceutical, insurance and automotive, as well as government agencies.

Does the BA Role Belong in IT or the Business?

Written by Terry Longo on . Posted in Articles.

The question of whether the BA role should be defined with IT or within the business is one of those ongoing questions of organizational structure. As we progress in professionalizing the role of the BA, we will need to hammer out a useful response that accounts for the pros and cons of each.

Are you a BA in IT or in a business unit or function? What do you see as the pros and cons of each? Where do you think a BA should be in the overall organizational structure, and why?

It seems to me that more and more people are landing on the side of the BA role being defined and “hosted” within the business. If that overall paradigm is inevitable, what can we, as a community of practice, do to ensure that we preserve the advantages of the BA-in-IT paradigm?

Behind this question are various complexities related to change management, relationship management, solution scope, risk management, and other elements that can make or break a business case.

I hope you can take a minute to comment on your situation, what you’ve learned based where you are in your organization, and what you believe to be a sound direction for the BA profession.

Effective Requirements Gathering and Management Need the Skills of Both the BA and the PM

Written by Cynthia Low on . Posted in Articles. 1 Comment on Effective Requirements Gathering and Management Need the Skills of Both the BA and the PM

In my previous article, Is it Time for the BA and the PM to Get Hitched? I set the stage for additional comments on the inevitability of the morphing of the business analyst (BA) and project manager (PM) into a single professional that I labeled the BA/PM for lack of an appropriate title. Along with that I promoted the idea of a World Class Business Project, Program, Portfolio and Process Office or BP4O, for short, to support this new professional.

In this article I would like to discuss requirements gathering and management. I believe it is the area of greatest overlap between the BA and the PM. Both the PM and the BA face the same challenges here. Even under the best of circumstances, it is very difficult if not impossible to identify and document complete requirements during the Initiation Phase of the project. The reasons are many and well known to both professional groups. There are at least a dozen approaches you might use for requirements gathering and it is not my intention here to present a tutorial on their use. Rather my focus will be on the need for a more collaborative effort between the BA and the PM in the process of effectively managing those requirements throughout the entire project life cycle. I have defined the Requirements Breakdown Structure (RBS) as an artifact in the Initiation Phase of the project. It is the infrastructure that supports requirements management throughout the project life cycle, the choice of a life cycle model and the choice of best fit project management tools, templates and processes.

Requirements Breakdown Structure

The RBS is a hierarchical description of the client’s needs. There are at most four levels of decomposition in the RBS:

Level 1: Client statement of a requirement
Level 2: Major functions needed to meet the requirement
Level 3: Sub-functions (for larger more complex functions)
Level 4: Feature(s) of the functions or sub-functions

The RBS defines what is to be done and can be thought of as a deliverables-based WBS which defines what will be done. Further decomposition of the RBS produces a deliverables-based Work Breakdown Structure (WBS), which defines not only what must be done but how it will be done. There is, however, a fundamental difference between the two. The RBS may not be a complete decomposition of what will be done whereas the WBS must be complete in order for the traditional linear approaches to project management to be appropriate. There is an obvious disconnect here. The temptation is to speculate on the future to fill in the gaps in the RBS. If you take this approach, you are planting the seeds for failure.

It is this lack of completeness that drives the choice of Systems Development Life Cycle (SDLC) and the supporting Project Management Life Cycle (PMLC) tools, templates and processes. The two life cycles are inextricably linked. Any project that produces an incomplete RBS at the outset must use some type of agile approach to managing the project. In these situations the obvious conclusion is that the professional who manages requirements gathering and management over the life of the project must be expert at both business analysis and project management. The learning and discovery of heretofore unidentified requirements occurs in the iterations that make up an agile approach. In other words, requirements discovery takes place throughout the entire project life cycle and is fully integrated into management of the project. This is not a situation where a hand-off from a BA to a PM will work. The complexity and uncertainty of the solution and the processes for its discovery negates that approach. A BA/PM is needed for maximum impact.

Project Landscape

At the risk of over-simplifying a complex and uncertain project environment, consider Figure 1. It is one way to envision the project landscape. Two variables define this landscape: the goal and the solution requirements.

EffectiveRequirements1.png
Figure 1: The Project Landscape

Each can take on one of two values: Clear or Unclear. Traditional Project Management (TPM) approaches are used in situations where both the goal and solution are clear. These projects should use life cycles that are Linear or Incremental. TPM Projects, because of the clarity of goal and solution identification, can effectively use a BA and a PM with the requirements hand-off fairly straightforward. Agile Project Management (APM) approaches are used in situations where the goal is clear but the solution is not. These projects should use life cycles that are Iterative or Adaptive. And finally, Extreme Project Management (xPM) approaches are used in situations where the goal and solution are unclear and should use life cycles that are Extreme.

As I travel around the planet speaking to BAs and PMs at conferences and workshops, I always ask my audience what percentage of their projects fall in each of the TPM, APM and xPM quadrants. I’ve asked that question to over 5,000 BAs and PMs in the US, Canada, England, Germany, Switzerland, Czechoslovakia, China and India. The results are remarkably consistent:

  • Linear or Incremental 20% 
  • Iterative or Adaptive 70% 
  • Extreme 10%

I suspect that a major contributor to project failure is the force fitting of a Linear or Incremental approach when an Iterative, Adaptive or Extreme approach should have been used. The fourth quadrant where the goal is unclear but the solution is clear is not a viable choice. That is not unlike a solution out looking for a problem. Maybe you know of some consulting firms that act like that. I sure do.

I’ve made my point. We say that every project is unique: That it has never happened before and will never happen again under the same set of circumstances. It would be naïve to think that one project management approach would work for every project. We have already noted how goal and solution clarity and completeness of requirements drive the choice of development model and project management approach, but there are several other project characteristics that should be considered. I have had occasion to consider risk, cost, duration, complexity, market stability, business value, technology used, business climate, degree to which you expect to have meaningful customer involvement, number of departments affected, the organization’s environment and team skills/competencies.

Putting It All Together

I believe in and have always presented a one-stop-shopping experience to my clients. It is critical to project success that a strong sense of teamwork be created between the client and their team and the project manager and her team. The BA/PM professional is better equipped to do that than if a BA and PM were separately involved. The BA, PM and client structure requires three communication links, all working in harmony, while the BA/PM requires only one. With people-to-people communication being the major reason for project failure, we need to give serious thought to creating the BA/PM professional for those APM and xPM Projects. There is much to discuss about the preparation and development of the BA/PM and I hope to present that information in subsequent articles.

The first article in this series drew a large response, and I would certainly like to hear your further thoughts on the BA/PM professional. I’m sure we could have a lively discussion. I promise to respond personally to every email and to incorporate your thoughts in succeeding articles.

Robert K. Wysocki, Ph.D., has over 40 years experience as a project management consultant and trainer, information systems manager, systems and management consultant, author, training developer and provider. He has written fourteen books on project management and information systems management. One of his books, Effective Project Management: Traditional, Adaptive, Extreme,3rd Edition, has been a best seller and is recommended by the Project Management Institute for the library of every project manager. He has over 30 publications in professional and trade journals and has made more than 100 presentations at professional and trade conferences and meetings. He has developed more than 20 project management courses and trained over 10,000 project managers.

 

ITSM Work Sessions: Lessons Learned

Written by Richard Lannon on . Posted in Articles.

Over the last few years I have facilitated several Information Technology Service Management (ITSM) work sessions within the oil and gas and utility industries. The challenge was to build consensus through identifying what is important, making recommendations and decisions, and establish direction that would enable the IT organization to improve processes and services offered to their customers. This article briefly outlines a number of lessons learned that came from our experiences.

An ITSM Work Session should provide the foundation for your organization to create the blueprint to propel IT services and business value forward. In establishing an ITSM initiative the following key groups must be involved:

Strategic: CIO and Directors to establish strategic intent, vision and enterprise objectives

Tactical: Directors and Managers to establish improvement objectives, priorities and program charter

Operational: Managers and Key Stake-holders to establish solution, roadmap, business case and project charters.

Fundamental to any ITSM session, when engaging these groups, is to develop a clear problem definition, defined and approved by the executives or senior steering committee. This is an area in which IT often falls short. The lack of a clear problem definition negatively impacts the tactical and operational levels of the organization, and limits the ability to move forward.

When working with your teams, build an understanding of all the work that is taking place in the IT department right now, and how it fits within the ITSM support and delivery relationship models. Discussion, training and clarity will be required to ensure your people understand the ITSM relationship and delivery model. By engaging people in a defined work exercise, your teams can map out and see how their work aligns with your ITSM program requirements. This is effective in establishing leadership and team buy-in.

Establish a clear understanding of your points of pain (PoPs) and the IT maturity. PoPs can be established through focused brainstorming sessions. Once collected, your PoPs should be looked at from an organizational and process maturity perspective. This is often missed, as IT has a habit of looking only at processes and tools to solve problems. Align your PoPs with the industry maturity model standards (non-existence, chaos, reactive, proactive, service, value). It is important that the content be translated into a service management maturity grid and aligned with the Information Technology Infrastructure Library (ITIL) process categories. Work to obtain various IT teams, customers and business representatives’ perspective on the ITSM organizational and process maturity levels. This builds some reality into the PoPs and maturity levels thinking by dislodging IT from a position of working in isolation.

Build a business case and program plan that can be activated by your people. At this point you are seeking clear recommendations and improvement objectives (what), benefit realization (why), tactical needs (how) and time frame (when) for which to move your organization forward with your ITSM program. This is the foundation for your ITSM program business case and charter that will be divided into project and operational requirements. You will need a solid approved business case and charter to enable you to navigate the challenges that will unfold on your journey and to clearly articulate the streams of work to be completed. There needs to be an executive team or steering committee assigned to provide clear strategic guidance. When forming and using a steering committee, their mandate must be strategic and clear. Tactical, task-based reporting can be left to the project management teams and their need for task-based results and status meetings.

Recognize that ITSM is not an IT tool solution. From a business perspective, IT needs to stop chasing tool solutions, and “flavor-of-the-month quick fixes.” Ultimately, the ITSM program is a business organizational change program that seeks to align IT with the business objectives and requirements, improve processes and change culture in an effort to control or decrease costs, increase productivity and contribute to the bottom-line. ITSM programs need to be effectively operationalized. Therefore change management and communication must be at the forefront.

Work with your teams to have them answer “WIIFM” and “WIIFT” questions (what is in it for me and what is in it for them). Ensure you established the fears, uncertainties and doubts (FUDs). Be prepared to have a long FUDs list. These will need to be acknowledged and managed within the context of the ITSM program and the change management and communications plan. Use your teams and people to establish a communication plan that takes into consideration your target audience and communication needs. Every organization has an approach to communications that may or may not align with their corporate culture. Prepare a clear communications strategy and follow it.

The information in this article is based on feedback obtained during facilitated ITSM work sessions and the work of dedicated IT professionals. Efforts focused on consideration for the strategic, tactical and operational requirements. Ultimately the goal was to improve IT. It can be done. Good luck.

Richard Lannon and BraveWorld Inc. ©2007

Richard Lannon is an international business and technology industry veteran turned corporate speaker, facilitator, trainer and advisor. He specializes in aligning the enterprise and technical skills to common business objectives. Richard helps organizations and professionals identify what’s important, establish direction and build skills that positively impact their bottom line. He provides the blueprint for your organization to be SET (Structured, Engaged and Trained). His clients call him the SETability Expert. He can be reached at [email protected] or 403-630-2808.