Skip to main content

Tag: Requirements

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

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.

Project Success Factors and Value Contracts

At some point in our careers we have innocently accepted a project with a poor or absent description of the project manager’s role and accountabilities. Usually this information is missing because the Project Management Office (PMO) executive failed to understand the full scope of the project and/or the project sponsor’s perceptions regarding the project manager’s role. The result involves the project manager wasting upfront critical project time defining their role and then selling their inclusion to the project sponsor and key stakeholders. This time is usually not replaced and puts an avoidable strain on the project.

The project charter briefly outlines the project manager’s role. Complementing and strengthening the project charter are two separate and distinct tools I use to clarify the project manager’s role, avoid misalignment and produce a harmonious project delivery experience.

The “Project Success Factors” and “Value Contracts” are tools that explain the specific deliverables, behaviors and actions that are expected from the project manager. Together they form an agreement that stipulates if such deliverables, behaviors and actions are produced by the project manager during the engagement the project sponsor and key stakeholders will irrevocably pronounce that the project was successful and that the project manager’s role in the initiative provided “value”. Think of these tools as assurance that the results of the project manager’s efforts will be truly recognized at the end of the project.

Project Success Factors

A project usually includes changes to operational logistics that may be perceived as a loss of control by some stakeholders. The result is personal agendas and stereotypes, organizational and interdepartmental politics, and conflicting cultures that mold misguided enterprise perceptions of the project scope. Naturally, a description of the in-scope work is included in the scope statement and charter. However, this description alone does not guarantee that, at the conclusion of the project, all stakeholders will agree that the project was successful. Most of the time, stakeholder defiance is due to changes (unknown, ignored or forgotten) that individual business units had to endure as part of the project and, at its conclusion, seek some retribution for these sacrifices. Thus, accompanying the project charter and scope statement is a detailed and holistic account of the exact deliverables that must be realized in order for the project to be classified as successful by the project sponsor and key stakeholders.

Begin by restating the project purpose, desired outcome and portfolio alignment. Then state the specific deliverables that must be produced for the project sponsor to classify this project as successful. You must be very specific; requests and actions that will not be delivered should also be listed. You may want to list easily delivered, in scope tasks that the project sponsor/key stakeholders have placed a heightened value on, but are not part of the critical path. These are considered “easy wins” and help build trust between the project sponsor/key stakeholders and manager.

Value Contracts

Recognition for the results produced by a project, as well as the accountability for the operational faults uncovered during the project, ignite competitive elements in most matrix organizations. Once these competitive forces are in full force, a project manager’s personal contributions may be “selectively remembered.” This lack of recollection eventually forms a common perception about the “value” added by the project manager. In most organizations perception is reality.

Selective perception is a psychological delusion that is dominant in most organizations. Limited time and the strength of interpersonal relationships will cause most senior managers to listen attentively to the gibberish provided by a trusted band of colleagues, fully versed in water cooler dogma, and ignore the lengthy details involved in the project charter they had previously signed.

A value contract is a brief outline (1 page) of the specific behaviors and characteristics that the project sponsor/key stakeholders wish to see the project manager display throughout the engagement. As well, it outlines the Key Performance Indicators to be used when evaluating the project manager’s contribution. Strong relationships, assertive and clear communications are also elements that will strengthen organizational perception regarding the project manager’s role and contribution. If the project manager’s value is contested a Value Contract will serve as a checklist for rebuttal.


George Konstantopoulos, PMP, PgMP, is a managing partner at Welch International Management Consultants Group. He has managed portfolios and executed program and projects in the telecommunications, banking, IT, marketing, utilities, retail and professional services industries. His entrepreneurial spirit and keen business insight have benefited many organizations through his effective consultative engagements and compelling achievements. George regularly lectures on project management and the PMP designation. Additionally, he facilitates quarterly seminars intended to prepare students to write the PMP designation exam. You may contact George at [email protected] or through his blog spot at http://welchconsulting.blogspot.com/

From Good to Bloody Excellent

In the last month’s piece, I outlined my vision for a highly successful PMO. The question that no doubt has arisen in the mind of many a PMO leader is: “This is all very nice, but how does one get there?”

Fair comment! As a consultant, I deal with this question often. My clients expect me to not only develop a vision and a strategy, but also to translate them into tangible, actionable items. So, this is what they get.

As a rule, transitioning of a PMO requires executive sponsorship, for at least five reasons:

  • Changes to the PMO model often have structural implications, meaning that people may be hired or let go, reporting lines may change and job responsibilities altered.
  • There are often financial (budgetary) implications.
  • Change management should include communication at appropriate levels. The message often needs to come from upstairs.
  • Left to their own devices, organizations naturally resist change. Executive support is usually necessary to provide for requisite impetus. (There are other ways in which a change may occur. See, for example, Warren Bennis’s Why Leaders Cannot Lead).
  • A successful transition, while providing significant value to the organization, would go unrewarded if it flies below the executive radar.

As a reminder, my vision contained five key factors:

  • Appropriate PMO model
  • Competency
  • Business acumen and business alignment
  • Presence
  • Innovation

Of the five factors, choice of the appropriate PMO model is the one where a generic can potentially be extremely harmful. A careful yet swift analysis is appropriate to determine the most relevant configuration. Usually, there is a choice of options. The confines of this posting do not allow expanding on this topic to the extent it deserves, but a couple of thoughts need to be shared.

First of all, the culture of the organization, its strategy, typical projects and reporting relationships need to be considered. For example, organizations with a high degree of initiative, engaged workforce and a culture of innovation may be good candidates for a decentralized PMO. By that I mean an entity which promotes project management practices across the enterprise, provides portfolio management support and enables project managers through provisioning of tools, techniques, coaching and mentoring.

Second, there is nothing sacrilegious in adopting a multiple PMO model in organizations consisting of business units with unique needs, disparate risk tolerances and unique cultures.

The good news is the rest of the factors in my vision are dependant on development of the business acumen and achieving of business alignment. It drives the development of the core competencies within the PMO in the direction dictated by the needs of the business. It develops the sense of presence by instilling the trust towards the PMO. In turn, trust develops when PMO staff is heard and seen speaking and acting with full understanding and in the best interests of the business. The last point, innovation, flourishes and becomes much more relevant to the business because it is guided by the framework of business needs.

So, how can a PMO leader advance the business acumen of the organization? This must be an expensive proposition!

Here are a few steps that come at no or little cost and help achieve dramatic positive change.

  1. Develop communication skills and promote cross-learning through frequent staff presentations to peers on best practices.
  2. Frequently discuss business environment, priorities, the company’s strategy, recent events and other business topics with your staff. Don’t assume they’re familiar with terms and concepts. Educate, share, and ask for their opinions.
  3. Promote the culture of openness and transparency, and encourage questions about business decisions. In the absence of such culture, people tend to develop their own, often incorrect, interpretation, or just declare the decision “stupid.”
  4. Invite heads or senior staff of other departments to come and speak to PMO staff about their respective functions, the work they are engaged in, current priorities and concerns. Such sessions are very effective in promoting mutual understanding and awareness.
  5. Hire a coach who will work with you and your staff (athletes have them, and so do successful organizations). For a modest investment, you’ll be able to dramatically improve your learning process.
  6. Hold “open door” events and invite the rest of organization to see the PMO from inside. This will promote trust, appreciation, and understanding.
  7. Invite guest experts to speak on a variety of business topics, from how to read financial statements to what marketing is all about. Invite other departments and split the expense.
  8. Adopt the “train the trainer” model: send one person on a course and have him or her teach this same subject internally.
  9. Read good business press relevant to your location and industry, forward to your staff, and instigate insightful discussion.

There is no excuse for not doing this today.

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.

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:
Level 1:

1
2
Level 2:
1
2
3
Level 3:
4
5
6
7
Level 4:
8
9
10
11
12
13
Level 5:
14
15
16
17
18
Level 6:
19
20
21
22
23

I never heard of it.
I can define it.

Familiar with the terminology
Understands the basic concepts
I understand what it can do.
Knows how it is used
Can explain key issues and benefits
Understands organizational relevance
I have limited hands-on experience.
Has a working knowledge of basic features and functions
Aware of relevant standards, policies and practices
Requires assistance and supervision
Can apply it in a limited (homogeneous) environment
I have extensive hands-on experience.
Knowledge of operational issues and considerations
Understanding of benefits and drawbacks
Working knowledge of relationships and integration
In-depth knowledge of major features, functions and facilities
Awareness of usage in other environments
Can work without assistance or supervision
I can adapt it to a variety of situations.
Theoretical background and understanding
Expertise in all major features, functions and facilities
Experience in multiple environments (heterogeneous)
Knowledge of and contribution to “best practices”
Ability to consult and coach others
I am recognized as an expert by my peers.
Extensive experience in multiple/complex environments
Industry and marketplace perspective
Historical and future perspective
Influencing wide or high-impact decisions and initiatives
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,3nd 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.

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.


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,3nd 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.