The odd couple

codependencies of project management and enterprise analysis

Director, Client Solutions, ESI International

Abstract

At the onset of their careers, project managers typically aren't involved in business analysis--centric assignments. However, after gaining experience and seniority, the breadth and depth of these managers' responsibilities increasingly require at least some business analysis functionality. In most organizations, business analysis is not yet a mature practice; therefore, established project managers with an interest in functions such as risk management have tended to take on many traditional business analyst responsibilities, including enterprise analysis. In active knowledge management transfer, high-performing mid- to senior-level project managers become involved in an organization's enterprise analysis.

The execution of enterprise analysis is actually not appropriate for one individual, but rather it should be handled by a group of professionals exploring the feasibility of solving a posed problem or proposing a new opportunity. In essence, the tactic is a project in itself, thus familiar territory for project managers. Sophisticated project managers are attracted to the value system of enterprise analysis because it promotes enterprise-wide thinking, the development of a harmonious business and IT environment, and agility in responses to both internal and external customer demands.

This paper will discuss how the intersection of the project management and business analysis disciplines is evident in the practice of enterprise analysis. It will cover the architecture of enterprise analysis---including the pillars of business architecture, feasibility study, project scope, business case, initial risk assessment, and design package---ensuring that you gain an understanding of how the codependencies between disciplines affects and is affected by guiding enterprise analysis principles.

Introduction

Although certainly a great deal of literature exists that recognizes the shortcomings of project management and their respective areas of failure, it is impressive that failure is often cited as being symptomatic of project management practices. Project managers of all walks of life will be the first to tell you that one of the most challenging components of project management is not the mechanical, tactical, or operational aspects of the discipline but the diversity of the people with whom they work. Behind every project are people who, no matter how small their assigned effort is, play an integral role in the development of their respective deliverables for overall project success.

The business analyst is no exception to this. In fact, it's quite easy to claim that business analysts play the most integral and collaborative role with the project manager, especially given the context of enterprise analysis.

Enterprise Analysis Versus Enterprise Architecture

Enterprise architecture is best defined as a series of interrelated disciplines including business, application, information, information technology, and security architectures. Combined, they are the blueprint for how an organization functions.

Enterprise analysis is the disciplined exercise of proving the optimum business value for a given initiative, investment, or resolution to a business problem. Its output is a clear understanding of the business architecture. Upon this foundation, all other architectures---application, information, information technology, and security---can be realized.

Enterprise Architecture = Sum (Business Architecture + (Application Architecture + Information + Information Technology + Security))

The examination of each discipline, independently or collectively, is no small task and, without question, must be facilitated using a structured and disciplined approach, with project management practices serving as the foundation. All elements of project management and business analysis practices must be employed to ensure that all architectures are accurately realized for both the “as-is” and “to-be” states.

The Business Case for Enterprise Analysis

As with any initiative, a solid case must be made for the demonstration of value that is to be realized as a result of its efforts. There is no exception to this when considering enterprise analysis. The following are the top five reasons for participating in enterprise analysis activities:

1. Better business alignment with strategic goals

Better business alignment with strategic goals ensures that the entire organization is working toward a common goal, be it increased revenue, increased profits, or increased efficiencies to realize revenues or profit. Enterprise analysis seeks to demonstrate this traceability by ensuring the integrity of the defined scope for the said project.

2. Improved planning

Improved planning includes the realization of resources, methodologies, regional or geographical diversities, organizational change, and expected impact. By having an enterprise-wide view of the initiative(s), both the project manager and the business analyst can collaborate on any of the above and realize the rough order of magnitude a project might take on.

3. Improved decision making

Improved decision making relies heavily on the output of enterprise analysis, as it serves to lend credible insight into the nature of the solution, scope, feasibility, estimated costs, and risks. All aspects of decision making are dependant on the evolution of business requirements and their quantification and validation by the project manager and the business analysts, both of whom are likely to provide artifacts and a decision package to be evaluated by the portfolio management committee for either approval or rejection of the initiative. If the initiative is approved for development, the program management group is likely to rely on the output of the enterprise analysis activities to assess and evaluate how the development of the solution and its respective components are to be managed. Decision making can also take into consideration the previous items, including business alignment and planning considerations.

4. Risk mitigation

Risk mitigation takes into consideration threats and opportunities both at the organizational level and at the project level. Organizationally, both a project manager and a business analyst can ascertain the potential impact in the event of success or failure, based on the type of solution realized during the EA activities. Also considered are project-based risks such as resources, time, and budget.

5. Reduction of duplicated efforts

The reduction of duplicated efforts is something that is very often overlooked in organizations. We often find one business unit developing, customizing, or purchasing a solution that very often has already been or is currently in the process of being realized elsewhere in the organization. The enterprise analysis approach is a great means to mitigate the risk of duplicating not only efforts but costs associated with these types of scenarios.

The Definition of Project Management and Business Analysis

Along with defining enterprise analysis and understanding the need for it, it is equally important to recognize the two critical roles responsible for laying the foundation from which all solutions are realized.

According to the Project Management Institute, project management is defined as “the application of knowledge, skills, tools and techniques to project activities to meet project requirements.” (Project Management Institute {PMI], 2004, p. 8)

I've always found it particularly interesting that the last word noted in this definition is “requirements,” those which are developed and managed typically by a business analyst.

According to the International Institute of Business Analysis, business analysis is defined as “the set of tasks, knowledge, and techniques required to identify business needs and determine solutions to business problems" (International Institute of Business Analysis, 2006, p. 8).

A collaborative definition of these two roles might look something like this:

The application of knowledge, skills, and techniques to realize and deliver goods and services needed to satisfy an organization's business goals and objectives.

Comparing the PMBOK® Guide to the BABOK®

If you've ever had the chance to climb a mountain you might be familiar with the term switch-back. This is a technique used by mountaineers to ascend the base of the mountain by moving up the mountain in “zig-zag” format, or moving from one side to another, thereby decreasing the degree of angle that is needed to get to the top. This technique is very systematic in nature and requires less effort. The same back-and-forth concept can be applied to the practice of project management and business analysis in the context of enterprise analysis.

Exhibit 1 illustrates the complementary nature of the Project Management Institute's A Guide to the Project Management Body of Knowledge (PMBOK Guide®)---Third edition, and its knowledge areas to the International Institute of Business Analysis' BABOK® and its knowledge areas.

Comparison of the PMBOK® Guide to the BABOK®

Exhibit 1--Comparison of the PMBOK® Guide to the BABOK®

In its simplest terms, integration can be easily aligned with enterprise analysis, as both seek to bring together components of an organization in terms of understanding how a solution might meet business goals and objectives. Bringing together activities such as understanding the business architecture, realizing the project and product scope, and developing a project charter will often ensure the integrity of the project right from the beginning. Integration of a solution across the enterprise and understanding its optimum value and impact on the overall business are both very much complementary to the tasks and activities of project managers and business analysts.

The activities necessary to produce the deliverables from integration and enterprise analysis provide the context from which both product and project scope can be defined. Through various elicitation and diagramming techniques, both a project manager and a business analyst can begin to craft the scope of a solution. The output and results of this easily allow for planning and management activities for the project manager and business analyst. The business analyst must focus his or her efforts on activities that are necessary to realize the requirements development and management life cycle. Meanwhile, the project manager must integrate planning and management activities with those of development, quality assurance, deployment, and implementation, as well as postimplementation. In addition, he or she must integrate these activities with all of the people, processes, and supporting tools that are necessary to realize a solution.

From planning and management come scheduling and cost control, elicitation, and the intricacies of quality and risks associated with the delivery of the solution. Through analysis and design activities conducted by the business analysis team, a risk response strategy can be easily realized considering the type, size, effort, and dollars that are required to develop what the business needs to solve their problems and realize their opportunities. Communication planning efforts often have overlapping areas of responsibilities, but carry different messages at different points in time during the project life cycle. A business analyst and project manager would clearly have to work to understand the frequency of communication, type of communication, key stakeholder expectations, and stakeholder involvement in the project life cycle itself.

Through solution assessment and validation activities, a business analyst and project manager can monitor and maintain the traceability of the requirements back to the originally stated goals and objectives. The scope of the project, changing risks, effort, and resources to complete existing or upcoming and pending work products are shared responsibilities, each with interdependencies.

Examining the Mutual Relationship Between the Project Manager and the Business Analyst During Enterprise Analysis Activities

It is important to note that regardless of the size of the initiative, each set of enterprise analysis activities outlined below may be treated as a separate project unto itself and all activities may fall into the program management discipline. Each set of activities may be iterative or waterfall in terms of methodology to deliver its output.

Business Architecture

During business architecture activities, both the business analyst and the project manager strive to understand the scope of the activities that they are about to embark upon. They assess and evaluate the as-is state of the business architecture, the appropriate framework (e.g., TOGAF, Zachman, Poldat, IBM Component Model) given the size and magnitude of the project, and the potential impact of change. As a result, high-level risk considerations begin to evolve. This proves to be a great opportunity for both the project manager and the business analyst to ascertain what other project dependencies the output of their effort might have an effect on.

Feasibility Study

As the existing business architecture is understood and “revealed,” the project manager and business analyst can begin to conduct feasibility studies to realize any potential solutions that may meet the overall stated objectives. Feasibility studies can often be time consuming and resource intensive, requiring a wide and varied demonstration of elicitation techniques. But, for a business analyst, they are critical for evolving the right possible solution or combinations of solutions. For the project manager, this becomes a critical exercise in resource management and allocation. With the realization of potential solutions, a project manager would be called upon to lend his or her expertise in the decomposition of high-level work breakdown structures focused on product development and deliverables. Also, the levels of risk---including financial risk---that each potential solution would have on the organization and the project itself are carefully considered and evaluated by both the project manager and the business analyst so that the appropriate solution can be realized.

Scope Definition

By ensuring the integrity of the agreed-upon solution(s) as articulated during the feasibility studies, a business analyst works with a project manager to develop the scope of the project, high-level assumptions and constraints, and the anticipated work effort required to realize the solution.

Business Case Development

Quantification of benefits and costs and demonstration of optimal business value are carefully scrutinized by both the project manager and the business analyst to ensure optimal project investment. All costs and measures of realization of costs are developed using all supporting documentation created during the previous activities, including models, diagrams, and schematics.

Risk Assessment

Although a large portion of responsibility falls on the project manager to realize a risk-response plan, a large portion of the plan must be concentrated on the solution to be developed, over and above financial risks and resource and time constraints. Working with a business analyst, a project manager can quickly surmise the potential impact that a changed process or procedure may have if not considered carefully, or in the event of failure, if the product is unable to meet the desired output, and so on.

Presentation of the Business Case

While everything from preparing the supporting documentation to understanding explicitly the business environment to determining a solution and its costs and risks are a collaborative effort, the business analyst and the project manager have very distinct roles in delivering messaging about the proposed solution. The business analyst will likely share key messages with the respective stakeholders regarding what the solution will be and how the team arrived at this conclusion. How the solution will be delivered, risks, constraints, assumptions, and associated costs are the key messages that a project manager will be sure to communicate to the respective stakeholders.

Regardless of the activity or activities necessary to develop output for an enterprise analysis type of initiative, it is imperative that a collaborative approach between the project manager and business analyst be considered. From planning the activities necessary to facilitate the evolution of requirements, to the financial quantification of those solution requirements, to the risk assessment and evaluation of potential solutions, both play an integral role.

References

International Institute of Business Analysis. (2006). A guide to the business analysis body of knowledge® (BABOK®) (Version 1.6). Retrieved June 23, 2008 from http://www.theiiba.org/Content/NavigationMenu/Learning/BodyofKnowledge/Version16/BOKV1_6.pdf.

Project Management Institute. (2004). A guide to the project management body of knowledge (PMBOK® guide)---Third edition. Newtown Square, PA: Project Management Institute.

This material has been reproduced with the permission of the copyright owner. Unauthorized reproduction of this material is strictly prohibited. For permission to reproduce this material, please contact PMI or any listed author.

© 2008, Glenn R. Brûlé
Originally published as part of 2008 PMI® Global Congress Proceedings — Denver, Colorado, USA

Advertisement

Advertisement

Related Content

Advertisement

Publishing or acceptance of an advertisement is neither a guarantee nor endorsement of the advertiser's product or service. View advertising policy.