Linkedin Profile

Check out my Linkdin Profile at www.linkedin.com/in/dritter5!  I’d love to hear your comments on what services you would like provided.

 

Donna

Ways to remain calm during the PMP test

Make sure you have studied a lot. The test is a 4 hour multiple choice test that is randomly selected from PMI’s test base. Bring energy bars and water. They won’t let you take anything in, but will give you a locker to store your stuff. Take a break at least once an hour to stretch your legs, take a snack and break. This clears your head.

When you first get in the testing center, they give you paper and pencil. The first part of the test is a tutorial on how to take the test. Take this time to do a brain dump of all the formulas, knowlege areas and procces groups. The questions are very situational, so you can usually emliminate 2 answers quickly. If you are not sure, mark the question (it lets you do that to come back to it) and go on. Also, somethims questions further on into the test will help answer an earler question. Aim for 30 minutes for looking at the questions you didn’t feel sure about and to review your exam. THen as soo as you push the confirtm question, it will take a few minutes to grade (a long few minutes) but it will help a lot. I wasn’t sure I passed – but I made a 98%! Keep you PMP certifcation eu to date and you’ll never have to take the test again. When I took it, the rule was you had to get 60  PDUs in 3 years. You can get some from training or some from running projects, reading a new PM theory book and other things. Look on PMP.ORG to find out the requirements to keep your PMP certication. And get a good nights rest and calm yourself. No one knows what you make and I think they give you 2 or 3 times to pass.

 

Have a great day!

Donna

The Nature of Project Management

Why do many talented developers and IT professionals consider project management to be an obstacle, rather than an enabler? Why do clients often resist project oversight or try to minimize it? Does project management really allow projects to reach completion more quickly, or are speed and project discipline mutually exclusive?

We’ve explored the balance of speed and delivery and the nature of innovative projects in recent articles. Let’s tie these themes together and review techniques that help keep project management relevant to even the most unique and innovative programs.

Project bureaucrats

When I teach project management, I often draw a distinction between project managers and project bureaucrats. We’ve all had encounters with project managers who turned into bureaucrats. Project bureaucrats are more interested in ensuring that every step of the methodology is applied and every line of every form is filled in than in what’s actually happening on the ground. On the other hand, it’s common to meet project managers who apply minimal project methodology, yet, through their expert use of relationships and personal interactions, always seem to know exactly where the project stands.

In my experience, it’s the project bureaucrats who often leave a bitter taste with both the delivery team and the client. These project managers turned bureaucrats have forgotten one of the key rules of project management: don’t mistake the map for the journey. All the plans, charts, and milestones mean nothing if they aren’t consistent with the reality on the ground. And there’s the rub; especially in innovative projects, the plans and estimates are often based on a fallacy — there’s the idea that we can predict the progress of something that’s never been done before.

Project spec compliance = success? Not always

In his outstanding book Agile Project Management, Jim Highsmith offers two examples that emphasize the point. The movie Titanic, from a project management perspective, was a huge failure — over budget, over schedule, and plagued by unforeseen risks that threatened to derail the project at every turn. Motorola’s Iridium project, which spent billions of dollars launching satellites into orbit in order to make telephone service available worldwide, was a great project management success. Yet the market is the ultimate judge, and the project management compliance of Motorola’s venture didn’t save the project from failure, nor did the project management disaster (no pun intended) of Titanic’s production taint the film’s appeal to the public.

The lesson that project managers should learn from these examples is that compliance with project specifications does not constitute project success; in the ultimate analysis, only business results matter. Stated another way, the largest risk in any project is not that it will deviate from plan; it’s the risk that the final outcome won’t fulfill the real need. Predictive methodologies, such as the techniques championed by the Project Management Institute in its PM Body of Knowledge, can add tremendous value, especially for projects for which we have a historical basis to look to for precedent. For truly innovative projects, in which any prediction is little more than guesswork and for which we’ll be inventing never-before-seen products, we need to look for a new approach. Hence, the growing popularity of agile approaches.

Agile myths and truths

The central insight of agile methods is not that project overhead is a pain in the neck or that programmers like to be free; instead, it is the observable truth that, especially in innovative programs, customers can’t describe what they want until they see it, and prediction is inappropriate when there’s no way to visualize what the final result will be, let alone exactly how long it will take to build.

Unlike predictive methods, in which the planning, estimating, and risk assessment activities are all front-loaded and often are seen as a separate “planning” phase, agile approaches assume that the requirements will grow incrementally and iteratively as the project proceeds. This emphasis on “just enough” planning and requirements discovery is an acknowledgement of the fact that the key up-front activity in an agile approach is the creation of the first iteration of the product, so that the sponsor can see it and touch it, and discrepancies between the sponsor’s vision and the product created by the team can be modified to fulfill the current business need.

Agile project management is often misunderstood, as illustrated by the proliferation of articles about “agile myths.” Agile methods are not about “buying pizza and getting out of the way,” as these methods are often caricatured. Agile methods, from SCRUM to Highsmith’s APM Framework, are disciplined and structured approaches to product development, just as predictive methods are; these methods just address different types of problems.

Predictive and agile approaches have robust requirements discovery techniques, but agile methods acknowledge that requirements will evolve throughout the life of the project rather than up-front. Both approaches have stakeholder participation practices, but agile methods insist that stakeholders and sponsors are involved throughout the project in a collaborative, interactive manner. Predictive and agile both have mechanisms for integrating changing requirements into the plan, but the approaches use different techniques. Predictive techniques often apply restrictive change management procedures. Agile methods are specifically designed to encourage and implement beneficial change by providing an iterative, incremental approach to development focused on implementing, rather than controlling, positive change.

Innovative projects call for innovative methods, but that doesn’t imply, as many agile skeptics insist, that the benefits gained by applying structured project management techniques must be abandoned. Agile approaches are appropriate for creative, inventive projects because the methods integrate exploratory, collaborative techniques into the project process and acknowledge the mutating nature of exploratory IT projects into the PM methods we apply. Even PMI, in its newly published Body of Knowledge, recognizes the value of the iterative, incremental approaches advocated by agile proponents.

More to come

In subsequent columns, we’ll dig a bit deeper into the specifics of some of these techniques and explore ways that agile approaches can be combined with familiar, predictive techniques to apply exactly the right level of rigor to the project, no matter where it falls on the innovation spectrum.

Get weekly PM tips in your inbox
TechRepublic’s IT Project Management newsletter, delivered on Wednesday, offers tips to help keep project managers and their teams on track. Automatically sign up today!

Rick Freedman is the author of three books on IT consulting, including “The IT Consultant”. Rick is a Director in the Global Services Division of NEC America, and a trainer and course developer in the Agile Project Management practice of ESI, the international PM training company.

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.

 

Project Process Groups

There are five Process Groups defined by PMI. They have clear dependencies and are performed in the same sequence on each project. They are independent of application areas or industry focus. Individual Process Groups and individual constituent processes are often iterated prior to completing the project. Constituent processes also can have interactions both within a Process Group and among Process Groups.

 

Note: During project phases, if a change occurs during the project execution or control, the documents and tools used in the Process groups may have to be revisited. For example, if a change is made to the scope during the project execution phase, the scope document and all of the project plans must be revisited to include the new scope.

 

An individual process may define and constrain how inputs are used to produce outputs for that Process Group. They are defined in a way that projects of all kinds can be managed with this standard, so some inputs or outputs may not be relevant to every project.

 

A Process Group includes the constituent project management processes that are linked by the respective inputs and outputs, that is, the result or outcome of one process becomes the input to another. The Monitoring and Controlling Process Group, for example, not only monitors and controls the work being done during a Process Group, but also monitors and controls the entire project effort. The Monitoring and Controlling Process Group must also provide feedback to implement corrective or preventive actions to bring the project into compliance with the project management plan or to appropriately modify the project management plan. Many additional interactions among the Process Groups are likely.

 

Where large or complex projects may be separated into distinct phases or sub-projects such as feasibility study, concept development, design, prototype, build, test, etc. all of the Process Group processes would normally be repeated for each phase or subproject.

The five Process Groups are:

 

·         Initiating Process Group. Defines and authorizes the project or a project.

·         Planning Process Group. Defines and refines objectives, and plans the course of action required to attain the objectives and scope that the project was undertaken to address.

·         Executing Process Group. Integrates people and other resources to carry out the project management plan for the project.

·         Monitoring and Controlling Process Group. Regularly measures and monitors progress to identify variances from the project management plan so that corrective action can be taken when necessary to meet project objectives.

·         Closing Process Group. Formalizes acceptance of the product, service or result and brings the project or a project phase to an orderly end.

Glossary of Terms for Earned Value

Actual Cost (AC): Total costs actually incurred and recorded in accomplishing work performed during a given time period.

Actual Cost of Work Performed (ACWP): See Actual Cost (AC).

Apportioned Effort (AE): 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.

Contrast with Discrete Effort.

Budget at Completion (BAC): The sum of all the budgets established for the work to be performed on the project. The total planned value for the project.

Budgeted Cost of Work Performed (BCWP): See Earned Value (EV).

Budgeted Cost of Work Scheduled (BCWS): See Planned Value (PV).

Control Account: A management control point where scope, budget (resource plans), actual cost, and schedule are integrated and compared to earned value for performance measurement. Control accounts are placed at selected management points (specific components at selected levels) of the work breakdown structure.

Cost Performance Index (CPI): A measure of cost efficiency on a project. It is the ratio of earned value (EV) to actual costs (AC). CPI _ EV divided by AC. A value equal to or greater than one indicates a favorable condition and a value less than one indicates an unfavorable condition.

Cost Variance (CV): A measure of cost performance on a project. It is the algebraic difference between earned value (EV) and actual cost (AC). CV _EV minus AC. A positive value indicates a favorable condition and a negative value indicates an unfavorable condition.

Discrete Effort: Work effort that is separate, distinct, and related to the completion of specific end products or services, and that can be directly planned and measured.

Earned Value (EV): The value of work performed expressed in terms of the budget assigned to that work. It is also referred to as the Budgeted Cost of Work Performed (BCWP).

Earned Value Technique (EVT): This is a technique or method for measuring the performance of work, and used to establish the performance measurement baseline (PMB).

Estimate at Completion (EAC):  The expected total cost of completing project work. EAC is equal to the actual cost (AC) plus the estimate to complete (ETC) for all of the remaining work. The EAC may be calculated based on performance to date or estimated by the project team based

on other factors.  

Estimate to Complete (ETC): The estimated cost of completing the remaining work.

Level of Effort (LOE): Support-type activity (e.g., seller or customer liaison, project cost accounting, project management), which does not produce definitive end products.

Management by Exception:  A management technique that emphasizes attention to performance behavior that falls outside of some predetermined range of normal or expected outcomes. This technique is characterized by containment and conservatism.

Organizational Breakdown Structure (OBS): A hierarchically organized depiction of the project organization arranged so as to relate the work to the performing organizational units. (Sometimes OBS is written as Organization Breakdown Structure with the same definition.)

Performance Measurement Baseline (PMB): An approved, integrated scope-schedule-cost plan for the project work against which project execution is compared to measure and manage performance.

Physical Work Progress: The amount of work physically completed on the project or task. This may be different from the amount of effort or money expended on the project or task. Predetermined techniques of claiming physical work progress that were selected during project planning are

used to credit Earned Value when work is partially complete at the time of progress reporting.

Planned Value (PV). The authorized budget assigned to the scheduled work to be accomplished. This is also referred to as the budgeted cost of work scheduled (BCWS).

Responsibility Assignment Matrix (RAM): A structure that relates the project organizational breakdown structure to the work breakdown structure to help ensure that each component of the project’s scope of work is assigned to a responsible person/team.

Schedule Performance Index (SPI):  A measure of schedule efficiency on a project. It is the ratio of earned value (EV) to planned value (PV). The SPI _ EV divided by PV. An SPI equal to or greater than one indicates a favorable condition and a value of less than one indicates an unfavorable condition.

Schedule Variance (SV): This is a measure of schedule performance on a project. It is the algebraic difference between the earned value (EV) and the planned value (PV). SV _ EV minus PV.

S-Curve:  Graphic display of cumulative costs, labor hours, percentage of work, or other quantities, plotted against time. Used to depict Planned Value, Earned Value, and Actual Cost of project work.

Time-Phase Budget: A project budget that identifies how much money or labor is to be expended on each task for each time period (e.g., month) in the project schedule (see Planned Value).

To-Complete Performance Index (TCPI): The calculated projection of cost performance that must be achieved on remaining work to meet a specified goal, such as the BAC or the management EAC. For example: To-Complete Performance Index _ (remaining work) / (budget remaining)

_ (BAC _ EV) / (BAC _ AC). The difference between the total budget assigned to a project (BAC) and the total cost estimate at completion (EAC). Variance at Completion _ Budget: at Completion _ Estimate at Completion. It represents the amount of expected overrun or under-run.

Variance Threshold: A predetermined range of normal outcomes that is determined during the planning process and sets the boundaries within which the team practices management by exception.

 

---

[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