Skip to main content

Author: Cynthia Low

Getting Back to Basics: Fourth Fundamental – Choosing Elicitation Techniques

Written by Cynthia Low on . Posted in Articles.

Since April, I’ve been writing a series of articles for this website about the basic competencies of business analysis. I’ve been doing this for a couple of reasons. First, I enjoy staring at my computer for hours on end and thinking about grammar. Secondly, and more importantly, the enormous influx of available information over the last several years has caused many business analysts to lose track of the core, basic principles of this vital discipline.

So far, I’ve written three articles, which have covered understanding your organization’s overall goals, creating a common vocabulary among your team and identifying the sources from which you’ll extract requirements. For my fourth article, I’ll be covering elicitation techniques.

A Pre-Elicitation Meeting
In articles like this, writers often make things seem easier than they actually are. Therefore, let me caution that there are a number of complications inherent to elicitation. For starters, your customers and stakeholders, with all due respect, likely won’t understand the process that you’re taking them through. Furthermore, because each stakeholder is most interested in his or her individual needs, that individual will be less conscious of the many interdependencies that exist between requirements. To combat this, it’s a good idea to look back at the stakeholder categories you’ve developed (see the third article in this series), sit down with the groups-either virtually or in real life-and walk them through your goals and expectations regarding elicitation. This is an excellent time to establish individual roles and to let them know that you’ll be coming back to them soon, when it’s time to talk validation.

Four Elicitation Opportunities
I recently saw an infomercial for a machine that sorts change.  Simply dump your bucket of mixed-up coins in and it organizes them all into neat, coherent little piles.  I immediately thought of business analysis-particularly requirements elicitation.

Say a client comes to you and says, “Let’s build a rocket!” Immediately after determining that this client is sane, you’d find yourself with a big bucket of mixed-up questions and ideas. What color will the rocket be? Where is a good place to buy rocket fuel? How far into space should the rocket go? Do rocket scientists get paid by the hour? As a business analyst, it’s your job to use the practices we’ve already discussed and requirements elicitation to sort all of those random questions and ideas into neat little piles of requirements that can be used to meet your ultimate goal. Here are four opportunities for elicitation and a look at some of the techniques to consider for each:

1. Enterprise Analysis
Enterprise analysis can help you develop a vision for your potential product or solution. Staying with our rocket-building theme, it’s where you’ll begin to get a sense of what your rocket is going to need to be able to do. Two useful techniques at this stage are brainstorming and surveys. When dealing with a group of experts, brainstorming sessions are effective because the group will have an inherent understanding of logistics and the reality of the situation. Conversely, if you’re dealing with a group of, say, non-rocket scientists, consider conducting surveys. This will help to limit tangents and hone ideas based on the questions you choose to include.

2. Requirements Definition
When defining your requirements, consider joint application design (JAD) sessions. Like brainstorming sessions, JADs work best when dealing with a group of stakeholders who have a high level of subject matter expertise. However, unlike brainstorming sessions, they may run for days at a time and follow very specific agendas. A detailed agenda lets you ensure that all uncertainties are unearthed and that no miscommunications occur.

3. Requirements Analysis and Documentation
Here, as you begin to go deeper into determining the needs and conditions required to build your rocket, analysis becomes vital-as in gap analysis, root-cause analysis and force-field analysis. Gap analysis enables you to identify the “gap” between where you are and where you want to be. Root-cause analysis, which is perfect for the neurotic among us, considers all of our problems and identifies the “root causes” of those problems. And, force-field analysis, which derives from the social sciences, identifies the “forces” that influence progress toward a goal-both positive and negative.

4. Solution Assessment and Validation
With your solution and its requirements in sight, it’s essential to circle back to your stakeholders for validation. As obvious as this may sound, startlingly often, business analysts fail to ensure the validity of the requirements that they’ve elicited. Multi-voting and prototyping will help you build consensus and demonstrate how your solution will materialize, going forward. Criteria-based grids and impact/effort grids are effective, too, as they weigh requirements against formal criteria and rank them in terms of importance and feasibility. 

Next Time – Choosing the Best Modeling Technique
Tune in next month for article number five of five. In this, the exciting series finale, we’ll bring all of the back-to-basics practices together and close out with a discussion of modeling techniques.

Glenn R. Brûlé, Director of Client Solutions at ESI, 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. These engagements focus on understanding, diagnosing and providing workable business solutions to complex problems across various industries. Glenn was formerly a Director at Large for the International Institute of Business Analysis (IIBA) where he was responsible for forming local chapters of the IIBA around the world.

A First Look under the Hood of the BA/PM Position Family

Written by Cynthia Low on . Posted in Articles.

In the previous article I defined the BA/PM Landscape. That set forth the high-level model of the six positions in the BA/PM Position Family. In this article I’ll set forth the high-level definition of each of those six positions. This will lay a foundation for a more detailed definition of the six positions, a discussion of the skills profile of all six positions and then the details of a BA/PM Professional Development Program. As was the case with the previous article this is my opinion and has not been discussed with any of my business analyst or project manager colleagues.

The responses to the first four articles have been overwhelming. They have been both positive and negative. Being a change management advocate I am pleased with your reactions. My hope is that we can continue the exchange. As always, I welcome opposing positions and the opportunity to engage in public discussions. Your substantive comments are valuable. Criticism is fine and is expected but in the spirit of agile project management so are suggestions for improvement.

I realize that I have taken a controversial position and I do so intentionally. At least I have your attention whether you agree with my position or not.

Professional Development of the BA/PM

In the previous article I offered a first pass at defining the BA/PM position family. Figure1, below, displays the career path for the BA/PM generic position titles. At the Staff Level there are two positions: Team Member followed by Task Manager. Once the staff person has acquired the experience and skills that qualifies them as a professional, they move into the Professional Level as an Associate Manager followed by Senior Manager. At this point there are two separate paths to the Executive Level. The Program Manager position is much like a consultant to the Professional Level positions. The Director position is a people management position. This is a look from a different perspective at the information that was presented in Figure1 of the previous article. With the career path defined, it makes sense to now define the positions themselves.

UnderHood1.png

Figure 1: The BA/PM Position Family

Position Descriptions

First let me clarify my use of the word project. I use it in a very general sense. It refers to business analysis efforts as well as projects not encompassing business analysis activities. At this level the position descriptions need to simultaneously embrace both the project manager and the business analyst. That has put some strain on the choice of language and I beg your patience with that. In time and with the help of BA Times and Project Times readers and others we will converge on the solution.  

Team Member

This is an entry level position into either a project management or business analysis effort.

Key Indicators

  • Relevant two or four year specialized education at entry.
  • May have relevant but limited part time, cooperative education or internship experience. 
  • May have previous experience in a trainee level position outside the BA/PM position family. 
  • Limited experience (12-18 months) in a related position.

Essential Characteristics 

  • Operates within a structured and routinely supervised environment. 
  • After initial training, uses methods, procedures and standards applicable to assigned tasks with less frequent need for direct supervision. 
  • Demonstrates rational and organized approach to tasks. 
  • Has developed sufficient oral and written communication skills for effective dialogue with colleagues and superiors. 
  • Is able to absorb and apply new technical information rapidly when it is systematically presented. 
  • Within a short time horizon, is able to plan, schedule and monitor own work.

Task Manager

This is the upper level staff position for those who are familiar with the scope of their tasks. Task managers do not have responsibility for projects. Their responsibility extends to tasks within a project. They may have team members assigned to these tasks and may receive guidance and supervision from the task manager. It is distinguished from the team member position by the depth and complexity of the technical knowledge base covered, and the extent to which supervision is required. This position implies a high degree of accountability for self-controlled work. It may include a guidance role for the less experienced team members assigned to their task.

Key Indicators 

  • Fully trained Team Member. 
  • Relevant experience in a related position (2-4 years).

Essential Characteristics 

  • Depending on the scope and complexity of the work, operates within a largely unsupervised environment but within a clear accountability framework. 
  • Is familiar with, uses effectively, and can select appropriately from applicable methods, procedures and standards. 
  • Is able to function effectively and productively, and meet time and quality targets across tasks within scope, using available tools, methodologies and/or equipment with reference to others only by exception. 
  • Can assume team leader responsibilities for the work of less skilled professionals. 
  • Demonstrates both formal and informal communications ability; orally and in writing, when dealing with all colleagues and clients. 
  • Is able to rapidly absorb new technical information as required. 
  • Demonstrates a systematic, disciplined and analytical approach to problem solving. 
  • Has a good appreciation of the wider field outside his/her own specialization and has developed a good broad understanding of computer systems and techniques. 
  • Understands how the specific role relates to the relevant are of employment, to its clients and to the employing business as a whole.

Associate Manager

This is the lower of two levels in the professional category. It will normally be achieved after clear evidence is available of full competence in a specialized role. At this level, full technical accountability for work done and decisions made is expected. The ability to give technical or team leadership will have been demonstrated as well as a high degree of technical versatility and broad industry knowledge. Will often manage major parts of projects and be responsible to the project manager or have project management responsibility for simple projects.

Key Indicators 

  • 12-18 months experience as a task manager. 
  • Recognized as a professional by their peers. 
  • Is capable of successfully managing simple projects.
  • Does not have direct management responsibility for staff.

Essential Characteristics 

  • Takes responsibility either for substantial technical decision-making or for teams of staff. If the latter, demonstrates the basic qualities associated with team leadership and project management. 
  • Is thoroughly familiar with the available tools, methods, procedures and/or equipment associated with specialization. Possesses adequate technical depth to make correct choices from alternatives in all areas. 
  • Is able to apply selected tools and techniques in such a way as to meet set targets of cost, time, quality and performance. 
  • Is able to communicate effectively, both formally and informally, with all those with whom working interfaces arise, whether they are colleagues, clients or customers. 
  • Shows initiative and makes time available to ensure general competencies are up to date and in line with the development of the individual. 
  • Possesses a clear understanding of the relationship of any specialized role to the context in which the work is carried out. More generally, this understanding applies to the employer’s business and the needs of those who will use the end product.

Senior Manager

This is the upper of two levels in the professional category. It will normally be achieved after 2-4 years experience as an associate manager and clear evidence is available of full competence in a specialized role. At this level, full technical accountability for work done and decisions made is expected. The ability to give technical or team leadership will have been demonstrated, as well as a high degree of technical versatility and broad industry knowledge. Will manage complex projects and often be responsible for managing the activities of associate managers who function as sub-project managers.

Key Indicators

  • 2-4 years experience in an associate manager position. 
  • Recognized as a professional by their peers. 
  • Is capable of successfully managing complex projects. 
  • Will often have direct management responsibility for project staff.

Essential Characteristics 

  • Has demonstrated a basic understanding of the consulting role and has acted in such capacity as requested. 
  • Demonstrates mastery of the qualities associated with team leadership and project management. 
  • Is thoroughly familiar with the available tools, methods, procedures and/or equipment associated with specialization. Possesses adequate technical depth to make correct choices from alternatives in all these areas. 
  • Is able to apply selected tools and techniques in such a way as to meet set targets of cost, time, quality and performance. 
  • Is able to communicate effectively both formally and informally with all those with whom working interfaces arise whether they are colleagues, clients or customers. 
  • Shows initiative and makes time available to ensure general competencies are up to date and in line with the development of the individual. 
  • Possesses a clear understanding of the relationship of any specialized role to the context in which the work is carried out. More generally, this understanding applies to the employer’s business and the needs of those who will use the end product.

Program Manager

This position represents the level associated with the mature, relevantly experienced and fully capable professional. Such a person is fully accountable for work quality as a technical specialist. He/she possesses the background knowledge and experience to make informed and responsible decisions, which are both technically sound and take the needs of the organization fully into account. They will be expected to advise and coach professional level staff and are respected for their ability to do that.

Key Indicators 

  • No or very limited consulting experience at entry. 
  • Has previous experience offering informal advice and support to less qualified professionals. 
  • Has some peer recognition in a defined area of expertise. 
  • Usually works under the direction of a more senior consultant.

Essential Characteristics 

  • Has defined responsibility for all technical decision-making within the scope of specialization. In so doing is expected to recognize and take appropriate action with respect to any safety-related applications within scope. 
  • Shows mature qualities of leadership in meeting targets of time, cost, quality and performance within projects of substantial value to his/her employer. 
  • Communicates effectively, both orally and in writing, with subordinates, colleagues, clients and customers at all levels of seniority. 
  • Shows mature understanding of the relationship of his/her specialization and/or project responsibilities to the undertaking as a whole. Is able to propose solutions within the scope of his/her expertise. 
  • Shows initiative and makes time available to ensure general competencies are kept up to date in line with industry developments.

Director

This is the most senior management level position in the BA/PM Position Family It is the level occupied by the most senior manager of a business function or unit in organizations where operating effectiveness (and possibly survival) is heavily dependent on the function or unit and where large numbers of practitioners are deployed. A wide and deep practical knowledge base is called for, accompanied by mature management qualities.

Key Indicators 

  • Director of a critical business unit or function in a large organization. 
  • Frequently will have visibility and direct contact at the board level. 
  • Advises and leads the organization in strategic initiatives within their area of responsibility.

Essential Characteristics 

  • Has defined responsibility and authority for decision-making or an advisory function having a direct bearing on the work of a business unit or major function. In carrying out these responsibilities, recognizes and ensures that all appropriate actions are taken with respect to any safety-related applications within scope. 
  • Has a technical background of sufficient depth and breadth to be able to recognize and successfully exploit opportunities for effective development or usage of their area of expertise, and lead and manage fully experienced reporting managers. 
  • Demonstrates a high level of presentation skills applicable to all levels of audience. 
  • Plays a senior role in formulating strategy and policy. 
  • Has specific management responsibility for a specialized activity, which normally includes full budgetary and policy implementation authority for a significant overall function, or a significant segment of a larger unit.

Putting It All Together

Obviously this is a work in progress. I have participated in the development of similar structures for the IT professional but not for the BA/PM professional (or PM/BA if you prefer). Much remains to be done. I welcome a partner from the BA side to work with me in this challenging and valuable pursuit. It is my hope that I have launched this effort in a direction that ultimately will make sense across the entire BA and PM professional landscape. I would certainly like to hear your thoughts on the BA/PM professional or PM/BA professional, if you prefer. 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. You may reach me directly at [email protected].

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.

A First Pass at Defining the BA/PM Position Family

Written by Cynthia Low on . Posted in Articles.

In the previous article I set forth and compared the skills profile of the Business Analyst and the Project Manager. That was a very high level comparison. In order to get down to the practice level proficiency, it is necessary to define the BA/PM Position Family. That is the intent of this article. Recognize that this is my opinion and has not been discussed with any of my business analyst or project manager colleagues.

The responses to the first three articles have been overwhelming. They have been both positive and negative. Being a change management advocate, I am pleased with your reactions. My hope is that we can continue the exchange. As always I welcome opposing positions and the opportunity to engage in public discussions. Your substantive comments are valuable. Criticism is fine and is expected but, in the spirit of agile project management, so are suggestions for improvement.

I realize that I have taken a controversial position and I do so intentionally. At least I have your attention whether you agree with my position or not.

Professional Development of the BA/PM
In the previous article I offered a first pass at defining the BA/PM position family. I see that family as consisting of the following six positions:

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

Let me offer the next level of detail for each of these positions. Years ago I had the opportunity to consult with the British Computer Society on the development and implementation of their Professional Development Program. A few years later I had the occasion to develop an internet-based decision support system for IT career development for one of my clients. That system was called CareerAgent. In this article I have integrated that model into the earlier work for the British Computer Society. Much of what I define below takes advantage of the deliverables from both of those engagements. The result is the graphic shown below.

Firstpass1_450x337.png
Figure 1: The Project Manager and Business Analyst Landscape


Figure 1 is interpreted as follows. The extreme left and right vertical sectors identify those professionals who are either pure project managers (PM) or pure business analysts (BA) with the accompanying skills and competencies needed for their positions. All of the sectors in between are professionals having some combination of project management and business analyst skills and competencies. For example, as you move from the PM to the PM/ba sector you identify professionals who have pure project manager skills and competencies plus some business analyst skills and competencies. Most project managers would have some business analyst skills and competencies. Project management remains the primary focus of their position. The same interpretation holds for the BA/pm sector. The primary focus of their position is business analysis and many business analysts have some project management skills and competencies. In the middle sectors are the PM/BA and BA/PM professionals. These are the professionals that I have been referring to in all the preceding articles. They are fully qualified to manage projects and manage business analysis engagements. Their skill and competency profiles are equivalent. Their primary orientation is either as a project manager (PM/BA) or as a business analyst (BA/PM). I believe that the major career opportunities are for the PM/BA or BA/PM professionals.

The rows of this landscape refer to the six levels in the position family. At the staff level there are two positions. At the entry level are the Team Members. These professionals will have an entry level skill and competency profile that qualifies them to be a team member in a project (PM) or business analysis (BA) effort. As they gain experience they will move up to the Task Manager level where they will be qualified to supervise the work of a task, perhaps with the support of other team members. At the professional level there are two positions. The lower of the two is the Associate Manager. These positions are qualified to manage small, simple projects. Through experience they progress to the Senior Manager level. They are now qualified to manage even the most complex projects. The Director level positions are of two types. One is the Program Manager. This position is both a consultant-type position as well as a manager of project managers working on a program – a collection of projects having some relationship with one another. The other position is the Director position. These are people management positions. They are the highest level of the six position family. 

Using the Landscape for Professional Development
Each cell in the landscape will have a minimum skill and competency profile defined for all positions in that cell. In order for an individual to be in this cell, they must possess the minimum skill and competency profile for the cell that they occupy, or would like to occupy. For professional development planning, the individual will be in some particular cell and have career aspirations to move to another position in the same cell, or to a position in another cell (usually this will be an adjoining cell). The skill and competency profile of the current and desired positions or cells can be compared and the differences will identify the skill and competency gaps. The training and experience needed to remove that gap and be qualified to move to a position in the desired cell can be defined. The implications to the training department planning are obvious, as are the applications to human resource management.

What Might a Professional Development Program Look Like?
This is a big topic. By way of introduction I think that a good professional development program should consist of the four parts briefly defined below

  • Experience Acquisition
    Further experience mastering the skills and competencies needed in the current position
  • On the job training
    Training to increase the proficiency of skills and competencies needed in the current position
  • Off the job training
    Training to increase the proficiency of skills and competencies needed in the desired position
  • Professional activities
    A combination of reading, professional society involvement, conference attendance and networking with other professionals

Every position in every cell will have a minimum skill and competency profile required for the position. To qualify for a specific position the individual must first define the skill and competency gap between their current and desired position and then build a professional development program using the above four components to remove that gap. That would position the individual to move to the desired position when a vacancy arises. Each individual should have a mentor assigned to them to help with plan development and other career advice.

Putting It All Together
Obviously this is a work in progress. It has been done for the IT profession but not for the BA/PM professional (or PM/BA if you prefer). Much remains to be done. I would certainly like to hear your thoughts on the BA/PM professional or PM/BA professional, if you prefer. 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. You may reach me directly at [email protected].

 

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.

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.