Taking the PMP Certification Test – My Advice

Taking the PMP Certification test is very anxiety provoking. When the test starts, there is a 15 minute tutorial on how to take the test. The only thing they let you have is paper and pencil in the testing facility. I learned a few tricks in taking the test (which is 4 hours).

·         As soon as they started the clock, I wrote down as many equations as I could. This way I would have that sheet to refer to later on in the test when I was stressed out. You can get this done in the first 15 minutes and use it later.

·         I took a 5-10 minute break every hour to get a snack, water and stretch my legs.

·         The allow you to mark a question that you want to come back to if you are not sure of the answer, so I went through all of the questions and marked a few but went on. I wanted to answer as many questions as possible and not get stuck on one hard one.

·         One thing to remember is the questions are very situational in nature. This means more than one answer can look correct. They also us the famous “none of the above” or “all of the above”. Those questions freak me out!

·         The test database is huge and your test is randomly selected so no two tests are exactly alike.

This was what I wrote down as fast as I could in the first 15 minutes so I could refer to it after my brain turned to mush.

·         I wrote down all of the knowledge areas, inputs, tools and techniques and outputs. This helped me figure out a lot of questions.

·         I wrote down all of the formulas I could think of: they included:

o   Expected Monetary Value (EVM) = Risk event probability X event value

o   Expected Cost = Sum of products of Expected Monetary Value

o   Expected Time = optimistic estimate + 4*most likely estimate + pessimistic estimate/6

o   Activity Standard deviation = pessimistic estimate –optimistic estimate/6

o   One standard deviation = 68 +/- % on a bell curve

o   Two standard deviations = 95 +/- % on a bell curve

o   Three standard deviations = 99 +/- % on a bell curve

o   The number of communications channels = n (n-1)/2 where n is the number of people.

o   Earned value terns are Earned value = EV, Planned Value = PV and Actual Cost = AC.  In an equation in Earned Value Management, EV always comes first.

o   Variance = Budged – Actual

o   Subtract for variance

o   Divide for Performance Index

o   SV = EV – PV (plus means ahead of schedule, minus means behind schedule

o   CV = EV – AC (plus means under budget, minus means over budget

o   Cumulative CPI = sum of EV/sum of AC

o   Variance at completion VAC = BAC – EAC

o   There are four ways to calculate EAC

§  EAC = BAC/CPI (assumes that whatever affected past results will also affect future results)

§  EAC = AC + remaining BAC/CPI (alternate way to get same results)

§  EAC = AC + remaining BAC (assumes that whatever affected past results will NOT affect future results)

§  EAC = AC + ETC (assumes that enough has changed to warrant a new estimate.

Good luck taking the exam. When I completed going through the questions I thought I knew the answer to, I had 30 minutes to look back at the ones I had marked. I didn’t change any of them. I panicked when I pressed the “Complete” button (which I didn’t until they rang the stop clock) and it seemed like an eternity, but I ended up with a 98% score! If I can do it, so can you!

 

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.

 

Risk Management Plan

What Goes Into a Risk Management Plan?

Whenever I managed a project, I paid a lot of attention to the Risk Management Planning. PMI is working on a Standard for Risk Management which can tell you just how important it is to make or break a successful project. It is a subject worthy of an entire standard.

The things the Risk Management Plan includes are:

1.   Risk Management Planning – this is deciding how to approach, plan and execute the risk management activities for a project.

2.   Risk Identification – this determines which risks may affect the project and documenting their characteristics. Some risks are not important enough to do further work on them. This all depends on the risk tolerance of the Stakeholders. For example, if you were buying a car and identified the risks as having a major repair or replacing a tire, you may consider the risk of replacing a tire not to be of significant consequence to stop you from buying the car. If, however, you thing the risk of losing the engine block to be high, you would probably pass on the car.

3.   Qualitative Risk Analysis – this is the process of prioritizing risks for subsequent further analysis or action by accessing and combining their probability of occurrence and impact. In the car analogy, replacing the tire may have a high probability but a low impact. In this case, you may cease to analysis it further but perhaps put a budget contingency in for the possible replacement.

4.   Quantitative Risk Analysis – this is where you numerically analyze the effect on the overall project objectives of the identified risks.

5.   Risk Response Planning – for a subset of the identified risks, you develop options and actions to enhance opportunities, and to reduce threat to project objectives. Note: not all risks are bad. You may have a risk of getting increased resources.

6.   Risk Monitoring and Control – this is where you track identified risks, monitor residual risks (that may come from an action to reduce the primary risk), identify new risks, execute risk response plans and evaluate their effectiveness during the project life cycle.

 

These processes interact with each other and with the processes of the other knowledge areas. Each process can involve effort from one or more groups of team members based on the needs of the project. Processes in practice may overlap and interact in details not presented in this post. I will write a separate post talking about process interactions.

[i]

 

---

[i] Most of this information can be found in Guide to the Project Management Body of Knowledge (PMBOK Guide) 3^rd addition. @2004 Project Management Institute, Four Campus Boulevard, Newton Square, PA 19703-3299 USA

What Goes Into a Project Plan?

What goes into a Project Plan?

1.   The Scope Management Plan: This is a document that defines the Scope of the Project. It is especially important to be though and accurate because it feeds into the Requirements document. It is also important that all the Stakeholders buy into it. It should be signed off before going the next step. If the Scope changes it has to go through a change management process and all of the Stakeholders must sign off on it.

2.   Schedule Management Plan: The Schedule Management Plan is a component part of the Project Plan that is use in Activity resource planning. The Activity resource plan includes expert judgment, various levels of resource levels or skills, size of machines, tools and make/buy decisions.

3.   Cost Management Plan: Costs will adhere to a prescribed precision based on the scope of the project and may include a contingency amount. Various cost measures or other indicators (e.g. person-days, volume of product).

4.   Quality Management Plan: The Quality Management Plan describes how the project team will implement the organization’s quality policy. It must address the quality control, quality management and continuous process improvement for the project.

5.   Staffing Management Plan: Identifying project roles, responsibilities and reporting relationships. Obtaining the human resources to complete the project. Improving the competencies and interaction of team members to enhance project performance. Team building plays a big part here.

6.   Communications Plan: Determining the information needs of the stakeholders. Making needed communications available to the stakeholders in a timely manner. Collecting and distributing performance information including status reports, performance reports and forecasting.

7.   Risk Management Plan: The Risk Management Plan includes risk identification, risk analysis, risk response planning, monitoring and control.

8.   The Procurement Plan: This plan includes what has to be procured, who will provide the estimates, types of contracts to be used, managing multiple providers, constraints and assumptions that could affect the contract and handling make/buy decisions. [i]

---

[i] Guide to the Project Management Body of Knowledge (PMBOK@ Guide) Third Edition @2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA

9 Top Things to Make a Successful Project

These are the 9 things that make a wonderful project!

1.   Know who your Stakeholders are. These are the people you have to communicate to. No one likes surprises!

2.   Spend a lot of time getting the scope right and signed off on. If the scope isn’t correct or sufficient, you will never get your requirements correct.

3.   Spend lots of time on your work breakdown structure. Break it down into work packages until they cannot be broken down further. A rule of thumb I use is a work package cannot be more than 40 hours.

4.   Spend a lot of time in team building. A good team works harder and produces a better product (and also has more fun!). Also reward them with a party or outing at the end of a successful project.

5.   Follow the SDLC. If the scope changes after you have written the Requirements documents, the Requirements documents must change accordingly. This follows all the way down the line. It is very important that you educate your Stakeholders that a change must go through a change review process, documents must change and the schedule will be extended.

6.   Manage people’s time on a daily basis. Not only do you want the time they spent on their task but also the remaining work. If you first estimate something at 40 hours and are 20 hours through, that doesn’t mean you are 50% done with the project. This way you can manage the schedule closely by putting an additional resource, dropping other functionality or whatever makes sense so you can make your schedule.

7.   Never surprise anyone. I make it a habit to never surprise my Stakeholders. As soon as an issue comes up, communicate it and brainstorm on options. I also tell all my team members to never surprise me. If I get bad news as soon as it happens, I have time to recover. If I get it 2 weeks before shipping I get very angry.

8.   Spend lots of time on Risk planning, Risk analysis and contingency planning. You can never spend too much time.

9.   Monitor the project carefully. Your critical path can change in an instant so you must look at it at least weekly.

 

Basic Concepts of Earned Value Management

 

Planned Value (PV): describes how far along project work is supposed to be at any given point in the project schedule. It is a numeric reflection of the budgeted work that is scheduled to be performed, and it is the established baseline (also known as the performance measurement baseline or PMB) against which the actual progress of the project is measured. Once established, this baseline may only change to reflect cost and schedule changes necessitated by changes in the scope of work. In previous versions of the PMBOK this was known as the Budgeted Cost of Work Scheduled (BCWS). Planned Value is usually charted showing the cumulative resources budgeted across the project schedule.

 

Earned Value (EV): is a snapshot of work progress at a given point in time. In previous versions of the PMBOK it was called the Budgeted Cost of Work Performed (BCWP).  EV reflects the amount of work that has actually been accomplished to date (or in a given time period), expressed as the planned value for that work.

 

Actual Cost (AC): which was previously called Actual Cost of Work Performed (ACWP), is an indication of the level of resources that have been expended to achieve the actual work performed to date (or in a given time period). It can indicate that the organization has spent more or less than it planned to spend to achieve the work performed to date.

 

DERIVATIONS OF THE BASIC EVM ELEMENTS

 

Planned Value (PV): The work planned for Project EZ, is the basis for the Planned Value and the performance measurement baseline for the project. This work plan establishes a time-phased budget for each task in the project. For example, a Task may have a budget of 48 resource units, which are phased over a four-month period. The plan for the next task calls for varying increments of Planned Value to be earned in each month of the task. As the planned work is accomplished, its budgeted cost becomes Earned Value.

 

Tasks may be planned and measured in whatever resource units are most suitable to the work, including labor hours, material quantities, and the monetary equivalent of these resources. As discussed in the next section, however, performance management works best when the physical progress of work is objectively planned and measured.

The techniques used in EVM to achieve this goal are Earned Value measurement techniques (sometimes called earning and crediting methods).

Earned Value is a measure of work performed. Techniques for measuring work performed are selected during project planning and are the basis for performance measurement during project execution and control. Earned Value (EV) techniques should be selected based on key attributes of the work, primarily 1) the duration of the effort and 2) the tangibility of its product.

 

The performance of separate and distinct work effort that is related to the completion of specific and tangible end products or services, and which can be directly planned and measured, is called discrete effort. In comparison, effort applied to project work that is not readily divisible into discrete efforts for that work, but which is related in direct proportion to measurable discrete work efforts, is called apportioned effort, and support-type activity that does not produce definitive end products is referred to as level of effort. Work performance is measured periodically, such as weekly or monthly. The EV technique selected for measuring the performance of discrete effort will depend on its duration and the number of measurement periods it spans. Discrete efforts that span one to two periods are often measured with fixed formula techniques, where a fixed percentage of work performance is credited at the start of the work and the remaining percentage is credited at the completion of the work. Discrete efforts of longer duration (greater than two periods) are measured with other techniques, including those known as weighted milestone and percent complete.

 

Fixed Formula

A typical example of fixed formula is the 50/50 technique. With this method, 50% of the work is credited as complete for the measurement period in which the work begins, regardless of how much work has actually been accomplished. The remaining 50% is credited when the work is completed. Other variations of the fixed formula method include 25/75 and 0/100. Fixed formula techniques are most effectively used on small, short-duration tasks.

 

Weighted Milestone

The weighted milestone technique divides the work to be completed into segments, each ending with an observable milestone; it then assigns a value to the achievement of each milestone. The weighted milestone technique is more suitable for longer duration tasks having intermediate, tangible outcomes.

 

Percent Complete

The percent complete technique is among the simplest and easiest, but can be the most subjective of the Earned Value measurement techniques if there are no objective indicators to back it up. This is the case when, at each measurement period, the responsible worker or manager makes an estimate of the percentage of the work complete. These estimates are usually for the cumulative progress made against the plan for each task. However, if there are objective indicators that can be used to arrive at the percent complete (for example, number of units of product completed divided by the total number of units to be completed), then this can be a more useful technique.

 

Apportioned Effort

If a task has a direct, supportive relationship to another task that has its own Earned Value, the value for the support task may be determined based on (or apportioned to) the Earned Value of the reference base activity.

 

Examples of proportional tasks include quality assurance and inspection activities. Using the apportioned effort technique, the project manager might determine that the Planned Value for the quality assurance task is 10% of the value of the main task. The total apportioned Planned Value for the quality assurance effort related to Task 2, therefore, would be 4.8 or 10 percent of 48 (which is the Planned Value for Task 2). Earned Value for each measurement period would be assigned for the quality assurance component in direct proportion to the Earned Value assigned for Task 2.

 

Level of Effort

Some project activities do not produce tangible outcomes that can be measured objectively. Examples include project management and operating a project technical library. These activities consume project resources and should be included in EVM planning and measurement. In these cases, the level of effort (LOE) technique is used for determining Earned Value. A Planned Value is assigned to each LOE task for each measurement period. This Planned Value is automatically credited as the Earned Value at the end of the measurement period. LOE should be used only when the task does not lend itself to a technique that actually measures physical work progress. LOE tasks have no schedule variance and bias the project data toward an on-schedule condition. They also can reflect misleading cost variances if they are not executed with the human resources on whom the cost estimates and planned values in the performance measurement baseline are based.

 

Earned Value

While value is planned and measured using the Earned Value techniques outlined above, value is earned by accomplishing the planned work. Earned Value is credited when progress is demonstrated in accordance with the Earned Value technique selected for the planned work. For discrete work, observable evidence of a tangible product or progress is required.

 

Actual Cost

To determine Actual Cost, an organization needs to have in place a system for tracking costs over time and by project component. The sophistication and complexity of this system will vary by organization and project, but, at a minimum, some type of cost tracking system must be in place that can tie costs to the plan and to the way Earned Value is credited.

 

PUTTING IT ALL TOGETHER

Once Planned Value, Earned Value, and Actual Cost have been determined, a manager can use these data points to analyze where a project is and forecast where it is headed.[i]

 

---

[i] Guide to the Project Management Body of Knowledge (PMBOK@ Guide) Third Edition @2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA

General Management and Interpersonal Skills for Project Management

General management encompasses planning, organizing, staffing, executing, and controlling the operations of an ongoing enterprise. It includes supporting disciplines such as:

 

• Financial management and accounting

• Purchasing and procurement

• Sales and marketing

• Contracts and commercial law

• Manufacturing and distribution

• Logistics and supply chain

• Strategic planning, tactical planning, and operational planning

• Organizational structures, organizational behavior personnel   administration, compensation, benefits, and career paths

• Health and safety practices

• Information technology.

 

General management provides the foundation for building project management skills and is often essential for the project manager. On any given project, skill in any number of general management areas may be required. General management literature documents these skills, and their application is fundamentally the same on a project.

 

The management of interpersonal relationships includes:

 

• Effective communication. The exchange of information

• Influencing the organization. The ability to “get things done”

• Leadership. Developing a vision and strategy, and motivating people to

achieve that vision and strategy

• Motivation. Energizing people to achieve high levels of performance and to overcome barriers to change

• Negotiation and conflict management. Conferring with others to come to terms with them or to reach an agreement

• Problem solving. The combination of problem definition, alternatives

identification and analysis, and decision-making.

More on Ike

In the newspaper today, many areas around here are not going to get electricity until October! Stores are barely stocked and some areas have houses that are ruined. We were so blessed. The people across the street won’t have electricity until Thursday.

It takes a disaster like this to make you realize how blessed you are. I am sure lots of you have seen the pictures of devastation. Some folks have lined up since 3am to receive food stamps only to find out in the mid-afternoon that they are not eligible.

Join me in saying a prayer for those less fortunate than others. Less than half of the folks have electricity and water has to be boiled for food.

I grew up in New Orleans and I never in 12 years in Houston have seen it so bad. Schools are closed for 2 weeks. I am volunteering to help others less fortunate than my family and urge you all to do the same or send money to help with the relief effort.

Uses of Earned Value Management to Save the Project

 As a Project Manager, I use the Earned Value Management (EVM) technique. It answers questions such “am I on schedule”, “have I met my budget goals” and “what will my project cost as predicted when the planning phase was done”. It uses many equations to figure this out. I make a habit of not only having engineers register the tie time they spent each day but also how much time they anticipate spending to complete the task.

 

It is the nature of software estimating that you know more about the task as you go along doing the task. Let’s say your original estimate was 40 hours. If 20 hours goes by you are not necessarily 50% done with the task. If you have the hours spent each day as well as the remaining work to be done, you may be over or under the original estimate. It is the Project Manager’s job to keep tight track on the work being done. If you find out a task is slipping early on in the project, you have plenty of time to recover. If you don’t find out until a week before the project is due, you have little control over saving the project.

 

In summary, EVM strategically augments good project management to facilitate the planning and control of cost and schedule performance. The key practices of EVM include:

 

·          Establish a performance measurement baseline (PMB)

·          Decompose work scope to a manageable level (work items) in WBS.     

·          Assign unambiguous management responsibility

·          Develop a time-phased budget for each work task

·          Select EV measurement techniques for all tasks

·          Maintain integrity of PMB throughout the project

·          Measure and analyze performance against the baseline

·          Record resourced during the project to be used in future planning

·          Objectively measure the physical work progress

·          Credit EV according to EV techniques

·          Analyze and forecast cost/schedule performance

·          Report performance problems and/or take action.

I have a requirement of never surprising my manager and ask my reports to never surprise me. This leads to a well managed project and a happy team!

Earned Value Management Planning Process

During the project planning process, EVM requires the establishment of a performance measurement baseline (PMB). This requirement amplifies the importance of project planning principles, especially those related to scope, schedule, and cost. EVM elevates the need for project work to be executable and manageable and for the workers and managers to be held responsible and accountable for the project’s performance.

 

Project work needs to be broken down—using a work breakdown structure—into executable tasks and manageable elements often called control accounts. Either an individual or a team needs to manage each of the work elements. All of the work needs to be assigned to the workforce for execution using an organization breakdown structure (OBS).

 

Project work needs to be logically scheduled and resourced in a work plan; the work scope, schedule, and cost need to be integrated and recorded in a time-phased budget known as a performance measurement baseline (PMB)

hypothetical work plan with a Gantt (bar) chart, to which earned value measurement has been added.

 

In the planning process, the means for assessing physical work progress and assigning budgetary earned value also needs to be established. In addition to routine project management planning, earned value measurement techniques are selected and applied for each work task, based on scope, schedule, and cost considerations.

 

In the project execution process, EVM requires the recording of resource utilization (i.e., labor, materials, and the like) for the work performed within each of the work elements included in the project management plan. In other words, actual costs need to be captured in such a way that permits their comparison with the performance Measurement Baseline.