Full Factorial and Fractional Designs

Would almonds, pistachios, or peanuts taste best in the new ChocoNut Cookie being launched by Katy’s Cookie Factory? And should sugar or honey be used as a sweetener? There are two factors here—nut type and sweetener type. There are three levels of the nut factor (almonds, pistachios, and peanuts) and two levels of the sweetener factor (sugar and honey). Katy decides to create samples of cookies to give to customers so she better understands the Voice of the Customer before launching the product. What kinds of cookies should she make? There are six possible combinations—almonds-sugar, pistachios-sugar, peanuts-sugar, almonds-honey, pistachios-honey, and peanuts-honey. If you were to suggest that she make all six kinds of cookies, you are recommending a Full Factorial design. A Full Factorial design examines every combination of all levels of the experiment’s factors. A Fractional design examines only some of these combinations. So if Katy’s subject matter experts tell her that honey would taste terrible with almonds or pistachios and she decides to exclude those combinations, she now has four conditions in her experiment (almonds-sugar, pistachios-sugar, peanuts-sugar, and peanuts-honey) and it is a Fractional design.

Another example would be a study to measure the percentage of defective cookies made across four factory locations which each have three shifts. There are 12 possible combinations of each factory location and each shift. If defects are measured across all 12 combinations, it is a Full Factorial. However, if they decide to exclude the third shift for two of the factory locations, it is now a Fractional design.

 

The 5 S’s

The waffle maker sits on the counter, and Katy doesn’t even like waffles. Flour dusts the counter and floors, and she can barely reach the brown sugar on the top shelf that she used almost everyday. Katy’s kitchen is a complete mess so she decides to apply the 5 S’s.

The 5 S’s method promotes a clean and organized area in the workplace. Needed items are found more easily and a safer environment is created. The 5 S’s are: Sort, Straighten, Shine, Standardize, and Sustain.

First Katy Sorts by taking away things that she does not need. She has mint julep glasses from a Kentucky Derby that she has never used and a deviled egg dish that she doesn’t use because she’s allergic to eggs. These and similarly unused items are packed into a box and stored in her attic. Next she Straightens by arranging things to be easily accessible. The flour she uses frequently was on a top shelf of the pantry whereas the cardamom she uses about once a year was conveniently on the counter. She changes the location of ingredients, appliances, tools, and dishes so that the items she uses most frequently are the most easily accessible. For the Shine step, she thoroughly cleans the kitchen including wiping down the refrigerator and cupboards. To Standardize, she maintains the first three steps. She does this with a little calendar magnet on her refrigerator on which she marks the days over the next year that she’ll Sort, Straighten, and Shine. She only Sorts four times a year. Some Shine tasks are done rarely, and others, like washing the counter, are done three times per day. The last step is Sustain, for which she remains dedicated to performing the tasks on her calendar to maintain a clean and organized kitchen.

Critical-to-Quality Requirements

Katy has been gathering data on the Voice of the Customer to guide her organization in developing a new line of cookies. She hires a company to survey 10,000 people on their cookie preferences. Gathering and organizing data about customer needs leads to Critical-to-Quality requirements (CTQ). These are the quality parameters of the product or process needed to assure that customer needs are met. For example, Katy’s survey found a large segment of customers that desire low-calorie cookies. So a CTQ could be that each cookie has 20 or fewer calories. Customer needs are often general, such as “low-calorie cookies.” The CTQ requirement translates this into something quantifiable. Katy’s customers also want “big cookies” which could be a CTQ requirement of having a diameter between three and four inches. A CTQ tree is a tool used to break down these general customer needs into specific and measureable requirements.

Voice of the Customer

Katy sifts through customer survey responses. “I like my cookies to be large, with lots of chocolate chips.” “Cookies must be chewy and soft.” “I need cookies that have the least amount of fat and calories as possible.” She is seeking to understand the Voice of the Customer (VOC). Understanding customer needs is foundational in Six Sigma. Customers may be both internal and external; and their needs may be both stated and unstated. There are many ways to learn what customers need, such as: individual or group interviews, surveys, focus groups, active or passive observations, and complaint logs. Reviewing data should lead to a better understanding of customer segmentation and customer needs. This is not something that can safely be performed once since customers change as do their needs. Customers of Katy’s Cookie Factory may prefer rich, buttery cookies today, but there could be a trend in the future towards concern about consuming butter and a preference for lower-fat foods. The key is to listen to what the VOC is saying and meet their changing needs.

Poka Yoke

The heat from some of the manufacturing equipment at Katy’s Cookie Factory sometimes melts chocolate chips together before they are added to the cookies. This results in extra-large, unsightly globs of chocolate chips that customers have complained about. Although a worker is supposed to be watching the temperature of the machines, it is easy to miss a brief time of extra heat that causes some chocolate chips to melt together. What can be of use here is Poka Yoke, which is a Japanese term for mistake-proofing. Poke Yoke either makes the mistake impossible from occurring or impossible not to notice. To prevent the large globs of chocolate from being added to the cookie dough, a sieve with holes just large enough for the correct-sized chocolate chips to pass through was added. Now there are no more mistakes of large globs of chocolate chips in the cookies. Anyone can come up with a creative idea to prevent mistakes in a process and therefore prevent a certain defect from occurring.

What is DMADV?

Six Sigma’s typical problem-solving approach of DMAIC stands for Define, Measure, Analyze, Improve, and Control which are the steps to improve an existing process. Six Sigma can also be used in the development of a new process or product. In this case, the DMADV phases are often used which stands for Define, Measure, Analyze, Design, and Verify. Here is an explanation of these five phases.

Define – what are the goals here?

Measure – what do customers want? What do the organization’s leaders want? What are our capabilities?

Analyze – what are options for our new design?

Design – what are the details for the design of our chosen solution?

Verify – does our new solution meet our needs?

 

Poll for Project Managers

Operational Definition

An operational definition is how a construct will be measured. This includes measurements in research studies such as Six Sigma studies. For example, in a pet obesity study a new weight loss drug will be given to overweight cats. But what is an overweight cat? Someone may suggest that if the cat is 15 pounds or larger, it is overweight. This is an operational definition, but it is not a great one because some cat breeds such as a good-sized Maine Coon could be thin at that weight. Another cat study needs a sample of happy cats. This is harder! Perhaps cats who purr ten minutes or greater on average per day with a complete absence of hissing and growling could be considered happy cats. As can be seen, if an operational definition is poor, the entire study can be poor. It is important not to rush the step of developing good operational definitions when conducting a study.

 

PMBOK Knowledge Area Poll

Multi-Voting

The popcorn, chips, and drinks were ready, but we had a problem…so many choices for movie night and my sisters, cousins, and I just could not agree on which movie to watch. Becky wanted a musical, Damian wanted a war movie, Julie and Felicia were thinking about a horror movie, and I wanted a comedy. So we took a set of 10 movies that we were most interested in and we each had three votes. I chose my comedy, a horror movie, and the war movie. We ended up watching the war movie as that received the most total votes. Little did we know, this is the tool of multi-voting. In addition to selecting a movie, it can be used to narrow down a list of potential solutions, ideas, problems, etc. to determine what should receive the most attention. Multi-voting is commonly listed as a Six Sigma tool, but can obviously be applied to many situations. Although voters can be given any number of votes, giving them votes equal to about 1/3 of the choices works well.

 

9/11 – where were you at 7 years and what’s the impact

I just shared an email with a former colleague of a dot.com we worked for that was imploding several weeks before, during and, most certainly after, 9/11.    I recallthe double whammy emotion I felt – wondering how to find a new gig and wondering what was going to happen to my family (kids were 4 months, almost 2 and almost 4 years old then)

It wasn’t so much the transition in employment – “hey had to tackle that once or twice through the climb of career advancement and job jumping from 1988 to 2001″.  It was the sense and feeling that I was sitting at home without much of a group to connect with.  Our kids were toddler age then and were off to daycare.  Not that the work place should be the end all.  But it was the sense of “when I was at the State Patrol or Omaha Police Department – my two primary gigs in the 1990’s -  I could have been doing something to help”.   Did my angst come anywhere close to those in NYC, DC, coasts or victim’s families - absolutely NOT. Could I still help out. YES.

Right before 9/11  I thought I would rebound find a PM / Director / expert consultant gig and fulfill the “force like destiny to become a CIO” or so Yoda or the Emperor was whispering to me.   The CTO and mentor or mine from the dot.com, Mark Resmer, had secured a wonderful opportunity with Prometheus — a learning management software start up incubated by GWU in DC – which was purchased by blackboard in 02′.  I was nailing down the finishing pieces for a commuter work arrangement (banking on flying in and out of Regan National Airport).

That changed very suddenly with 9/11.

• National shut down
• US races into recession
• Head count reductions in IT, project management, all over
• Living on pins and needles with concerns for “what next”

Now, and there’s always a learning and growth experience for all of life, it did lead my life in a more rewarding and better fitting profession.

• Juggling FTE and consulting roles in project management – sort of getting back to the basics from 2002-03
• teaching for several colleges and universities – with Bellevue University
• nurturing the idea to grow something distinctive — ala http://www.tapuniversity.com
• pushing myself more toward my family (kids grow fast), exercise (hey why stop at 3 marathons in the 90s), music and helping others.

It hasn’t been an instant rush to gold (still thinking happy Michael Phelps thoughts).  It has been a better direction.

So a couple of questions

1. Where were you at on 9/11 and more importantly
2. How has your life been since then, are you still on the exact same course?  If different, how so?

David
Seminar Leader
TAPUniversity

Welcome to the TAPUniversity blog and first entry

Welcome.

We communicate in quite a few virtual ways at TAPUniversity -

• through our learning management system (thank you moodle and remote learner!) that has served over 1,010 students since early 2006 and helped 143 professionals achieve their PMP
• through an enewsletter that is shared with 2,000 subscribers
• through various professional and social networking sites (LinkedIn, Facebook and Plaxo)
• through trade journals and articles at IBM, project connections, PM hub
• through monthly webinars and chats with our alums and continuing education subscribers

Now we want to provide an additional way that supports slightly polished thoughts and allows for interaction (one of learning hallmarks and missions)

You’ll see a somewhat autobiographical post next — reflecting on 9/11 seven years ago.

Working With People @ TAPUniversity!

TAPUniversity congratulates the following professionals from our Working With People workshop delivered for PMI Minnesota. They continued on to hone the skills they learned about in the workshop, online. This follow on class was full of dialog, introspection and application. Thank you everyone for an engaging class and best success to you! David

Ann Connelly
Michele Daniels
Mert Horne
Steve Harper
Joanne Moloney
Penny Nahn
Theresa Reisdorf
Bobbi Stark

TAPUniversity’s CST Series – Professional and Social Networking for Results

Career Survival Series  – Professional and Social Networking for Results

In challenging times your ability to network, professionally and socially becomes a vital tool.  Opportunities arise for a very brief moment and the inside track is essential for unearthing and seizing those.  The same skills vital for networking are also those that map to a highly effective project manager.  Join us for this 14 PDU course and learn how to networking more effectively.  We begin November 17th.  Your price for participation is only $99.00!

Practical takeaways from this 4 week class include:
1.  Refined and polished LinkedIn and Plaxo profile
2.  Refined and polished Facebook or Myspace profile (and how to coordinate with #1 above)
3.  Ability to use Twitter from web and text (phone)
4.  Ability to use other secondary support tools (RSS, de.lic.ious, etc)
5.  Identification of a “fourth” networking tools
6.  Growing a large network without falling into the pitfalls of promiscuous networking.

Register – http://shop.1asecure.com/prod.cfm?ProdID=340226&StID=9187

Top 10 list for contractors

I began a consulting services contract this week for a large, fortune 2000 company.  The mission is to support their consolidation efforts into some massive data centers.

This is the seventh longer term contracting assignment I’ve had since going solo in 2002/03.  The first few assignments were challenging in that I was unlearning the “successful full time employee” habits and needed to learn and get smart about “successful contractor”.  Now there are different stripes and kinds of contractors from, an ala Big 6, 4 (OK how ever many there are now) consultant, to a true time and material laborer.  I tend to fall in between the two.  Success characteristics tend to be similar.

I’ve found that success in growing TAPUniversity and delivering training is slightly different than success in being a “roaming Jedi, hired hand”.  While there’s a lot in common there are some differences.

So here’s some tips – a top 10 list if you will that may help you if you’ve found yourself joining the ranks of “contractor”.  These tips are not all areas I’m perfect in — in fact I’ve stumbled on each of these at some point over the last seven years. Please feel free to add, comment and respond!

• 10 arrive early for bridge calls – nothing raises the ire of the full time, permanent crowd than that late arriving conference call “beeps” and drive by call participants.
• 9  understand you’re expendable and can be bounced in a day… so mute or tone down your personality.  This is tough for me to do and is different from my training delivery and small business growth.  In those I let my natural self show.  Yet I need to mute the “Dave show”.
• 8  don’t use the client’s computer to surf the net.  Even where permissible for permanent employees, understand that it’s a privilege that may not be conveyed to contractors
• 7 save your drama for your mama and away from work.  I’ve overhead some rather bizarre Dr. Phil conversations over the last six years and, while strange for managers of full time, permanent employees to deal with, are a real liability for contractors.  Take personal calls at lunch and away from the limelight.
• 6  pitch into the local corporate goodwill.  Though you’re a passerby and stranger in a strange land, you can still help with community food-banks, santa cops, etc.
• 5  do pitch in outside your role (this is not a contradiction to #2).  If a team member needs a hand, help them.  You are on a team, whether for 4 weeks or 2 years.  Help out.  Just don’t call a lot of attention to it.
• 4  offer your collective wisdom in private conversations — especially with your direct report “boss”.  Yours is a temporary life and you really don’t need to “grease the execs”.  Help the one signing your timesheet / approving your bill rate and life will be good.
• 3  Stay positive, at all times.  You may be frustrated and feel XYZ organization is inept.  But unless you’re a Merger and Acquisition Tsar it’s not your job to inform them of their ineptness.  A bit like Patrick Swayze portraying a tough yet smart bouncer in the movie “Roadhouse” — be nice, then be nice, then be nice outside (meaning don’t take the fight inside the bar or office).
  
• 2  Don’t gather unnecessary attention — fulfill your role (explicit and implicit) and only your role.  It’s unlikely you’ll earn a promotion by ranging far and wide.  You might be given additional assignments as you carefully network.  Grandstanding typically leads to short assignments
  
• 1  Don’t engage in the internal politics.  you’re there for 4 weeks, 6 months or maximum of 2 years (US Federal Code due to Microsoft class action suit).  Nothing is gained by engaging in turf wars.

Please do let me know of your tips as well!

David

TAPUniversity’s Effective Virtual Team Institute Graduates — December 2008

Congratulations to TAPUniversity’s eight most recent Effective Virtual Team graduates.  Since August of 2005 over 175 people have graduated from this class.  Look forward to the unveiling of the Effective Virtual Team Institute soon.

The honor roll includes:

Ken Bratch, Quad Cities
Karen Miller, Quad Cities
Melissa Olson, Minneapolis
B Howard Penix, Quad Cities
Peggy Pangersis, Denver
Mary Regan, Nashville,
Bobbi Stark, Minneapolis
Max West, Boston

Best success all on a healthy, prosperous new year and on all your virtual team interactions!

PMP Exam Tips

Greetings! As many of those preparing for their PMP® exam already know, the Project Management Institute has now released the 4th edition PMBOK®. If you have been studying using the 3rd edition PMBOK, it is best if you take the exam before June 30th, which is when the 4th edition exam will replace the old one. Otherwise, you will be faced with learning some additional processes and concepts, and will find that some of the process and concepts you have learned are now called something else. If you have already taken a prep course, it’s time to get serious about finishing your final studying and applying for the exam. We’ve found that our students are the most likely to pass when they take their exam within about a month of finishing their PMP course. If you have finished a course recently, now is the time to schedule your exam. If you have finished your PMP course more than two months ago, give yourself at least a few weeks to do some intensive review before taking your exam. For those of you who have not taken a PMP course, plan ahead—study the 3rd edition if you’ll be able to take the exam before June 30th. Otherwise, start your studies with the 4th edition PMBOK. Best of success to you!

PMP Exam – Communication Formula

There are a number of formulas to memorize before taking the PMP Exam. The good news is that once you know the formulas, those questions should be particularly easy to answer correctly as there is a definite right answer. Here we’ll review the communication formula, which is used to calculate the number of possible paths of two-way communication among a group of people. The formula is (N * (N-1))/2 where N is the number of people in the group. So if you have 4 people in your group, the number of communication paths is (4*3)/2 which is 12/2 which is 6.

Let’s use an example—say the four people in your group are Annie, Barney, Cathy, and Dannie. Annie could talk directly to any of the other three—Barney, Cathy, and Dannie—which makes 3 paths of communication. We’ve already accounted for Barney and Annie talking to each other, but Barney could also talk directly to Cathy or Dannie, which adds 2 more communication paths. Lastly, Cathy and Dannie could talk directly to each other (we’ve already accounted for them talking to Annie and Barney), so that adds 1 more communication path. So 3 paths, plus 2 paths, plus 1 more path equals 6 paths, which is exactly what we quickly calculated using the communication formula.

If you’d like some practice with this formula, try answering the following:

1. There are 10 people on the project management team. How many communication paths are there?

2. There were 8 people on the team, but 2 people left. How many communication paths are there now?

3. There were 5 people on the team, but the team has now doubled in size. How many communication paths have been added?

PMP Exam – Cost Estimating Tools and Techniques

So, how much is all this going to cost me? Project Managers must routinely obtain estimates of project and activity costs. The Cost Estimating process (a process in the PMBOK®’s cost knowledge area and planning process group) deals with the task of obtaining reliable estimates for project costs. The Cost Estimating process has three tools and techniques that are specifically meant to obtain cost estimates—Analogous Estimating, Bottom-up Estimating, and Parametric Estimating.

Here are some example of these techniques. The Estemitte family is planning their annual vacation. Mr. Estemitte says that last year’s vacation cost $2,300, so this one should cost about the same. This is an example of Analogous Estimating. Notice that this was a very quick way to obtain a cost estimate and that it may not be highly accurate. If Mrs. Estemitte replies that the cost of travel has increased substantially since last year, and they would obtain a more accurate estimate if they used the vacation expenses of someone who has travelled recently, she is calling into question her husband’s Expert Judgment. Expert Judgment (for example, knowing what vacation or other project to use as a comparison) is critical in order to obtain a cost estimate that has the degree of accuracy needed to be useful.

Mrs. Estemitte breaks down the vacation expenses and obtains costs for lodging, car rental, meals, entertaintainment, souvenirs, and the pet sitter. She totals all these costs at $3,500. This is called bottom-up estimating. Notice that the more detail she uses to break down the vacation activities, the more accurate her estimate is likely to be. Also, it is likely to be more accurate than Analogous Estimating.

The Estemitte family has decided to go to a local all-inclusive resort, which charges $500 (taxes included)/day per family. Travel and other expenses will be miniscule. They want to have 5 days of vacation, so they calculate that the resort will cost about $2,500. This is an example of Parametric Estimating. The cost per unit is multiplied by the quantity of work. Other examples of units of work could be line of code in programming and miles of highway in constuction.

Develop Project Team – Team-building

Develop Project Team is one of the 44 processes in the third edition PMBOK®. This process is classified as a Human Resource process in the Executing process group. The Develop Project Team process concerns improving the competencies of project team members and the interactions among team members. One of its tools and techniques to accomplish this is team-building activities. In some fields and situations, a group of people may work together for many years and form a high-functioning team that is impressive to observe in action. Project Management by its very nature deals with the temporary—teams are formed quickly and disbanded as soon as the project comes to a close. To add to the challenge, some teams are virtual teams that never or rarely actually meet in person, yet to meet the project’s goals they must learn to work together effectively.

The project manager that can encourage the rapid development of a team has a great advantage. According to a well-known theory, teams go through stages of Forming, Storming, Norming, and Performing. A team that reaches the Performing stage will work most effectively. At the beginning, project managers should make certain that team members understand the objectives and importance of the project to help guide their individual decisions and to make the project goals their own. If the team members have individual agendas overshadowing a mutual team goal, problems are likely to ensue as they work against each other rather than together. Also, the project manager should try to encourage an atmosphere of trust and communication. To these ends, team-building activities may be introduced. Examples that people have used include: ice-breakers, ropes courses, off-site corporate events, games, company parties, and workshops. It can be difficult to find and execute a good team-building activity. What team-building activities have you experienced? Please share any ideas for team-building activities that you’ve found useful.

PMP Exam – PERT Formula

The Program Evaluation and Review Technique (PERT) formula is a simple and useful tool for project managers, and those who are planning to take their PMP Exam should have it memorized. There is much more to PERT as a project scheduling and planning technique than this formula, but here we’ll focus just on the formula. The PERT formula is mentioned in the 4th edition PMBOK® as a tool and technique of two processes—Estimate Activity Durations and Estimate Costs. The formula provides a weighted estimate—and the formula doesn’t care if the numbers you use represent time or money—so that’s why it’s in both the PMBOK’s Time and Cost knowledge areas.

To use this formula, we need three estimates—Optimistic (best-case scenario), Most Likely (realistic), and Pessimistic (worst-case scenario). We then find the average, but we first weight the Most Likely estimate by 4. The formula is (O + (4*ML) + P) / 6. We must divide by six because we in effect have six different estimates (although three of these estimates are the same number). We are averaging (O + ML + ML + ML + ML + P) / 6.

Here’s an example. The Estemitte family is driving home. They guess they are most likely 10 minutes from home, so that is their Most Likely estimate. If all the lights turn green, they guess it may take just 7 minutes to get home, so that is their Optimistic estimate. If it starts raining hard, they guess it may take them 12 minutes to get home, so that is their Pessimistic estimate. We simply put these numbers into the formula: (7 + 10 + 10 + 10 + 10 + 12) / 6 = 9.83 minutes.

This formula is most useful in estimating time or cost of activities for projects that are especially unique, such as in research and development where there are many unknowns. For projects that are similar to previous projects and there is good historical data and expert experience, the formula is less useful.

Pareto Chart

The Pareto Chart (also called Pareto Diagram) is used to show the various causes of defects. It is listed as a tool and technique of the fourth edition PMBOK®’s Perform Quality Control process. The purpose of the Pareto Chart is to identify the biggest problems affecting quality so that those causes may be targeted for improvement first. This concept is based on Pareto’s Law (also called the 80/20 rule) which is applied in this context to state that 80% of the problems are due to 20% of the causes. The various causes of defects in a Pareto Chart are ordered from left to right starting with the biggest cause of defects. The exception to this is the “other” category which is always at the far right. If the first several bars are substantially larger than the others, it is called a Pareto Effect. Note that if the “Other” category is comparatively large, it warrants further investigation to determine whether there are some major causes of defects that need to be further investigated. Pareto Charts typically display the number or percentage of defects, and some also have a line above the bars illustrating the cumulative percentage of the causes of defects.

Pareto Chart

Scatter Diagram

The Scatter Diagram (also called Scatter Plot) graphically illustrates data from two variables. It is listed as a tool and technique of the fourth edition PMBOK®’s Perform Quality Control process. One of the two variables is on the x-axis, and the other variable is portrayed on the y-axis. In this fictional example, 17 people were given IQ tests and were then asked how many books they owned. Their IQ scores are shown on the y-axis, and the number of books they own are on the x-axis, so the red dot illustrates an individual with an IQ of 130 who owns 200 books. The dots are showing a general pattern of the higher the IQ, the more books that are owned. This is called a positive correlation, because the variables are increasing together. If we had seen the opposite pattern—that the higher the IQ, the fewer books that are owned, it would be a negative correlation because one variable increases as the other decreases.

Scatterplot

Reserve Analysis

Several processes found in the PMBOK® listReserve Analysis as a technique . It is also referred to as a “contingency reserve” or “buffer.” The concept is quite simple—we know to expect the unexpected, so we plan for it. Applicable to both time and cost, it is the technique of adding some extra time to complete activities and extra funds to the budget. Although we may know how long our project activities should take, we also know that it is likely that there will be at least some minor setbacks—a key person is sick, weather delays a shipment, etc. Similarly, although we may know how much things should cost, we can easily find ourselves dealing with unexpected costs. By planning upfront for a little extra time and/or funds, we have a safety net when things do not go as hoped. Adding these buffers is one of the principles of the Critical Chain Method. There is not a set way to determine how much of a buffer to add—some may simply add a couple days to each activity or systematically add a certain percentage to the budget. The nature of the project relates to how large of a safety net to spread. A routine project should not need as much of a buffer as will a critical project in unchartered waters. Do you perform reserve analysis? If so, how do you choose how much time or funds to add?

PMP Exam –Process Inputs and Outputs

In the third edition PMBOK®, there are 44 processes—each with its own set of inputs, tools and techniques, and outputs. When learning these processes for your PMP® exam, look for patterns in the inputs and outputs and focus especially on any that are unique to a particular process. For example, in the third edition PMBOK, there are six risk processes: Risk Management Planning, Risk Identification, Qualitative Risk Analysis, Quantitative Risk Analysis, Risk Response Planning, and Risk Monitoring and Control. Here are some things to note:

o Risk Management Planning has the risk management plan as its only output
o The risk management plan is then an input to the five other processes
o Risk Identification has the risk register as its only output
o The risk register is then an input to the four remaining processes
o Updates to the risk register is also an output to the four remaining processes
o Only Risk Response Planning and Risk Monitoring and Control do not have organizational process assets and the project scope statement as inputs
o Only Risk Response Planning and Risk Monitoring and Control have more than one output
o Except for Risk Monitoring and Control (which is a Monitoring and Controlling process) the risk processes are Planning processes

Project Stakeholders

A project stakeholder is a person or organization that is actively involved in the project, or whose interests are affected by the project. They have an interest (stake) in the project. If a stakeholder benefits from the success of the project, they are a positive stakeholder; whereas if a stakeholder benefits from the failure of the project, they are a negative stakeholder. The members of the project team and performing organization are expected to be positive stakeholders. A competitor is an example of a likely negative stakeholder. Stakeholders can be both internal (belonging to the organization performing the project) or external (not belonging to the performing organization). A given stakeholder may or may not exert influence over the outcomes of the project. Examples of stakeholders include the project sponsor, project manager, project management team, project team, as well as any PMO office or customers. The fourth edition PMBOK® has added a process called Identify Stakeholders which emphasizes knowing who the stakeholders are early in the project, and understanding their interests, expectations, and level of influence over the project. The Stakeholder Register and Stakeholder Management Strategy are outputs to the Identify Stakeholders process that document information concerning the project’s stakeholders.

Run Chart

The tool of Run Charts are a way to graphically illustrate a set of data. The passing of time is usually graphed on the x-axis. Time could be measured in any increment—seconds, days, months, decades, etc. The measure of interest is graphed on the y-axis. Run Charts are especially useful for showing any trends over time in the data. For example, is there a trend that the data is increasing, decreasing, or staying the same? A formal examination of these trends using specific rules is called Trend Analysis. Run Charts are also useful for drawing attention to extreme data points called outliers. The fourth edition PMBOK® lists the run chart as a tool and technique of the Perform Quality Control process. When measuring the performance of a process for quality control purposes, one may be hoping to observe as little variation as possible, which would appear as a fairly flat line. When graphing the number of defects over time, if measures are implemented to decrease the rate of defects, one may be expecting a downward trend. Below is an example of a Run Chart illustrating how many cookies Katy ate per day over three weeks.

Run Chart

Control Chart

The Control Chart is a type of run chart that shows whether a process is in statistical control by adding lines called Control Limits to the chart. There is both an Upper Control Limit and a Lower Control Limit. It is also common to add a line representing the mean (average), and sometimes lines representing specification limits. The Control Limits are frequently drawn three standard deviations above and three standard deviations below the mean, because normally over 99% of the data should fall between these two limits. When the data exceeds these limits, it is worth investigating. There are different varieties of Control Charts named for the type of data it contains (c-chart for count type data, p-chart for proportions, etc.) that are especially common in Six Sigma. However, the underlying principle is the same.

There are three Quality processes described in the fourth edition PMBOK®—Plan Quality, Perform Quality Assurance, and Perform Quality Control. Plan Quality and Perform Quality Control specifically list the Control Chart as a tool and technique, and Perform Quality Assurance contains all the tools and techniques of the other two processes, so the Control Chart is a part of the all quality processes.

Below is an example of a Control Chart showing how many cookies Katie ate each day for three weeks. The average number of cookies she eats a day is 9, which is drawn with the red line. The blue line is the Upper Control Limit (which is 3 standard deviations above the mean) and the purple line is the Lower Control Limit (which is 3 standard deviations below the mean). What the Control Limits make clear is that on day 10, Katie enjoyed eating an exceptional number of cookies!

Control Chart

Develop Project Charter Process

Project managers (especially those preparing to take the PMP exam) should be familiar with the 42 project management processes outlined in the fourth edition PMBOK®. Develop Project Charter is categorized as one of the six Integration knowledge area processes, and one of the two Initiating process group processes. The most important thing to know about this process is that it creates one of the key project documents—the Project Charter.

The Project Charter accomplished a number of things, including formally authorizing and initiating the project, justifying the project, and assigning the project manager. At this point, the project has just formally begun, so although the details have not all been worked out, the Project Charter can still include broad descriptions of the requirements, budget, milestones, and risks. There are a few documents that the author of the Project Charter should have in front of them as they write—the Project Statement of Work (SOW), Business Case, and if performing the project for a customer, the contract is needed as well. Who writes the project charter varies across organizations and projects, but ideally the project manager participates in the creation of this document.

Identify Stakeholders Process

Identify Stakeholders is one of the 42 project management processes outlined in the fourth edition PMBOK®. It’s new to the fourth edition. Identify Stakeholders is categorized as one of the five Communication knowledge area processes, and one of the two Initiating process group processes. The purpose of this process is twofold—first, discover the people and organizations that are impacted by the project, and secondly, document relevant information about them. There are a couple documents that should be examined when discovering stakeholders—the Project Charter, and if there is procurement involved in the project, the procurement documents. These documents should list names and organizations of key stakeholders involved in the project. By interviewing these stakeholders, they are usually able to identify additional stakeholders. The task of gathering information about the stakeholders is called Stakeholder Analysis, which is a tool and technique of this process. Information gathered may include: roles, interest areas, expectations, influence levels, amount of potential impact and support, and how they are likely to respond in certain situations. If there are a large number of stakeholders, they should be classified into useful groups. The Stakeholder Registry is the primary output to this process—this is the document containing the list of stakeholders and relevant information about them. The other output is the Stakeholder Management Strategy which outlines a plan to increase support and minimize obstruction from the stakeholders. Project managers must be careful about the type of information that is included in this document and control who has access to it.

From a Triple Constraint to Six Constraints

Central to the work of a project manager is balancing competing demands. The term “triple constraint” is a well-known phrase in project management that refers to the competing demands of scope, time, and cost. The manner in which these three demands are balanced affects quality. If one of these factors is affected, at least one other factor will also be affected. For example, if the scope of the project increases, there will need to be an increase in the amount of time to complete the project, an increase in costs, or both. The new, fourth edition PMBOK® changes the name “time” to “schedule” and changes “cost” to “budget”, plus adds three new constraints. The six constraints are: Scope, Quality, Schedule, Budget, Resources, and Risk. Now quality isn’t merely affected by how the constraints are balanced—it is considered an actual constraint. Especially when dealing with highly-skilled individuals as resources, it makes sense to consider them a unique constraint as there may be very few each with limited time to commit to a single project. If stakeholders decide to change their tolerance for risk, this will affect other constraints as well. How to balance these constraints is a skill, and how they should be balanced differs across projects. For example, a certain deadline might be crucial to meet, and the project may be given as much funds as they need in order to meet that deadline. Conversely, it may be impossible to increase the budget, so the scope and quality have to be reduced. In your experience, what has been the most important constraint in your projects?

Develop Project Management Plan Process

Develop Project Management Plan is one of the 42 project management processes outlined in the fourth edition PMBOK®. It’s categorized as one of the six Integration knowledge area processes, and one of the twenty Planning process group processes. As the name suggests, the purpose is to create the Project Management Plan, which is the only output. The Project Charter should be available when writing the Project Management Plan as it provides direction to keep plans within the purpose of the project. The Project Management Plan is not simply a single plan written at the beginning of the project—rather, the Project Management Plan is a collection of plans and baselines that are progressively elaborated upon until the completion of the project. Which plans and baselines are included in this collection of plans depends on the particular project. Examples of these subsidiary plans are: Scope Management Plan, Requirements Management Plan, Schedule Management Plan, Cost Management Plan, and Risk Management Plan. Baselines could include: Schedule, Cost, and Performance baselines. It’s important to realize that these subsidiary plans and baselines are outputs from separate processes—they’re not from the Develop Project Management Plan Process. For example, the Requirements Management Plan is an output of the Collect Requirements process, and the Scope Baseline is an output to the Create Work Breakdown Structure process. What the Develop Project Management Plan does is define, prepare, integrate, and coordinate all the subsidiary plans and baselines.

Collect Requirements Process

Collect Requirements is one of the 42 project management processes outlined in the fourth edition PMBOK®. It’s new to the fourth edition. Collect Requirements is categorized as one of the five Scope knowledge area processes, and one of the twenty Planning processes. The purpose of this process is to define and document the needs of the stakeholders as they relate to meeting the project objectives. This process describes the responsibilities of the business analyst—if one is part of the team. This alone is an indicator that specialized knowledge and experience is especially useful for performing this particular process. Also, Collect Requirements has numerous tools and techniques in addition to three unique outputs. The tools and techniques represent different methods of learning the details of what stakeholders want—interviews, focus groups, facilitated workshops, group creativity techniques, group decision making techniques, questionnaires and surveys, observations, and prototypes. The outputs are: requirements documentation (stakeholders’ needs), the requirements management plan (how the requirements will be analyzed and documents), and the requirements traceability matrix (tracking of requirements throughout the project). This process requires more knowledge and a greater time commitment than does many of the other processes.

Define Scope Process

Define Scope is one of the 42 project management processes outlined in the fourth edition PMBOK®. It was called Scope Definition in the previous PMBOK. Define Scope is categorized as one of the five Scope knowledge area processes, and one of the twenty Planning processes. The purpose of this process is to make a detailed description of the project and the product. The most important thing to know about this process is that is creates the Project Scope Statement. The two major documents used to develop this scope statement are the Project Charter (which was developed in the Develop Project Charter process) and Requirements Documentation (which was developed in the Collect Requirements process), so these processes must be performed before writing the Project Scope Statement. When writing the Project Scope Statement, be sure to include the following: product scope description, product acceptance criteria, project deliverables, project exclusions, project constraints, and project assumptions. So not only is the scope of the project described, but also the project exclusions, which is specifically stating what is out of scope. A line is being drawn between what is within the boundaries of the project, and what is out of bounds. The project constraints are limitations placed on the project (such as a set budget), and project assumptions are things that the team is assuming to be true (such as assuming that a vendor will be available when needed). As more information becomes known, the Project Scope Statement is further elaborated upon and defined.

Earned Value Management – Step 1

There is much to understand and a number of formulas to know in order to apply Earned Value Management (EVM). It’s often the most difficult concept for project managers to learn when they are studying for their PMP exam if they have not applied it in their work. The very first step is gaining a conceptual understanding of what this thing is that we called Earned Value. Earned Value is the idea that even though we have not completed the work, there is value to the amount of work we have accomplished. How do we define value? It’s usually by money, such as in dollars, but it could be by hours of labor also. Here is the basic earned value formula: BAC * (work completed / total work). BAC stands for Budget at Completion, which it the total budget for the project. This is multiplied by the percentage of work completed.

Now for the examples—if Patty’s budget for her party is $1000, and the work is half done, what is her earned value? It’s $500, because half the work is done and half the budget is $500.

If Carl’s car re-design project has a budget of $4 million dollars, and he is one-fourth done, what is his earned value? It’s $1 million, because 25% of the work is done, and 25% of the budget is $1 million.

In this example, you aren’t told the percentage of work completed—that must be calculated. Shelly has $20, and wants to use it to find 10 seashell souvenirs to buy. So far, she’s bought 2 seashells. What is her earned value? It’s $4. BAC * (work completed / total work) = $20 * (2 seashells/10 seashells) = $4. The project work is to buy 10 seashells, so far she’s bought 2, so the work is 20% complete. 20% of $20 is $4.

Create Work Breakdown Structure Process

Create Work Breakdown Structure is one of the 42 project management processes outlined in the fourth edition PMBOK®. Create Work Breakdown Structure (WBS) is categorized as one of the five Scope knowledge area processes, and one of the twenty Planning processes. The purpose of this process is to break down the deliverables and project work into smaller components. The documents used as a reference for knowing what work needs to be broken down are the Project Scope Statement (created by the Define Scope process) and the Requirements Documentation (created by the Collect Requirements process). The project manager’s organization may also have templates available to help in creating the WBS. There is only one tool and technique for this process—decomposition. Decomposition refers to the actual work of breaking down components into smaller components. For example, a project’s deliverable may be a position paper. This may be broken down into performing background research, writing the paper, and proofing the paper. Each of these may then be further broken down—background research may be decomposed into determining relevant sources, obtaining written sources, reading written sources, and interviewing human sources. It’s important to know how far to breakdown components and to make sure sub-components completely meet the requirements of the component above so that nothing is missing. The major outputs of this process are the WBS, WBS dictionary, and scope baseline. The WBS illustrates the components and how they’ve been broken down. It could be displayed in various formats—such as an outline, organizational-type chart, etc. The WBS dictionary is the accompanying document that further elaborates on the individual components of the WBS. The WBS and WBS dictionary together with the Project Scope Statement is called the Scope Baseline, and this Scope Baseline becomes incorporated into the Project Management Plan.

Earned Value Management AC and BAC – Step 2

An earlier posting described the concept of Earned Value—the idea that accomplished work has value, even if the work is incomplete. There are a number of formulas and acronyms to know when applying Earned Value Management (EVM). A couple more will be introduced here. Actual Cost (AC) and Budget at Completion (BAC) are two basic concepts to understand. AC is how much money you’ve actually spent at this point in time (not planned to spend, meant to spend, wanted to spent, but really and truly actually have spent). BAC is how much money has been budgeted for the entire project. So if Benjamin is part-way through managing a project that has been allotted ten thousand dollars, and as of today he’s spent seven thousand on the project, the BAC is ten thousand dollars and the AC is seven thousand dollars. The term AC is used in formulas to calculate whether a project is on-budget, how much value is being obtained for the cost, and how much more the project will cost. The term BAC is used in formulas to calculate how much the total project will cost, how much more the project will cost, and the difference in how much the project was supposed to cost compared to what it actually will cost.

Define Activities Process

Define Activities is one of the 42 project management processes outlined in the fourth edition PMBOK®. It’s categorized as one of the six Time knowledge area processes, and one of the twenty Planning processes. The purpose of this process is to identify the specific tasks needed to be done in order to produce the project’s deliverables. The Scope Baseline is used as a starting point to breakdown the documented deliverables even further, as well as a guide to assure that the entire scope of the project is covered, but that the activities do not extend beyond the boundaries of the project. The Scope Baseline, an output of the Create Work Breakdown Structure (WBS) process, comprises three things—the WBS, WBS dictionary and the Project Scope Statement.

Decomposition is a tool and technique of Define Activities, just like the Create WBS process; here the work is being decomposed to a more detailed level than it was in the Create WBS process. Define Activities involves examining the lowest level of the WBS, called work packages, and breaking them down even further into activities. For example, if a work package was “bake a birthday cake,” the activities derived from this could include: select recipe, determine which ingredients needed to be bought, buy ingredients, preheat oven, mix ingredients, place ingredients in cake pan, place in oven, and remove from oven when done. The outputs of this process are the Activity List, Activity Attributes, and Milestone List. The Activity List is simply the list of activities, whereas Activity Attributes can document a number of things about each activity, for example, who is responsible, which activities must come first, constraints and assumptions. In summary, Define Activities creates a list of activities based on the deliverables defined in the WBS.

Earning Your PMP

In order to take the PMP Exam, you must have a certain amount of experience managing projects and have 35 hours of formal education in project management. If your highest degree is a high school or associates degree, you’ll need to document 5 years and 7,500 hours of managing projects. If your highest degree is a bachelor’s degree or higher, you’ll need to document 3 years and 4,500 hours of managing projects. The 35 contact hours of formal education can take the form of various types of instruction, although it is often in the form of taking a course with a Registered Education Provider (REP). A REP is an organization that is approved by the Project Management Institute (PMI) for providing education and has the ability to award contact hours and Professional Development Units (PDUs) to its students. For example, here at TAPUniversity we are a REP whose 10-week online PMP course both prepares participants for their PMP Exam and also satisfies the requirement of 35 contact hours.

For those that meet the experience and education requirements, the first step is going to http://www.pmi.org to work on the application for the PMP exam. You’re able to save your application and come back and work on it later if you wish. On this application, you’ll be documenting your education and the specific details of the projects you have led. After submitting your application, PMI reviews it for completeness. Then you’ll be asked for payment. The cost of the exam for PMI members is $405. At this point, some applications will be audited. Otherwise, the exam can be taken. The computerized exam is scheduled through Prometrix at a testing center. You’ll be taken to the Prometrix website through the PMI website.

The exam itself is 200 questions. Only 175 of these questions are actually scored. The rest are questions that are being tested for future exams, and you won’t know which questions these are. You’ll have four hours to take the exam. You’re allowed to take breaks, but the clock is still ticking so it’s best to keep breaks short. Immediately after you finish the exam questions, you’ll be informed whether you passed. To maintain your PMP certification, you’ll need to earn PDU’s. During the three years after you earned your PMP, you’ll need 60 PDU’s. There are various ways to earn PDU’s—for example, you can be involved in your local PMI chapter meetings, give talks or write papers on project management, and take classes. If you choose to take classes for your PDU’s, TAPUniversity has a variety of online classes available.

Here’s the link to PMI’s official handbook that goes into more detail on the PMP certification if you wish to read more: http://www.pmi.org/PDF/pdc_pmphandbook.pdf

Sequence Activities Process

Sequence Activities is one of the 42 project management processes outlined in the fourth edition PMBOK®. It’s categorized as one of the six Time knowledge area processes, and one of the twenty Planning processes. The purpose of this process is to document the relationships among the project activities. We already have the list of activities—they were documented in the Define Activities process. So the three outputs of the Define Activities process—the Activity List, Activity Attributes, and Milestone List—are all inputs into the Sequence Activities process. For a given activity on the list, we determine which activities come before (called predecessors) and which activities come after (called successors). If one of our activities for baking a birthday cake is “buy ingredients,” then predecessor activities could be to select the recipe and determine which ingredients need to be bought. Successor activities could include preheating the oven, mixing ingredients, and placing the ingredients in a cake pan. The tool and technique of the Precedence Diagramming Method categorizes the relationships between activities based on whether an activity can be merely started, or has to be completely finished, until the next activity can be started or completely finished. For example, you have to finish buying all the ingredients for the birthday cake before you can start mixing all the ingredients together. Another tool and technique of this process is Dependency Determination, meaning that the relationships between activities may be categorized as Mandatory, Discretionary, or External. A Mandatory dependency would be that you must buy the ingredients for the cake before you can possibly place them in a cake pan. An example of a Discretionary dependency is that although it may be best to preheat the oven before mixing the ingredients, you could also mix the ingredients and then preheat the oven. The primary output of Sequence Activities is Project Schedule Network Diagrams, which graphically illustrates the order and relationships among the project activities.

Estimate Activity Resources Process

Estimate Activity Resources is one of the 42 project management processes outlined in the fourth edition PMBOK®. It’s categorized as one of the six Time knowledge area processes, and one of the twenty Planning processes. The purpose of this process is to examine the project activities and estimate what materials, people, equipment, and supplies are needed and how much is needed. The first thing to obtain is the list of activities and the accompanying information about them. These documents are called the Activity List and Activity Attributes, and they were created in the Define Activities process. Another input needed in order to make the estimations involving people is Resource Calendars, which is an output of the Acquire Project Team process that indicates when people are available. To actually estimate the resources needed for a specific activity, someone who is knowledgeable about the activity can provide an estimate—this is called Expert Judgment. Sometimes there are publications available that indicate what one should expect to pay for certain materials or labor. Utilizing these publications is called the tool and technique of Published Estimating Data. Lastly, an activity may need to be broken down into smaller components whose resource needs can be more accurately estimated. The total resources for these smaller components are simply added together to provide the overall resources needed for that activity. This is called the tool and technique of Bottom-Up Estimating. After the estimations are made, they become the major outputs of this process— Activity Resource Requirements and the Resource Breakdown Structure. Activity Resource Requirements is the documentation of the type and quantities of resources needed for each activity, and the Resource Breakdown Structure illustrates the needed resources in a hierarchical form based on the different categories of resources.

Estimate Activity Durations Process

Estimate Activity Durations is one of the 42 project management processes outlined in the fourth edition PMBOK®. It’s categorized as one of the six Time knowledge area processes, and one of the twenty Planning processes. The purpose of this process is straightforward—it estimates how long the individual project activities will take. We first need a list and information about these activities, which is in the form of the Activity List and Activity Attributes documents (outputs of the Define Activities process). We also should know the resource requirements, which is in the form of the Activity Resource Requirements document (an output of the Estimate Activity Resources process), and we must know how much time people have to work and when they are available, and this is in the form of the Resource Calendars (an output of the Acquire Project Team process). Estimate Activity Durations lists four different ways to actually estimate how long an activity will take—Expert Judgment, Analogous Estimating, Parametric Estimating, and Three-Point Estimating. Also, the tool of Reserve Analysis may be used to add a little time into your estimates as a safety, so that the entire project will not be behind schedule if some activities take longer than planned. To read more about these tools, please see earlier postings on TAPUniversity’s blog: PMP Exam – PERT Formula (posted February 6, 2009) which is a weighted three-point estimating formula; Reserve Analysis (posted February 11, 2009); and PMP Exam – Cost Estimating Tools and Techniques (posted February 4, 2009). The primary output of Estimate Activity Durations is the Activity Duration Estimates, which is then used to develop the project schedule in the Develop Schedule process.

Develop Schedule Process

Develop Schedule is one of the 42 project management processes described in the fourth edition PMBOK®. It’s one of the six Time knowledge area processes, and one of the twenty Planning processes. The purpose of this particularly important process is to create the project schedule. This is the most important Time process, and there are more inputs and tools for the Develop Schedule process than any other Time process. The four Time processes that occur beforehand (Define Activities, Sequence Activities, Estimate Activity Resources, and Estimate Activity Durations) all contribute information that is needed to create the schedule, and the process that begins after the schedule is made (Control Schedule) monitors whether the project is on track with the schedule. In addition to the Project Scope Statement and Resource Calendars being inputs, the Time processes provide the inputs of Activity List and Activity Attributes (from Define Activities), Project Schedule Network Diagrams (from Sequence Activities), Activity Resource Requirements (from Estimate Activity Resources), and Activity Duration Estimates (from Estimate Activity Durations).

The Develop Schedule process takes all this information from these inputs concerning the activities, their needed durations and resources, and their dependencies among each other, and creates the Project Schedule. This is not a simple process. In fact, PMI (Project Management Institute) even offers a credential for scheduling professionals, the PMI-SP. Software is frequently used to make schedule creation easier, which is this process’s tool of Scheduling Tool. Leads and lags are determined, which is accounting for lead time before an activity and lag time after an activity. The Critical Path Method and Critical Chain method are two common methods of organizing individual project activities into a complete schedule. If the schedule must be compressed, there are the options of crashing (adding some type of resources) and fast-tracking (performing tasks in parallel). Of course, the primary output of this process is the Project Schedule.

Earned Value Management – Planned Value – Step 3

In earlier postings, the concepts of Earned Value (EV) and Actual Cost (AC) have been discussed. Earned Value is how much value is in the work already accomplished, and Actual Cost is how much money the work already accomplished has actually cost. The third term to understand is Planned Value (PV). PV is how much we estimate the value to be of the work that we’re planning to do. Another way of thinking about PV is the amount of money we’ve budgeted for the work scheduled at that point in time. The chart below illustrates the EV, PV, and AC for a ten-week project that is currently on week 5. PV should be estimated for the whole project at the beginning of the project. Note that the PV on the chart extends for all ten weeks, whereas we do not know what the EV or AC will be for that week until we get to that week, so those lines stop at week 5. At week 5, PV is $5000. So we budgeted to spend a total of $5000 by week 5. The AC for week 5 is $5,500, so we’ve spent $500 more than we had planned. The EV for week 5 is $5,200, meaning that the value of the work performed so far is worth more than we had planned it to be at this point in time. This all means that we’re a little over budget, but we’re also a little ahead of schedule.

Planned Value

Estimate Costs Process

Estimate Costs is one of the 42 project management processes described in the fourth edition PMBOK®. It’s one of the three Cost knowledge area processes, and one of the twenty Planning processes. The purpose of this process is to estimate how much money will be needed for the project activities. Although the purpose is straightforward, this process has more inputs, tools, and outputs than most—6 inputs, 9 tools and techniques and 3 outputs. It’s difficult to accurately estimate costs, especially at the beginning of a project, so these estimates are refined during the course of the project. Estimates at the beginning of a project could be over or under by 50% (called the rough order of magnitude), whereas later on the estimates may be within 10% of the actual costs.

The Human Resource Plan (from the Develop Human Resource Plan process) is used as a reference to help estimate costs associated with paying the people who are working on the project. The Scope Baseline (from the Create WBS process) contains information on the budget constraints in addition to the project activities and their inter-relationships. Like the Scope Baseline, the Project Schedule (from the Develop Schedule process) contains a large amount of information related to the needed resources and activity durations. Mitigation costs should also be calculated using the Risk Register (from the Identify Risks process) as a guide.

As mentioned, there are many tools that can be employed when estimating costs. When vendors are involved, there may need to be an overall analysis of what the project should cost. The costs of quality should also be considered. To read more about the tools of this process, please see earlier postings on TAPUniversity’s blog: PMP Exam – Cost Estimating Tools and Techniques (posted February 4, 2009), PMP Exam – PERT Formula (posted February 6, 2009) which is a weighted three-point estimating formula; and Reserve Analysis (posted February 11, 2009).

The major outputs of Estimate Costs are Activity Cost Estimates and Basis of Estimates. The Activity Cost Estimates are the actual estimates of expenses, and the Basis of Estimates is the supporting detail, such as the assumptions used for a particular estimate.

Determine Budget Process

Determine Budget is one of the 42 project management processes described in the fourth edition PMBOK®. It’s one of the three Cost knowledge area processes, and one of the twenty Planning processes. The purpose of this process is to add up the estimated costs of the project activities in order to create the budget. These cost estimates and their explanations are found in Activity Cost Estimates and Basis of Estimates, which were outputs of the Estimate Costs process. Cost Aggregation is the fancy term for simply adding up these estimated costs. Additionally, there are a few other documents that are good to reference when developing the budget—the Scope Baseline, Project Schedule, Resource Calendars, and Contracts. The Scope Baseline should be referenced for mention of funding constraints. Assuring that the budget is within these funding constraints is called Funding Limit Aggregation. The Project Schedule and Resource Calendars are used as a basis for knowing how much to budget for different calendar periods of the project. For example, costs may be low for the first couple months, but according to the calendar, in the third month a substantial amount of material may need to be purchased and specialized labor hired, so more funds will be budgeted for that time. Contracts associated with the project should also be examined for agreed-upon costs.

While developing the budget, having some information available on relevant past costs is called Historical Relationships, and taking advantage of someone’s expertise in the area is called Expert Judgment.

The major outputs of Determine Budget are the Cost Performance Baseline and Project Funding Requirements. The Cost Performance Baseline is usually a graph illustrating the budget over the length of time of the project. It does not include reserves which are funds set aside in case they are needed. Please see the earlier posting of Reserve Analysis (posted February 11, 2009). Project Funding Requirements, however, includes the cost baseline in addition to any reserves.

Payback Period

One of the several financial selection techniques that may be used to compare potential projects in order to estimate which would be the most financially beneficial is Payback Period. Selecting among projects takes place at the program or portfolio level where the organization decides which projects are worth the investment. The potential return on investment may be only one of several criteria used for selecting among projects, however. Project selection methods were considered a tool of the 3rd edition PMBOK’s Develop Project Charter process, but it is not mentioned in the 4th edition. Payback Period is not as informative as other financial selection techniques such as Internal Rate of Return and Net Present Value. But it is a quick, simple method for comparing potential projects that project managers should understand.

Payback Period is simply the amount of time it will take for the project to break even with its initial investment. The faster one can get their money back, the better, so the project with the shortest Payback Period is preferred. For example, if project A has a Payback Period of 1 year and project B has a Payback Period of 2 years, we would prefer to select project A.

Before comparing among projects, the Payback Period will have to be calculated. It is important that accurate data be obtained to make these estimations. For example, if project C will cost $75, and the first 3 months will provide no returns, but after that the project will bring $25 per month, what is the Payback Period? The Payback Period would be 6 months. The first three months total $0, month 4 totals $25, month 5 totals $50, and month 6 totals $75. At month 6, we have gotten back the $75 that we invested in the project.

Observations

Observation (also called Job Shadowing) is a tool and technique of the PMBOK’s Collect Requirements process. The Collect Requirements process defines and documents the needs of the stakeholders as they relate to meeting the project objectives. This method consists of watching people perform their work. It can be useful in understanding how the work is actually done (which may be different than how it should be done, or how a manual states that it should be done, or how managers think it is being done). Also, some work processes may not be written anywhere and only the workers themselves may know how the work is actually done. At times, people are unable to clearly communicate how work is performed, so observing them is the best method.

There are two approaches to observation: Passive (invisible) and Active (visible). In Passive observation, the observer does not interfere by asking questions or participating in the work—they simply observe and take notes (afterwards they may ask questions). In Active observation, the observer is free to ask questions and may even perform some of the work. In some cases, the observer may act as an apprentice. There are advantages to both methods. Passive observation provides a more accurate representation of how the work is performed because the observer interferes less. However, Active observation allows the observer to have a better understanding of the work by asking questions while the work is being performed and perhaps even gaining first-hand experience of performing the work.

CBAP Exam Changes

For Business Analysts studying for their CBAP (Certified Business Analyst Professional) certification, be aware that the exam will be changing. The current exam is based on the Business Analysis Body of Knowledge (BABOK®) version 1.6. The new version, BABOK 2.0 is being released on March 31st, 2009, according the International Institute of Business Analysis (IIBA®) which is the organization that awards the CBAP. The exam will not change with the release of the new BABOK however, and the IIBA states that the current BABOK should be used to study for the exam. A date has not yet been provided for the exam change, but IIBA states that candidates will be “informed well in advance” of the test change date (http://www.theiiba.org). Here at TAPUniversity our online and in-person CBAP courses for those preparing for their exam are currently based on BABOK 1.6, as suggested by the IIBA, and we’ll change to using the BABOK 2.0 for our courses when recommended by the IIBA. If you are planning to take the exam in the future, simply be sure that you are studying from the correct version of the BABOK.

Plan Quality Process

Plan Quality is one of the 42 project management processes described in the fourth edition PMBOK®. It’s one of the three Quality area processes, and one of the twenty Planning processes—which should not be difficult to remember with its name. The purpose of this process is to decide what quality requirements and standards should apply to the project and develop a plan (Quality Management Plan) to assure compliance with them. The Scope Baseline includes acceptance criteria for the project which is especially useful in the development of the Quality Management Plan.

The quality processes contain many tools and techniques. In fact, after listing Cost-Benefit Analysis, Cost of Quality, Control Charts, Benchmarking, Design of Experiments, Statistical Sampling, Flowcharting, and Proprietary Quality Management Methodologies as tools and techniques of this process, “Additional Quality Planning Tools” is listed. See earlier posting of Control Chart (posted February 17, 2009). The Cost of Quality technique examines costs of conformance (prevention and appraisal costs) and nonconformance (internal and external failure costs). The primary output of this process is the Quality Management Plan, which describes how the conformance to the selected quality standards will occur. The Quality Management Plan is then used to guide the other two quality processes—Perform Quality Assurance and Perform Quality Control.

Leads and Lags

Applying Leads and Lags is a tool and technique of the fourth edition PMBOK®’s Sequence Activities process; and Adjusting Leads and Lags is a tool and technique of the Control Schedule process. In order to manage a project schedule, a project manager should understand the simple concepts of leads and lags. Leads and lags are sometimes needed in order to more accurately describe the relationship among project activities. For example, the relationship between two project activities may be that one is the predecessor (it needs to be done before the successor activity) and the other activity is the successor (it occurs after the predecessor). If one activity is mixing cake ingredients and the other activity is placing the cake batter in the oven, then the relationship between these two activities is that mixing cake ingredients is the predecessor and placing the cake batter in the oven is the successor.

A lead allows the successor activity to begin more quickly, and a lag means there is a delay before the successor activity may begin. For example, the activity of turning the oven on may take less than 1 minute, and the successor activity of placing the cake batter in the oven may take less than 1 minute. The schedule would be flawed, however, if only a couple minutes were allowed for completing both turning on the oven and placing the cake batter in the oven. This is because there is a lag of the time it takes for the oven to heat to the desired temperature. We may need to add a lag of 15 minutes to account for the oven heating before we can place the cake batter inside the oven. However, even though the oven is not done heating, we could be mixing cake ingredients while it is heating, which gives us some lead time (the ability to start on this activity sooner).

Cost of Quality

How much should be invested in quality efforts? Cost of Quality is a tool and technique of the fourth edition PMBOK®’s Plan Quality process. These are the expenses associated with the investment to make a quality product and the costs of failing to meet quality standards. Cost of Quality is broken down into these two major categories which are called the Cost of Conformance and the Cost of Nonconformance. The Cost of Conformance may be further broken down into Prevention Costs and Appraisal Costs. Prevention Costs represent the investment of keeping the defects from happening at all. This could include extra training for staff members and sophisticated equipment that accurately assembles a product. Appraisal Costs are the expenses of checking the product in order to find any defects that may have occurred. This could include visually inspecting the product, turning the product on to see if it works, and using equipment that detects products that are not within the set parameters. The Cost of Nonconformance may also be broken down into two categories—Internal Failure Costs and External Failure Costs. If a defective product is discovered in-house before being sent to the customer, the costs of scrapping or re-doing the product are Internal Failure Costs. If the product is sold to the customer, the costs of handling returns, complaints, lawsuits, and lost business are called External Failure Costs.

Develop Human Resource Plan Process

Develop Human Resource Plan is one of the 42 project management processes described in the fourth edition PMBOK®. It’s one of the four Human Resource knowledge area processes, and one of the twenty Planning processes. The purpose of this process is to create the Human Resource Plan. The Activity Resource Requirements document (from the Estimate Activity Resources process) is needed as a reference for knowing what human resources are needed for the project. To document the roles and responsibilities in the Human Resource Plan, the organization’s Organizational Charts and Position Descriptions are used, which outline reporting relationships. Networking in order to know more people, and to know people better is especially helpful at the beginning of the project when people are being selected for the team. Having an understanding of how people work together and are motivated is also helpful in putting together a good team, and this is called Organizational Theory.

The Human Resource Plan contains the roles and responsibilities of those involved in the project, organization charts outlining reporting relationships specific to the project, and the staffing management plan. There is much information contained in the staffing management plan, including a description of how staff will be acquired and released, resource calendars, training needs, how safety and compliance issues will be addressed, and how rewards will be given to team members.

Plan Communications Process

Plan Communications is one of the 42 project management processes described in the fourth edition PMBOK®. It’s one of the five Communications knowledge area processes, and one of the twenty Planning processes. The purpose of this process is to create the Communications Management Plan based on the communication needs of the stakeholders. It must be documented who should receive what information, how often, in what format, and from whom. Information about the key stakeholders can be found in the Stakeholder Register and Stakeholder Management Strategy (both documents are from the Identify Stakeholders process). This is the starting place for performing Communication Requirements Analysis, which is the identification of the unique communication needs of the various stakeholders. In developing the Communications Management Plan, one needs to know what type of communication technology is available (phone, email, video-conferencing, etc.) and should have knowledge of Communication Models and Communication Methods. The primary output of the Plan Communications process is the Communications Management Plan, which becomes part of the overall Project Management Plan. This document can contain much information depending on the size and formality of the project, including stakeholder communication requirements, what information should be communicated and why, who is responsible for communications, when communications should occur, the time and budget allowed for communication activities, communication constraints, and information flowcharts.

Please also see the related, earlier posts of Identify Stakeholders Process (posted February 19, 2009) which is a predecessor to this process, and PMP Exam – Communication Formula (posted February 3, 2009), which is part of performing Communication Requirements Analysis.

Plan Risk Management Process

Plan Risk Management is one of the 42 project management processes described in the fourth edition PMBOK®. It’s one of the six Risk knowledge area processes, and one of the twenty Planning processes. The purpose of this process is to develop the Risk Management Plan which lays the foundation for the other risk processes on how risk activities will be performed for the project. The Project Scope Statement is referenced to better understand the project and its deliverables as every project has a unique set of risks. A project that involves unchartered territory will have more unknowns involved than a more routine project based on a history of similar projects. Understanding the contingencies in place for risks affecting the budget and schedule can be accomplished through examining the Cost Management Plan and the Schedule Management Plan. Knowing with whom to discuss project risks and responses may be found in the Communications Management Plan (from the Plan Communications process). Interestingly, Planning Meetings and Analysis is the only tool and technique of this process. This demonstrates that planning for risk management essentially is determined by a group of stakeholders discussing and deciding what is best for the particular project at hand. The result of these discussions is the only output of Plan Risk Management—the Risk Management Plan which describes what risk activities will be performed and how they will be performed throughout the project.

Risk Register

The Risk Register is an important project management document. It originally appears as the only output to the Identify Risks process of the fourth edition PMBOK®. As more analysis, planning, and monitoring occurs throughout the four risk processes that follow it (Perform Qualitative Risk Analysis, Perform Quantitative Risk Analysis, Plan Risk Responses, and Monitor and Control Risks), the risk register is updated as part of performing each of these processes. As each of these risk processes are performed, more information is added to the expanding document. Eventually it may contain a list of all identified risks, along with information describing them including their causes, categorization, probability of occurrence, impact if they occur, planned responses, person responsible, qualitative and quantitative risk analyses, and current status. The risk register is also used as an input to three other processes outside of the risk knowledge area—Estimate Costs, Plan Quality, and Plan Procurements.

Milestone List

A milestone is stone along a roadway carved with information for travelers such as how many more miles to the next town. Today, we see the common metal road signs and mile markers which serve the same purpose. They provide an indication to travelers on how close they are to their destination and which way they should go. Similarly, milestone lists are utilized in project management as an indication of progress through the achievement of a major project accomplishment. A project milestone is a significant project event or point in time. Milestone lists are an output of the fourth edition PMBOK®’s Define Activities process and an input to the Sequence Activities process. The milestone list is considered a project document that is not part of the project management plan. The list contains all the project milestones along with information indicating whether they or not they are mandatory to achieve. Dates may be included that correspond with the milestones, which is especially useful for the Sequence Activities process and later scheduling.

Negative Risk Strategies

For a project manager, a risk is an uncertain event. This potential event could be either desired (positive) or undesired (negative). A positive risk may be referred to as an opportunity, and a negative risk may be referred to as a threat. There are three unique strategies used for handling negative risk (avoid, transfer, and mitigate), and one strategy that can be used for either positive or negative risk (accept). These are described as a tool and technique of the fourth edition PMBOK®’s Plan Risk Responses process. Below are some examples of the negative risk strategies as related to Katy baking a wedding bake for her daughter’s wedding.

Avoid means that plans are modified to completely eliminate the threat. Katy originally planned to bake a five-tier wedding cake, but she is so afraid that it will collapse, that she has decided to avoid the risk of collapsing altogether by baking the five cakes and setting them each on their own platter beside each other on the cake table.

Transfer means that the ownership and consequences of the risk are transferred to another party. Katy decides to buy cake insurance from a local baker—so that if the risk of her cake being ruined occurs, the baker will be able to bring a replacement cake in time.

Mitigate means that the probability or impact of the risk is lessened. Katy found a sturdy silver stand with five platforms for the five layers of cake. Although it appears that the cakes are balanced on top of each other, they actually aren’t. Because of this, it is very unlikely that the risk of the cake collapsing will occur.

Accept means that plans are not changed due to the risk, and the consequences of the risk event happening are simply accepted. Katy decides to make the five-tier cake. In the unlikely case that it becomes ruined, there simply won’t be wedding cake for the guests to eat.

Positive Risk Strategies

For a project manager, a risk is an uncertain event. This potential event could be either desired (positive) or undesired (negative). A positive risk may be referred to as an opportunity, and a negative risk may be referred to as a threat. There are three unique strategies used for handling positive risk (exploit, share, and enhance), and one strategy that can be used for either positive or negative risk (accept). These are described as a tool and technique of the fourth edition PMBOK®’s Plan Risk Responses process. Here are some examples involving Katy, who is hoping that the positive risk event of “cookies being available this afternoon” occurs.

Exploit means that the potential positive event is made to occur. Katy drives to a grocery store and buys a box of chocolate chip cookies.

Share means that the opportunity is shared with a third party for the benefit of both. Katy has a friend who makes delicious oatmeal raisin cookies. Katy offers to buy the ingredients if her friend will bake a batch that they can share.

Enhance means that the probability and positive impact of the opportunity is increased. Katy sends a text message to her mother that reads “I wish someone cared enough to bring me cookies.”

Accept means that plans are not changed due to the risk, but if the opportunity does occur, it will be accepted. Katy hopes that because people know she is addicted to cookies, someone will think of her and give her some. She won’t ask anyone to get her some though.

Identify Risks Process

Identify Risks is one of the 42 project management processes described in the fourth edition PMBOK®. It’s one of the six Risk knowledge area processes, and one of the twenty Planning processes. The purpose of this process is to document the risks along with their characteristics in the Risk Register that may affect the project. With the many inputs and tools to this process, there is only one output—the risk register—which is then updated in subsequent processes. The Risk Management Plan (output of the Plan Risk Management process) is a key input because it provides guidance as to how all the other risk processes are to be performed. Additionally, a number of project plans and other documents are used to uncover and identify risks that should be incorporated in the Risk Register, which is called Documentation Reviews. Simply having the team think about what risks could occur is covered by the tool of Information Gathering Techniques, and if thinking specifically about challenging the project’s assumptions, it’s called Assumptions Analysis. Tools to guide this thinking in a more structured way include SWOT Analysis and Diagramming Techniques. Using historical information such as the risks from similar, past projects is Checklist Analysis. Altogether, these tools simply aid the team in forming the list of risks to be placed on the Risk Register for further analysis and planning in later processes. For more on this topic, please see the earlier posting of Risk Register (posted March 27, 2009).

Perform Qualitative Risk Analysis Process

Perform Qualitative Risk Analysis is one of the 42 project management processes described in the fourth edition PMBOK®. It’s one of the six Risk knowledge area processes, and one of the twenty Planning processes. The purpose of this process is to perform a qualitative risk analysis, which prioritizes risks based on their probability of occurring and their potential impact. The Risk Register, which contains the list of project risks, is needed in addition to the Risk Management Plan, which contains pre-defined definitions of probability and impact. To perform the qualitative risk analysis, the probability of each risk occurring is estimated and this is multiplied by a number representing how severe the impact would be if the risk occurs. This assumes that the data is accurate—investigating the quality of the data is the tool of risk data quality assessment. The risks are then prioritized based on which have the largest ratings, as these will be the most important risks to invest in planning and monitoring. This information is then added to the Risk Register, and this update to the Risk Register is the only output to this process. For more on this topic, please see the earlier posting of Risk Register (posted March 27, 2009).

Perform Quantitative Risk Analysis Process

Perform Quantitative Risk Analysis is one of the 42 project management processes described in the fourth edition PMBOK®. It’s one of the six Risk knowledge area processes, and one of the twenty Planning processes. The purpose of this process is to numerically analyze the effects of project risks. This can be time-consuming, so it typically is only performed on the risks that have been considered high-priority based on the qualitative risk analysis that was done during the Perform Qualitative Risk Analysis process. The list of project risks, including the results of any qualitative analysis that may have been done, can be found in the Risk Register. The Risk Management Plan provides overall guidance on how the risks processes, including this one, are to be performed. In order to model the potential impacts of risks, data is needed. This can be obtained through interviewing people and using probability distributions that statistically indicate the likelihood of events. To perform the analysis, one may use a variety of techniques including a sensitivity analysis (the tornado diagram is a common example), expected monetary value analysis, or a modeling/simulation technique such as a Monte Carlo analysis. The only output to this process is Risk Register Updates which represents adding the results of the quantitative analysis to the Risk Register. Also see the earlier postings of Perform Qualitative Risk Analysis Process (posted April 3, 2009) and Risk Register (posted March 27, 2009).

Schedule Compression

It needs to be done in less time… Schedule Compression is a tool and technique of the Develop Schedule process described in the fourth edition PMBOK®. If a project needs to be completed faster than it is currently progressing, the project manager may apply a schedule compression technique. Two schedule compression techniques are crashing and fast-tracking. Crashing applies additional money and/or resources to shorten the duration of the project. This can increase risk to the project, so the trade-off should be carefully considered. Also, there some types of tasks that additional money or resources cannot shorten. Fast-tracking is the preferred method of schedule compression. Fast-tracking performs activities in parallel that are normally done sequentially. Like crashing, there can be additional risk introduced.

Here are some examples involving Katy, who is planning on making cookies tomorrow afternoon just before her dinner guests arrive so that the cookies will be warm from the oven. She discovers that her dinner guests will be arriving earlier than planned, but she can’t start making the cookies earlier, either. She applies the technique of crashing, and buys a couple more cookies sheets so that she bake three sheets of cookies at once, rather than just one sheet of cookies at a time. So, she has invested more money (to buy the extra cookie sheets) in order to shorten the duration of her cookie baking project. Typically, Katy watches the cookies the entire time they are in the oven so they don’t burn. But she decides to also apply fast-tracking and set the table for her dinner guests while the cookies are in the oven. Normally the task of setting the table would come after her cookies are taken out of the oven, but now the task of the cookies baking is done at the same time the table is being set. As you can see, there is some added risk that the cookies are more likely to burn, but she decides it is worth the trade-off to have warm cookies ready for her guests.

What-If Scenario Analysis

Thinking through potential outcomes, the What-If Scenario Analysis is a tool and technique of the Develop Schedule process and the Control Schedule process, both described in the fourth edition PMBOK®. This technique is used to estimate impacts to the project schedule if potential scenarios occur. This technique simply repeatedly asks “what if” a certain event should happen. It is useful to have more than one person’s perspective and ideas for this analysis. For example, Katy has two hours to bake three dozen cookies. She and her family are doing a What-If Scenario Analysis for this cookie baking project. “What if you burn the first batch?” asks her husband. They estimate that will extend the schedule an hour. “What if Dad is eating the cookies as fast as you can make them?” asks her daughter. They estimate that he’ll become full at a certain point, so it’ll extend the schedule half an hour. In summary, What-If Scenario Analysis simply estimates the effect that potential events may have.

Plan Risk Responses Process

Plan Risk Responses is one of the 42 project management processes described in the fourth edition PMBOK®. It’s one of the six Risk knowledge area processes, and one of the twenty Planning processes. The purpose of this process is to develop plans to minimize threats (negative risk) and maximize opportunities (positive risk). The Risk Register, which lists the project risks and information about them, and the Risk Management Plan, which provides overall guidance for the risk processes, are both needed. For each risk on the register that is important enough to warrant investing time into planning a response, a strategy is chosen. The seven strategies are: Avoid, Transfer, Mitigate, Accept, Exploit, Share, and Enhance. Please see the earlier postings of Positive Risk Strategies (posted April 1, 2009) and Negative Risk Strategies (posted March 31, 2009) to read more about these strategies. Contingency Response Strategies may also be developed, which are plans that are executed only if a certain trigger occurs. The outputs of this process include Risk-Related Contract Decisions and updates to several documents including the Risk Register, Project Management Plan, and Project Document updates.

Group Decision Making Techniques

How can direction be set for a group? Group Decision Making Techniques is listed as a technique of the Collect Requirements process described in the fourth edition PMBOK®. However, these can be used at any time a group decision must be made—not only decisions regarding requirements or project management. Four methods of reaching a decision are: unanimity, majority, plurality, and dictatorship. Katy and her husband have three children. The family is trying to decide what type of cookies they should bake. Here are examples of each of the decision making methods.

Unanimity: everyone in the group agrees to the same thing. Everyone in the family has to come into agreement. After discussing their options and hearing a passionate speech from the youngest child about how good great-grandma’s recipe for oatmeal raisin cookies is, each person decides that they could have oatmeal raisin cookies.

Majority: more than fifty percent of the group decides. There are five people in Katy’s family. Her husband and two of the children want sugar cookies, and since three of five people is sixty percent (which is more than the necessary fifty percent), the family has sugar cookies.

Plurality: the largest block of people in the group decides. The parents are a block of two people and the children are a block of three people, so the children are permitted to decide that the family will have peanut butter cookies.

Dictatorship: one person makes the decision for the group. Katy states that she’s the one that will be baking, and she alone decides that the family will be having chocolate chip cookies.

Prototypes

One of the tools and techniques of the Collect Requirements process described in the fourth edition PMBOK® is Prototypes. They are a working model of a product that allows for feedback before producing the final product. Feedback cycles may be utilized in which people (such as stakeholders) can provide input, and then a revised model can be presented for further input and revisions. For example, Katy is trying to bake a batch of chocolate chip cookies to be entered in an upcoming cookie contest. She bakes an experimental batch and asks her family for feedback. They tell her that she needs more chocolate chips in the cookies, and that they need to be chewier. Katy revises her recipe and bakes another batch for her family. This time they suggest that she make the cookies larger and a little less sweet. After a few more iterations, Katy believes she has the recipe for a winning chocolate chip cookie.

TAPUniversity has received its renewal as a Global R.E.P. for PMI

For immediate release —————————-

Technology As Promised and its learning portal TAPUniversity recently completed their renewal as a Global Registered Education Provider for the Project Management Institute. This designation allows TAPUniversity to continue its expanding delivery of project management related courses – online and in-person. That delivery now includes not only project management but virtual teams, business analysis, Six Sigma, CobiT, Career Survival Series and several additional subject areas geared toward helping our alums succeed in difficult economic conditions.

—————————-

Dear Mr. Kohrell, I am happy to inform you that the Technology as Promised renewal application for enrollment as a PMI Registered Education Provider (R.E.P.) has been reviewed and approved by PMI…

Best Regards,

Cherie Sterling
R.E.P. Processor
Project Management Institute

Plan Procurements Process

Plan Procurements is one of the 42 project management processes described in the fourth edition PMBOK®. It’s one of the four Procurement knowledge area processes, and one of the twenty Planning processes. The purpose of this process is to document the purchasing decisions and approach as well as identify potential sellers. There is much information needed beforehand to accomplish this, which is represented by eleven inputs to this process. The Scope Baseline and Requirements Documentation are important inputs used to describe the project work to be performed. The specific work that is to be performed in a contract is called the Procurement Statements of Work.

It must first be decided whether certain work is best done in-house or whether it should be purchased. This is called Make-or-Buy Analysis, and its outcome is Make-or-Buy Decisions. There are advantages and disadvantages of the different types of contracts that need to be considered as well. The types of contracts that should be used, in addition to much other information, is written in the Procurement Management Plan that provides guidance for performing the procurement processes. Procurement Documents describing what work is needed are made available to sellers in order to elicit their offers. Source Selection Criteria are the criteria developed in this process that will be used to choose among sellers’ responses. For example, sellers representing larger or local organizations might be preferred.

Make-or-Buy Analysis

The project management technique of deciding whether certain work should be performed in-house or whether it should be purchased is called Make-or-Buy Analysis. Make-or-Buy Analysis is listed as a technique for the fourth edition PMBOK®’s Plan Procurements process. A project manager may have a Procurement Management Plan for the project that offers guidance in making these decisions. There are many considerations to take into account when deciding whether or not to purchase, and these considerations will vary across organizations and projects, and over time. Seller’s price will typically be a key consideration. Whether there is currently the level of in-house expertise for the work that needs to be done and the time project team members have available are also important to consider. An example Make-or-Buy Analysis question is: should you mow your own lawn or hire a lawn service company to do it? You may consider whether you currently own a mower, how much time you have to devote to lawn mowing, if allergies or other health issues would make mowing difficult for you, and how much you’re willing to pay a lawn service. The decisions on whether to make or buy something are called Make-or-Buy Decisions. These Make-or-Buy Decisions are an output to the PMBOK®’s Plan Procurements process and then used as an input to the Conduct Procurements process.

Fixed Price Contracts

Project managers increasingly need to be knowledgeable about procurement and contracts. Contract Types is a tool of the fourth edition PMBOK®’s Plan Procurements process. There are a variety of contract types falling under the general categories of Fixed Price, Cost Reimbursable, and Time and Materials. The types of Fixed Price contracts (as termed in the PMBOK®) are Firm Fixed Price (FFP), Fixed Price Incentive Fee (FPIF), and Fixed Price with Economic Price Adjustment (FP-EPA). Fixed Price contracts are generally preferred by project managers. Below are examples of each type of Fixed Price contract.

Firm Fixed Price (FFP). The price is set and cannot be changed unless the scope of work changes. For example, Katy has agreed to bake ten dozen cookies for her neighbor for the price of $40.

Fixed Price Incentive Fee (FPIF). The price is set, but there is the potential for the seller to also receive a financial incentive if an agreed-upon, objective metric is met. Katy has agreed to bake ten dozen cookies for her neighbor for $40, and if she is able to finish baking by 2:00pm this afternoon, the neighbor will pay her an additional $10.

Fixed Price with Economic Price Adjustment (FP-EPA). The price is set, but especially for contracts over long periods of time, it may be adjusted due to changing economic conditions. Katy has agreed to bake ten dozen cookies every year for her neighbor’s annual office party. This year she will receive $40, and every year afterwards she will receive 3% more than the year before to account for inflation.

Cost-Reimbursable Contracts

As project managers work with procurements, it’s important that they understand the different types of contracts. Contract Types is a tool of the fourth edition PMBOK®’s Plan Procurements process. There are a variety of contract types falling under the general categories of Fixed Price, Cost Reimbursable, and Time and Materials. The types of Cost Reimbursable contracts (as termed in the PMBOK®) are Cost Plus Fixed Fee (CPFF), Cost Plus Incentive Fee (CPIF), and Cost Plus Award Fee (CPAF). Note that the definitions have changed slightly since the last edition of the PMBOK®. Cost Reimbursable contracts reimburse the seller for their actual costs. Below are examples of each.

Cost Plus Fixed Fee (CPFF). The seller is reimbursed for their actual costs plus given a percentage of those costs. Katy’s neighbor pays her for the cost of ingredients plus 50% of those costs in return for ten dozen of Katy’s homemade oatmeal raisin cookies. The ingredients cost $40, so Katy is paid $40 plus 50% of $40 (which is $20), which totals $60.

Cost Plus Incentive Fee (CPIF). The seller is reimbursed for their actual costs plus given a financial incentive if an agreed-upon objective is met. Katy’s neighbor offers to pay her for the cost of ingredients in return for ten dozen of Katy’s award-winning sugar cookies, plus $20 if she can finish the cookies before 7:00pm this evening.

Cost Plus Award Fee (CPAF). The seller is reimbursed for their actual costs plus a financial incentive based on criteria that are at the buyer’s discretion. Katy’s neighbor offers to pay her for the cost of ingredients for 100 of Katy’s peppermint chip cookies, plus $50 if the neighbor decides they are the best cookies she has ever eaten in her entire life.

Time and Materials Contracts

Time and Materials is one of three broad types of contracts—Fixed Price, Cost Reimbursable, and Time and Materials. Contract Types is a tool of the fourth edition PMBOK®’s Plan Procurements process. Time and Materials contracts are useful when the full scope of the project is unknown. They resemble Fixed Price contracts in that there can be a fixed price for each unit. However, it is unknown how many units will be purchased so there is not a fixed price for the entire contract. As an example, Katy’s neighbor knows that there will be numerous times this summer that she’ll want to purchase homemade cookies from Katy. Katy’s neighbor doesn’t know exactly how many times, but she and Katy agree that each time over the summer she wants a dozen cookies she’ll pay Katy $10 for them. Although the unit price is set at $10, it is unknown how much Katy will earn in total by the time summer is over.

Project Charter

The Project Charter is the only output of the fourth edition PMBOK®’s Develop Project Charter process. The Project Charter is a key project management document. This document formally authorizes and initiates the project. Ideally, the project manager assigned within the document participates in creating it. Earlier editions of the PMBOK described the Project Charter as containing more detailed information than the standard describes today. Now the information tends to be high-level—which is logical, as this is the document that initiates the project. The information contained in the charter will be progressively elaborated upon as the smaller details of the project are later decided. Here is a list of what a Project Charter may contain: project purpose or justification, measurable project objectives and related success criteria, high-level requirements, high-level project description, high-level risks, summary milestone schedule, summary budget, project approval requirements, assigned project manager with their responsibility and authority level, and name and authority level of who is sponsoring the project. For more on this topic, see the earlier posting of Develop Project Charter Process (posted February 18, 2009).

Focus Groups

The Focus Group is common across many disciplines, including project management. They are a tool of the PMBOK®’s Collect Requirements process. The desired type of group should be determined. A homogenous group will have similar people who likely have similar perspectives. A heterogeneous group will contain a variety of people who have varying perspectives. A homogenous group will likely feel more comfortable voicing their opinions and will more likely come to a group consensus. A heterogeneous group will display the interaction of different perspectives. There should be at least several people in the focus group, but beware of allowing the group to so large that people become reluctant to speak. It’s common that not everybody who is invited will come, so more people can be invited than are needed. About an hour is a good length of time for a focus group session—they shouldn’t be so long that people lose interest. The moderator of the focus group should have questions prepared beforehand, and encourage participation from everyone. The focus group should be recorded for later analysis and summary. For more on this topic, see the earlier posting of Collect Requirements Process (posted February 24, 2009).

Project Exclusions, Assumptions, and Constraints

Project exclusions, assumptions, and constraints (among other information) are included in a Project Scope Statement. Katy has a project to make exotic papaya honey cookies to enter in her city’s bake-off competition. The scope of the project is to make and enter one dozen cookies for the competition. Here are some examples of exclusions, assumptions, and constraints for this project.

Project exclusions are those things that outside of the project boundaries. It explicitly states what is not included in the project. This project does not include making enough cookies for Katy to eat some herself. This project does not include submitting her recipe to the judges.

Project assumptions are those things that are believed to be true. Katy believes that she’ll be able to obtain the cookie ingredients from her local grocery store. She also believes that her car will reliably transport her and the cookies to the competition.

Project constraints are limitations placed upon the project team. Katy must have the cookies delivered to the competition one hour before the judging starts. Katy’s husband insists that she spend no more than fifty dollars on exotic ingredients for the cookies.

Rolling Wave Planning

A common type of Progressive Elaboration is Rolling Wave Planning. Progressive Elaboration means to continuously improve and refine planning. Rolling Wave Planning is a technique of the PMBOK®’s Define Activities process and it also describes how the Project Management Plan evolves. The planning is on-going during the project—not completed beforehand. Rolling Wave Planning means that the work to be done in the near-term is detailed; work in the more distant future is not yet detailed. As work is being performed during a stage that had already been planned in detail, the upcoming work is broken down into more detail.

For example, a family is on vacation. On Monday, they decide that on Tuesday they will go to the Dizzying Fun Rides amusement park at 9:00am and will make dinner reservations at 6:00 for an Italian restaurant. They know that they want to go to a zoo on Wednesday, but they don’t have any details worked out. On Tuesday, they go to the amusement park and Italian restaurant as planned, as well as refine their plans for Wednesday’s trip to the zoo. They find a map and directions to the zoo and decide that they’ll arrive at the zoo at 10:00, and bring a picnic lunch to eat at the zoo grounds. They decide that on Thursday they’ll see a national monument, but they won’t decide which one until tomorrow. In this way, the near future of the next day is planned in detail, but the planning of further than one day into the future is still at a high-level.

Basis of Estimates

This document, Basis of Estimates, is an output of the PMBOK®’s Estimate Costs process. This is a companion document to Activity Cost Estimates, which details how much each project activity is expected to cost. The Basis of Estimates document indicates how these estimates were derived. It could include information such as how the estimate was developed, assumptions, constraints, range of possible values, and confidence in the estimate.

For example, in Katy’s Activity Cost Estimates document, she has the activity of “Shopping for Cookie Ingredients” with the cost estimate of $17. Her Basis of Estimates document first contains how this estimate was developed. It was developed by using expert judgment to estimate the cost of the individual ingredients on the shopping list. The flour is about $4, the sugar $3, the chocolate chips are $3, the vanilla is about $2, the eggs are about $2, and the butter is around $3, which totals the $17 estimate. Next are the assumptions and constraints. She assumes that the chocolate chips that typically cost about $4 will only cost $3 because she has a coupon for one dollar off the price of the chocolate chips. She is constrained by only having $20 to spend. Last is the value range and confidence level. The range of possible values for this activity is from $12 to $20, and she is 75% sure that her estimate of $17 will be accurate.

More on this topic can be found in the earlier postings of Estimate Costs Process (posted March 12, 2009) and of Project Exclusions, Assumptions, and Constraints (posted April 23,2009).

PERT Sample Questions

One of the most common topics read on this blog is the PERT formula. Please see the posting “PMP Exam – PERT Formula” (posted February 6, 2009) for an explanation of this formula. To use this formula, we need three estimates—Optimistic (best-case scenario), Most Likely (realistic), and Pessimistic (worst-case scenario). We then find the average, but we first weight the Most Likely estimate by 4. The formula is (O + (4*ML) + P) / 6. Here are some practice questions:

1. Anne hopes that it takes just 10 hours to make preparations for an important meeting. It will probably take 12 however, and if some key things go wrong, it will take 20 hours. How many hours should be scheduled for the meeting preparations using the PERT formula?
a. 14
b. 15
c. 11
d. 13

2. Tim’s mother-in-law just called. He hopes he can get off the phone in 4 minutes, but he knows she usually talks 20 minutes. If her arthritis is bothering her, the call could be 45 minutes. How many minutes should he plan on being on the phone, using the PERT formula?
a. 21.5
b. 23
c. 21
d. 23.5

3. Ginger is racing her horse against her neighbor’s horse. She hopes her horse will run a fourth of a mile in 30 seconds. Usually her horse runs that distance in 32 seconds, but when he’s grouchy it takes him 37 seconds. How many seconds can she guess her horse will run a fourth of a mile, using the PERT formula?
a. 33
b. 32.5
c. 33.5
d. 35

4. Using the PERT formula, George estimated that a certain report will take 10 days to write. His optimistic guess was 7 days and his pessimistic guess was 13 days. What was his guess for the time it would most likely take to write the report?
a. 10
b. 9
c. 11
d. 20

5. Using the PERT formula, Geraldine estimates that it will take her 6 hours to clean her house. Her optimistic guess was 3 hours and her most likely guess was 5 hours. What was her pessimistic guess?
a. 7
b. 4
c. 12
d. 13

Answers: 1. D; 2. A; 3. B; 4. A; 5. D

Direct and Manage Project Execution Process

Direct and Manage Project Execution is one of the 42 project management processes described in the fourth edition PMBOK®. It’s one of the six Integration knowledge area processes, and one of the eight Executing processes. The purpose of this process is to actually perform the project work described in the Project Management Plan. The key input is the Project Management Plan, as that provides the guidance for performing the work. Expert Judgment is used in carrying out the work. During the course of performing the work, Change Requests will arise. This process interacts with the Perform Integrated Change Control process to manage these requests. If a Change Request is approved through the Perform Integrated Change Control Process, this Approved Change Request then becomes an input to Direct and Manage Project Execution. The primary output is Deliverables, which demonstrates the importance of this process. Of the 42 processes, this one is most affected by the application area. Whereas planning and documenting will be similar across all projects, the actual work performed will vary tremendously.

Perform Quality Assurance Process

Perform Quality Assurance is one of the 42 project management processes described in the fourth edition PMBOK®. It’s one of the three Quality knowledge area processes, and one of the eight Executing processes. The purpose of this process is to perform quality audits to ensure that the appropriate quality standards are being met. A quality assurance department within the organization may work together with the project team in performing this process. To perform a quality audit, the quality standards chosen for the project must be compared to the work being performed on the project. These quality standards are found in the Project Management Plan, specifically in the Quality Management Plan and Process Improvement Plan, and in the selected Quality Metrics, which are an output of the Plan Quality process. Information on the work being performed is obtained through two other processes—Direct and Manage Project Execution provides Work Performance Information and Perform Quality Control provides Quality Control Measures. Interestingly, the PMBOK simply states that the tools for this process include all the tools for the other two quality processes. But additional tools are Quality Audits and Process Analysis. Especially if quality standards are not being met, the output of Change Requests can be expected. The other outputs are updates: updates to the Project Management Plan, Project Documents, and Organizational Process Assets.

Other related postings on this blog include: PMP Exam – Pareto Chart (posted February 9, 2009); Scatter Diagram (posted February 10, 2009); Run Chart (posted February 16, 2009); Control Chart (posted February 17, 2009); Plan Quality Process (posted March 19, 2009); and Cost of Quality (posted March 23, 2009).

Acquire Project Team Process

Acquire Project Team is one of the 42 project management processes described in the fourth edition PMBOK®. It’s one of the three Human Resource knowledge area processes, and one of the eight Executing processes. The purpose of this process is to obtain the team members needed for the project. The Project Management Plan contains the Human Resource Plan which outlines what roles are needed are how long they are needed. If people have been assigned to the project before it has started, it’s called Pre-assignment. Acquisition is used to obtain people from outside the organization, and Negotiation may be performed by the project management team to obtain the best people for their project. If the team is to spend little or no time face-to-face with each other, the tool of Virtual Teams is used. The primary output of this process is Project Staff Assignments, which assign individuals to their roles on the project. Documentation of the time these individuals are able to work on the project is done for the Resource Calendars. Overall, this process examines the needed roles as defined in the Project Management Plan and finds individuals to fill those roles.

Develop Project Team Process

Develop Project Team is one of the 42 project management processes described in the fourth edition PMBOK®. It’s one of the three Human Resource knowledge area processes, and one of the eight Executing processes. The purpose of this process is to improve the team’s competencies and their interactions among each other. The list of who is on the team can be found in the Project Staff Assignments, and the times when each person is available can be found in the Resource Calendars. If the team members are at the same location, it’s called Co-location. The Project Management Plan may contain information on planned team development activities and training. It is helpful if the project management team has relevant Interpersonal Skills in their attempt to improve the interactions and skills of the project team. Training can increase competencies of individual members, and Team-Building Activities and Ground Rules can increase the overall functioning of the team. Recognition and Rewards can be used in a fair manner to recognize and increase desirable behavior. The primary output to this process is Team Performance Assessments which evaluate the effectiveness of the team. Also see the related posting of Develop Project Team – Team-building (posted February 5, 2009).

Manage Project Team Process

Manage Project Team is one of the 42 project management processes described in the fourth edition PMBOK®. It’s one of the three Human Resource knowledge area processes, and one of the eight Executing processes. The primary purpose of this process is to track an individual’s performance and provide them feedback. The list of team members can be found in the Project Staff Assignments document, and the Project Management Plan further outlines team members’ responsibilities. Performance Reports provide data indicating how well the project is being performed, whereas Team Performance Assessments are appraisals on how well the team itself is performing. It is possible for the team to be working quite effectively as a group, but due to circumstances beyond their control, the project itself is not going well. Project Performance Reports, which provide feedback to individual project members on their performance, are completed as part of this process. It is common for problems to arise among team members, and these can be handled using Conflict Management techniques and keeping track of problems in an Issue Log. The project management team can utilize their Interpersonal Skills and the tools of Observation and Conversation to facilitate a well-functioning team comprised of unique personalities and motives. The output of this process is the updating of documents in additional to generic change requests, which can include a request for a staffing change.

Activity List

The Activity List is the primary output of the fourth edition PMBOK®’s Define Activities process. The Activity List is the complete list of the scheduled activities for a project. As it is used to help develop the project schedule and estimate needed resources, it serves as an input to the following processes: Sequence Activities, Estimate Activity Resources, Estimate Activity Durations, and Develop Schedule.

The Activity List is created through examining the Work Breakdown Structure (WBS), WBS Dictionary, and Project Scope Statement, and making a list of specific activities. The WBS is a hierarchy of all the work that needs to be performed for a project. The lowest level of the WBS hierarchy is composed of work packages, and these are broken down into the specific activities that are included on the Activity List. For example, if a work package were “laundry,” the activities added to the list may include: Obtain laundry detergent, Sort laundry, Wash laundry, Dry laundry, Determine which laundry to iron, Iron laundry, Fold laundry, and Put laundry away. The Project Scope Statement serves as guidance to assure that the listed activities cover all the project work, but do not extend beyond the boundaries of the project. For example, the scope statement could state that ironing is not considered part of the laundry process. Activity Attributes is a companion document to the Activity List, just as the WBS Dictionary is a companion document to the WBS. The Activity Attributes document contains details on the listed activities such as who is responsible, which activities must come first, constraints and assumptions. For more on this topic, see Define Activities Process (posted March 3, 2009).

Cost-Benefit Analysis

A Cost-Benefit Analysis is a comparison between the costs of an activity and its benefits. This is a broad concept that can be applied across many situations. In general, if the benefits outweigh the costs, the activity is worth pursuing. It can also be used as a means of comparing multiple potential projects to discover which would be the most valuable to initiate. For this reason, it may be included in a project’s Business Case, which is the document that justifies the project.

Cost-Benefit Analysis is specifically listed as a tool and technique of the fourth edition PMBOK®s Plan Quality process. In this case, the costs of a potential quality activity, such as a one-day training seminar, are compared to the benefits, such as higher quality products due to less human error. Essentially, it is part of a Business Case for each proposed quality activity that may be planned.

If the benefits and costs are measured strictly in financial terms, the Benefit-to-Cost Ratio may be examined. This is simply dividing the benefits by the costs. For example, if project Alpha is expected to bring in $100 and it will cost $50, then the Benefit-to-Cost Ratio is 100/50, which is 2.0. If project Beta is expected to bring in $75 and it will also cost $50, then the Benefit-to-Cost Ratio is 75/50, which is 1.5. Because project Alpha has a higher ratio, on financial considerations alone, it should be preferred over project Beta.

Project Management Plan

The Project Management Plan describes how a certain project is to be executed, monitored and controlled, and closed. Its contents, length, and level of detail will vary across different projects. It is the only output of the fourth edition PMBOK®’s Develop Project Management Plan process. Because it serves as a roadmap for the project, the writing of the Project Management Plan should begin very early in the project. When writing begins, the Project Charter may be the only previous document to use as a reference. However, the Project Management Plan is not completely written before the project begins. On the contrary, it is continuously updated and elaborated upon throughout the project. Also, the Project Management Plan is not a single plan—it is a collection of subsidiary plans and baselines. Examples of these subsidiary plans are: Scope Management Plan, Requirements Management Plan, Schedule Management Plan, Cost Management Plan, and Risk Management Plan. Baselines could include Schedule, Cost, and Performance baselines. These subsidiary plans and baselines are outputs from separate processes that are then integrated into the Project Management Plan. The level of detail of these subsidiary plans, and whether or not they are even included, will vary from project to project. A long-term project with a large team will necessitate a far more detailed Project Management Plan than will a smaller project. The PMBOK’s Develop Project Management Plan Data Flow Diagram on page 79 shows how this process directly interacts with 32 other processes that provide additions to the Project Management Plan and/or are directly guided by it. This emphasizes that the Project Management Plan is central to a well-managed project. Also see Develop Project Management Plan Process (posted February 23, 2009).

Change Requests

During the course of a project as situations change and the scope of the work is better understood and elaborated upon, it can be expected that there will be some changes to the original planning. A suggested change is called a Change Request. The third edition PMBOK® had several types of change requests that could be outputs of various processes, but this has been simplified so that now they are all referred to as Change Requests. The process that handles Change Requests is the fourth edition PMBOK’s Perform Integrated Change Control. Change Requests which have arisen from other processes are an input. These requests are discussed in Change Control Meetings where the request may be approved or rejected. The primary output of the Integrated Change Control process is Change Request Status Updates, meaning that the requests are now approved or rejected. Change Requests can only be an input into the Integrated Change Control process. If this process has approved a request, this Approved Change Request may be an input into these three processes: Direct and Manage Project Execution, Perform Quality Control, and Administer Procurements. Change Requests can arise during the performance of the following processes: Direct and Manage Project Execution, Monitor and Control Project Work, Verify Scope, Control Scope, Control Schedule, Control Costs, Perform Quality Assurance, Perform Quality Control, Manage Project Team, Manage Stakeholder Expectations, Report Performance, Monitor and Control Risks, Plan Procurements, Conduct Procurements, and Administer Procurements. Notice that the three processes that have Approved Change Requests as inputs also have Change Requests as an output.

Recognition and Rewards

What should be done when good behavior occurs to encourage it? Recognition and Rewards is a tool of the Develop Project Team process listed in the fourth edition PMBOK®. The purpose of recognizing and rewarding desirable behavior is to encourage that type of behavior in the future. This extends into our everyday life—far beyond the boundaries of project management. It is most effective when people know what behaviors will be rewarded, rather than be surprised that something they did happened to deserve a reward. For some people, the promise of a reward can be a strong motivator. For example, if a team is told that if they finish the project early each person can have an extra week of vacation, that could be a strong motivator. However, it should be kept in mind that what is rewarding to one person may not be rewarding for another person. A highly-driven person might not want an extra week of vacation as it could interfere with their work goals. Similarly, a shy individual may dread the thought of being publically recognized for something they have done. In order to be fair and prevent frustration, the rewarded behavior should also be within the control of the person or team. Lastly, the reward or recognition should be appropriate for the behavior. Heroic efforts deserve a greater reward than doing basic job requirements. Also see the earlier posting of Develop Project Team Process (posted May 4, 2009).

Team Development Stages

As a project team matures, they go through certain stages. These Team Development Stages are described under Team-Building Activities, which is a tool of the fourth edition PMBOK®’s Develop Project Team process. According to this theory, there are five stages of team development—Forming, Storming, Norming, Performing, and Adjourning. Teams typically begin at the first stage and then progress to later stages. However, teams can stop progressing at a certain stage and never reach the higher stages. Also, an event such as the addition of a team member can cause the team to regress to an earlier stage. In the Forming stage, the team members meet each other and learn about the team’s purpose and goals. In the Storming stage, team members may struggle for certain roles and responsibilities as well as try to convince others of their perspective on how the work should be performed. When the Norming stage is reached, team members are working together and an element of trust has been established. The Performing stage demonstrates a highly effective team whose members are working together smoothly as a unit. When the work is done and the team is disassembled, it is called Adjourning. Project Managers have an advantage if they are able to quickly move their team into the Performing stage. Also see the earlier posting of Develop Project Team Process (posted May 4, 2009).

Conflict Management

Managing conflict is part of managing projects and people. Conflict Management is a tool of the Manage Project Team process listed in the fourth edition PMBOK®. Also see the earlier posting of Manage Project Team Process (posted May 5, 2009). Conflict Management is an important skill not only project management, but for any situation in which people have disagreements. There are six general techniques of managing a conflict—Withdrawing/Avoiding, Smoothing/Accommodating, Compromising, Forcing, Collaborating, and Confronting/Problem Solving. Here are some examples of these techniques. Katy plans to bake her family Carrot Raisin cookies, but her children start complaining, because they want Chocolate with Peanut Butter Chip cookies.

Withdrawing/Avoiding – avoiding the conflict or situation. Katy runs out of the room screaming that she can never please anyone.

Smoothing/Accommodating – emphasizing areas of agreement. Katy’s husband reminds everyone that all are in agreement that they would like a batch of cookies.

Compromising – finding a solution that brings at least some satisfaction to everyone. Katy makes Chocolate Carrot cookies rather than Carrot Raisin or Chocolate with Peanut Butter Chips.

Forcing – one’s viewpoint is pushed at others’ expense. Katy says that she is making the Carrot Raisin cookies as she planned—and there will be no further discussion!

Collaborating – incorporating multiple views. Each family member discusses exactly what they like and dislike about the two types of cookies, so that together they can create a new recipe to incorporate what is most important to everyone. Katy’s husband wants the raisins included, one child wants them soft and chewy, one child wants them shaped in balls, and Katy wants them to be relatively healthy.

Confronting/Problem Solving – treating the conflict as a problem to solve. Katy and her family try to think of some alternatives to solve the problem, including: making one batch of each kind, helping the children make a batch of the kind that they want, and making one kind today and making the other kind next week.

Distribute Information Process

Distribute Information is one of the 42 project management processes described in the fourth edition PMBOK®. It’s one of the five Communications knowledge area processes, and one of the eight Executing processes. The primary purpose of this process is to distribute relevant information to stakeholders. This is a relatively simple, straightforward process. The Project Management Plan is needed because it contains the Communications Management Plan that outlines the details of how the information is to be distributed. Performance Reports contain the actual information on the status of the project that will be distributed. This information is distributed through Communication Methods (one-on-one meetings, group meetings, videoconferencing, etc.) and Distribution Tools (hard copies, email, telephone, portals, press releases, etc.). The only output is Organizational Process Asset Updates. These updates could include copies of the reports that were distributed, presentations given, and feedback from stakeholders, etc. This process is simply the act of providing accurate project information to stakeholders in a timely manner.

Manage Stakeholders Expectations Process

Manage Stakeholders Expectations is one of the 42 project management processes described in the fourth edition PMBOK®. It’s one of the five Communications knowledge area processes, and one of the eight Executing processes. The primary purpose of this process is to work with stakeholders to meet their needs and resolve issues. The Stakeholder Register provides the list of stakeholders, and along with the Stakeholder Management Strategy, contains information on each stakeholder that will assist in working effectively with them. This process is fundamentally about communication, so the Project Management Plan, which contains the Communications Management Plan, is needed as a guide for communicating with individual stakeholders. An Issue Log and Change Log are maintained to track stakeholder concerns and any changes that are made. Communicating with upset stakeholders can involve finesse and tact, so the intangible tools of this process are: Communication Methods, Interpersonal Skills, and Management Skills. Change Requests are an expected output of this process, and with those changes comes updates to Project Documents and the Project Management Plan.

Virtual Teams

Becoming increasingly popular, Virtual Teams is one of the tools of the fourth edition PMBOK®’s Acquire Project Team process. A virtual team is a team who has some or all members that spend little or no time face-to-face. With advances in communications technology, the advantages of virtual teams are becoming leveraged more frequently in today’s organizations. A virtual team allows for geographically dispersed people, including outside experts, to work together. Also, it can allow employees to work from home. Team members can be included who have difficulties traveling, and travel expenses can be saved for all team members. Virtual teams is a favorite topic here at TAPUniversity, with online courses offered through our Virtual Teams Institute. There are numerous forms of communications technology as well as best practices that can be learned and leveraged to maximize the effectiveness of a virtual team.

Alternatives Identification

This tool of Alternatives Identification is part of the fourth edition PMBOK®’s Define Scope process. The purpose of this tool is to generate ideas on different ways to accomplish the project. The desired work is already known, but there may be preferred ways to accomplish the work. Clearly, this should preferably be performed at the very early stages of the project before work is already begun using a less desirable method. At its basis, this tool is simply the generation of useful ideas. This can be accomplished in any of the typical ways such as brainstorming; lateral thinking; reverse thinking with no feedback; random word association with critical feedback; metaphors and supportive feedback; and exaggeration with feedback.

Project Scope Statement

The Project Scope Statement is a major project document that is produced through the fourth edition PMBOK®’s Define Scope process. The Project Scope Statement contains the project’s deliverables and required work in detailed statements. It includes the Product Scope Description, Product Acceptance Criteria, Project Deliverables, Project Exclusions, and Project Constraints. For example, Katy’s project is to bake a dozen cookies for her neighbor. One dozen round chocolate chip cookies that are three inches in diameter is the Product Scope Description. If the neighbor deems them not burned, that is the Product Acceptance Criteria. The Deliverables are: one dozen cookies and a paper plate that they will be placed upon brought to the neighbor’s door. A Project Exclusion is that the recipe will not be provided. A Project Constraint is that the cookies must be delivered by 4:00pm this evening. Also see the earlier posting of Define Scope Process (February 25, 2009).

Conduct Procurements Process

Conduct Procurements is one of the 42 project management processes described in the fourth edition PMBOK®. It’s one of the four Procurement knowledge area processes, and one of the eight Executing processes. The purpose of this process is to obtain responses from sellers, select among those sellers, and award a contract to the selected seller. This was formerly two processes, and so there are several activities involved. The previously performed Plan Procurements process provides Procurement Documents, Source Selection Criteria, and Make-or-Buy Decisions as inputs to this process. Other inputs include the Project Management Plan which contains the Procurement Management Plan that serves as guidance; and the organization may have a Qualified Sellers List of sellers that have already been determined to meet certain criteria important to the organization. Finding prospective sellers can be aided by the tools of Advertising and performing an Internet Search. Bidder Conferences may be conducted to provide information to interested sellers, and then sellers submit their Seller Proposals. An organization may use the tool of Independent Estimates to judge whether the proposals are suggesting reasonable prices. These Seller Proposals are compared using the pre-defined Source Selection Criteria and Proposal Evaluation Techniques to determine which sellers will be selected. A major output is the Selected Sellers, who are then provided a Procurement Contract Award. This contract may have its terms negotiated through the tool of Procurement Negotiations. Also see the earlier posting of Plan Procurements Process (posted April 14, 2009).

Monitor and Control Project Work Process

The Monitor and Control Project Work process is one of the 42 project management processes described in the fourth edition PMBOK®. It’s one of the six Integration knowledge area processes, and one of the ten Monitoring and Controlling processes. The primary purpose of this process is to track, review and regulate progress on the project. This is accomplished by comparing the Project Management Plan to actual progress, which is represented by the Performance Reports obtained from the Report Performance process. The only tool for the Monitor and Control Project Work process is the common, broad tool of Expert Judgment. Expert Judgment is used to determine whether project progress is matching the expectations outlined in the project management plan. And if not, the output of Change Requests will go to the Integrated Change Control process for approval to bring performance back in line. These changes can then be reflected as updates to the Project Management Plan and Project Documents. Also see the earlier postings of Change Requests (posted May 11, 2009) and Project Management Plan (posted May 8, 2009).

PMP Exam Studying with WEMSHA

When studying for your PMP® Exam, if you deeply interact with project management tools and standards, rather than simply read about them, you’ll not only be better prepared for your exam, but you’ll learn more that you can utilize in your project management career. At TAPUniversity, for our PMP exam preparation courses we use our project management workbook called WEMSHA, which is aligned with the new fourth-edition PMBOK®. It contains 111 exercises on the processes, tools, and concepts necessary for project managers to know for their exam. When studying is more engaging, it’s also easier to find the required time to study. For those of you currently enrolled in our fourth-edition PMBOK PMP courses, you can download the 321-page workbook at no extra cost from your course website. Also, it can be obtained at Lulu Publishing using the following link: http://www.lulu.com/commerce/index.php?fBuyContent=7141508

Statement of Work

A Statement of Work (SOW) is a narrative description of the products, services or results to be supplied by a project. The SOW is considered a Project Document—not part of the Project Management Plan. The SOW is written by the project’s sponsor, and then used as an input to the fourth-edition PMBOK®’s Develop Project Charter process, which formally initiates the project. The SOW references three things—the Business Need, Product Scope Description, and Strategic Plan. The Business Need describes why the project is needed. The Product Scope Description contains the details of the product that will be the project’s outcome. How this particular project supports the organization’s Strategic Plan should also be included. When dealing with procurements, a Procurement SOW will be necessary which is the SOW referring only to the part of the project scope that pertains to a particular contract. Time and Materials contracts are especially well-suited to situations in which it’s not possible to have a well-defined SOW. On a smaller scale, a Work Breakdown Structure (WBS) Dictionary contains a brief SOW for each component in the WBS. Overall, the SOW describes what work needs to be done and why it is important to perform that work.

Resource Breakdown Structure

A Resource Breakdown Structure (RBS) is a Project Document utilized by project managers. It is one of the documents created by the fourth-edition PMBOK®’s Estimate Activity Resources process. A RBS is a heirarchical structure of a project’s resources by category and type, including human resources. This provides an illustration of the overall materials, people, equipment, and supplies needed, in addition to the quantity needed of each. The portion including people can be utilized in the Develop Human Resource Plan process. The Activity List, Activity Attributes, and Resource Calendars are used to form a starting point for estimating the needed resources. Someone with expertise can estimate how much resources are needed for a given activity, and Published Estimating Data may also be available. These estimated resources are then organized in a hierarchy. For example, Katy needs 500 cookies baked in a single day. Her RBS may include the major categories of ingredients, cooks, baking equipment, and baking tools. Her category of ingredients might be broken down into refrigerated and non-refrigerated ingredients, and the non-refrigerated ingredients category could contain 20 lbs of flour, 20 lbs of sugar, 10 cups of cocoa, and 1 cup of baking powder. Also see the earlier posting of Estimate Activity Resources Process (posted March 6, 2009).

Perform Integrated Change Control Process

The Perform Integrated Change Control process is one of the 42 project management processes described in the fourth edition PMBOK®. It’s one of the six Integration knowledge area processes, and one of the ten Monitoring and Controlling processes. The primary purpose of this process is to review change requests, determine whether to approve them, and then manage the effects of those changes on the deliverables, organizational process assets, project documents, and project management plan. There are fifteen processes that have Change Requests as an output. These Change Requests then all become an input into the Perform Integrated Change Control process. In order to help determine whether changes should be approved, the Project Management Plan and Work Performance Information are used as additional information. The change control board convenes in Change Control Meetings to make the decision to approve or reject each change request. The primary output of the Integrated Change Control process is Change Request Status Updates, meaning that these discussed Change Requests are now approved or rejected. Because of these changes, updates may need to be made to the Project Management Plan and Project Documents. If a Change Request is approved, this Approved Change Request may be an input into these three processes: Direct and Manage Project Execution, Perform Quality Control, and Administer Procurements. Also see Change Requests (posted May 11, 2009).

Control Scope

The Control Scope process is one of the 42 project management processes described in the fourth edition PMBOK®. It’s one of the five Scope knowledge area processes, and one of the ten Monitoring and Controlling processes. The primary purpose of this process is to watch the product and project scope as well as manage any changes to the scope baseline. This process safeguards against scope creep so that the project’s boundaries do not expand. Knowing what the project boundaries are and how to handle changes to them is found in the Project Management Plan (specifically the Scope Baseline, Scope Management Plan, Change Management Plan, Configuration Management Plan, and Requirements Management Plan), Requirements Documentation and Requirements Traceability Matrix. Work Performance Information indicates how well actual progress aligns with the scope baseline. The only tool and technique of this process is Variance Analysis. This simply compares actual progress to the scope baseline. These comparisons of Work Performance Measurements are an output that can be shared with stakeholders. If changes are needed based on these measurements, there will be Change Requests which go through the Perform Integrated Change Control process. Updates may also be needed to Organizational Process Assets, the Project Management Plan, and Project Documents. Also see the earlier postings of Change Requests (posted May 11, 2009) and Perform Integrated Change Control Process (posted June 1, 2009).

Verify Scope Process

The Verify Scope process is one of the 42 project management processes described in the fourth edition PMBOK®. It’s one of the five Scope knowledge area processes, and one of the ten Monitoring and Controlling processes. The primary purpose of this process is to formalize acceptance of the completed project deliverables. The most obvious input is Validated Deliverables. The finished deliverables are validated if they have been checked for meeting quality standards through performing the Perform Quality Control process. To determine whether these deliverables are acceptable, the criteria for the deliverables is examined which is found in the Project Mangement Plan’s Scope Baseline, Requirements Documentation, and Requirements Traceability Matrix. There is only one tool and technique of this process—Inspection. The deliverables are examined in some manner and compared to the acceptance criteria. Essentially, this process verfies that the deliverables are consistent with the Scope Baseline. If the deliverables are satisfactory, the output is Accepted Deliverables. If the deliverables are unacceptable, the output is a Change Request outlining what changes can be made to make the deliverables acceptable.

Control Schedule

The Control Schedule process is one of the 42 project management processes described in the fourth edition PMBOK®. It’s one of the six Time knowledge area processes, and one of the ten Monitoring and Controlling processes. The primary purpose of this process is to update progress and manage any changes to the project schedule. The Project Management Plan contains the Schedule Baseline and the Schedule Management Plan which outlines how changes to the schedule are to be made. The most recent Project Schedule is compared to Work Performance Information in order to gauge how well the project is on-schedule. Comparing actual progress to planned progress is called Variance Analysis, and this leads to the output of Work Performance Measurements. With the mathematical calculations involved, Project Management Software and Scheduling Tools are useful for ease of making schedule changes. If the work needs to be performed over a shorter duration of time, Schedule Compression techniques such as crashing and fast-tracking may be needed. Adjusting Leads and Lags and Resource Leveling are other tools to adjust the schedule. When changes are needed, there will be Change Requests which go through the Perform Integrated Change Control process. Updates may also be needed to Organizational Process Assets, the Project Management Plan, and Project Documents. Also see the earlier postings of Change Requests (posted May 11, 2009), Project Management Plan (posted May 8, 2009), What-If Scenario Analysis (posted April 8, 2009), Schedule Compression (posted April 7, 2009), and Leads and Lags (posted March 20, 2009).

Statistical Sampling

There is much to know about selecting a good sample and it should be done carefully by someone knowledgeable. A good sample can accurately describe the whole population with a fraction of the cost and time it would take to measure the entire population. Project managers may use statistical sampling as part of performing the fourth edition PMBOK®’s quality processes. The first step is to define the population of interest, such as every full-time employee in a certain organization. Then a sampling strategy, such as random sampling, stratified sampling, cluster sampling or others, is used to select the individuals who will be in the sample. Random sampling selects a sample of employees with each one having an equal chance of being selected. Stratified sampling first divides the population into strata—for example the organization’s population could be grouped by men and women, and then a separate sample drawn from each group to assure that the desired number of men and women are included in the sample. Cluster sampling samples a sub-group of the population. For example, everyone in the marketing department could be chosen instead of choosing people from throughout the organization. It is also important to determine the correct size of sample. Too small, and your data will be misleading, while an unnecessarily large sample will waste resources.

Maslow’s Hierarchy of Needs

Psychological and sociological theories explaining how individuals and groups behave, such as this theory, is listed as the tool of Organizational Theories in the fourth edition PMBOK®’s Develop Human Resource Plan process. Maslow’s hierarchy of needs is a motivation theory that explains how people are differentially motivated depending on their state of needs. The most basic needs are physiological—such as eating, sleeping and breathing. Only after these needs are met, are people able to concentrate on meeting the next level of needs. The next level consists of safety needs, following by belongingness needs, and esteem needs. Only after all these have been satisifed can an individual be at the highest level called self-actualization, which is fully meeting one’s potential. Later, Maslow suggested additional levels to his hierarchy. Note that it is possible to take steps backward on the heirarchy. For example, one may be focused on gaining respect at work and forget to take lunch. Eventaully the physiological need to eat will become more urgent to meet than the esteem needs. Also see the earlier posting of Develop Human Resource Plan Process (posted March 24, 2009).

Control Costs Process

The Control Costs process is one of the 42 project management processes described in the fourth edition PMBOK®. It’s one of the three Cost knowledge area processes, and one of the ten Monitoring and Controlling processes. The primary purpose of this process is to monitor the budget and manage any changes made to the cost baseline. The Cost Performance Baseline and Cost Management Plan can be found in the Project Management Plan, which is used to guide this process. Project Funding Requirements and Work Performance Information are additional inputs. There are many tools available to manage costs, such as Earned Value Management, Forecasting, To-Complete Performance Index, Performance Reviews, Variance Analysis, and Project Management Software. The tools enable the project manager to calculate how close spending matches the budget, and how much more funding is needed. This results in Work Performance Measurements and Budget Forecasts that can be used to plan the remainder of the project. As Change Requests are approved through the Perform Integrated Change Control process and implemented, there may be updates to the Organizational Process Assets, Project Management Plan, and Project Documents. Also see the earlier postings of Earned Value Management – Step 1 (posted February 26, 2009), Earned Value Management AC and BAC – Step 2 (March 2, 2009), and Earned Value Management – Planned Value – Step 3 (posted March 11, 2009).

Quality Management Plan

The Quality Management Plan outlines how selected quality policies will be implemented for a certain project. It’s part of the Project Management Plan. The Plan Quality process described in the fourth edition PMBOK® decides which quality requirements and standards should apply to the project and then develops the Quality Management Plan to assure compliance with them. The formality and level of detail of the plan varies across projects. The other two quality processes—Perform Quality Assurance and Perform Quality Control—are guided by this plan. Quality and Risk are closely tied together. The Quality Management Plan is used as an input to the Identify Risks process, because the approach to quality will increase or decrease overall risk. And when performing the Plan Risk Responses process, the plan may be updated to reflect changes in how risk will be addressed. In the course of doing the project work and monitoring its progress, the two processes Direct and Manage Project Execution and Monitor and Control Project Work, can additionally lead to revisions to the Quality Management Plan. Also see the earlier posting of Plan Quality Process (posted March 19, 2009).

Resource Calendars

The documentation of the time individuals on the project team are able to work on the project is called Resource Calendars. They must take into consideration vacation time and holidays as well as time dedicated to other work in the organization. A composite Resource Calendar may also indicate the skills of the resources. Interestingly, the fourth edition PMBOK® lists Resource Calendars as an output of two processes—they are an output of the Acquire Project Team process to show when internal resources are available, and they are an output of the Conduct Procurements process to indicate when contracted resources are available. Resource Calendars are an input to the Develop Project Team process in order to know when individual team members are available for team development activities. In creating the project schedule, Resource Calendars are an input the Estimate Activity Resources , Estimate Activity Durations, and Develop Schedule processes. They are also an input of the Determine Budget process so that compensation for team members can be included in the project budget. Resource Calendars are considered a Project Document—not part of the Project Management Plan. However, they can be included in the Staffing Management Plan, which is part of the Human Resources Plan, which is part of the Project Management Plan. Also see the earlier posting of Acquire Project Team Process (posted May 1, 2009).

Acheivement Theory

Psychological and sociological theories explaining how individuals and groups behave, such as this theory, are listed as the tool of Organizational Theories in the fourth edition PMBOK®’s Develop Human Resource Plan process. David McClelland, an American psychologist, is the author of Achievement Theory. This theory postulates that humans are motivated by three general needs—achievement, affiliation, and power. Individuals vary in how strongly these three things motivate them. For example, one person may be highly motivated by power, and only slightly by achievement. Another person may be motivated by affiliation, but not as interested in achievement or power. To generalize these types of motivations, those who are high in achievement motivation are driven to excel in what they undertake. Individuals high in affiliation motivation strive for good relationships with others and they want to be accepted. People who are high in power need to have an influence on others. Also see the earlier posting of Develop Human Resource Plan Process (posted March 24, 2009).

Perform Quality Control Process

The Perform Quality Control process is one of the 42 project management processes described in the fourth edition PMBOK®. It’s one of the three Quality knowledge area processes, and one of the ten Monitoring and Controlling processes. The primary purpose of this process is to monitor the results of the quality activities so that any needed changes can be made. The Quality Management Plan, which is found in the Project Management Plan, is used to guide this process. The Plan Quality process provides Quality Metrics and Quality Checklists to be used in this process. Information about that actual work that is compared to the pre-determined quality standards is found from Work Performance Measurements and Deliverables. Also, performance data is gathered through the tools of Statistical Sampling and Inspection. A better understanding of the causes of defects can be accomplished through Cause and Effect Diagrams. Once data is gathered, it can be displayed in a variety of ways, including: Control Charts, Flowcharts, Histograms, Pareto Charts, Run Charts, and Scatter Diagrams. The outcome of these measures are Quality Control Measurements. The data is not simply displayed, however—it must be assessed to determine whether or not it demonstrates that quality standards are being met. If the quality is not acceptable, a Change Request will be made. If the deliverables are acceptable, the output of Validated Deliverables goes to the Verify Scope process for final approval. Also see the earlier postings of PMP Exam – Pareto Chart (posted February 9, 2009), Scatter Diagram (posted February 10, 2009), Run Chart (posted February 16, 2009), Control Chart (posted February 17, 2009), Change Requests (posted May 11, 2009), and Statistical Sampling (posted June 5, 2009).

Stakeholder Management Strategy

A Stakeholder Management Strategy is a document used by project managers to outline a plan to increase support and minimize obstruction from the project stakeholders. This document is created through the Identify Stakeholders process, which is one of the 42 project management processes described in the fourth edition PMBOK®. The Stakeholder Management Strategy is then used as an input to two other Communication processes—Plan Communications and Manage Stakeholder Expectations. The document should include all key stakeholders for the project. Groups of stakeholders should be identified that increase the ease of communication and management. For example, a group could include individuals from a certain geographic location or individuals with a specific interest in the project. Also documented should be the level of participation desired by these key stakeholders. Do they want to be intimately involved with each phase of the project, or merely informed when the deliverables are approved? Because this document can include sensitive information on managing specific stakeholders, the project manager must be careful about the type of information that is included and control who has access to it. Also see the earlier postings of Project Stakeholders (posted February 13, 2009) and Identify Stakeholders Process (posted February 19, 2009.)

Activity Dependencies

A project is composed of many smaller activities. Although some activities are independent of each other, others have dependencies that must be accounted for when making the project schedule. Using the Precedence Diagramming Method (PDM), there are four types of dependencies that two activities can have with each other. These four types of dependencies are: Finish-to-Start, Finish-to-Finish, Start-to-Start, and Start-to-Finish. The names of these dependencies describe what must happen to activity “A” before what can happen to activity “B”. For example, for a Finish-to-Start dependency, activity “a” must finish before activity “b” can start. Here is an example of a Finish-to-Start dependency: Katy must finish mixing her cookie batter before she can start shaping the dough into cookies. Mixing the cookie batter must be completely done before individual cookies are made. Here is an example of a Start-to-Start dependency: Katy must start shaping the dough into cookies before she can start baking them. She doesn’t have to finish the whole activity of shaping all the dough into cookies, but she has to at least start this activity so that she has some cookies that can start baking while she shapes more.

Pairwise Chart

A Pairwise Chart is a tool used by a group of people to rank a set of alternatives. In project management, it is used to decide among a set of potential projects, among other decisions. The charts may vary somewhat in appearance, but the purpose is the same—to reach a decision by systematically comparing two choices at a time. A vote is taken for each set of two choices, and the alternative that overall receives the most votes is the winning choice. Here is an example of a committee trying to decide what to serve at the annual company picnic. The five nominated choices for the main dish are: fried chicken, hamburgers, macaroni, spaghetti, and steak. There are ten committee members. First they vote between fried chicken and hamburgers—s even people preferred fried chicken and three preferred hamburgers. Next they compared fried chicken and macaroni—five people preferred fried chicken and five people preferred macaroni. They had eight more votes to compare the remaining pairs. Then, the total votes for each choice were summed. Altogether, steak received the most votes so it was the winning choice.

Pairwise Chart

Product Analysis

For projects that have a product as a deliverable (as opposed to a service or result), product analysis may be performed. Product analysis is a tool and technique of the Define Scope process described in the fourth edition PMBOK®. It means gaining a deep understanding of the product. Because there are so many different types of products and perspectives, there are many different ways that products can be analyzed. One of these methods is product breakdown which analyzes the components of the product. For example, does the container of weed killer have the correct percentages of each chemical? The method of systems engineering begins early in the process with designing and making the product to meet customer needs. The value analysis method examines the relationship of cost and quality. How much more will customers pay for luggage that lasts fifty years than low-quality luggage that will need to be replaced after several trips? Other methods that the PMBOK mentions are: systems analysis, requirements analysis, and value engineering.

Expert Judgment

An expert is someone who has specialized education, knowledge, skill, experience or training in a certain area. A project manager should obtain the opinions of experts throughout the course of managing a project. Expert Judgment is a common tool and technique of the processes found in the fourth edition PMBOK®. It is a general tool, and its use will appear differently depending on the process. For example, a team member may be able to provide good activity duration estimates, an outside consultant may be hired for technical advice, and already identified stakeholders may be experts in identifying additional stakeholders. For the Conduct Procurements process, an entire panel of experts that each specialize in different areas may evaluate seller proposals. An expert may be a consultant, stakeholder, professional and technical association, industry group, SME, PMO, other unit in the organization, senior management, and a project manager. It could also simply be a member of the organization who has been there for 35 years.

Of the 42 processes, 19 have Expert Judgment listed as a tool and technique. In fact, some of these processes have Expert Judgment as their only tool and technique. Note that all six of the Integration processes contain Expert Judgment. Here is a listing of the processes: Develop Project Charter, Develop Project Management Plan, Direct and Manage Project Execution, Monitor and Control Project Work, Perform Integrated Change Control , Close Project or Phase, Define Scope, Define Activities, Estimate Activity Resources, Estimate Activity Durations, Estimate Costs, Determine Budget, Identify Stakeholders, Identify Risks, Perform Qualitative Risk Analysis, Perform Quantitative Risk Analysis, Plan Risk Responses, Plan Procurements, and Conduct Procurements.

Communications Management Plan

The Communications Management Plan as outlined in the fourth edition PMBOK® describes how communications will be accomplished throughout a project. It is a subsidiary of the Project Management Plan and is developed through the Plan Communications process. It is specifically listed as an input to the Plan Risk Management process. The Communications Management Plan is executed through the Distribute Information and Manage Stakeholders Expectations processes, but rather than being listed specifically as an input, the broader Project Management Plan is listed as an input instead.

The nature of the Communications Management Plan will vary with the size and complexity of the project. There are many items that can be included. The requirements that the stakeholders have for communications should be included. Specifically contained could be what information should be communicated and why, who is responsible for communications, when communications should occur, the time and budget allowed for communication activities, communication constraints, and information flowcharts. Also, a glossary of common terminology, escalation processes, and the method for updating the Communications Management Plan may be included. Also see the earlier posting of Plan Communications Process (posted March 25, 2009).

Project Schedule Network Diagrams

A Project Schedule Network Diagram is any display of the relationships among project activities which is then used to develop the project schedule. A subnetwork is simply a section of the overall Project Schedule Network Diagram. Project Schedule Network Diagrams are an output of the fourth edition PMBOK®’s Sequence Activities process and an input to the Develop Schedule process. The most common type of network diagram is the Precedence Diagramming Method (PDM) which is also called Activity on the Node (AON). In this diagram, activities are represented by boxes or nodes with arrows connecting these nodes to demonstrate the relationships among activities. The PDM method uses all four types of dependencies between activities (Finish-to-Start, Finish-to-Finish, Start-to-Start, and Start-to-Finish). The older network diagramming method of Activity on the Arrow (AOA) places the activities on the arrows rather than the nodes, and only uses the Finish-to-Start dependency. This method is not as commonly used. Also see the earlier postings of Activity Dependencies (posted June 17, 2009), Sequence Activities Process (posted March 5, 2009), and Develop Schedule Process (posted March 10, 2009).

Business Case

The Business Case document presents the reasoning for performing a project or activity from a business standpoint. The content, formality, and length will vary across situations and organizations. For external projects, the customer may be the author of this document. The Business Case is an input into the fourth edition PMBOK®’s Develop Project Charter process, so it is used as a reference when creating the charter that formally initiates the project. According to the PMBOK, there are seven reasons for creating a business case:

Market Demand (A farm changes to organic in response to more customers preferring food products that have not been treated with pesticides or herbicides).

Organizational Need (An office building is expanded due to the need to hire more employees).

Customer Request (A customer orders a custom-built home).

Technological Advance (A boat manufacturer upgrades their engines after a more fuel-efficient engine has been developed).

Legal Requirement (Hiring procedures are updated after legislation is passed mandating reporting on the demographics of applicants).

Ecological Impact (A manufacturing plant takes steps to lessen air pollution from their smokestacks).

Social Need (A non-profit company provides fans at no cost during heat waves to those with low income).

Report Performance Process

The Report Performance process is one of the 42 project management processes described in the fourth edition PMBOK®. It’s one of the five Communications knowledge area processes, and one of the ten Monitoring and Controlling processes. The primary purpose of this process is to collect and distribute information about project performance. First of all, to know how well the project is progressing, the project manager needs to know how it was supposed to progress, and this is found in the Project Management Plan. The plan is then compared to Work Performance Information, and the difference is called Work Performance Measurements. Understanding the causes of these differences is the tool of Variance Analysis. Estimates on how much more funding is needed for the project is found in the Budget Forecasts, and the tool of Forecasting Methods estimates future project performance. Once the information is collected, it is formatted into Performance Reports, which is the primary output of this process, and it is distributed through the tools of Communication Methods and Reporting Systems.

Variance Analysis

If projects went exactly as planned, this tool would be unnecessary. Variance Analysis is the comparison of planned results and actual results. The planned results may be found in the Project Management Plan and compared to work performance information. The project manager should be certain that the data itself is trustworthy, and then examine how much variance exists between planned and actual results. Then, the potential impact and causes of any variance should be analyzed, along with determining what action may be needed. Variance Analysis is listed in the fourth edition PMBOK® as a tool of Control Schedule, Control Costs, Control Scope, Report Performance, and as part of the Monitor and Control Risks process. When Earned Value Management is utilized, the formulas of SV and SPI can indicate schedule variance and the formulas of CV and CPI can indicate cost variance. The results of a Variance Analysis may be found in a project’s Performance Reports.

Monitor and Control Risks Process

The Monitor and Control Risk process is one of the 42 project management processes described in the fourth edition PMBOK®. It’s one of the six Risk knowledge area processes, and one of the ten Monitoring and Controlling processes. The primary purpose of this process is to implement risk plans, watch already identified risks and residual risks while watching for new risks, and evaluate risk process effectiveness. The Risk Register is where the list of identified risks and information about then can be found. How risks are to be handled can be found in the Risk Management Plan, which is part of the Project Management Plan.

Monitoring the status and effects of risks, as well as the potential for new risks can be done through obtaining Work Performance Information and Performance Reports. Variance and Trend Analysis and Technical Performance Measurement are tools that examine actual project performance and therefore provide current information on project risk.

Because the status of risks change throughout the project and new risks arise, Risk Reassessments should be scheduled during the project. And to determine whether risk responses are effective, Risk Audits should be performed. Comparing the amount of contingency reserves to the amount of remaining risk is called Reserve Analysis. Throughout the project, Status Meetings should include updates and discussion on project risk.

The outputs of this process include updates to the Risk Register when changes occur as well as the results of risk audits and reassessments. If a change is needed in response to more information about risks or new risks, Change Requests may be made. Also, updates may be made to the Organizational Process Assets, Project Management Plan, and Project Documents. Also see the earlier postings of Risk Register (posted March 27, 2009) and Variance Analysis (posted June 29, 2009).

Administer Procurements Process

The Administer Procurements process is one of the 42 project management processes described in the fourth edition PMBOK®. It’s one of the four Procurement knowledge area processes, and one of the ten Monitoring and Controlling processes. The primary purpose of this process is to manage procurement relationships, monitor contract performance, and make any needed changes. Information about the procurement work can be found in the Procurement Documents, Procurement Management Plan (which is part of the Project Management Plan), and the actual Contract. Monitoring the procurement performance is aided through Performance Reports and Work Performance Information.

Any Change Requests that have been approved through the Integrated Control Process relating to procurement are also an input to this process. A Contract Change Control System manages changes to the contract. These and other changes will be in the form of the Change Requests output. Contested Changes between the buyer and seller are handled through the Claims Administration.

The day-to-day management of the procurement relationship uses Payment Systems and a Records Management System. Assuring that the obligations of the parties are being met is done through Procurement Performance Reviews, Inspections and Audits, and Performance Reporting. Outputs of this process include Procurement Documentation and updates to the Organizational Process Assess Updates and Project Management Plan.

Organizational Process Assets

The fourth edition PMBOK® defines Organizational Process Assets as “any or all process related assets, from any or all of the organizations involved in the project that can be used to influence the project’s success.” Examples include: plans, procedures, lessons learned, historical information, schedules, risk data and earned value data. Organizational Process Assets fall into two broad categories—Processes and Procedures, and the Corporate Knowledge Base. The key concept is that these are assets a project manager may use for the benefit of the project.

Organizational Process Assets is a common input into the project management processes. In fact, most of the 42 processes list it as an input. These processes are: Develop Project Charter, Identify Stakeholders, Develop Project Management Plan, Define Scope, Create WBS, Define Activities, Sequence Activities, Estimate Activity Resources, Estimate Activity Durations, Develop Schedule, Estimate Costs, Determine Budget, Plan Quality, Develop Human Resource Plan, Plan Communications, Plan Risk Management, Identify Risks, Perform Qualitative Risk Analysis, Perform Quantitative Risk Analysis, Plan Procurements, Direct and Manage Project Execution, Acquire Project Team, Manage Project Team, Distribute Information, Manage Stakeholder Expectations, Conduct Procurements, Monitor and Control Project Work, Perform Integrated Change Control, Control Scope, Control Schedule, Control Costs, Perform Quality Control, Report Performance, and Close Project or Phase

Fewer processes have updates to the Organizational Process Assets as one of their outputs. These processes are: Perform Quality Assurance, Manage Project Team, Distribute Information, Manage Stakeholder Expectations, Control Scope, Control Schedule, Control Costs, Perform Quality Control, Report Performance, Monitor and Control Risks, Administer Procurements, Close Project or Phase, and Close Procurements.

Inspection

The technique of inspection is an examination to assure that work meets the required standards. In project management, this is most closely related to quality inspections, procurement inspections, and the final inspection of deliverables.

Inspection is a technique of the fourth edition PMBOK®’s Perform Quality Control process. Although prevention is preferred over inspection, inspection is part of the Appraisal Costs of the Cost of Conformance. If a project involves a contract, the buyer should examine the work while it is being performed to assure that it is being performed as agreed. For this reason, Inspections and Audits is a tool of the Administer Procurements process. When completing a project, there should be a final inspection of the deliverables. This is the purpose of the Verify Scope process, and inspection is its only technique. At this point, the deliverables are reviewed with the customer or sponsor. The work should be measured, examined and/or verified to determine whether it meets the project requirements. This may also be called reviews, walk-throughs, product reviews, or audits.

Stakeholder Register

The Stakeholder Registry is a project management document that contains the list of stakeholders and relevant information about them. It is developed through the fourth edition PMBOK®’s Identify Stakeholders process which first discovers the people and organizations that are impacted by the project, and secondly, documents relevant information about them. This information can be placed into three categories—identification, assessment, and stakeholder classification. Identification information includes name, role, location and contact information. Assessment information includes stakeholders’ requirements, expectations, and influence on the project. The classification of stakeholders could be whether or not they belong to the performing organization, whether or not they are supporters of the project, and any other useful categorization. The Stakeholder Register then serves as an input to five other processes: Collect Requirements, Plan Quality, Plan Communications, Manage Stakeholder Expectations, and Identify Risks. Also see the earlier posting of Project Stakeholders (posted February 13, 2009) and Identify Stakeholders (posted February 19, 2009).

Close Project or Phase Process

The Close Project or Phase process is one of the 42 project management processes described in the fourth edition PMBOK®. It’s one of the six Integration knowledge area processes, and one of the two Closing processes. The primary purpose of this process is to finalize activities in order to complete the project or phase of the project. The Project Management Plan and Organizational Process Assets may both contain guidance on how the project is to be closed. Expert Judgment is used in applying the standards for closing.

The Accepted Deliverables (those which have been inspected and accepted through the Verify Scope process) are an input to this process, and after performing the administrative closing, are considered the output of Final Product, Service, or Result Transition. Project files, closure documents and historical information may be added to the Organizational Process Assets, so the other output from this process is Organizational Process Assets Updates.

Close Procurements Process

The Close Procurements process is one of the 42 project management processes described in the fourth edition PMBOK®. It’s one of the four Procurement knowledge area processes, and one of the two Closing processes. The primary purpose of this process is to complete all the project’s procurements. It is closely tied with the Close Project or Phase process. The Project Management Plan is used for guidance for this process, as are all the collected and organized procurement documents. A records management system can help organize information for this process. For use in future procurements, a procurement audit may be performed to learn what worked well and what should be done differently next time. Any disputes over the contract need to be resolved, leading to negotiated settlements. The procurement file, deliverable acceptance, and lessons learned documention may be added to the Organizational Process Assets, so an output of this process is Organizational Process Assets Updates. The primary output is the closed procurements, in which the buyer gives the seller formal written notice that the contract has been completed.

CBAP and PMP Certification Exam Changes this Summer

The summer of 2009 brings changes to two certification exams for which TAPUniversity provides preparation. Both the Project Management Institute’s (PMI) Project Management Professional (PMP®) exam and the International Institute of Business Analysis’s (IIBA) Certified Business Analysis Professional (CBAP®) have version changes this summer. As of July 1, the PMP exam is based on the fourth-edition PMBOK®. There will be no more exams given based on the third-edition PMBOK (not even re-takes for those who have failed the exam based on the third edition). The changes from the third-edition PMBOK to the fourth-edition PMBOK are minor. For example, most processes have been re-named and procurement processes have been merged, but this has no effect on the underlying concepts. Two new processes have been introduced—Collect Requirements and Identify Stakeholders—but they should be familiar concepts to most project managers.

The CBAP exam will be based on the BABOK® (Business Analysis Body of Knowledge) version 2.0 beginning August 1. The BABOK change from version 1.62 to version 2.0 has been dramatic. Information has been deleted, added, re-named, and re-arranged. The earlier version was basically an incomplete draft, and the current version is much better edited. If you plan on taking the 1.62 version exam, you only have 3 more weeks to do so.

Risk Management Plan

The Risk Management Plan is a document used by project managers to provide guidance on handling risk throughout a project, and because this includes early risks, it should be created early in the project’s planning phase. It is the only output of the Plan Risk Management process, which is one of the 42 project management processes described in the fourth edition PMBOK®. There is only one tool utilized in developing the Risk Management Plan—Planning Meetings and Analysis—which indicates that the quality of this plan is dependent on the productive meetings of thoughtful individuals. Resources that may be used by these individuals include the Project Scope Statement, Cost Management Plan, Schedule Management Plan, Communications Management Plan, Enterprise Environmental Factors, and Organizational Process Assets. The Project Scope Statement is referenced to better understand the project and its deliverables as every project has a unique set of risks. A project that involves unchartered territory will have more unknowns involved than a more routine project based on a history of similar projects. Understanding the contingencies in place for risks affecting the budget and schedule can be accomplished through examining the Cost Management Plan and the Schedule Management Plan. Knowing with whom to discuss project risks and responses may be found in the Communications Management Plan. Enterprise Environmental Factors includes risk attitudes of the stakeholders, and organizational process assets includes risk templates, definitions, and categories used by the organization. There is much included in the Risk Management Plan, such as: Methodology, Roles and Responsibilities, Budgeting, Timing, Risk Categories, Definitions of Risk Probability and Impact, Probability and Impact Matrix, Revised Stakeholders’ Tolerances, Reporting Formats, and Tracking. Risk Categories may be in the form of a Risk Breakdown Structure (RBS). The Risk Management Plan is an input to the following processes: Identify Risks, Perform Qualitative Risk Analysis, Perform Quantitative Risk Analysis, and Plan Risk Responses. Monitor and Control Risks lists the Project Management Plan as an input rather than specifically listing the Risk Management Plan, but mentions that the Risk Management Plan is contained there. So all the other risk processes use the Risk Management Plan, but it is not listed as an input to any processes other than the risk processes. Also see the earlier posting of Plan Risk Management Process (posted March 26, 2009).

Questionnaire

The questionnaire is a commonly used tool utilized across many fields, including project management and business analysis. It is listed as a technique both of the fourth edition PMBOK®’s Collect Requirements process and as a technique of the BABOK® 2.0. It can be a cost-effective way to gather large amounts of data from individuals.

Questionnaires are easy to make, but they are hard to make well. Make certain there is a clear purpose for the questionnaire and that the target population is appropriately selected. The questions themselves may be close-ended (there is a provided set of choices) or open-ended (the respondent can give any answer). There are advantages and disadvantages to each type of question. Close-ended questions are much easier to analyze, but they prevent unique and insightful responses that may be critical in situations such as gathering requirements from a select group of stakeholders. The wording of questions must be clear, and shorter questions are preferable—especially if the questionnaire will be administered audibly. The questionnaire should not be so long that the respondents lose interest or refuse to participate altogether. Arrange the questions so that they flow logically, with some questions that are enjoyable to build rapport at the beginning, and any more personal or difficult questions at the end. It’s useful to have a pilot test of the questionnaire, as it can be surprising how people misinterpret questions.

Interviews

An interview is a straightforward method of gaining information and opinions from others in a verbal manner by the interviewer asking an interviewee a set of questions. It is listed as a technique both of the fourth edition PMBOK®’s Collect Requirements process and as a technique of the BABOK® 2.0. In the fields of project management and business analysis, interviews are commonly used to collect requirements. Also, when identifying stakeholders, already known stakeholders may be asked to identify additional stakeholders. Expert Judgment is a common tool across the project management processes, and it may be obtained through several methods including interviews. Lastly, risk management typically involves interviews, because dealing with risk depends much on people’s knowledge, experiences, and ideas of what might go wrong for a particular project.

Interviews are usually one-on-one, but a group of people can be interviewed simultaneously. The interview itself can be structured (the interviewer must exactly follow the script of pre-written questions) or unstructured (the interviewer can ask follow-up questions and has some flexibility).

It is important that the interview questions be prepared beforehand, and it is best if the session can be recorded. The quality of the interview results depends in part on the interviewer. The interviewer should be able to build rapport, be knowledgeable (especially when performing unstructured interviews), and maintain focus on the goals. Afterwards, the information from the interview is analyzed, and notes may be sent to the interviewee for confirmation.

Proposal Evaluation Techniques

When selecting among multiple potential sellers, Proposal Evaluation Techniques can assist in choosing the best seller. Proposal Evaluation Techniques is a technique of the fourth edition PMBOK®’s Conduct Procurements process. It involves an evaluation committee comparing seller proposals against pre-defined criteria. The evaluation committee is the group of people who examine the information provided by and about the sellers. The entire committee could review everything, or certain people could be responsible for certain criteria. The criteria for selecting the seller should be defined beforehand, and these criteria may already be an organizational process asset. The criteria could include price, past performance of seller, seller’s technical capabilities, years the company has been in business, creativity of solution, etc. Assuming that not all criteria are equally important to the buyer, the criteria will be weighted. For example, the cost may be three times more important than how many years the company has been in business. After scoring the different areas, the committee will offer their choice of proposal.

WBS (Work Breakdown Structure)

A WBS (Work Breakdown Structure) is a project document that displays a deliverable-oriented hierarchical decomposition of the project work. At the first level of decomposition, the major branches of the WBS could represent phases, major deliverables, or subprojects. At each lower level, the work is broken down into more detail. This process of breaking down the work into its more detailed components is called decomposition. The lowest level components of the hierarchy are called Work Packages. The WBS contains the entire scope of the project. The approved detailed scope statement with its WBS and WBS Dictionary is called the Scope Baseline for a project.

The WBS is an output of the fourth edition PMBOK®’s Create Work Breakdown Structure process. The Project Management Institute has also released an 111-page standard for creating a WBS called The Practice Standard for Work Breakdown Structures (http://www.pmi.org/Marketplace/Pages/ProductDetail.aspx?GMProduct=00100084701). Also see the earlier posting of Create Work Breakdown Structure Process (posted February 27, 2009).

Exercise and Certification Exam Peformance

Greetings.

Laura Hilkemann, the chair of TAPUniversity, has done the heavy lifting on this blog the last several months.  As of July 21, 2009, there are 124 core descriptions of project management.  We’ve indexed over 500 core learning objects across business analysis, human resource management, information technology, project management and quality management  disciplines.  A good number of those objects cross over those disciplines – for example group formation and development (forming, storming, norming, performing and reforming).

To help your understanding and mastery of those objects, over the last six months I’ve been researching the  impact of physical, spiritual and mental performance on each other. The gate swings all ways.  There’s some solid, reliable research out there to back it up.  Call it the body, spirit and mind game.   My interest is twofold:

• from our work to help professionals achieve certification results as efficiently as possible and
• my passion for exercise – primarily in triathlons, marathons and quests to reach milestones in each.

Exam Day

What started as “ten things to do before your PMP exam” five years ago has grown into a deeper passion of mine.  In looking at 9 certification exam experiences of mine since 2000, I did very well on 8 and so/so on 1.   One of the factors on the so/so one in 2004 was taking exam after a period of 2 weeks of semi activity and on depleted resources (lack of sleep, stress and poor nutrition). 

Before my most recent exam (CBAP – certified business analyst professional –  in April of 2008) I purposely ran two miles (7 minute pace) , 30 minutes prior to the exam.  I had a good overall aerobic and anaerobic exercise week (30 mile running week and 3 strength training sessions).  I felt pumped, though sweaty.  Pity my fellow exam takers .  My pulse was moderate through the experience – not spiking up. I got up twice to grab some water and finished the exam rather fast.  Now, my mental preparation wasn’t necessarily text book – I crammed during a 6 hour lay over at the St Louis airport.  Granted I had been immersed in the BA jargon for 15 years –still not the ideal prep.

So what?  We coach and recommend that exam takers get up and move around during an exam.  Prior to entering the exam we recommend aerobic exercise commensurate with the exam takers current level of fitness. It helps the different pieces and parts of the brain.    It will not replace adequate preparation!  It does help you reach the optimum mental state.

Day to Day Performance

I’ll share more on later blogs in terms of how it does that.  The essence of it is that we’re wired to move; as we move our brain thinks and learns better; as we move we also touch a spiritual pulse inside and the spirit and mind also propel our body to move.  The three are connected.

To complete this first “exermindspir” blog – I want to share two links to one of the works I’ve studied from Dr. John Ratey’s “Spark: The Revolutionary New Science of Exercise and the Brain.”  Take a peek and let me know what you think!

 http://brainsciencpodcast.wordpress.com/2008/03/21/brain-science-podcast-33-exercise-and-the-brain/

Resource Leveling

The project management technique of Resource Leveling examines the possible need for adjustments to a schedule already constructed using the Critical Path Method based on the availability of resources. The fourth edition PMBOK® defines it as “any form of schedule network analysis in which scheduling decisions (start and finish dates) are driven by resource constraints.” It is listed as a technique of the PMBOK’s Develop Schedule and Control Schedule processes. Although typically the resources are people, other types of resources may also be leveled. If the schedule was constructed assuming that a project team of ten would be working forty-hour weeks, it will need to be adjusted if the team is only available to work mornings or if the team has been reduced to eight people. Also, a highly skilled person may be needed to perform several activities which are currently listed as occurring simultaneously, and there are simply not enough hours in the day for that single person to accomplish all the work. Another situation which may require Resource Leveling is if the team is unwilling to work varying number of hours (for example, the schedule may currently require 20 hours of a person’s time during some weeks, and 60 hours of that person’s time during other weeks). In this situation, the schedule could be adjusted so the resource(s) work the same number of hours each week. Often the project schedule will need to be extended to account for these constraints.

Issue Log

The Issue Log is a project document (not part of the Project Management Plan) described in the fourth edition PMBOK® whose purpose is to record and monitor issues. It is a tool of the PMBOK’s Manage Project Team process and an input to the Manage Stakeholder Expectations process. Note that one is a Human Resource knowledge area process and the other is a Communication knowledge area process, so the issues of concern in this case focus on human interaction and communication, not on all the technical project problems. Although the issues themselves can seem minor, unresolved problems have the potential to cause schedule delays and other detrimental effects. The Issue Log should assist in communicating the issue to the project team. A template is useful in which columns represent for each issue who is responsible for resolving the issue, the urgency of the problem, the potential impact of the problem, and the target date for resolution—along with any other information useful to the project management team.

Bidder Conferences

A Bidder Conference is a project management technique used for procurements. It is a technique of the fourth edition PMBOK®’s Conduct Procurements process. They may also be called contractor conferences, vendor conferences, and pre-bid conferences. A Bidder Conferences is a meeting for potential bidders to all fairly understand the buyer’s requirements. If the buyer were to meet individually with bidders or answer a particular bidder’s question privately, they would not all receive the same information—placing some bidders at a disadvantage. Imagine that Katy wants to pay one of her children to bake a dessert. She meets with all three of her children at the same time to inform them that she’ll pay one of them to bake a dessert that serves ten people by six o’clock this evening. Her oldest daughter wants to know if she’ll give preference to chocolate desserts, and Katie says “yes.” Her youngest daughter wants to know if the dessert can be a chilled dessert. Katie tells them all that the dessert should not be a chilled dessert. Her son wants to know if Katie will go to the grocery store if they need an ingredient not in the house, and Katie says that she will go to the grocery store, but won’t spend more than ten dollars on ingredients they don’t already have. After the Bidder Conference, the children are dismissed and each of them writes a simple proposal. The oldest daughter will make a German Chocolate cake if she is paid ten dollars. The youngest daughter proposes to make brownies for three dollars, and the son proposes to make s’mores for two dollars. At this point, Katie decides which proposal to accept. Also see the earlier posting of Proposal Evaluation Techniques (posted July 20, 2009).

Exercise – Brain Connection: Goals and Measurements

Goals and measurements, a topic that once again blends in some management concepts (TAPUniversity is a learning portal that supports management and technology so it’s fitting).  The brain thrives in goal setting situations.  Often it’s the mental part of the game that keeps exercise programs on target, or causes them to slip.  So put on your SWOT caps, step up the dry-erase board and chart your life!

For the last several years I’ve seen them boldly rush in to the local YMCA we belong to in the first week of January.  Brave and very well intentioned people making a change.  Hit the gym, push the pedals, ramp up the treadmill and check out a class!  Somewhere in early February it becomes apparent those that can make it stick and those that won’t.  What was made as a resolution soon fades under the pressures of life or unrealistic expectations.

Now rather than lament what happens to those that fade, I’ve been thinking about what’s consistent with those who stick.  What seems apparent are a few simple yet powerful things:

• Relationships develop- we are meant to do things together.  Even if it’s a bunch of introverts who just meet at the same thing and do their stuff quietly.  When done in pack we stick.  We’re pack animals. Even Rocky had Mick, then Apollo, Duke and finally Paulie (ok 1 of those is not like the other).  Some activities can be done alone, but doing stuff together makes it motivational.
• Doing something that you can enjoy once you’re over the learning curve.  If you’ve never swam before it’s a stretch to think you can jump out of adult swim lessons and into lap swimming in 4-5 weeks.   I know several triathletes have greatly improved their swimming over the course of a year and found enjoyment.   There is a learning curve to each new exercise, technique so patience helps.  It can be fun.  Kicking myself from a recreational bike rider to one that has clip shoes, cares about carbon forks/frames and has the foggiest notion about rhythmic stroke motion has been a blast.  It’s also been good for the brain – you see I’m learning something new and triggering that learning in the limbic or “doing” part of the brain.
• Goals and measurements - I should add “reasonable” goals and measurements.  Unreasonable goals flow through two channels (one) if exercise is viewed as a one shot, 90 day miracle deal or  (two) if the expectation is to shed 50lbs, increase strength, speed, stamina potentially in 90 days.   Neither works.    Reasonable goals with measurement should help propel you – not defeat you.  Goal setting start with an accurate assessment of what your current level is.  Here’s mine for 2009 I typed into a simple spreadsheet I keep on 12.28.08 and a measure of where I’m at as of August 6,  7 months into it.  I try to just keep an honest flowing conversation going with myself – no bull. 
  • Goals:1,500 running (29 per week).. 100 swimming or 3,200 laps.. 200 bike.  Lincoln Marathon – 4:15; Pikes Peak Double!  4:55 and 7:55.  HyVee Long Course Triathlon – Finish.  Des Moines Marathon 4:10
  • Measurement as of 08.08.09 –
    Running on target – 27.9 average, highest number of 40+ mileage weeks since 1997.  High points – Cornhusker State Games & Thunder Run 5k’s, winter and Pikes Peak build up; Low Points – after my father passed away in April – a bit listless.
    Swimming below target but planned up tick in August  following Pikes Peak – 17 miles.  High points  – most mileage since high school and tried new events (1k open water swim) and HyVee 1,500 meter swim at 38 minutes.  Low points – CSG sprint tri was 4 minutes slower? 
    Cycling – over or ahead by 65 miles – cranked in more for HyVee  and hope to finish with 500 total (leads into 2010 goal of 1/2 iron man).  High point – learning to ride a ‘real’ road bike for CSG in June and somehow not totally embarrassing myself on HyVee bike portion.  Low point – taking too long to ask to borrow a decent road bike.
    Pike’s Peak Double is next week – in as good as shape as I’ve been since 1998,
    Lincoln Marathon – blew up and overheated at mile 21 – missed goal by 17 minutes was able to help a friend from high school finish her first marathon – was over’joy’ed with that,
    Des Moines 4:10 updated to sub 4 hours, why that when I blew up in Lincoln? Figuring out the root cause (thyroid / hydration / base mile / April stress) and am getting in much better shape.  I also have 4 to 5 “litmus test” races from 1/2 marathons to 10k/5k to validate.
  • My longer term, 2 to 4 year horizon, goals include 1) Boston Qualifying marathon of 3:30, 2) 1/2 Iron Man and once #1 goal is met, Iron Man Triathlon, 3) 10k swim without search and rescue and 4) matching PR’s in running (5k, 5 mile, 10k, 10 mile and 1/2 marathon).  Could I knock these goals off based on where I was at in December of 2008?  No.  But I can build each year.  Could someone new to any of these activities blaze by me with 6 months of training – absolutely!  And after tripping them I would applaud  – goals and measurements are personal.  The miracle is making it out the door.

Please  let me know some of your exercise goals and ways you use to measure.  Another method I’ve found fun to  measure is a through a couple of ad-in’s in Facebook: VOMaxer and RunLogger.  It’s been encouraging to see how virtual and ‘real’ friends are doing and to chart my own progress. 

Finally wanted to share a cartoon the extols the benefits of beginning your program.

So what do I need to do for good health?

Critical Chain Method

The Critical Chain Method, developed by Eliyahu M. Goldratt, is a schedule analysis technique that is listed in the fourth edition PMBOK®’s Develop Schedule process. Although similar to the Critical Path Method, this method emphasizes resource limitations and buffers. After building a project schedule network diagram, any necessary changes are made to the schedule based on resource limitations. For example, the original schedule could have four simultaneous paths that each has a certain type of specialist working full-time on that path’s activities. However, the organization may only be able to obtain one specialist, and that person cannot work four full-time jobs at once! So the schedule in this case would be lengthened so that the specialist can do all the work within normal full-time hours.

The Critical Chain Method also inserts buffers, which is a length of time without scheduled activities that can be used for activities that may last longer than expected. For example, if everything goes as planned, a project could take 11 months to complete, but an extra month is scheduled at the end whose days can be used for activities that take longer than expected. This is called the project buffer. Buffers throughout the project are called the feeder buffers.

Critical Chain does not place as much emphasis on finding the shortest possible critical path, as it recognizes the high element of uncertainty in the duration of project activities. Also see the earlier postings of Critical Path Method Explained with Cookies (posted August 6, 2009), Develop Schedule Process (March 10), and Project Schedule Network Diagrams (posted June 24, 2009).