Using Project Management Best Practices to Manage Oracle Enterprise Resource Planning (ERP) Projects

Using Project Best Practices to Manage Oracle Enterprise Resource Planning (ERP) Projects Edward Charity, Jr., Project Professional (PMP) Project Systems Consultants (PMSC), LLC Oracle Enterprise Resource Planning (ERP) implementation projects are complex undertakings that benefit from a proven, structured project management approach. In this paper, we ll walk through the planning, execution, and wrap-up of an Oracle ERP project using concepts adapted from the Project Institute s (PMI s) Project Body of Knowledge (PMBOK). This paper will discuss PMI s PMBOK and its application to ERP implementations projects. This paper will provide an overview of PMI s PMBOK concepts, provide an overview of ERP implementation projects, and illustrate the application of PMBOK concepts to ERP projects. It will indentify tools and techniques available to support ERP projects using PMBOK concepts, and finally, provide practical guidance for successful ERP implementation projects based on my experience over the past 20 years. The Project Institute (PMI) and the Project Body of Knowledge (PMBOK) The Project Institute (PMI) is one of the world s largest professional membership associations, with half a million members and credential holders in more than 185 countries. It is a not-forprofit organization that advances the project management profession through globally recognized standards and certifications, collaborative communities, an extensive research program, and professional development opportunities. The Project Body of Knowledge (PMBOK) is one of the globally recognized standards established by PMI. The PMBOK, as it is known, contains the fundamental practices that all project managers need to attain high standards and project excellence. This internationally recognized standard gives project managers the essential tools to practice project management and deliver organizational results. The formal title for the PMBOK is A Guide to the Project Body of Knowledge (PMBOK Guide) Fourth or Fifth Edition. The Fifth Edition, published in 2013, is the latest guidance and is the source of information contained in this paper. PMBOK Project (PM) Process Groups The PMBOK is comprised of five (5) major Project (PM) Process Groups. These five PM Process Groups are a briefly defined below: 1) Initiating Process Group Those processes performed to define a new project or a new phase of an existing project by obtaining authorization to start the project or phase. Within the initiating processes, the initial scope is defined and initial financial resources are committed. Internal and external stakeholders who will interact and influence the overall outcome of the project are identified. If not already assigned, the Project Manager will be selected. This information is captured in the Project Charter and Stakeholder Register. A key purpose of this Process Group is to align the stakeholder s expectations with the project s purpose, give them (stakeholders) visibility about the scope and objectives, and show how their participation in the project and its associated phases can ensure that their expectations are achieved. 2) Planning Process Group Those processes required to establish the scope of the project, define and refine the objectives, and define the course of action required to attain the objectives that the project was undertaken to achieve. These planning processes develop the project management plan and the project documents that will be used to carry out the project. The key benefit of the COLLABORATE 13 OAUG Forum P a g e 1

planning process group is to delineate the strategy and tactics as well as the course of action or path to successfully complete the project or phase. The project management plan and project documents developed as outputs from the planning process group will explore all aspects of the project s scope, time, cost, quality, communications, human resources, risks, procurements, and stakeholder engagement. Each will be documented as its own, unique management plan, i.e. Scope Plan, Time Plan, etc. 3) Executing Process Group Those processes performed to complete the work defined in the project management plan to satisfy the project specifications. This process group involves coordinating people and resources, managing stakeholder expectations, as well as integrating and performing the activities of the project in accordance with the project management plan. A large portion of the project s budget will be expended in performing the executing process group processes. 4) Monitoring and Controlling Process Group Those processes required to track, review, and regulate the progress and performance of the project; identify any area in which changes to the plan are required; and initiate the corresponding changes. This process group, more than any of the others, interacts with all of the other process groups. The key benefit of this process group is that project performance is measured and analyzed at regular intervals to identify variances from the project management plan. This continuous monitoring provides the project team insight into the health of the project and identifies any areas requiring additional attention. 5) Closing Process Group Those processes performed to finalize all activities across all Process Groups to formally close the project or phase. This process group, when completed, verifies that the defined processes are completed within all of the process groups to close the project or project phase, and formally establishes that the project or project phase is complete. The five Process Groups have clear dependencies and are typically performed in each project and regularly interact with each other. The Process Groups are independent of application areas or industry focus. Put another way, all projects will, in some form or another, have each of these Process Groups. Each of the Process Groups will be present in each phase of a project and for multiple phase projects, these Process Groups will be repeated. PMBOK Project (PM) Knowledge Areas In addition to the five major Project Process Groups identified above, there are ten (10) Project Knowledge Areas included in the PMBOK. A Knowledge Area represents a complete set of concepts, terms, and activities that make up a professional field, project management field, or area of specialization. Each knowledge area is composed of detailed processes unique to that knowledge area. There are a total of 47 of these detailed processes. The PMBOK Guide defines the important aspects of each Knowledge Area and how it integrates with the five Process Groups. As supporting elements, the Knowledge Areas provide a detailed description of the process inputs and outputs along with a descriptive explanation of tools and techniques most frequently used within the project management processes to produce each outcome. These ten PM Knowledge Areas are briefly defined below: 1) Project Integration The processes and activities to identify, define, combine, unify, and coordinate the various processes and project management activities within the Project Process Groups. Two key outputs of this knowledge area are the Project Charter and the Project Plan. One of the key tools used in this knowledge area is the Project Information System (PMIS). 2) Project Scope The processes required to ensure that the project includes all the work required, and only the work required, to complete the project successfully. The Project Charter and the Project Plan are two key inputs into this knowledge area. Three key outputs of this knowledge area are the Scope Plan, the Requirements Documentation/Traceability Matrix, and the Scope Baseline (aka Work Breakdown Structure (WBS)). A number of tools are used in this key area, specifically around Requirements Development, including facilitated meetings, interviews, and questionnaires. 3) Project Time The processes required to manage the timely completion of the project. The Project Charter and the Project Plan are two key inputs into this COLLABORATE 13 OAUG Forum P a g e 2

knowledge area. Three key outputs of this knowledge area are the Activity Resource Requirements/Resource Breakdown Structure (RBS), the Schedule Baseline and the Project Schedule. Some of the tools used in this knowledge area include scheduling methods such as Critical Path Method (CPM) or Critical Chain Method (CCM) and scheduling software/tools. 4) Project Cost The processes involved in planning, estimating, budgeting, financing, funding, managing, and controlling costs so that the project can be completed within the approved budget. The Project Charter and the Project Plan are two key inputs into this knowledge area. Two key outputs of this knowledge area are the Costs Baseline and Cost Forecasts. The main tools used in this knowledge area are the various estimating tools, such as Analogous, Parametric, Bottom-up, and Three-Point Estimating. 5) Project Quality The processes and activities of the performing organization that determine quality policies, objectives, and responsibilities so that the project will satisfy the needs for which it was undertaken. Project Quality works to ensure that the project requirements, including product requirements, are met and validated. The Stakeholder Register and Requirements Documentation/Traceability Matrix are two key inputs into this knowledge area. Two key outputs of this knowledge area are Change Requests and Validated Deliverables. The main tools used in this knowledge area are Quality Audits and Inspection. 6) Project Human Resource The processes that organize, manage, and lead the project team. The Project Plan and Activity Resource Requirements are two key inputs into this knowledge area. Two key outputs of this knowledge area are Change Requests and Project Staff Assignments. The main tools used in this knowledge area are Observation and Conversation and Negotiation 7) Project Communications The processes that are required to ensure timely and appropriate planning, collection, creation, distribution, storage, retrieval, management, control, monitoring, and the ultimate disposition of project information. The Project Plan and Stakeholder Register are two key inputs into this knowledge area. Two key outputs of this knowledge area are Project Communications and Change Requests. Some of the tools used in this knowledge area include Communication Technology, Communications Models and Methods, and Performance Reporting. 8) Project Risk The processes of conducting risk management planning, identification, analysis, response planning, and controlling risk on a project. The objectives of project risk management are to increase the likelihood and impact of positive events, and decrease the likelihood and impact of negative events on the project. The Project Plan, Project Charter and Stakeholder Register are key inputs into this knowledge area. Two key outputs of this knowledge area are the Risk Register and Change Requests. Some of the tools used in this knowledge area include Strengths Weaknesses Opportunities and Threats (SWOT) Analysis and Risk Probability and Impact Assessment. 9) Project Procurement The processes necessary to purchase or acquire products, services, or results needed from outside the project team. The Project Plan and the Requirements Documentation are key inputs into this knowledge area. Two key outputs of this knowledge area are Selected Sellers and Change Requests. Some of the tools used in this knowledge area include Bidder Conferences and Proposal Evaluation Techniques 10) Project Stakeholder The processes required to identify the people, groups, or organizations that could impact or be impacted by the project, to analyze stakeholder expectations and their impact on the project, and to develop appropriate management strategies for effectively engaging stakeholders in project decisions and execution. The Project Plan and the Project Charter are key inputs into this knowledge area. The predominate output from this knowledge area are Project Communications and Change Requests. Some of the tools used in this knowledge area are Stakeholder Analysis and Meetings. The PM Process Groups and Knowledge Area intersect at various stages during the lifecycle of a project. The illustration below shows this intersection. The shaded boxes represent the detailed processes unique to the specific knowledge area and where they intersect with the PM Process Groups. The individual processes have been excluded for simplicity sake. A Glossary of Terms is included at the end of this paper. COLLABORATE 13 OAUG Forum P a g e 3

Knowledge Areas Project Integration Project Scope Project Time Project Cost Project Quality Project Human Resource Project Communications Project Risk Project Procurement Project Stakeholder Initiating Process Group Planning Process Group Project Process Groups Executing Process Group Monitoring Process Group Closing Process Group Overview of ERP Implementation Projects Oracle (and other) Enterprise Resource Planning (ERP) Implementation projects are typically designed using a traditional Systems Development Life Cycle (SDLC) process. The most common of the SDLC methods is the Waterfall method, utilizing a sequential series of phases or stages to get from the start of the project to the end. The SDLC methods were developed primarily to manage custom development efforts where the end-product software application is being built from scratch. ERP systems are what are known as Commercial-Off-The-Shelf (COTS) software where a significant amount of the desired functionality is delivered by the software developer. As a result, the SLDC methods have to be modified to meet the differences between custom development and COTS. There are a number of methodologies used specifically for ERP Implementation projects, including those developed by the various ERP software developers themselves. Oracle Corporation s current iteration is the Oracle Unified Method or OUM. Prior to OUM there was the Application Implementation Method or AIM and prior to that was the Application Implementation Program or AIP. While each of these had or has its strengths, very few are utilized in a consistent, comprehensive manner. In addition to the methods from the software developers, the various Systems Integrators (SIs) have methods that they have developed and rely on for their implementation projects. They train their resources COLLABORATE 13 OAUG Forum P a g e 4

to use these methods on projects they staff and/or manage. These methods are usually a part of the sales pitch the SIs use to make a case for purchasing their services. Finally, most client (end-user) organizations have some form of project management approach that they adhere to for internal systems development purposes. While most of these are geared to custom development efforts, they are repeated used to drive ERP implementations. My position, and the purpose of this paper, is to argue that using a globally recognized approach, such as that delivered through PMI s PMBOK, should be seriously considered by client organizations either starting or already involved in an ERP implementation project. Application of PMBOK Concepts to ERP Implementation Projects Although the titles may change from one methodology to another, most ERP Implementation projects include the following phases/stages: 1) Analysis; 2) Design; 3) Build; 4) Train; 5) Transition; and 6) Support (Post Production). Depending on the organization managing the implementation effort, there may be some form of planning done prior to the formal start of the project. Rarely have I seen a formal project closure phase/stage. Over the past 20 years, I ve worked exclusively on Business Transformation projects that included some component of Enterprise Resource Planning (ERP) software implementation. Some of this was in the form of clients replacing their legacy systems with ERP applications. Others were in the form of clients upgrading the current version of their ERP applications to later versions. As a result, I ve observed a number of situations where projects or project phases were either successful or not so. My observations of the not so successful projects or project phases have led me to develop a list of Ten Reasons Why ERP Implementation Projects Go Bad. This list is not exhaustive, but represents a consistent pattern of problems I ve seen over the last 20 years. In addition to listing these problems, I m including solutions based on the PMBOK concepts identified earlier in this paper. Note: These are not listed based on the order of importance, with the exception of Number 1, Poor Communication. 1) Poor Communications. According to PMI, more than 50% of the Project Managers time should be spent communicating with Project Stakeholders. The solutions to this problem include: a) a comprehensive Communications Plan that is actively used; along with b) the Stakeholders Plan. These two documents, outputs from the Project Plan, should clearly lay out the methods for communication to the divergent parties and the specific audiences that must be communicated to. 2) Unclear/incomplete Business Requirements. One of the quickest ways to get a project off- track is to start it without a clear method for identifying, documenting, validating, and getting approval of the Business Requirements that will be used to validate the project s success. One of the leading contributors to Scope Creep is the identification of legitimate business requirements late in the project. The solutions to this problem include: a) a comprehensive Scope Plan that identifies how requirements will be managed. The Scope Plan will set forth when the requirements gathering process is substantially complete, as well as how new requirements will be incorporated into the project. 3) Lack of specific ERP Implementation Project Knowledge and Experience. Managing ERP/COTS implementations are not the same as managing Custom Development efforts. The experience gained from multiple ERP/COTS implementations is extremely valuable, especially to client organizations un-familiar with the process and its associated perils. For example, the assumption that mature ERP/COTS software will work as advertised once installed is a common fallacy. One of my favorite phrases to get this concept across is this is not MS Office, you don t just install it and start using it. In spite of the multi-million dollar expenditure for the software, the implementation effort is where the real work starts. Additionally, navigating within the software developer s organization structure in an efficient manner is gained from years of experience in the trenches. The key solution to this problem is to hire an experienced Project COLLABORATE 13 OAUG Forum P a g e 5

Manager that has significant experience with the ERP software that you ve chosen. If necessary delay hiring/identifying the Project Manager until after you ve selected the software vendor. This should be incorporated in the Project Charter and the Human Resource Plan. Note: Client organizations tend to rely on their Implementation Partners (Systems Integrators) to provide this knowledge and expertise. While the implementation partners should bring this skill set to the table, the client organization must have this type of resource under their direct control. The implementation partner Project Manager has a different motivation than the client organization Project Manager. I strongly recommend hiring a seasoned ERP Project Manager, preferably as an employee instead of as a contractor. The implementation partners Project Managers should report to the client organization s ERP Project Manager. 4) Unrealistic Timeframes. I can t tell you how many times I ve heard the phrase we must be finished with this project by x date, no matter what, without any regard as to how that s going to happen. These are the same projects that people are surprised that x date comes and goes and the project is nowhere near completion. The Time Plan should be used to clearly lay out the amount of time and the resources required to complete the project successfully. The Project Schedule is an output of the Time Plan and is developed using such scheduling methods as Critical Path or Critical Chain. The timeline of the project should not be driven by some arbitrary date, but by estimating the duration of activities and appropriate scheduling of the activities based on the availability of competent resources. 5) Inadequate/poor estimating skills/experience. One of the recurring themes on projects that get off track is the inability to complete project deliverables based on estimates provided. This is especially true of technical component development. Completion of technical components (aka Reports, Interfaces, Conversions, and Extensions (RICE)) on schedule is key to moving the project from the building stage to the testing and transition stages. Most projects use a multiphased testing approach through the project life cycle. This typically takes the form of 1) Unit Testing; 2) Systems/Integration Testing (SIT); and 3) User Acceptance Testing (UAT). Delayed delivery of technical components should force the delay of SIT and UAT completion, which forces the project to be delayed. In my experience, the delayed delivery of technical components is primarily the result of inadequate estimates of the effort required to design, develop, and unit test the components. This is a function of non-existent development standards and the experience level of the technical resource team. The development standards used on the project should be clearly laid out in the Quality Plan and the specific resource requirements and standards should be clearly laid out in the Human Resource Plan. Peer and Independent validation of the technical component development estimation efforts should also be built into the Quality Plan. 6) Inadequate client resource commitments. ERP implementation projects are very labor intense and usually require a significant amount of client resource commitment. Typically client resources are identified in the early stages of the project. The expectation is that these resources will stay with the project through its completion. One of the ways that these projects get off track is when the client resources are committed to the project at a utilization rate significantly above their actual participation rate. Examples include: a) 50% utilization for planning purposes, but only 20% actual participation; or b) 100% utilization for planning purposes, but only when available for actual participation. One of the recurring reasons for the low participation rate has to do with the need to do their regular job in addition to working on the ERP implementation project. This rarely, if ever, works. The planning and estimating that goes into an ERP implementation project is based on the availability of resources to do the work being estimated. If the expected availability rate is much higher than the actual participation rate, the estimates for completion will be repeatedly missed. One of the items that must be clearly laid out in the Human Resource Plan, via the Activity Resource Requirements and Project Staff Assignments, is the level of expected participation of selected client resources. One of the Risks associated with ERP implementations is the risk that required resources will not be available at the appropriate time. One of the Risk Mitigation Strategies that are commonly used to address this risk is back-filling of selected resources either through internal resource movement or external COLLABORATE 13 OAUG Forum P a g e 6

hiring. Risks of this nature should be documented in the Risk Register, as a part of the Risk Plan. 7) Lack of Training. This problem comes in two forms. The first is implementation team training, both functional and technical development. As noted above, ERP implementations come in two forms: a) replacing a legacy system, whether it s home-grown or commercially purchased; and b) upgrading from an older, outdated version to a newer version of the same vendor s software. Both of these require the implementation team members to get familiar with the new software. My personal and professional preference is to have this training done as early as possible in the implementation project. I also prefer formal class-room training away from the client s facility. This gives the participants the opportunity to fully focus on the training without distractions from work. I ve found it especially helpful to work with the training provider to customize the training to focus on those areas directly applicable to the client s situation. Optimally, implementation team training should happen immediately prior to Requirements Development. The second form is end-user training. One of the easiest ways to derail a perfectly good ERP implementation project is to under-play the importance of end-user training. If the end-users are not properly trained, adoption of the new system is almost impossible. One of the issues that must be addressed early in the planning stage is who is responsible for developing and delivering end-user training. There is no one correct answer and the right answer for a given organization depends to the internal resources of that organization. The Human Resource Plan along with the Stakeholders Plan will be used to determine the appropriate type of training required for both of the training populations. The Procurement Plan will be used facilitate make-versus-buy decisions around training development and delivery. The Time Plan will help to determine the optimal times for developing and delivering project training. 8) Unqualified Consulting Resources In my opinion, consulting resources come in one of three flavors: 1) Functional Resources they have expertise in specific ERP modules or modules groups i.e. payables or procure to pay, respectively; 2) Technical Resources they have expertise in the various technical development tools used i.e. PL/SQL, Oracle Forms, Oracle Reports, etc.; and 3) Project Resources they have expertise managing ERP implementation projects. I talked about this in item 3 above. Some of the more senior functional and technical resources will have some level of PM expertise, but their roles on the project are usually limited to their functional or technical area of expertise. The recurring problem that I ve experienced over the years is functional and technical resources that have the required functional or technical expertise, but lack the soft skills necessary to be successful. Some of these soft skills include: a) Verbal and written communication skills; and b) Meeting facilitation skills. Both of these are critically important during requirements gathering, one of the most critical phases of the project. Client organizations tend to focus primarily on the specific functional or technical expertise to fill a certain role, without regard to the need for the appropriate soft skills. I recommend that client organizations play an active role interviewing and selected consulting resources assigned to their projects. This should clearly be laid out in any Procurement Documents generated out of the Procurement Plan. Additionally, the Human Resource Plan, via the Activity Resource Requirements and Project Staff Assignments should be used to clearly identify the traits of the consulting resources assigned to the project and the process for removing unsatisfactory resources. 9) Inadequate Executive Support/Leadership. Without the ongoing support of an organization s Executive Team, it is almost impossible to have a successful ERP implementation. This support has to be shown at the initiation of the project and continued throughout the life of the project. Executive support is initially provided in the Project Charter. The Project Charter, by definition, authorizes the project and commits funding and people to the project. Per PMI, no project can exist without a Project Charter, but all of us have been involved with projects where none existed. The Project Charter, along with the Project Plan lays out how the Executive Team will be engaged during the project. One strong recommendation is to have the Project Sponsor kick-off the project and vocally support the project as often as possible. There will be stakeholders that are not ardent supporters of your project and they will look for opportunities to undermine your project. A strong, vocal Project Sponsor can help to reduce these opportunities. 10) Inadequate Client Information Technology/Infrastructure Support. Deploying ERP systems involves a significant investment in software and hardware that may be foreign to some client COLLABORATE 13 OAUG Forum P a g e 7

Conclusion organizations. Some of this can be alleviated by providing sufficient training to existing client resources. Hiring resources with the required expertise can also help to alleviate this problem. Lastly, client organizations should at least consider outsourcing this function to any of the number of organizations that offer this service. Oracle itself offers hosting of its applications through its Oracle On-Demand (OOD) service. Whether to perform this function in house or to outsource it is one of the things included in the Procurement Plan via a make-versus-buy analysis. Oracle Enterprise Resource Planning (ERP) implementation projects are complex undertakings that benefit from a proven, structured project management approach. The Project Institute s (PMI s) Project Body of Knowledge (PMBOK) is a structured approach the can be adapted to meet this purpose. In this paper, I ve provided an overview of a number of PMI PMBOK concepts, provided an overview of ERP Implementation Projects, identified a number of common ERP project failure areas, and shown how a number of the PMI PMBOK concepts can be utilized to alleviate these failure areas. Edward Charity, Jr. is President and Chief Executive Consultant of Project Systems Consultants (PMSC), LLC. PMSC is a boutique Consulting firm specializing in the design, development, deployment, and management of Enterprise Resource Planning (ERP) implementation projects. Mr. Charity has worked with Oracle s ERP applications since 1993. Mr. Charity is an acknowledged Subject Matter Expert (SME) in Oracle s Projects (aka Project Accounting) Application Suite. Prior to founding PMSC, Mr. Charity was a Senior Manager in the Oracle Service Line at CapGemini s and Ernst & Young s Consulting Organizations. Prior to that Mr. Charity was a Managing Principal Consultant at Oracle Corporation. Mr. Charity is a Certified Public Accountant (CPA), Project Professional (PMP), and Oracle E-Business Suite R12 Projects Certified Implementation Specialist. Mr. Charity and PMSC, LLC are based in Arlington, Virginia (Washington, D.C. Metro Area). COLLABORATE 13 OAUG Forum P a g e 8

Glossary of Terms Activity Resource Requirements The types and quantities of resources required for each activity in a work package. Analogous Estimating A technique for estimating the duration or cost of an activity or a project using historical data from a similar activity or project. Bottom-Up Estimating A method of estimating project duration or cost by aggregating the estimates of the lower-level components of the work breakdown structure (WBS). Communications Plan A component of the project, program, or portfolio management plan that describes how, when, and by whom information about the project will be administered and disseminated. Cost Plan A component of a project or program management plan that describes how costs will be planned, structured, and controlled. Critical Chain Method (CCM) A schedule method that allows the project team to place buffers on any project schedule path to account for limited resources and project uncertainties. Critical Path Method (CPM) A method used to estimate the minimum project duration and determine the amount of scheduling flexibility on the logical network paths within the schedule model. Human Resource Plan A component of the project management plan that describes how the roles and responsibilities, reporting relationships, and staff management will be addressed and structured. Make-or-Buy Analysis The process of gathering and organizing data about product (or project) requirements and analyzing them against available alternative including the purchase or internal manufacture of the product. Parametric Estimating An estimating technique in which an algorithm is used to calculate cost or duration based on historical data and project parameters. Procurement Plan A component of the project or program management plan that describes how a project team will acquire goods or services from outside the performing organization. Project Charter A document issued by the project initiator or sponsor that formally authorizes the existence of a project and provides the project manager with the authority to apply organizational resources to project activities. Project Information System (PMIS) An information system consisting of the tools and techniques used to integrate, and disseminate the outputs of project management processes. It is used to support all aspects of the project from initiating through closing, and can included both manual and automated systems. Project Plan The document that describes how the project will be executed, monitored, and controlled. Project Manager The person assigned by the performing organization to lead the team that is responsible for achieving the project objectives. Project Schedule An output of a schedule model that presents linked activities with planned dates, durations, milestones, and resources. Proposal Evaluation Techniques The process of reviewing proposals provided by suppliers to support contract award decisions. Quality Audits A structured, independent process to determine if project activities comply with organizational and project policies, processes, and procedures. Quality Plan - A component of the project or program management plan that describes how an organization s quality policies will be implemented. Requirements Traceability Matrix (RTM) A grid that links project/product requirements from their origin to the deliverable that satisfy them. Resource Breakdown Structure (RBS) A hierarchical representation of resources by category and type. Risk Plan A component of the project, program, or portfolio management plan that describes how risk management activities will be structured and performed. Risk Mitigation A risk response strategy whereby the project team acts to reduce the probability of occurrence or impact of a risk Risk Register A document in which the results of risk analysis and risk response planning are recorded. COLLABORATE 13 OAUG Forum P a g e 9

Scope Creep The uncontrolled expansion to project scope without adjustments to time, cost, and resources. Scope Plan A component of the project or program management plan that describe how the scope will be defined, developed, monitored, controlled, and verified. Stakeholder Analysis A technique of systematically gathering and analyzing quantitative and qualitative information to determine whose interests should be taken into account throughout the project. Stakeholder Plan A subsidiary plan of the project management plan that defines the processes, procedures, tools, and techniques to effectively engage stakeholders in project decisions and execution based on the analysis of their needs, interests, and potential impact. Stakeholder Register A project document including the identification, assessment, and classification of project stakeholders. SWOT Analysis Analysis of strengths, weaknesses, opportunities, and threats of an organization, project, or option. Systems Integrators - A person or company that specializes in bringing together component subsystems into a whole and ensuring that those subsystems function together, a practice known as system integration. Systems integrators may work in many fields but the term is generally used in the information technology (IT) field, the defense industry, or in media. Three-Point Estimating A technique used to estimate cost or duration by applying an average of optimistic, pessimistic, and most likely estimates when there is uncertainty with the individual activity estimates. Work Breakdown Structure (WBS) A hierarchical decomposition of the total scope of work to be carried out be the project team to accomplish the project objectives and create the required deliverables. COLLABORATE 13 OAUG Forum P a g e 10