Ethical Challenges for Project Managers: When a Project Manager has to make an Ethical choice in Project Management

by Cheryl Wilson PMP, PMI-RMP, CCEP

Project managers face various challenges every day in managing projects.  Not only do we face the normal challenges managing a project with scope changes, time crunches, cost overruns and risk potentials, but many of our decisions involve ethical parameters that we may not at first understand or perceive. Project Managers deal with political issues, budget accountability, HR challenges involving virtual teams, cultural differences, project sponsors, government regulations, vendor negotiations, and a myriad of communications challenges.

Regardless if the project manager is managing public or private projects, managing a project while navigating these dark inlets requires the project manager making decisions every day, which can lead to many ethical quagmires. While some of these ethical shoals may be easy to navigate around, some take the project manager down the path of having to stand-alone when faced with an ethical dilemma.  At first, the difference between the right and unethical decision when it involves managing a large project may not always be clear.  The buried reef to watch for is the crossing over to unethical decisions.

Ethics can be defined as the basic moral values, beliefs, and rules that we uphold in our lives. I believe the pressure of the project manager in meeting challenging deadlines makes this sometimes difficult. The project manager can blur the line between personal beliefs and what they will do as a  project manager in order to achieve a successful project.

So, what is the fine line between making ethical decisions as a project manager, and choosing to take the path of least resistance?  Is it natural for a project manager to be ethical? I once heard this quotation:  “do not sacrifice the immediate on the altar of the permanent.”  Sort of fits, does it not?  However, it begs the question: can a project manager be successful in their project and remain 100% ethical?

Often the project manager is faced with a situation that is not easily to resolve by normal management skills or knowledge gained from our training. Many times the project manager can reason their way to a decision when faced with an ethical dilemma, but this is when the project manager must draw from their ethical obligations and their training as a strong moral leader to make the right decision. Such ethical, professional behavior becomes more difficult as the project manager is witness to others who are not as ethical, gain the advantage.

Remember, ethics are the results of our moral values and beliefs training which we have reared with or experienced. Sometimes professional ethics are emphasized and taught in project management training.  What is the difference between morals and values and ethics?  Actually, do not they all provide behavioral rules?

  • Values are the standards or rules we use to make decisions between right and wrong or whether we as should do something or not do something.  Values govern our behavior and choices.  When we decided to do something, we make that decision on based on our values.
  • Morals in the dictionary are defined as motivation based on ideas of right and wrong.  Morals trace back to ties we have with society, government, or religious beliefs.
  • Ethics, on the other hand, are the rules or standards governing the conduct of a person or group of people in a profession.

As project managers, we work under a “Code of Ethics” when making decisions, but as we all know, an ethical decision can be biased by our values and morals we personally define. The ethical tone or the lack of ethical standards of a project manager can also be traced back to the framework of the company as a whole.  If a company proactively establishes a set of ethical guidelines, a working code of conduct, the project manager is provided a moral compass so to say to help navigate the sometimes-murky waters involving ethical situations.

Ethical situations that a project manager may face can be some of the most difficult decisions that must be made since they involve weighting the possible outcomes against doing what is right or what is expedient. Expediency has always been a readily available excuse for tipping the scale into unethical behavior.

To provide an example of the consequences of an unethical decision that resulted in a $28.4 million fine, I wanted to tell you about a project I managed. I was hired on a team to put into place a compliance program, internal controls and training to prevent future Foreign Corrupt Practices Act (FCPA) violations stemming from an unethical decision made at the Titan Corporation, a California-based defense and telecommunications company.  Not only were there unethical decisions made on the part of employees of the Titan Corporation, but also in the hiding of the funds within the books and records.

The Titan Corporation violated the FCPA when their employee took the bribe from the government official, Benin President Mathieu Kerekou, to build the telecom infrastructure in his African country.  In 2000, Titan’s Benin Agent asked Titan to pay $2.0 Million (USD) in “social payments” before the next presidential election which Titan completed using the cover of falsified invoices.

In March 2005, Titan Corporation pled guilty to three-counts stemming from improper payments made by a foreign sales agent to a Benin government official. Titan was required to pay the largest FCPA penalty ever ($28.4 million) at that time, including disgorgement of profits stemming from the illicit payments.  The unethical acts were discovered when Lockheed Martin was doing their due diligence to acquire Titan Corporation. Of course, Lockheed Martin declined to acquire Titan due to the FCPA violations.

The full story can be access at the following Department of Justice web site:

As project managers, we face these various challenges every day in managing our project. We, however, have consequences for these decisions, and being a professional means understanding the outcomes from our decisions. We will be addressing these and other ethics and compliance issues in this monthly column. Each issue will deal with a different set of circumstances or problems facing project managers in the execution of their duties.

PMBOK® Guide, 5th Edition, Review

By PH Lohnes, PMP

With the release of the 5th edition, the PMI added a new Area of Knowledge (AOK) called Project Stakeholder Management as the 10th AOK. Of the four processes in this new AOK, number 13, two of them are recast from the 4th editions Communications Management AOK, number 10. If you have not already noticed, the 5th edition renames all 10 AOKs to begin with the adjective, Project – all AOKs are now Project XXXX Management with XXXX being the name of the AOK proper.

The new 10th AOK, Project Stakeholder Management, unfortunately, diverges from the standard recasting of the other AOKs in that it does not begin with the normal Plan, Manage, Control processes, but moves what was the previous Process 10.1, Identify Stakeholders, to Process 13.1, Identify Stakeholders. Thus you will have to remember that AOK 4 and 13 now begin with processes that are not aligned with the other 8 AOKs. One would assume that it will be in the 6th edition that these oversights will be remedied.

Beginning with Process 13.1, Identify Stakeholders, the differences between Process 13.1 and Process 10.1 of the 4th edition are minor. The wording is almost exactly the same in 4th edition; however, there are a few changes to the Input, Tools & Techniques, and Outputs (ITTO) for this process. The Inputs (13.1.1) are the same. The Tools & Techniques (13.1.2) adds a new item, Meetings in order to indicate the use of profile analysis meetings in identifying project stakeholders and their interests. Finally, the Outputs (13.1.3) has a single output, the Stakeholder Register ( removing the Stakeholder Management Strategy (, 4th edition) output given the new Process of Plan Stakeholder Management (13.2) coves the details of the previous output.

The new process, Plan Stakeholder Management (13.2) is now the primary planning process of the new AOK covering the details developing the strategies for analyzing and managing project stakeholders with the following ITTO items:


Inputs (13.2.1): The PM Plan Stakeholder Register Enterprise Environmental Factors (EEF) Organizational Process Assets (OPA)

Tools & Techniques (13.2.2): Expert judgment Meetings Analytical techniques

The biggest addition was the use of stakeholder engagement classifications of:




Supportive, and


with the indication of either C for current engagement classification, and D as desired classification for the indicated stakeholder or stakeholder group.

Outputs (13.2.3): Stakeholder Management Plan (PMP subsidiary plan) Project documents updates

Next, Process 13.3, Manage Stakeholder Engagement, is an updated version of the 4th edition, Process 10.4, Manage Stakeholder Expectations with changes in the Inputs and Outputs, but not with the Tools & Techniques. The changes on the Inputs (13.3.1) include a reduction from 6 to 4, more confusing is the movement of the Issue Log from Input to Output, and the elimination of the Stakeholder Register as an Input altogether. These changes seem to be a bit capricious since in the 4th edition the Issues Log was updated as part of the 4th edition’s Output of Project Documents Updates while in the 5th edition, the Issues Log is singled out with its own Output identifier (

Process 13.3, Manage Stakeholder Engagement ITTOs are:

Inputs (13.3.1) Stakeholder Management Plan Communications Management Plan Change Log OPA

Tools & Techniques (13.3.2) Communications methods Interpersonal skills Management skills

Outputs (13.3.3) Issues Log Change requests PM Plan Updates Project Documents Updates OPA Updates (new)

The final process, Control Stakeholder Engagement (13.4) completes the new AOK with the standard process formulation that the 5th edition has implemented: Plan – Manage – Control. This process is described to improve the effectiveness of Stakeholder engagement as the project evolves dynamically with time. Stakeholder expectations, a large component of stakeholder management, should be continuously met as the project progresses from stage to stage through its life cycle. Thus controlling stakeholder engagement ensures that current project performance data gathered from defined metrics and audits is meeting the expectations of the stakeholders, or else remediation activities are needed.

Process 13.4, Control Stakeholder Engagement ITTOs are:

Inputs (13.4.1) Project Management Plan Issue Log Work Performance Data Project Documents

Tools & Techniques (13.4.2) Information Management Systems Expert Judgment Meetings

Outputs (13.4.3) Work Performance Information Change requests PM Plan Updates Project Documents Updates OPA Updates (new)

This lengthy column has attempted to show the PMBOK® Guide’s 5th edition major addition: the new AOK of Project Stakeholder Management. While two of the four AOK’s processes are new, the remaining two are updated versions of the 4th edition Communications Management AOK.


The PPPM Roadmap: The Insanity Continues

By PH Lohnes, PMP

Before I move into my column this month, I must clarify an issue that landed me in hot water with some readers of last month’s topic. When I said that the best candidate to be a portfolio manager is a member of the Senior Leadership Team (SLT), I did not mean to imply that this was their own duty. The chosen member of the SLT could in fact delegate most of the actual portfolio effort to a working manager. However, I stand by the need to ensure the portfolio manager, director, chair (use your own title) is both privy to and a participant of the enterprise strategic landscape design. Without this connection, well, read this month’s front page for the consequences of such lack of strategic awareness for the portfolio manager.

Onward now. After spending over three years working as a project, program, and portfolio manager/consultant in support of a research endeavor at over 7 government agencies, 3 healthcare companies, and for 5 small-medium government contractors, I have come to the conclusion that the project management state of the practice is disoriented and in chaos. I say this only because over the past 20 years the number of certified project managers has increased by well over 100 times (4,000 to over 400,000) while the project success rates have not shown any material improvement with the small exception of Agile-type projects in the IT world.

What could be the cause of this disconnect? Here is my story, and it is only mine. I do not blame anyone or any institution – they are doing what they think is best to protect their own turf or philosophies. However, I bring up Albert Einstein’s definition of insanity:

“Doing the same thing over and over, but expecting different results.”

By this definition, the current state of project management is decidedly crazy. We are continuing to do the same things over and over, but expecting that somehow the results will be marginally different. I point to the fact that next version of what is called the industry project management body of knowledge by its creators is fundamentally the same as the previous versions especially in the risk discipline. Project management is not the same as it was 20 years ago or even 5 years ago. We need to be dynamic and adaptive; flexible and applicable.

Therefore, what in the current state of the practice is limiting our profession from achieving the results that our employers, clients, or customers desire?

Simply, we have become stifled in a liturgy of project management processes that look good on paper, but do not work in the real world. The profession is more interested in protecting its brand than protecting the best interests of those that procure its services. With a comparison to history, the project management profession is at the same point in time as the Western religions were at the beginning of the Reformation – processes are more important than production, form is more important than function, and ostentatiousness than outcomes.

The practice of project management is professionally bankrupt! Those of us that see this need to begin the steps of retaking the profession from those that have put us into this “process limiting” perspective, and rebuild it along the lines that provide value for our employers and clients. We need to show value for our mostly very expensive services – not continued low project success rates.

From the early 1990’s until now, there has been a 100 fold increase in the number of certified project managers just from the PMI – not counting the other PM organizations overseas. If the value of the certification was correlated to the success ratios of project completions, one would expect the ratios to have taken a significant increase over these past two decades. This is far from the reality as has been shown in several studies of project success ratios from the Standish Group, Computerworld, InfoWorld, and authors: Martin Cobb, Kirk Kirksey, Bob Lewis, Thomas Hoffman, Julia King, and many others.

Consequently, if the large increase in certified project managers has not advantaged the project success ratios, the problem must lie elsewhere. In some blogs, the fault is levied at the increase in project complexities, lack of senior management support, lack of defined goals, requirements, etc. However, it would seem that most likely culprit is the methods, processes, and perspectives in use over the past two decades. What I am speaking about is the industry best practices or bodies of knowledge in use. These components of project management are largely unchanged from the 1950’s – 1960’s where they were born of the construction industry. One notable exception is the advent of the Agile methodology in use for the development of software applications.

I maintain that the project management profession MUST come to grips that it is not serving its customers, stakeholders, or clients by continuing to demand wages in the low six figures, but not delivering business value for those high compensatory pay-outs. The US Government has already begun the process of altering their perception of what a project manager is by defining, creating, and instituting their own project management certification program: the FAC-P/PM (Federal Acquisition Certification for Program and Project Managers) from the OFPP (Office of Federal Procurement Policy).

The policy letter of April 25, 2007 states that “the certification shall be accepted by, at a minimum, all civilian agencies as evidence that an employee meets core training and experience requirement for general program and project management.” This should have rocked the PMI and APM to its core; however, nothing appears to have been done about this lack of acceptance of the commercial certifications by the US Government. We are seemingly going quietly into the good night. Sooner or later, the industry must come back from the over complication of its practices towards the concept that in project management it is all about the deliverables – pure and simple – the production of “fit-for-use” deliverables.




The Project Whisperer Approaching a Troubled Project

By PH Lohnes, PMP

Let’s begin with a story…

This conversation occurred several years ago between a client and a project rescuer concerning a troubled project for which the consultant was being asked to service.

“Glad you could make it, today. We really need to get cracking on this project issue,” he said quite matter-of-factly.

“Happy to help, Mr. Blamet, my schedule was open when you called,” I said.

There was more small talk for another 30 seconds or so, and then I asked the big question:

“So tell me why you think you need my services on this particular project?”

The VP of R&D’s face fell immediately, and he swallowed hard and long,

“I believe this one is in trouble, and I can’t seem to get answers on its status,” he said.

“All right, let’s begin with this task — can you assign me an IT person that is skilled in the workings of your communications systems: email, file archives, reporting system?”

“Yes, but I do not understand, why communications?” he stammered.

I paused, looking thoughtfully before answering,

“I have usually found that the quickest method to discovering what is going on with a project is to review its actual communications between the project manager, the project team, and the project’s stakeholders.

Projects that are doing well compared to plan usually have up to date and accurate reports and communications to stakeholders while those that are suffering in silence, do not. It’s just a commonality I have found over the years in helping to rehabilitate troubled projects.”

Mr. Blame picked up the phone and asked his assistant to tell Mr. Pickering in IT to send up his best company communications tech, someone that knows how to retrieve emails, reports, and documents from the archives.

He hung up the phone, and turned to me, and said,

“How long do you think it will take to figure something out? Can we at least expect something by next week or so?”

Looking him in the eye, I told him, “Brad, I can tell you this afternoon once I review the communications dump. It is not brain surgery. Give me about 2 hours with your comm tech, and I should be able to have at least a preliminary report.

Does that work for your schedule?”

He simply muttered, “Unbelievable, I should have called you in sooner,” and then almost under his breath, “if you can deliver…” trailing off as he lowered his head back to the papers littering his massive, oak desk, indicating to me the interview was over.

From this point on in facing a troubled project, it is important to review only what has a minimal probability of being altered, faked, or reported in error. While you would hope that fakery is not an issue, troubled projects may involve a need to obscure reality, and this usually manifests itself in problem communications.


In reviewing the communications dump, I was able to discover two items that needed further investigation:


  1. Communications with stakeholders all but ceased 4-5 weeks ago, and
  2. project emails between the team members dropped almost 72% during the same period.

Once I had an idea about where to begin my review, I asked the comm tech for access to the project archives particularly the stakeholders register and the risk register. Upon completing the archive search, only one of the two registers was available: the stakeholders. It was evident that risk management was not a part of this project’s planning.

I made some calls to the key stakeholders, and asked two questions:

  1. Can you tell me what you believe is the current status of the project?
  2. When was the last time you received any communications (reports, emails, etc) about the project?

From the answers to these questions, I was quickly able to determine that something major had occurred about 5 weeks in the past for which the project manager had stopped all stakeholder communiques, and severely limited his contact with the project team. Again, the communications, or lack of it, led me to the issues that needed to be addressed with this troubled project.

Armed with the communications and answers from the stakeholders, it was time to meet with the project manager. However, before confronting a sitting project manager, I would suggest that you obtain his/her background/bio or organizational HR dossier so that you understand his/her history, experience, and skills for project management.

In this case, it was quite evident that while Todd was an excellent optical engineer, he was not trained in project management and the management skills and capabilities he might need to run a project successfully.

I spoke with Todd, and asked him what happened 5 weeks ago. His head almost snapped off his neck as the realization that someone else knew something about the problems with his project. I mentioned that one of the main functions of a project manager is to communicate truthfully, accurately, and timely all status and performance issues related to his project. Keeping bad information to himself was only delaying the inevitable since the project could not be carried forward in this manner indefinitely.

He seemed relieved that he no longer had to carry his secret, he told the story:

Five weeks ago, the sole supplier of the photonic phase-tuning circuit (PPTC) for the laser based interferometer deliverable of his project had gone out of business due to bad management. He had not completed a risk identification or risk management plan so using a sole-sourced component was not considered a risk event nor planned for with a risk response. When he found out that this critical component was not going to be provided, and there was not enough time to find, procure and deliver a suitable replacement, he panicked and tried to hide the fact by cutting off communications hoping he could fix it somehow.


In writing up the report for Mr. Blamet, I mentioned that had the project manager come to him, as the project sponsor, with the problem when it occurred, there may have been enough time to repair the issue without dramatically altering the schedule or budget of the project. Now, it seemed that unless Mr. Blamet was willing to allow the project the time and cost of second-sourcing the PPTC, it would be best to close down the project or roll it into next year’s R&D portfolio.

Using the best numbers from both the severely out-of-date project financials, Todd’s project notes, the organization’s best optical engineers, the cost of rolling the project forward would be roughly $420,000 vs. $485,000 to find, contract, and obtain a new source of the PPTC plus allowing another 6 weeks for the effort.

Since it would have past the time for the industry conference at which the organization was going to announce the new product (the laser interferometer), Mr. Blame decided that he would roll the project forward to next year’s R&D portfolio. Todd, the excellent optical engineer, but under-trained project manager, was released back to the engineering staff for re-assignment after the normal “dressing-down” for trying to hide the project’s problems from the stakeholders.

As the project rescuer, I used something I have discovered over the many years and many troubled projects:

Do not assume that what you read, see, or hear about a project from the standpoint of reports, EVM/EVT analysis, or performance measurements is accurate as to the honest status of the project especially if it is in trouble. Many project manager’s do not like nor want to deliver bad news, and are sometimes likely to try and stall or hide it while they search for a “workaround” that will get them out of their predicament.


I use the communications inspection as a very quick, but excellent methodology for finding out what is going on with a trouble project since it is very hard if not impossible to alter or mask communications given the networking and security technologies and applications that support the communications infrastructure used in most organizations today.

As a trouble project rescuer, be diligent and fair, but be skeptical until proven otherwise — use the project’s communications or lack of it to lead you in the right direction rather than being taken in by wonderfully prepared reports, excellent analysis profiles, or nicely purported presentations.



Risk Management Maturity Concepts: Discuss and Reassess Risk Management Often

by Cheryl Wilson PMP, PMI-RMP, CCEP

In my series of Risk Management Maturity Concepts, I want to bring you through my experiences of implementing an effective risk program. Recently I worked with a client’s troubled project by putting a risk program in to place. When I ask about what they already had in place and why they implemented it, they indicated: “I have a risk register with 5 columns with 12 risks.”

Using the ideas from my first article in this series, I told them and what I want to emphasis here is that the steps prior to even implementing the risk register are critical in providing the project manager with the tools necessary towards achieving a successful risk program.  Merely having a risk register is not enough and leaves the project vulnerable. You are more than likely to have missed information that you should be managing in your risk environment.

The section on “Inputs” to your risk environment will help ensure your project is ready for issues, contingency planning, government reporting requirements, audits, metrics, etc. These preparations are critical to your risk environment. They can guide you to deciding what is necessary in your risk register.  Every project will be slightly different. You cannot manage every project in the same way.

Since normally your projects will progress through your defined project life cycle, it is critical to frequently reassess the risks as the risk environment never remains static.  Thus, methods of how you identify your risks will change to address this dynamic landscape.

One of the first documents you will discuss and write for your project will be the Project Management Plan.  Within this plan, the risk environment should be discussed in the Risk Management subsidiary plan.  I recommend for projects that are complex, large or in trouble, a separate Risk Management Plan be written and evolved on its own.

As the risk environment is an iterative rolling wave process, the following areas should be addressed in your risk management plan.  Future articles will expand each section in more detail.

  1. Identification of potential risks by utilizing risk tools and techniques. There are many tools and techniques to identify risk potentials, their root causes, triggers, etc.  Depending on whether your project team is in one location, or virtual has an impact on how risk identification will happen. The project team needs to know how to identify a new risk and how to report the risks.  They need to know to whom to report the risk, and the time sensitivity of such reporting.

One area projects have the most problems with is identifying the true risk and understanding the difference between the cause of the risk and the effect of the risk.  Identify the WRONG risk is in itself a risk to the project.  If you are wondering why your project has a long list of risks, but no progress in mitigation of those risks, it is more than likely the wrong risks are stated!

2. Assessment of risks both quantitatively and qualitatively. In order to know the risk potentials that will have the most impact on the project, the project manager and the project team need to prioritize all risks. A common temptation is to skip the methods of quantitative risk assessment—where estimation of risk value is precisely calculated with numerical measures—and only concentrate on a few cheap and easy qualitative methods. Quantitative methods often provide a more accurate image of risk likelihoods and can be critical to the success of risk management and contingency planning. Today’s computers and software can reduce the effort of using quantitative risk analysis.

3.  Prioritization of risks using impact analysis. Prioritization of the risks by assessing their potentially negative impact and the likelihood of occurrence is necessary to effectively utilizing limited risk management resources. There are two common ways to do this. One way is to assess the risk’s impact and probability on a scale of 1 to 5, where 1 and 5 represent the minimum and maximum possible negative impact and in similar fashion, the likelihood of risk occurrence.  The other way is to assess these two variables in terms of low, medium, and high. Prioritizing your risks will enable your organization to focus on the most critical potentials first before tackling others.

4. Design and implementation of risk mitigation and contingency plans. After you have prioritized your risks, develop risk mitigation and contingency plans for the highest potential risks in order to manage, eliminate, or reduce their potential impacts to acceptable levels. Mitigation plans need to tie each risk to scope, time, cost, and quality while identifying mitigation strategies and contingency plan triggers.  You also need to clearly define risk-related roles and responsibilities in terms of risk owners (the person responsible for ensuring appropriate mitigation strategies) and risk action owners (the people responsible for implementing the chosen strategies).

5. Management of the risk environment in order to reduce risk impacts. The last step is reviewing mitigation and contingency plans on a frequent basis to stay abreast of changing circumstances that may affect them. As noted above, it is a best practice to set a schedule for risk discussions, such as weekly for high risks, bi-weekly for medium risks, and monthly for low risks. Another best practice is bringing in internal or external risk auditors, such as quarterly, to evaluate the effectiveness of your risk management and contingency planning. Risk audits will often point out better ways of handling a specific risk so that you can change your mitigation strategy going forward.

In summary, the need to be dynamic in identifying, assessing, and managing the risks confronting your projects is clearly a solid practice of improving project success rates. It is always better to mitigate a risk than attempt to survive an issue.




Work Breakdown Structure (WBS)

According to Wiki, “The Work Breakdown Structure (WBS)…is a deliverable oriented decomposition of a project into smaller components. It defines and groups a project’s discrete work elements in a way that helps organize and define the total work scope of the project.”  So what does this really mean? The Work Breakdown Structure (WBS) is an integral tool in developing the project schedule.  But what is a work breakdown structure, where does it come from, how is it developed? The WBS is developed directly from the contract/ Statement of Work/ Requirements document. The high-level WBS should be directly traceable to the governing scope document for the project/ program.

Brief History:

WBS was first developed by the Department of Defense (DoD) during the early days of the Program Evaluation and Review Technique (PERT) development.  According to the DoD the WBS is:

a.  A product-oriented family tree composed of hardware, software, services, data, and facilities. The family tree results from systems engineering efforts during the acquisition of a defense materiel item.

b.  A WBS displays and defines the products or deliverables, to be developed and/or produced. It relates the elements of work to be accomplished to each other and to the end-result. In other words, the WBS is an organized method to breakdown a product or deliverable into sub-products at lower levels of detail.

c.   A WBS can be expressed to any level of interest. Generally, the top three levels are sufficient unless the items identified are high cost or high risk. It is then important to take the WBS to a lower level of definition.


The WBS precedes schedule development – that is the schedule is produced from the WBS and Integrated Master Plan (IMP); it traces directly from the project scope, the “what”, i.e. “what is/are the thing(s) that will be delivered.  The Integrated Product Team (IPT – Systems, Software, Hardware, CM, etc.) reviews the high-level deliverables and breaks them down (decomposition) into chunks (actual deliverables, not tasks) at the next lowest level.  This breakdown process continues at each level culminating in a deliverable-oriented hierarchy until you get to the lowest “what”.  At each decomposition level, use of the “100% rule” is applied.  Simply, the “100% rule” says the sum of the “what” of the child level must equal 100% of its parent.

Since the WBS is focused solely on scope, it does not granulate to the “how” level.  “Hows” are the activities and tasks from which the schedule is developed.  To use an analogy, the WBS is the backbone (support structure) whiles the activities and tasks comprise the ribs and appendages connected to the backbone.

Key Benefits of a Well-Structured WBS:

1.  Scope is well defined, clarified, managed and protected

2.  Scope is reviewed and validated for completeness

3.  Scope is ‘locked-down’ – put under document control – to avoid future creep

When scope creep inevitably rears its ugly head, the PM can raise her/ his WBS shield to hopefully thwart this enemy.  If management wants additional requirements or scope, then the WBS speaks up and says, ‘no can do….unless you provide additional time and resources’.  The WBS is, in fact one the PMs best friends and strongest allies.


Mitigating “External” Risks is usually Scoop Creep

by Cheryl Wilson PMP, PMI-RMP, CCEP

Tasks outside of a projects planned objectives, is commonly known as scope creep. Scope creep can originate from several sources and is a leading risk potential. As a review, the project primary constraints are Scope, Time, and Cost, Quality and Risk. Constraints behave in concert based on stressor mechanics. Equilibrium = the projects primary constraints in balance. If one constraint is altered the other primary constraints must be realigned to re-balance. If equilibrium cannot be achieved, projects cannot produce the “fit for use” deliverables. Risk potentials should be categorized into internal and external risks as soon as they are identified.

Internal Risks
Internal risk potentials are risks that fall within the scope of the project. The project manager and the project team have some control over the mitigation plan.

External Risks
Risk potentials that cannot be mitigated by the project manager or the project team are considered external risks. Organizational problems that the Project manager has no control over fall into this category as well as funding for the project. If the project manager or the project team cannot mitigate the risk within their scope, additional resources or funding will need to be applied.

Scope Creep
Because as effective mitigation of external risks normally involve tasks that are outside of the projects deliverables, external risks should be escalated to the program level or the portfolio level for effective management. By trying to mitigate the risk, the result is usually scope creep.

Critical Chain vs. Critical Path

By Barry Clark, PMP, PMI-SP

One the very heated and passionate debates of the project management discipline is that of the capabilities of the well-known critical path form of schedule analysis and management and the lesser-known critical chain. Guest columnist, Mr. Barry Clark, a credentialed schedule professional, writes this month’s Schedule Dispatch on the major differences between these two often-confused scheduling tools.

Critical chain (CC), derived from the Theory of Constraints, is the longest chain of tasks in the schedule that accounts for both duration and the resources required for tasks. Simply stated, the critical chain is the ‘resource constrained critical path’.  By contrast, the Critical path (CP), the longest chain of tasks in the schedule that represents the shortest amount of time to project completion, is irrespective of resource availability or resource allocation or over-allocation.  Critical path strictly considers task duration and float (the difference between late finish and early finish, or late start and early start), ignoring resource availability, over-allocation, and possible multiple tasks having assigned identical resources that are simultaneously scheduled.  Resource over-allocation inevitably results in bottlenecks and/or scheduling conflicts that invariably lead to schedule delays.

One of the key differences between CC and CP is their use of buffers.  Buffers are added to tasks or schedule as blocks of time to prevent slippage.  Critical chain utilizes buffers, while Critical path does not.  There are three types of buffers:

1)    Feeding Buffers:  time-block set at the end of a sequence of non-critical tasks;

2)    Resource Buffers:  time-block set aside to indicate resource needs.  It is basically a resource place-holder;

3)    Project Buffer:  time-block set aside at the end of the project.

These buffers are strategically placed along the critical chain to account for and accommodate resource allocation, risk avoidance, and human behaviors, i.e. Parkinson’s Law and student syndrome.  Parkinson’s Law is filling available time with redundant work when tasks are completed early (if you know you have a set time to complete a task, people generally will use the entire time); student syndrome is putting off until the last minute what should have been initiated earlier.  Both issues are chronic problems in traditional scheduling using CP analysis.

Comparatively, the Critical path doesn’t consider resource allocations or dependencies, or the use of time-blocks (which reduces schedule risk), and basically ignores non-critical tasks, which can easily become critical. When projects inevitably run afoul, CP calls on schedule crashing and fast-tracking to ‘right-the-ship’ (move back to the left, or ‘left-the-ship’).


Given the nature of projects (and people who work them), including poorly defined project tasks, unknown pop-up tasks, unrealistic durations, multi-stakeholders with varying interests, volatile financial/ resource markets, etc., it is little wonder why projects run at an unacceptably high failure rate.  Critical Chain analysis accounts for many known and unknowns (risks) and addresses the human factor, which consequently keeps projects under control more effectively.

With focus on resource leveling and bottle-neck avoidance (and thus risk avoidance), Critical chain scheduling paints a more realistic view of current status and future project outcome given that many projects are often underfunded and understaffed (usually due to Management’s demand to do more with less).  If they are running a tight critical chain ship, the Project Manager need not sound the alarm to arms since the buffers have provided the needed relief; if however, they are running a Critical path ship and rough gales are eminent, crashing or fast tracking the schedule may exacerbate an already precarious situation.

The PPPM Roadmap: Linking it Together

< This is a personal blog – not indicating the corporate views of MCLMG, LLC >

Project/Program Portfolio Management (PPPM)
By PH Lohnes, PMP

Having the roadmap details behind us, we now have to put the final piece into the jigsaw to crystallize the entire concept. In this post we will discuss the interrelationships between the PPPM vision, the goals, direction, roadmap, and outcomes. Let’s first start with the organizational prerequisites. These are the conditions that I have discovered are conducive to the benefits a vibrant PPPM environment can provide to a project management organization. These prerequisites are:

  • A Senior Leadership Team (SLT) willing to discuss a PPPM vision, if not already in place,
  • The designation of a member of the SLT as the portfolio manager,
  • Willingness to apply organizational resources to the creation of a PPPM environment, and finally,
  • A SLT member as the champion of the PPPM effort (not the same as the portfolio manager)

An organization lacking these prerequisites are less likely to be successful in their establishment of a PPPM environment, so the first step would be to determine if your organization has these conditions in place ready to support the PPPM establishment. Save yourself a significant level of frustration and wasted energy by postponing your PPPM activities until these conditions are mostly in place. You can assist with the creation of these conditions, but unless you are one of the very senior SLT members, you might not have the authority to condition your organization for this path.

With the assumption that you have the prerequisites in place, it is time to setup a regular, periodic time to meet with both the PPPM champion and potential portfolio manager for the purpose of establishing your organization’s PPPM vision. This vision needs to specifically define the PPPM To-Be conditions that the PPPM roadmap will implement. These vision statements will define the environment as it will exist once the PPPM roadmap has been completed. You will be describing the desired landscape your organizational project management discipline will take as the roadmap activities are scheduled and accomplished.

With the vision statements defined, and approved by the entire SLT, the next step is to begin the development of the PPPM roadmap. This involves all of the details discussed in the previous postings on the roadmap components so you have your work cut out for you and your organization. If you have any questions or comments, please feel free to contact me here at

Good luck, and while it may appear to be long and complex, the benefits are worth the effort.


The PPPM Roadmap Components: Goals

< This is a personal blog – not indicating the corporate views of MCLMG, LLC >

Project/Program Portfolio Management (PPPM)
By PH Lohnes, PMP

This will be a short post about the importance of setting the right goals for each of the PPPM roadmap periods which you have designed to implement your PPPM vision. First there is a concept going around that goals should be SMART, SMARTER or something similar. If you are not familiar with the acronym SMART, I would suggest that you look it up on the Wikipedia web site. However, be careful, while the definitions of the acronyms is defined correctly, the web site posting is confused and does exactly what was discussed in a previous post about mixing up the differences between goals and objectives. The web site begins speaking about setting SMART objectives and then in a subsequent paragraph it fluidly begins discussing SMART goals as if goals and objectives are the same thing.

As we know, goals and objectives are different in their makeup and application, and thus posses different levels of these characteristics. While it appears that the SMART characteristics can apply to both, the application of these is best applied towards goals and not objectives. The reasoning behind this is that goals are horizons and thus need to be specific, measurable, attainable, relevant (I use the term realistic), and timely. Objectives must, by their very nature of being the “how to obtain a goal,” are already SMART since one cannot express the how of an accomplishment without many of these characteristics. It is the definition of SMART goals that alludes many organizations.

There are other “googlized” searches on goals and objectives where many say that goals cannot be measured or are not to be specific. Goals need to be SMART or they are of little value. Many times I have had to discuss this point with the Senior Leadership Team (SLT) members of my clients when I find their goals to be such trivia such as:

  • We want to the best in category,
  • We want to beat our competition,
  • We want to increase market share,
  • We want to be more profitable,
  • We want to have more clients,
  • We want……

you get the picture. These goals are simply mush and fluff. Goal setting by those that are successful are specific. For example, setting a goal to be in Vienna, Austria is not mushy or fluff. It is very specific, it can be measured since one would know if they are in Vienna or not. It is attainable, realistic, and by the setting of a time frame, can be timely. So please excuse the mush that passes for knowledge on the Internet sites, and think about the value of setting SMART goals versus the mushy and fluffy ones you have probably seen being passed off as viable goals.

Without goals for each period of the PPPM roadmap, the PPPM vision has very little chance of being successfully implemented. It is the goals of each period that when paired with the period’s other components that breaks the overall vision into obtainable “chucks of action.” Each period’s goals should be also compared in one other characteristic: compatibility. The goals of each period must provide a link from one to the other and without being compatible, this is not possible.

We have finally completed the entire discussion of the PPPM roadmap components for implementing your organization’s PPPM vision. We will “gift wrap” the concepts in the next post by detailing all the linkages between the roadmap components.