Scope Control

Who hasn’t been on a project where scope creep is an issue? One of my pet peeves is when people try to add functionality (or even a bug fix) and don’t realize they need to inform the Project Manager and all prior documentation has to be changed. An engineer may be able to code a fix very quickly, but if he does that has ramifications on documentation, schedule management and quality control (to name a few). When someone tries to pull this, I always draw the infamous triangle of scope, time/cost and resources. If one changes, the others will as well.

 

One way to formally control this is to implement a formal scope verification process where you require a change to be communicated to the stakeholders’ for formal acceptance of the completed project scope and associated deliverables. Verifying the project scope includes reviewing deliverables to ensure that each is completed satisfactorily. If the project is terminated early, the project scope verification process should establish and document the level and extent of completion.

 

Scope verification differs from quality control in that scope verification is primarily concerned with acceptance of the deliverables, while quality control is primarily concerned with meeting the quality requirements specified for the deliverables.

 

Quality control is generally performed before scope verification, but these two processes can be performed in parallel; and when a change occurs (that is accepted) all project team members need to re-examine their project documents and schedule. Any corrective changes go to the project manager and new plans and schedules are produced. Then a process of verifying the scope occurs. The following lists potential outputs from Scope verification:

 

·         Accepted Deliverables The Scope Verification process documents those completed deliverables that have been accepted. Those completed deliverables that have not been accepted are documented, along with the reasons for non-acceptance. Scope verification includes supporting documentation received from the customer or sponsor and acknowledging stakeholder acceptance of the project’s deliverables.

·         Requested Changes Requested changes may be generated from the Scope Verification process, and are processed for review and disposition through the Integrated Change Control process.

·         Recommended Corrective Actions

 

 

For a successful project, the Project Manager is in charge of scope control. Scope control is concerned with influencing the factors that create project scope changes and controlling the impact of those changes. Scope control assures all requested changes and recommended corrective actions are processed through the project Integrated Change Control process. Project scope control is also used to manage the actual changes when they occur and is integrated with the other control processes. Uncontrolled changes are often referred to as project scope creep. Change is inevitable, thereby mandating some type of change control process. The biggest thing to remember is to communicate to all team members and stake holders during this process. It is wise to institute a formal change control system.

 

A project scope change control system, documented in the project scope management plan, defines the procedures by which the project scope and product scope can be changed. The system includes the documentation, tracking systems, and approval levels necessary for authorizing changes. The scope change control system is integrated with any overall project management information system to control project scope. When the project is managed under a contract, the change control system also complies with all relevant contractual provisions.

 

Project performance measurements are used to assess the magnitude of variation. Important aspects of project scope control include determining the cause of variance relative to the scope baseline and deciding whether corrective action is required. Earned value management is very helpful here.

 

Approved change requests affecting the project scope can require modifications to the WBS and WBS dictionary, the project scope statement, and the project scope management plan. These approved change requests can cause updates to components of the project management plan.

 

A formal configuration management system provides procedures for the status of the deliverables, and assures that requested changes to the project scope and product scope are thoroughly considered and documented before being processed through the Integrated Change Control process.

 

 

Building a Work Breakdown Structure

Building a Work Breakdown Structure

The WBS is a deliverable-oriented hierarchical decomposition of the work to be executed by the project team, to accomplish the project objectives and create the required deliverables. The WBS organizes and defines the total scope of the project. The WBS subdivides the project work into smaller, more manageable pieces of work, with each descending level of the WBS representing an increasingly detailed definition of the project work. The planned work contained within the lowest-level WBS components, which are called work packages, can be scheduled, cost estimated, monitored, and controlled.

 

On projects I’ve worked on, the project team would go into a conference room and use post it notes for each piece of work until we reached something that was a week or less. NOTE: It’s easiest to bring a roll of paper to put the post it notes on so you can roll the whole thing up to input it into soft format.

 

The WBS represents the work specified in the current approved project scope statement. Components comprising the WBS assist the stakeholders in viewing the deliverables of the project.

 

Work Breakdown Structure Templates

 

Although each project is unique, a WBS from a previous project can often be used as a template for a new project, since some projects will resemble another prior project to some extent. For example, most projects within a given organization will have the same or similar project life cycles and, therefore, have the same or similar deliverables required from each phase. Many application areas or performing organizations have standard WBS templates.

 

The Project Management Institute Practice Standard for Work Breakdown Structures provides guidance for the generation, development, and application of work breakdown structures. This publication contains industry-specific examples of WBS templates that can be tailored to specific projects in a particular application area. A portion of a WBS example, with some branches of the WBS decomposed down through the work package level.

 

Decomposition

 

Decomposition is the subdivision of project deliverables into smaller, more manageable components until the work and deliverables are defined to the work package level. The work package level is the lowest level in the WBS, and is the point at which the cost and schedule for the work can be reliably estimated. The level of detail for work packages will vary with the size and complexity of the project.

 

Decomposition may not be possible for a deliverable or subproject that will be accomplished far into the future. The project management team usually waits until the deliverable or subproject is clarified so the details of the WBS can be developed. This technique is sometimes referred to as rolling wave planning.

 

Different deliverables can have different levels of decomposition. To arrive at a manageable work effort (i.e., a work package), the work for some deliverables needs to be decomposed only to the next level, while others need more levels of decomposition. As the work is decomposed to lower levels of detail, the ability to plan, manage, and control the work is enhanced. However, excessive decomposition can lead to non-productive management effort, inefficient use of resources, and decreased efficiency in performing the work. The project team needs to seek a balance between too little and too much in the level of WBS planning detail.

5

Decomposition of the total project work generally involves the following activities:

 

·         Identifying the deliverables and related work

·         Structuring and organizing the WBS

·         Decomposing the upper WBS levels into lower level detailed components

·         Developing and assigning identification codes to the WBS components

·         Verifying that the degree of decomposition of the work is necessary and sufficient.

 

This analysis requires a degree of expert judgment to identify all the work including project management deliverables and those deliverables required by contract. Structuring and organizing the deliverables and associated project work into a WBS that can meet the control and management requirements of the project management team is an analytical technique that may be done with the use of a WBS template. The resulting structure can take a number of forms, such as:

 

·         Using the major deliverables and subprojects as the first level of decomposition.

·         Using subprojects where the subprojects may be developed by organizations outside the project team. For example, in some application areas, the project WBS can be defined and developed in multiple parts, such as a project summary WBS with multiple subprojects within the WBS that can be contracted out. The seller then develops the supporting contract work breakdown structure as part of the contracted work.

·         Using the phases of the project life cycle as the first level of decomposition, with the project deliverables inserted at the second level.

·         Using different approaches within each branch of the WBS, where test and evaluation is a phase, the air vehicle is a product, and training is a supporting service.

 

Decomposition of the upper level WBS components requires subdividing the work for each of the deliverables or subprojects into its fundamental components, where the WBS components represent verifiable products, services, or results. Each component should be clearly and completely defined and assigned to a specific performing organizational unit that accepts responsibility for the WBS component’s completion. The components are defined in terms of how the work of the project will actually be executed and controlled. For example, the status reporting component of project management could include weekly status reports, while a product to be manufactured might include several individual physical components plus the final assembly.

 

Verifying the correctness of the decomposition requires determining that the lower-level WBS components are those that are necessary and sufficient for completion of the corresponding higher-level deliverables.

 

Outputs of Creating a WBS:

 

·         Project Scope Statement (Updates): If approved change requests result from the Create WBS process, then the project scope statement is updated to include those approved changes.

·         Work Breakdown Structure: The key document generated by the Create WBS process is the actual WBS. Each WBS component, including work package and control accounts within a WBS, is generally assigned a unique identifier from a code of accounts. These identifiers provide a structure for hierarchical summation of costs, schedule, and resource information.

 

The WBS should not be confused with other kinds of breakdown structures used to present project information. Other structures used in some application areas or other Knowledge Areas include:

 

·         Organizational Breakdown Structure (OBS). Provides a hierarchically organized depiction of the project organization arranged so that the work packages can be related to the performing organizational units.

·         Bill of Materials (BOM). Presents a hierarchical tabulation of the physical assemblies, subassemblies, and components needed to fabricate a manufactured product.

·         Risk Breakdown Structure (RBS). A hierarchically organized depiction of the identified project risks arranged by risk category.

·         Resource Breakdown Structure (RBS). A hierarchically organized depiction of the resources by type to be used on the project.

 

The WBS Dictionary

 

The document generated by the Create WBS process that supports the WBS is called the WBS dictionary and is a companion document to the WBS. The detailed content of the components contained in a WBS, including work packages and control accounts, can be described in the WBS dictionary. For each WBS component, the WBS dictionary includes a code of account identifier, a statement of work, responsible organization, and a list of schedule milestones. Other information for a WBS component can include contract information, quality requirements, and technical references to facilitate performance of the work. Other information for a control account would be a charge number. Other information for a work package can include a list of associated schedule activities, resources required, and an estimate of cost. Each WBS component is cross-referenced, as appropriate, to other WBS components in the WBS dictionary.

 

The Scope Baseline

 

The approved detailed project scope statement and it’s associated

WBS and WBS dictionary are the scope baseline for the project. The next step is to estimate all of the work packages and create your baseline schedule.

 

Using Earned Value to Predict Project Success

This Post examines how the data points of Planned Value (PV), Earned Value (EV), and Actual Cost (AC) can be used to analyze the current status of a project and forecast its likely future. EVM looks at project performance for the current period and at cumulative performance to date. EVM is described and illustrated here in terms of cumulative data, using the Project data.

This post introduces a fourth data point, Budget at Completion (BAC), which is the final data point on the performance measurement baseline (PMB). Budget at Completion represents the total Planned Value for the project. For Project EZ, the BAC is 150.

This is a goof rule of thumb:

• If your SV >0 and your SPI > 1.0, you are ahead of schedule and under budget. If your SV = 0 and your SPI > 1.0, you are on budget and ahead of schedule. If your SV < 0 and your SPI 0 and your SPI > 1.0, you are ahead of schedule and under budget. If your SV = 0 and your SPI > 1.0, you are on budget and ahead of schedule. If your SV < 0 and your SPI < 1.0 you are behind in budget and schedule.
• Indices: Schedule Performance Index (SPI); Cost Performance Index (CPI); and To-Complete Performance Index (TCPI)
• Forecasts: Time Estimate at Completion (EACt); Estimate at Completion (EAC); and Estimate to Complete (ETC)

These variances, indices, and forecasts can be used to answer the key project management questions. It lets us show the relationship between those project management questions and the EVM performance measures.

Schedule Variance (Are we ahead or behind schedule?)
The Schedule Variance (SV) determines whether a project is ahead of or behind schedule. It is calculated by subtracting the Planned Value (PV) from the Earned Value (EV). A positive value indicates a favorable condition and a negative value indicates an unfavorable condition.

The Schedule Variance can be expressed as a percentage by dividing the Schedule Variance (SV) by the Planned Value (PV). In other words, the project is 33 percent behind schedule, meaning that 33 percent of the planned work has not been accomplished.

Schedule Performance Index (How efficiently are we using time?)
The Schedule Performance Index (SPI) indicates how efficiently the project team is using its time. SPI is calculated by dividing the Earned Value (EV) by the Planned Value (PV). The Schedule Performance Index indicates that—on average—for each 8-hour day worked on the project, only 5 hours and 20 minutes worth of the planned work is being performed; that is, work is being accomplished at 67 percent efficiency. This is a very useful statistic to use in resource allocation.

Time Estimate at Completion (When are we likely to finish work?)

Using the Schedule Performance Index (SPI) and the average Planned Value (PV) per unit of time, the project team can generate a rough estimate of when the project will be completed, if current trends continue, compared to when it was originally supposed to be completed.

The originally estimated completion time for the project was 12 months, so the project manager now knows that if work continues at the current rate the project will take six months longer than originally planned. It is important to note that this method generates a fairly rough estimate and must always be compared with the status reflected by a time-based schedule method such as critical path method. It is possible that an earned value analysis could show no schedule variance and yet the project is still behind schedule; for example, when tasks that are planned to be completed in the future are performed ahead of tasks on the critical path.

One trick I always use is to have the engineers update their time on the project daily. This is quite normal. But I also have them update the remaining time that task will take. If the original estimate was 40 hours, and the engineer spent 20 hours on it, that does not mean he is 50% done. Software is very hard to predict and new things are learned as one gets deeper in the project. So if the culture allows the engineers to update their remaining work every day, I can run Project scenarios to see if the critical path has changed. I can also have a discussion with the engineer to see if we can work smarter to pull in the estimate. Most of the time, we don’t spend enough time estimating a project and just jump in and write code. This mode usually bites you in the end.

Next I will show an example I found using the techniques I’ve written about in this post.

Project Risk Identification

All projects have risks. It is the job of the Project Manager to identify these risks as part of the Risk Management Planning Process. Risk Identification determines which risks might affect the project and documents their characteristics. Participants in risk identification activities can include the following, where appropriate: project manager, project team members, risk management team (if assigned), subject matter experts from outside the project team, customers, end users, other project managers, stakeholders, and risk management experts. While these personnel are often key participants for risk identification, all project personnel should be encouraged to identify risks. I worked on a project where we used several of these techniques. I will point those out to you in the following sections.

 

Risk identification is an integrative process. The frequency of iteration and who participates in each cycle will vary from case to case. The project team should be involved in the process so that they can develop and maintain a sense of ownership of, and responsibility for, the risks and associated risk response actions. Stakeholders outside the project team may provide additional objective information. Especially important is the risk tolerance of the Stakeholders. This is invaluable information in Risk Planning.

 

The Risk Identification process usually leads to the Qualitative Risk Analysis process. Alternatively, it can lead directly to the Quantitative Risk Analysis process when conducted by an experienced risk manager. On some occasions, simply the identification of a risk may suggest its response, and these should be recorded for further analysis and implementation in the Risk Response Planning process.

 

Documentation Reviews

A structured review may be performed of project documentation, including plans, assumptions, prior project files, and other information. The quality of the plans, as well as consistency between those plans and with the project requirements and assumptions, can be indicators of risk in the project.

 

Information Gathering Techniques

I worked on a project where we spent three days planning the project. We engaged several experts in our technology to help us with the Information Gathering Techniques. This helped the project a lot since we (the project team) were not experts at the time of the project. They were very helpful in the brainstorming and Delphi techniques. During each following phase of the project, the Risk list should be looked at to see if any further risks have been identified.

 

Examples of information gathering techniques used in identifying risk can include:

 

·         Brainstorming. The goal of brainstorming is to obtain a comprehensive list of project risks. Our project team performed the brainstorming with a multidisciplinary set of experts not on the team. Ideas about project risk are generated under the leadership of a facilitator. Categories of risk such as a risk breakdown structure can be used as a framework.  (see earlier post) Risks are then identified and categorized by type of risk and their definitions are sharpened.

·         Delphi technique. The Delphi technique is a way to reach a consensus of experts. We used Project risk experts as well as Technology experts to participate in this technique anonymously. A facilitator uses a questionnaire to solicit ideas about the important project risks. The responses are summarized and are then sent back to the experts for further comment. Consensus may be reached in a few rounds of this process. The Delphi technique helps reduce bias in the data and keeps any one person from having undue influence on the outcome.

·         Interviewing. We also interviewed experienced project participants, stakeholders and subject matter experts to identify risks. Interviews are one of the main sources of risk identification data gathering.

·         Root cause identification. This is an inquiry into the essential causes of a project’s risks. It sharpens the definition of the risk and allows grouping risks by causes. Effective risk responses can be developed if the root cause of the risk is addressed.

·         Strengths, weaknesses, opportunities, and threats (SWOT) analysis. This technique ensures examination of the project from each of the SWOT perspectives, to increase the breadth of considered. Our project team used this technique to more fully examine the risks that had been identified.

·         Checklist Analysis. Risk identification checklists can be developed based on historical information and knowledge that has been accumulated from previous similar projects and from other sources of information. This means you have to record project information at the end of the project to build the historical database. The lowest level of the risk breakdown structure can also be used as a risk checklist. While a checklist can be quick and simple, it is impossible to build an exhaustive one. Care should be taken to explore items that do not appear on the checklist. The checklist should be reviewed during project closure to improve it for use on future projects.

·         Assumptions Analysis. Every project is conceived and developed based on a set of hypotheses, scenarios, or assumptions. Assumptions analysis is a tool that explores the validity of assumptions as they apply to the project. It identifies risks to the project from inaccuracy, inconsistency, or incompleteness of assumptions.

·         Diagramming Techniques. Risk diagramming techniques may include:

o   Cause-and-effect diagrams. These are also known as Ishikawa or fishbone diagrams, and are useful for identifying causes of risks. We used these frequently in projects.

o    System or process flow charts. These show how various elements of system interrelate, and the mechanism of causation. Seeing the flow sometimes triggers someone to identify a risk that may have slipped through the cracks.

o   Influence diagrams. These are graphical representations of situations showing causal influences, time ordering of events, and other relationships among variables and outcomes.

 

You can never spend too much time in identifying risks. After the list is made, qualitative and quantitative analysis is done to figure out which risks you spend time and/or money on. Murphy’s law is always a good one!

PM and BA Glossary

3-Pass approach: method of finding the critical path by working through calculations on the network three times: forward; backward; and once again to calculate the activity and network flexibility (float).

 

Acceptance: one of four possible strategies for response planning with regards to an identified risk; indicates the impact of the risk that can be tolerated at its identified level.

Active/visible observation: observing in a way that interacts with those being observed (i.e., asking questions and having others describe what they are doing and why).

Activity: component of work performed during the course of a project; also called a task.

Activity diagram: dynamic modeling technique used to show activities and decision points, and the roles assigned to them.

Administrative closure: the activities of the project team necessary to collect project records, analyze project success or failure, gather lessons learned, and archive project information for future use; performed when a project ends, when a project is terminated before work is complete, or at the end of each project phase.

Administrative closure process: includes perform product verification, complete final project performance reporting, obtain formal acceptance of project, perform lessons learned, create project archives, release resources, and celebrate!

Application architect: responsible for reviewing the requirements for feasibility and using them as a guide in developing the system architecture.

Application architecture: part of the enterprise architecture that shows how the various software applications interact.

Assumptions: things considered real, true, and certain for the purposes of planning; factor believed to be true but not confirmable or factor known to be true but that could change during the project.

Avoidance/elimination: one of four possible strategies for response planning with regard to an identified risk; indicates that risk cannot be tolerated to any degree and must be prevented from having any impact on the project.

 

BABOK: Abbreviation for IIBA’s Business Analysis Body Of Knowledge.

Backward pass: method of determining the late start time (LST) and late finish time (LFT) for each activity.

Baseline: project’s point of reference for requirements changes; established at the point of plan approval and should not be changed except in response to significant, approved change in the project scope.

Black box reverse engineering: deduces the system’s requirements from its behavior, without examining its code or other technical details.

BOSSCARD Framework: acronym for remembering project definition elements: Background; Objectives; Scope; Stakeholders; Constraints; Assumptions; Reporting; and Deliverables.

Brainstorming: requirement elicitation method that generates creative ideas among a group of people; success is dependent on participants’ creativity.

Business Analyst (BA): a person who identifies the business needs of clients and stakeholders to determine solutions to problems; responsible for requirements development and management; acts as a bridge between the client, stakeholders, and the solution team.

Business architecture: part of the enterprise architecture that shows the structure of the enterprise (that is, divisions, locations, etc.) and its product or service strategy.

Business constraints: limitations imposed on the solution related to business activities, (i.e., budget limitations); restrictions on the people who can do the work (skill sets available, etc.).

Business objective: defines why the project is important to the business and what the business needs to get from the project for the investment to be successful.

Business requirement: stated from the viewpoint of the business function and using that terminology.

Business risk: eventualities that could threaten the project; positive (opportunities) or negative impacts the project could have on the business.

Business rules: static modeling technique that looks at the rules governing business processes and decisions (regulation, company policy, etc.).

 

CAPM®: Certified Associate Project Manager; certification offered by PMI; requires less experience than PMP®.

Capability: the functionality of the specified system.

Cause-and-effect diagram: combines brainstorming and concept mapping to identify and consider a range of causes and impacts relative to a problem; also referred to as a fishbone diagram or an Ishikawa diagram.

CBAP: Certified Business Analysis Professional; certification offered by IIBA.

Class model: static modeling technique that looks at representations of each entity in a system, showing the attributes and activities of each; describes one or more objects with a uniform set of attributes and services, including a description of how to create new objects in the class.

Closed-ended surveys: survey method that limits the responders’ options to pre-selected choices; requires writing questions with great skill and care to avoid ambiguity or bias; provides quantitative data.

Communications Management: one of nine Knowledge Areas identified in the PMBOK® Guide; focuses on ensuring that project information is generated, collected, disseminated, stored, and disposed of in an appropriate and timely manner.

Communications planning: the process of determining what information will flow into and out of the project and who wants or needs that information.

Constraints: any limitations imposed on the project or solution; typically falls into the categories of time, cost and resources, scope, and quality.

Contingency plan: response plan formulated for identified risks if/when a risk is realized.

Cost/benefit analysis: technique focused on the identification of the associated costs and the related benefits.

Cost Management: one of nine Knowledge Areas identified in the PMBOK®Guide; focuses on planning, estimating, budgeting, and controlling costs so that the project is successful.

Crashing: identifying schedule compression alternatives along the critical path and taking action to decrease the total project duration; typically accomplished by adding resources to the critical path tasks.

Critical path: the longest path through the project network; the sequence of activities that defines the minimum time required to complete the project.

CRUD matrix: static modeling technique that looks at how each data element is created, read, used, and deleted.

Customer: person or organization that will use the project’s product, service, or result.

 

Database Analyst: a person who reviews requirements for feasibility and completeness, and uses them as a guide in developing the system’s database.

Data dictionary: static modeling technique that provides a detailed description of each data element, including its source (for primary elements) or how it is derived or computed (for composite elements).

Data-flow diagram: dynamic modeling technique that shows how data is shared among the various activities and entities in a system.

Data transformation/mapping: static modeling technique that shows the changes data elements go through.

Decision package: provides information that the decision makers need to make a decision about the proposed project; almost always includes both a document and a presentation.

Decision tree technique: provides a structure within which you can identify options and investigate the potential outcome of following these various options.

Decision tree: decision support tool that uses a graph or model of decisions and their possible consequences, including chance event outcomes, resource costs, and utility.

Decomposition: process of breaking something down into smaller constituent pieces; most effectively accomplished through the use of a work breakdown structure (WBS).

Deliverable: any unique and verifiable product, result, or capability to perform a service that must be produced to complete a process, phase, or project; the solution due to the customer at the end of a project.

Delphi: consensus-based estimating technique using anonymous inputs from the team working on the project.

Dependency: logical relationship between two schedule activities.

Developer: a person who reviews requirements for feasibility and ensures understanding; responsible for creating a product that satisfies the requirements.

Document analysis: requirement elicitation method that studies available documentation to leverage existing material; can be time-consuming and often information may be out of date.

Duration: actual amount of time to complete the activity or the actual time on task; measured as elapsed work time, includes resources

 

Earliest completion date: first date the project can be finished by; determined by adding the time to complete all of the activities on the critical path.

Effort: amount of actual work in an activity; measured in hours or staff days.

EFT: Early Finish Time; earliest point in time in a project network an activity can finish.

Eight-Stage model: leadership-based model of change including: Urgency; Guiding Coalition; Vision and Strategy; Communication; Empowerment; Short-Term Wins; Consolidation and Production; and Anchor New Approaches.

Elicitation: techniques used to extract requirements information from people, as well as from other sources.

Enterprise Analysis: one of six knowledge areas identified by the BABOK; analyzing needs and opportunities from the overall organizational perspective and recommending projects to improve specific business processes and systems.

ERD: Entity Relationship Diagram; static modeling technique that looks at the data entities in a system and how they relate to each other.

EST: Early Start Time; earliest point in time in a project network an activity can begin

Event identification: dynamic modeling technique that shows the events the system must respond to, and what its response should be to each.

Evolutionary prototype: used with an incremental development life cycle to discover precisely what should be built, rather than trying to specify it in full detail before development begins.

Executive sponsor: ultimate authority on the project.

Expectation gap: results from clients, sponsors, and the team, each holding different views of the project.

External dependencies: dependencies that exist between schedule activities and factors outside of the project, like the output from another project or goods and services provided by vendors.

 

Fast tracking: attempts to reduce the overall project schedule by overlapping activities that would normally be done in sequence; requires an increase in planning and coordination between the overlapped tasks.

Feature: service the system/solution provides to fulfill one or more stakeholder needs; typically high-level abstractions of a solution that turn into functional or non-functional requirements; allow for early priority and scope management and for getting a high-level sense of the stakeholders view of the solution.

Financial risk: unexpected project costs; costs of implementing or operating the proposed process.

Finish-to-finish precedence relationship: similar to start-to-start relationships, except that the point of relationship is at the end of the activity; predecessor activity must be completed in order for the successor activity to be completed.

Finish-to-start precedence relationship: most common; the predecessor must be 100-percent completed before the successor can begin.

Float: amount of time an activity can be delayed without affecting the project end date.

Focus group: requirement elicitation method that involves an interactive session with a carefully selected group of people; can be an effective way to capitalize on the synergy of a group if all participants feel free to interact.

Forced-field analysis: relatively simple but powerful means of comparing the forces that favor and oppose a given decision; provides a basis for weighing the importance of the forces affecting the decision; provides a range of options for carrying out decisions.

Forward pass: in a network diagram, allows you to calculate the EST and EFT for each activity.

Free float: the amount of time an activity can be delayed without affecting successor activities.

Functional design: observable behaviors of the solution; as opposed to technical design.

Functional requirements: define what the system must be able to do; describe both the systems behavior in detail and the information the system will manage.

 

Horizontal prototype: mockup of a broad area of a system that has little or no actual capability to do work; often used to review user interfaces or work flows.

Human Resource Management: one of nine Knowledge Areas identified by the PMBOK® Guide; focuses on organizing and managing the project team members.

 

IIBA: International Institute of Business Analysts; professional association for business analysts.

Implementation requirements: special set of conditions or capabilities that are needed only during system rollout or implementation.

Information Architect: a person who reviews requirements for feasibility and completeness and then uses them to derive the system’s information needs.

Information architecture: part of the enterprise architecture that shows how data flows within the organization.

Infrastructure Analyst: a person who reviews the requirements for feasibility and uses them as a guide in establishing the operational infrastructure that is necessary to support the solution.

Integration Management: one of nine Knowledge Areas identified by the PMBOK® Guide; focuses on the processes that integrate the various elements of project management that are identified, defined, combined, unified, and coordinated in the project management process groups.

Interview: requirement elicitation method that offers the opportunity for rich communication by meeting with either an individual or group of people.

 

Lags: waiting time inserted between the activities in a relationship (i.e., downtime).

Leads: partial overlapping of activities; essentially a head start for one activity, relative to the other in the relationship.

Lessons learned: identified at the end of each stage of the project and collected for cumulative analysis; gathers and documents what went right and wrong, what should be done differently, and what would you recommend to others.

LST: Late Start Time; the latest time an activity can begin without jeopardizing the project end date.

 

Mandatory dependencies: also referred to as hard dependencies or hard logic; characterized by a required order in the relationship between the activities.

Milestone: significant point or event in the project; point in time of significant accomplishment in the project.

Mitigation: one of four possible strategies for response planning with regard to an identified risk; indicates that the risk cannot be tolerated at its identified impact level, but cost acceptable steps can be taken to reduce the risk impact down to a tolerable level; always results in residual risk.

Modeling: representations of a business or solution that often include a graphic component along with supporting text and relationships to other components.

Murphy’s Law: adage in Western culture that broadly states “things will go wrong in any given situation, if you give them a chance”; or shorter “anything that can go wrong, will”.

 

Needs: type of high-level requirement that is a statement of a business objective, or an impact the solution should have on its environment.

Non-functional requirements: required system capabilities that do not describe functionality; examples include the number of end users, response times, fail-over requirements, usability, and performance; also known as supplementary requirements.

 

Object-oriented modeling: approach to software engineering where software is comprised of components that are encapsulated groups of data and functions which can inherit behavior and attributes from other components; and whose components communicate via messages with one another.

Observation: requirement elicitation method that involves watching people as they go about their jobs; can be an effective way to gain an understanding of how work is done in the production environment; can be time consuming and may disrupt work.

Open-ended surveys: allow the respondent to write out answers in their own words; are more difficult to analyze quantitatively than closed-ended surveys.

Operational management: focused on the development and execution of programs that sustain the organization and move it forward.

Optional dependencies: relationships in which the project manager has some influence over the sequence of the relationship; often referred to as soft logic dependencies or discretionary dependencies.

 

Paired-comparison analysis: technique for calculating the importance of a number of options relative to one another; especially useful when you do not have objective data to base the decision on.

Pareto principle: also called the 80/20 rule; based on Pareto’s study of the concentration of wealth in Italy that found 80 percent of the wealth was held by 20 percent of the people.

Pareto analysis: used for finding the changes that will yield the greatest benefits; particularly useful in situations with many competing alternatives.

Parkinson’s Law: concept that states “work will always expand to fill available time”; padding or expanding estimates simply encourages procrastination.

Passive/invisible observation: observing in a way that does not disturb the workers being observed.

PDM: Precedence Diagramming Method; places activities in boxes and shows the precedence relationship with arrows; also known as AoN (Activity on Node) or EoN (Event on Node).

PERT: Program Evaluation Review Technique; uses multiple points of estimate for the same activity to derive a weighted average estimate for the activity.

Phase: a collection of logically related project activities, usually culminating in the completion of a major deliverable.

PMBOK® Guide: Abbreviation for PMI’s Guide to the Project Management Body of Knowledge.

PMI: Project Management Institute, Inc.; professional association for project managers.

PMP®: Project Management Professional; certification offered by PMI.

Process: set of interrelated actions and activities performed to achieve a specified set of products, results, or services.

Product: solution, or component of a solution, that is the result of a project.

Product metrics: based on the product scope and requirements; give insight into whether the product being built will achieve its goals.

Project: (for project managers) unique, non-routine endeavor requiring an investment decision that has defined and agreed upon objectives and a start and end date; (for business analysts) specific, detailed, and coordinated steps through which programs accomplish the changes defined to enact the strategic plans.

Project charter: 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 Manager (PM): person ultimately responsible for the project, including ensuring that the final product satisfies the requirements.

Project metrics: based on the project’s goals and give insight into whether the project is likely to achieve those goals.

Project objectives: definition of what the project will accomplish.

Project risk: things that may impact the project’s ability to meet stakeholder expectations; uncertainty (both positive and negative) that matters to the project.

Prototyping: usage modeling techniques that mocks up a user interface, or the flow of screens or forms in a user interface, for review.

 

QA Analyst: a person who reviews the requirements to ensure that they are testable and that they meet quality standards and policies; responsible for testing the product after it is developed to see if the requirements were indeed satisfied.

Quality of Service (QoS) requirements: explain the way in which the system must provide the functional requirements (i.e. response times, security, usability, and maintainability); often called nonfunctional requirements.

Quality assurance: planned and systematic quality activities to ensure requirements are met.

Quality control: monitoring specific results for compliance with relevant quality standards.

Quality Management: one of nine Knowledge Areas identified by the PMBOK® Guide; focuses on ensuring that the project will satisfy the needs for which it was undertaken.

Quality planning: phase of identifying relevant quality standards and how to satisfy them.

 

RAM: Responsibility Assignment Matrix; structure that relates the project organizational breakdown structure to the WBS to ensure that each element of the scope of work is assigned.

Resource: includes skilled human resources (specific disciplines, either individually or in teams), equipment, services, supplies, commodities, materials, budgets, or funds.

Resource leveling: technique used to address resource overloads and ensure that resources are expected to perform realistically.

Resource load: total amount of assigned work within a timeframe.

Requirement: condition or capability needed by a stakeholder to solve a problem or achieve an objective.

Requirements Analysis and Documentation: one of six knowledge areas identified in the BABOK; making sense of the information that is elicited, organizing it, and documenting it in appropriate forms (that is, words, tables, models, and prototypes); describes how business, functional, and nonfunctional requirements can be assessed, documented, and presented.

Requirements analysis: defines the methods, tools, and techniques used to structure the raw data collected during requirements elicitation; identifies gaps in the information and defines the capabilities of the solution.

Requirements attribute: characteristic of a requirement that captures additional information, such as priority or level of risk.

Requirements Communication: one of six knowledge areas identified in the BABOK; involves providing requirements information to those who need it, when they need it, in the form that they need.

Requirements communication plan: defines the communication activities during a project used to ensure that requirements information is available to all project members when it is needed, and in a usable form.

Requirements discovery session: a forum (like a JAD) where stakeholders and SMEs get together to provide information about the target system.

Requirements document: captures and communicates gathered requirements.

Requirements Elicitation: one of six knowledge areas identified by the BABOK; the collection of activities and approaches for capturing the requirements of a target system from requirements information from various sources and stakeholders.

Requirements package: all the items that comprise the requirements for a project; defined based on the stakeholders for whom they are built and their needs and preferences.

Requirements planning and management: one of six knowledge areas identified by the BABOK; includes producing a plan for determining requirements activities on a project, and keeping those activities on track; includes managing changes to individual requirements and project scope

Reverse engineering: analyzing an existing system to understand what it does and why.

Reverse engineering requirements: method of identifying requirements by interviewing developers, reading code, and testing applications.

RFP: Request For Proposal.

RFQ: Request For Quote.

Risk mitigation: risk response strategy that takes action to reduce the probability and/or impact of a risk.

ROI: Return On Investment.

 

Satir change model: system view of change including seven stages: Old Status Quo; Foreign Element (change); Chaos; Transforming Idea; Integration; Practice; New Status Quo.

Scope: sum of the products, services, and results to be provided as a project.

Scope creep: changes that occur during a project that are neither recognized, evaluated, nor approved.

Scope exclusions: specifically indicate what work falls outside of the project boundaries.

Scope inclusions: indicate what the project is about and what it will do.

Scope Management: one of nine Knowledge Areas identified by the PMBOK® Guide; focuses on ensuring that the project includes all the work required, and only the work required, to successfully complete the project.

SDLC: Software Development Life Cycle.

Security architecture: part of the enterprise architecture that shows the security needs and practices within the organization.

Sequence diagram: dynamic modeling technique that shows the exact steps for a specific scenario; shows objects participating in interactions and the messages exchanged.

Sign off: formal, written approval gained throughout the project management processes at the end of a phase.

Solution Assessment and Validation: one of six knowledge areas identified by the BABOK; focuses on collaborating with the technical and quality assurance teams to ensure that the solution built satisfies the requirements and collaborating with business users to plan acceptance and rollout of the solution.

Solution owner: major supplier of requirements information, and is often an approver of the requirements; also referred to as the customer.

Sponsor: person or group that provides the financial resources for the project.

Stakeholder: persons or organizations that are actively involved in the project, or whose interests may be positively or negatively affected by execution or completion of the project, or who can exert influence in project decisions.

Start-to-finish precedence relationship: the predecessor activity that must begin in order for the successor to be completed; relatively rare.

Start-to-start precedence relationship: predecessor task that must be started before the successor task may be started.

State Machine Diagram: dynamic modeling technique that shows all the states the system can be in, and the possible transitions among those states.

States: exist in a system if the same input generates different responses in different situations; for example, a hotel has two states: “vacancy” and “no vacancy”, and a request for a room generates different results in those two states.

Storyboard/screen flows: usage modeling technique used to mock up a user interface, or the flow of screens or forms in a user interface; differs from a prototype in that these are not functional systems, rather they are often drawings.

Strategic planning: systematic and formalized effort to establish organizational purposes, objectives, and policies, and to develop plans to implement them.

Structured interview: has a detailed agenda and formal set of questions.

Subject Matter Expert (SME): a person who provides many important requirements, and in certain situations, may need to approve requirements.

Survey: requirement elicitation method that allows you to collect information from many people in a relatively short period of time.

SWOT (Strengths, Weaknesses, Opportunities. and Threats) Analysis: method of identifying project benefits.

 

Task: component of work performed during the course of a project, also called activity.

Technical constraints: limitations imposed on the solution related to business activities (i.e. architecture decisions that are made).

Technical risk: technological changes that could impact the project or technologies that may not work as expected.

Technical requirements: state requirements in terms that the implementation team needs (i.e. system or software requirements).

Technology architecture: part of the enterprise architecture that shows how different technologies support the business.

Throw-away prototype: prototype used to answer specific questions as a basis for development but is not meant to be used in the final system.

Time Management: one of nine Knowledge Areas identified by the PMBOK® Guide; focuses on ensuring that the project is completed in a timely manner.

Traceability: information that shows stakeholders the relationships between individual requirements and their sources; allows a BA to manage scope creep and ensure all requirements have been met.

Traceability association: exist between requirements when more detailed requirements are associated with the higher level requirements (i.e. needs and features); can also exist between detailed requirements and design models/test cases.

Transference: one of four possible strategies for response planning with regard to an identified risk; indicates that the risk cannot be tolerated but the cost of elimination is too great, so ownership of risk response and impact are shifted to a third party.

Triple-constraints model: notes the relevant constraints of time, scope, and cost/resources that are shared by all projects; provides a basis for planning project controls.

                                                                                                             

Unstructured interview: has only a loose agenda, depending more on ad hoc interaction.

Use-case descriptions: usage modeling technique that identifies the specific steps that will happen in a particular transaction (or use case) along with entry and exit conditions and other relevant information; usually necessary to describe the use cases depicted in a use case diagram.

Use-case diagrams: usage modeling technique that captures all actors and use cases involved with a system or product.

User interface designs: usage-modeling technique that is similar to storyboards and screen flows, but used much earlier in the analysis process.

User profile: usage-modeling technique that lists the end users of a system, including relevant attributes of each.

User requirements: subset of business requirements that address the needs of specific users to do their jobs.

User story: usage-modeling technique that is similar to use case descriptions, but with much less detail.

 

Validation: checking requirements to be sure that they are correct, complete, and feasible.

Verification: checking requirements to ensure that they have been written and specified well; should be done before validation.

Vertical prototype: detailed view or functional model of a narrow area of a system; often used to test the feasibility.

 

WBS: Work Breakdown Schedule; deliverable-oriented, hierarchical decomposition of project elements that defines the total work scope of the project.

Wide-band Delphi: works just like normal Delphi, except that the successive estimating rounds focus on the inputs that PERT requires.

White box reverse engineering: examines the program code and other technical details to determine not just what it does, but why and how it does those things.

Work package: deliverable or project work component at the lowest level of each branch of the WBS.

Workflow models: dynamic modeling technique that diagrams the flow of activities among responsible parties.

Workshop: requirement elicitation method that involves a structured meeting with a group of people to generate many ideas in a short period.

 

Minimum Expectations for a Project Manager

The purpose of any project methodology is to define a repeatable process that increases the probability of meeting or exceeding customer expectations of project scope, time, cost & quality.

 

Since all projects are different to some degree, the methodology should be flexible to meet projects of different size and complexity.  A “flexible” toolkit is needed with both required and optional tools that can be tailored as needed to deliver project results.

 

Regardless of the size and complexity, all projects should be managed to some minimum expectations.  The level of effort and document detail will vary, but the basic management expectations are consistent.

 

Leadership has agreed on the following minimum project management expectations:

 

1. Define the scope of work, business requirements and project deliverables.
2. Identify work required to achieve project deliverables.
3. Prepare project timeline of project milestones and deliverables.
4. Identify resources required to achieve project deliverables.
5. Track project progress.
6. Report project status.
7. Plan and manage project resources.
8. Plan and manage stakeholder communications.
9. Plan and manage project risks and issues.
10. Plan and manage project quality.
11. Plan and manage changes to project scope, timeline and resources.
12. Ensure project deliverables are transitioned.
13. Close the project.

 

The level of effort and the documentation detail required for each of these expectations should be agreed upon between the Project Manager and the Project Sponsor at the outset of the project.  Multiple versions of some tools are included in the “flexible” toolkit to help the project manager adjust to project size and complexity.

 

The Sponsor is accountable for ensuring these minimum expectations are being met through a “health check” process.  Frequency and level of detail of the “health check” will depend on the size and complexity of the project, but at a minimum will occur at the end of each project.

 

Management and Leadership is accountable for encouraging the use of the methodology and auditing its use through ad hoc project reviews.

 

The Project Management Group is accountable for day-to-day support, mentoring and training.  The Project Management Group will also provide performance metrics based on project “health checks”.

Decision Trees

A decision tree is a popular tool to use to share information about risks using expected value. Every decision has an outcome and something will happen as a result of the decision. The decision “tree” helps us decide whether we can live with the choices we make; if we choose to eat lunch out or stay in for lunch, whether to build or buy, whether to pursue a line of business or not. These events are out outcomes of whatever decisions are made – not on probability.  However, the outcomes of events do have a probability associated with them. There is a chance they will occur, as well as a chance they will not. It’s important to acknowledge that the outcomes from a single event are mutually exclusive of one another. If outcome 1 happens; outcome 2 cannot. If outcome 2 happens, outcome 1 cannot. For that reason, we can determine their probabilities clearly. If there are only 2 outcomes, and there’s a 40% chance of outcome 1 occurring, then there is always a 60% chance of outcome 2 occurring. The multiple of the outcomes will always sum to 100%.

Here is an example. We have a decision called “where to eat lunch”. We have 3 possible choices which lead to an outcome. The outcome is either “keep customer” or “lose customer”. For this example, we are associating some probabilities and some values of the outcomes. These values are not “Expected values”, but simply values of the outcomes if they come to pass. The costs of the meals are also included. Costs associated with the outcomes represent lost business through negative word of mouth communication. Revenues associated with outcomes represent newly acquired business by virtue of the positive experiences associated with the meal.

So we have 1 Decision – Where do we eat? There are 3 choices, we can eat at a hot dog vendor for – $10, fast food for -$20, or Fine dining for -$150. If we eat at the hot dog vendor we stand a 10% chance of keeping the customer which leads to outcome 1 ($500). That gives us a 90% chance of losing the customer if we eat at the hot fog vendors place (-$600). Choice 2 is eating at a fast food place costing -$20. It leads to a 40% chance of keeping the customer valued at $750 and a 60% chance of losing the customer valued at -$300. The third choice is fine dining costing -$150 leading to a 60% chance of keeping the customer valued at $1000 and a 40% chance of losing the customer valued at -$100.

Now we have enough information to figure out the best outcomes for our company. If for example, we select a hot dog vendor for this client lunch and achieve a positive outcome, the total benefit for the company will be $490 (outcome of event – cost of lunch). If we choose last food and have a positive outcome with the customer, the net benefit to the customer is $730.

When looking at risks, we need to also take the potential losses into consideration. Returning to the hot dog example, the negative impression generated may cost an additional $600 in lost business. That combined with the initial cost of the lunch would mean losses to the company on the order of -$610.

 

Stay tuned for part 2.

 

Donna

Negotiation

Negotaition is a great skill for anyone to have. On almost every project I’ve been involved with, there has come a time when I needed someone else to do something for the success of my project. The most important advice I can give you is to “seek first to understand” where the other person is coming from. To them, their project may be the most important thing on earth. If you first understand that, you can come up with some win-win scenarios where their project and yours both get done in a timeframe that is acceptable to both of you – and they will appreciate that you took the time to understand their constraits. In the end, you probably both work for the same person, so you both want that person to succeed. Going out of your way to ensure both projects work out is to the interest of both of you. Never come at someone with the attitude that what you are doing is more important than what they are doing. Honey wins over vinegar every time!

 

ttfn, Donna

Team Building

I have often found that the key to any endeavor, including Project Management or Coaching, lies around building a good relationship. Think back to the most effective teams or relationships you have ever had. Did it have characteristics such as?

· Mutual trust

· Honesty and integrity

· Confidentiality

· Valuing differences

· Having fun

· Being respected (I once worked on a team where everyone was given a ping pong gun. If they caught anyone disrespecting another, they were allowed to shoot them).

· Clearly defined “SMART: goals. (S = specific, M= measureable, A = attainable, R = realistic and T = time based)

· Responsibility that is expected in all the members of the team’s work – there is no such thing as “It’s not my job”

· Shared responsibility, accountability and rewards tied to performance

· Frequent celebrations when called for

· Ability to make decisions (the only way to learn is to take risks)

· Mutual support and mentoring

· AND the most important thing is a Leader who leads, sets a vision and allows sharing of ideas from all team members

Team Spirit is vital to the making of a team that works. It is the ability to work on ones’ own, feel free to ask for help and share the glory of your combined work. That is the reason why team communication and team building is so important.

When I first start a team, I have everyone take an assessment and share the results with each other. Everyone communicates differently and if you know the style of your team member it will go a long way in making that relationship successful. I also take the assessment and share it with the team. Pretty soon it gets to be fun when person A witnesses Person B reacting to Person C in a way that is uncomfortable for person C. If it is caught in the moment, people can laugh about it and not let it get in their way. Some teams I’ve worked on even go so far as wearing a badge that signifies their personality traits.

If a team is built with these suggestions in mind, they will work towards the goal of overall team success and not individual success. You may find a person or two who won’t follow this team building activity. If you run into this case, either remove the person from the team, or if this is not possible, give them a chance to see others make it work. People in general, want to do a good job and want their team to succeed.

On-going training for the team is essential and will keep the ideas fresh in their heads. It is also beneficial to have some bonding time like playing softball or some activity outside of work.

Another technique that is beneficial is to have a scoreboard that states how the team is doing towards making their goals. This should not be used to single out anyone, but to find areas where mentoring or training can help the overall team. Whenever the team beats its goals, the success should be celebrated. You’d be amazed how quickly the team will strive for high results.

There are two major types of teams: the ongoing team and the project team. We are going to concentrate on project teams since work that is of an ongoing nature is defined as an operation, not a project. The exception to this is in a matrix organization where the functional managers are in charge of the teams and loan them to the project manager for the duration of the project. IT team, the marketing-research team, and the accounts payable team.

Project teams are formed for a particular purpose; to complete the project. They usually disband when their mission is accomplished. The mission that binds them is the project’s mission and it falls upon the project manager to instill the leadership required to build followers of the project’s mission.

There are many benefits to be working on a project team. The social aspects as well as the opportunities for less experienced members to learn from the more experienced members along with the abilities for the more experienced members to mentor and learn from that experience. The synergy that the team provides allows them to make better decisions than if they were working in isolation. Everyone has a different skill set to bring to the table. As we all have learned “the whole is larger than the sum of its parts”.

I’d like to say a little bit about team leaders. Some schools of thought are that the subject matter experts should be the team leaders. As I said before, everyone has a different skill set to bring to the table and most people who concentrate on becoming the expert in a particular technology are usually introverts and aren’t the one you want to resolve conflict between team members, keep the team on track and keep them energized. These folks usually are better at people skills, negotiations and are typically extroverts. That’s why having a mixture of talent makes up the best team. I once heard a Vice President talk to me about his staff. He said he always looked for people that were not like him, giving him a well rounded staff that came out with better solutions than a bunch of “Yes” men would have.

Another possibility is to train people to take over in leadership positions. The fact is you are born with natural abilities and you can be trained, but in a crisis situation will usually revert back to what you were born with. It is also a very unique individual who is good at everything required to run the business.

In the end, have fun with what you do and do what fulfills you!

Risk Definitions – PMP 1

Now here are some definitions you may find on the PMP exam:

 

Uncertainty

Lack of knowledge of future events

Goals of PRM

To identify project risks and develop strategies which either significantly reduce them or take steps to avoid them.

Opportunity

The probability those outcomes will be favorable.

Risk

The probability those outcomes will be unfavorable.

Project Risk

Is the cumulative effect of the chances of uncertain occurrences adversely affecting project objectives.

Risk Factors

1.      Risk Event – Precisely what might happen to the detriment of the project

2.      Risk Probability – How likely the event is to occur

3.      Amount at Stake – The severity of the consequences

Probability

Probability = Frequency of relevant events

                      Total number of possible events      

Risk Event Status (criterion value or ranking)

Risk Event status = risk probability x amount at stake

Processes

1.      Risk Identification

Determining which risks are likely to affect the project and documenting the characteristics of each.  Can be classified as:

a.      Scope – Risk associated with changes of scope or the subsequent need for “fixes” to achieve the required technical deliverables.

b.      Quality – Failure to complete tasks to the required level of technical or quality performance

c.       Schedule – Failure to complete tasks within the estimated time limits, or risks associated with dependency network logic

d.      Cost – Failure to complete tasks within the estimated budget allowances

2.      Risk Quantification

Evaluating risks and risk interactions to assess the range of possible project outcomes.

3.      Risk Response Development

Defining enhancement steps for opportunities and responses to threats.

4.      Risk Response Control

Responding to changes in risk over the course of the project.

Identification

1.      Inputs

a.      Product description

Risk depends on the nature of the product.  Proven technology has less risk than products requiring innovation and invention.

b.      Other Planning outputs

Review outputs from the processes for possible risks, e.g., WBS, cost estimates and schedule duration’s, staffing plan, procurement management plan.

c.       Historical information

2.      Tools and Techniques

a.      Checklists

b.      Flowcharting

Helps understand the cause and effects of risks.

3.      Outputs

a.      Sources of Risks

This includes such items as stakeholder actions, unreliable estimates, team turnover, changes in requirements, insufficiently skilled staff.

b.      Potential Risk Events

Precisely what might happen to the detriment of the project, such as natural disasters, requirement for development of new technology, etc.

c.       Risk symptoms

These sometimes are called triggers, early warning of an impending event, etc.

d.      Inputs to other processes

Risks can be inputs to other processes as constraints or assumptions.

Quantification

1.      Inputs

a.      Stakeholder risk tolerances

This provides a screen for both inputs and outputs to risk quantification.

b.      Sources of risk

c.       Potential risk events

d.      Cost Estimates

e.      Activity duration estimates

2.      Tools and Techniques

a.      Expected Monetary value

This is the product of risk event probability of occurring times the risk event value (could be a gain or loss).

b.      Statistical sums

This calculates the range of alternative project budgets from the cost estimates for individual work items.

c.       Simulation

The most common is Monte Carlo analysis, which is used to analyze the behavior or performance of the system. The results of a schedule simulation may be used to quantify the risk of various schedule alternatives, different project strategies, and different paths through the network or individual activities.

d.      Decision Tree

e.      Expert Judgment

3.      Outputs

a.      Opportunities to pursue, threats to respond to

This is a list of opportunities that should be pursued and threats that require attention.

b.      Opportunities to ignore, threats to accept