The Skilled PM: What Makes a Skilled PM?

by PH Lohnes, PMP

Before delving into the basis for decision making biases as we alluded to in last issue’s inaugural piece on “The Well-Skilled PM,” the understanding of just what constitutes a skilled project manager is an necessary first step. In this article we will attempt to describe the trappings or characteristics of a well-skilled PM to assist in answering the question for your own determination.

According to the PMI’s own records there are approximately 500,000 certified project managers – a 100 fold increase over the past two decades. So as in any growing, dynamic population, how does one stand out in order to be the spearhead of one’s professional discipline?

Having spoken with, interviewed or observed well-over a 1000 of the 500,000 PMPs over the past decade, there are certain common characteristics of the top performers that can be defined. These common characteristics are:

  • Self-evaluative,
  • Self-corrective,
  • Self-innovative,   and
  • Self-expansive

The first characteristic of a well-skilled PM is that of being self-evaluative. This is the ability to evaluate one’s position, current skills, capabilities, accomplishments, knowledge, and career goals objectively against an articulated career baseline. Yes, planning one’s career as one would a project is not narcissistic; it is simply an application of sound logic and resource allocation. However, being objective about one’s future career is tougher than might be expected. A future discussion on decision making based on political biases will assist in understanding this difficulty.

A second characteristic of a well-skilled PM is the ability, closely aligned with the first, to be self-corrective. This is the ability when career performance is compared to the previously defined career baseline to take remedial action to adjust identified plan deviations. Many professionals lacking this ability can see their career for what it is (self-evaluative), but lack the objectivity to determine that if has deviated from plan. More likely they are willing to make excuses for why they are not progressing at the rate or in the desired direction. They are liable to blame others or circumstances out of their control.

Thirdly, well skilled PMs are self-innovative. This is the ability to use current skills, knowledge, capabilities, and focus to improve the status of one’s professional career. Technologists can tell you specifically when something is outdated or innovative by how it relates to the current known maturity of a specific technological discipline. Well-skilled PMs are no different in that they can tell you when their skills, knowledge, and capabilities are dated, but they do not stop with this assessment. Using their current abilities and creativity, they build on or add to them thereby improving their rate of career achievements or the quality of current assignments. They do not continue to do the same safe, tried-and-true activities expecting their career to magically blossom.

Finally, a well-skilled PM is self-expansive. In similar fashion to a project that experiences an increase in scope which requires change and impact analysis, a well-skilled PM can see the need to alter their original programming as the circumstances of their professional career offer them opportunities. This could mean a completely different course of direction, new goals, or different timelines. Examples of being self-expansive would include the decision to quit working as an employee, and begin seeking work as an independent agent or contractor; starting a new business or venture to fill an exposed need in a chosen industry or field; changing professions altogether such as taking up an academic career or starting a new career.

As in all professions, most participants remain in the “large area under the curve” or the mediocrity bubble not caring to move outside this comfort zone. The well-skilled PM is one that knows to improve oneself will improve their discipline and the impact they will have. Sitting safe does preserve one’s existence, but what horizons would have been lost if the first risk-takers had never sought to see what lay over the next hill or obstacle?

Are you a well-skilled PM? Have you been “coasting or taking it easy?” Have you wished that you could step out, take a few risks, seek to improve yourself, or your knowledge? The Well-Skilled PM each month will attempt to assist you with finding answers to these questions, and maybe help with rekindling your desire to become more than just what can be settled for…

DCPM: Use of Concurrent Scenario Approach (CSA)

by PH Lohnes, PMP

One of the ideas that has finally begun to gain ground on the fringes of the project management discipline is the failure of the phased approach to solve project issues in producing “fit-for-use” deliverables. The phased approach is such an ingrained part of project management bodies of knowledge that when I speak of this to project managers they look at me like I have two heads!

What I mean by the phased approach is that one collection of similar activities are completed and then a review or gateway is reached, permission is given to proceed, and then the next phase is commenced. Now most think of this as waterfall and not applicable to the new Agile-form of software development, but I need to bust your bubble in that Agile type project development formats are simply very small waterfall cycles. Instead of taking 6-18 months as in most waterfall approaches, Agile breaks the cycles into smaller 2, 4, or 8 week cycles called sprints. However, each Sprint goes through the same “phases” from requirements, design, development, and testing prior to sprint delivery to the customer. The sprints are simply shorter, covering less work effort before delivering smaller units of work effort.

I know that this may be seen as abhorrent to many in the Agile community, but it’s the truth and needs to be understood since the same problems of using the phased approach yield similar issues in both the traditional waterfall methodologies as well as the Agile methodologies. The main difference is the amount time between the cycles and the production size of deliverables to the customer.

So what is the CSA? In the phased approach, a single solution is selected upon which the project then moves forward into design, development, and delivery of this chosen solution. This seems such a wonderful idea that it is almost heresy to even speak about its shortcomings in open forums; however, the definition of a project itself shows that single solution approaches (or pre-fix solutions as they are chosen before project planning) are futile in many cases.

A project has the following characteristics:

  • A definite timeframe for its completion,
  • Confined by primary constraints (scope, time, cost, quality, and risks), and
  • Production of unique, “fit-for-use” deliverables.

This definition is a more specific than most bodies of knowledge currently in use; however, it covers all the true and mature aspects of projects as they are implemented today. The characteristic that is left out from most lists today is the second one of being confined by the primary constraints. The PM discipline now realizes that all projects are bounded by these constraints, and the balancing of these constraints is an important function of all project managers (See the concept of Deliverables-Center Project Management).

By exhibiting these characteristics, projects can be differentiated from operations which exhibit an on-going nature that produce common, and well-understood products or services. An example would be the production of a specific truck model from the Ford assembly plant in Dearborn, MI. Operations and projects are the two major activities that businesses engage in to accomplish their mission or vision profiles.

This seems a long route to address the CSA concept for projects; however, think about what a phased approach to project planning and execution means? Think about the last project you worked on and how the project had to define, cost, schedule, and execute a single solution approach. If you submitted a project business case that provided for a “trial and error” or multiple-scenario approach in order to decide on a development approach, you would have been ridiculed or even laughed at (I know from personal experience) for not coming up a defined solution that matches the requirements of the project’s business case. Is not this the reason for having business analysts on the project? Is this not the reason for all the requirements definition and mapping?

NO! Please explain to me how a set of activities that is to produce a unique set of deliverables would categorically know at the beginning of the project how to solve the production of these unique deliverables? One of the reasons for such dismal project success rates, in my opinion, is that project managers are required to submit a single, phased-approach to the solution of a project that has never been accomplished before this one. Being forced to settle on a pre-selected solution drives the project down a road that may, and usually does not given the current project failure rate, not produce the desired results.

Why cannot the project management discipline accept that a project needs to have the flexibility to investigate with actual resources, budget, and schedule the possible alternatives to the production of “fit-for-use” deliverables? The most often given answer is: COST!! However, please consider the cost of almost 2/3 of all projects that fail to meet their deliverables on either a budget or schedule basis. Would it not make sense to spend a few resources on finding the more appropriate solution as to one that we can only guess may be the right solution?

I caution you to use these ideas carefully. If you do not believe me, try suggesting this approach to the selection of a project solution at your next project kick off meeting and see how quiet and cold the room becomes at even the mention of this approach?

Where was the Ethics?: Cheating Scandal Proves Good Example of Compliance Hot Spot.

by Cheryl Wilson PMP, PMI-RMP, CCEP

Earlier this month 35 teachers, administrators and a superintendent in the Atlanta Public school system turned themselves in to the police.  The teachers were accused of erasing and changing standardized test answers to improve scores.  The motive was said to be federal funding and teacher bonuses for elevated student testing scores.

As the Project Post-Gazette lays out the framework for implementing a Compliance and Ethics (C&E) Program within organizations in this issue, one of the first areas in implementing a framework for a solid C&E program is starting with a risk assessment to determine hot spots for possible wrongdoing in the environment.

As the plot unfolded, it was clear the basics for a C&E program were not put into place in the Atlantic public school system.  Well educated people fell under the spell of gain faced with the temptation of defrauding a system that was without a system to 1) Prevent wrong doing and 2) Detect wrong doing.

The teachers and administrators involved including a former Atlanta School Superintendent were caught due to the simple application of mathematical analysis when a local newspaper suggested that the recent increases in student test scores were statistically improbable. As the investigative reporting uncovered the scandal that went all the way to the top of the Atlanta Public School System, the outcome of the cheating scandal was revealed that the improved scores provided several school system administrators with additional bonuses and funds. For one of the administrator’s involvement in the scandal, she could be facing a total of 40 years if convicted on all counts.

Were the monies received worth the now possible jail time, and the tarnishing of a public school system official’s over 20 year long career? A sound compliance and ethics program could have provided the education and controls necessary to possibly prevent this scandal; however, this fact will never be known given that the scandal is a reality and under investigation.

After being caught, and too late, C&E steps are now being put into place in this school system:

1) Mandatory Annual Ethics Training

2) Testing Protocols

3) Triggers for possible Fraud

4) Ethics Expectations

One would now expect to see a causal link between the offering of bonuses and the possible temptation to manipulate the system in order to maximize the bonus schedule. While these may seem to be a bit far-fetched at first, once such a scandal has occurred many look back and ask, “why was not the link or possibility considered?” These are the basis for a sound C&E program where causal links can be investigated without the casting of blame or indication of wrong-doing without evidence.

Scheduling Standards – Good Scheduling Practices

by Barry E. Clark, PMP, PMI-SP

For the novice – and not so novice scheduler, creating a dynamic, logical, and accurate schedule can be a daunting task. Having in your tool-kit and adhering to a ‘good scheduling practices checklist’ is essential in achieving that goal.  Project managers demand and expect accurate schedules that gives them confidence in using it as one of their chief management tools.  Professional, well-structured schedules just do not happen by accident.   Here are some of the governing principles/ standards that can guide you in what to do/ what not do when creating a project schedule.

  • Schedule should map to the WBS, which defines the project’s scope
  • Tasks should have a verb in the task name
  • Task Duration:  Assigned duration should be consistent with the work/scope required to complete the task
  • Long durations on discrete tasks should be avoided.  Generally no longer than 2 months
  • Constraints:  Constraints fine-­tune a logic-driven schedule by establishing date restrictions based on factors such as component delivery, near term resource availability, or contractual obligations.
  • Soft constraints such as Start-No-Earlier-Than and Finish-No-Earlier-Than enable the schedule to be logic-driven.  If there is a logical reason/ justification for using a constraint, it should be documented
  • Use of hard constraints such as Must-Finish-On, Must-Start-On, Start-No-Later-Than, & Finish-No-Later-Than prevents tasks from being dynamically adjusted by their dependencies (predecessors/ successors)/ network, thus preventing the schedule from being logic-driven.  Hard constraints should therefore be avoided
  • All schedule tasks, except the first and last, should be linked (at least one predecessor and one successor), creating the schedule ‘network’ which shows logical dependencies.  Missing predecessors/ successors will skew the networked logic, creating erroneous forecast dates, and an inaccurate critical path (CP). Project managers and SMEs/ technical leads need to verify the accuracy of the network. Relationship types: There are four scheduling relationship types used for linking: Finish-to-Start (FS), Finish-to-Finish (FF), Start-to-Start (SS) and Start-to-Finish (SF)
  • Schedules should be structured with predominantly Finish-to-Start (FS) relationships. (95% recommended)
  • Start-to-Finish (SF) relationship type is counter-intuitive (“the successor cannot finish until the predecessor starts” – huh?) and should only rarely be used and with detailed justification
  • Lags and Leads:  A lag is a delay in the start of a successor task; leads are the opposite – they accelerate the start of the successor.  Lags and leads should be used sparingly.  Leads are illogical and should be avoided.  If a ‘lead’ is absolutely necessary, changing the relationship type to SS with a lag is recommended.  Use of lags should be documented.
  • Summary Tasks:  Summary tasks should not be linked and should not have resources assigned to them.  Linking summaries causes errors in the schedule network and dates by preventing the start of other summary groups until all sub-tasks are completed.  Summaries are just that – they are intended to only provide a calculated rollup of the subtasks and linking summaries skews the summary % complete calculation.
  • Level of effort (LOE) tasks that continue for the life of the schedule should have durations less than the overall duration of the total program to ensure they do not fall on the critical path (CP).
  • Schedule structure: Horizontal Integration – shows work is planned in a logical sequence considering interdependencies; work and planning packages.  It ensures the overall schedule is logical and depicts schedule dependencies, etc. within the same scheduling level.
  • Schedule Structure: Vertical Integration – Shows consistency between various scheduling levels and consistency between various WBS elements in the schedule.

There is a wealth of information on scheduling practices, techniques, standards, etc. that can be quickly found, including PMI Community of Practice, Microsoft Project Users Group (MPUG), LinkedIn scheduling/PM groups, Project Management blogs, webinars, seminars, and the like.   Quick internet searches should get you 95% or more of what you’re looking for when developing your schedule.  Remember: a good schedule needs to be accurate in scope definition, dynamic in structure, and realistic.

Implementing a Proactive Risk Program: Establishing a Collaborative Environment

by Cheryl Wilson PMP, PMI-RMP, CCEP

As the first article in this series indicated, a top down approach as opposed to a bottom up approach will provide a solid basis for a success risk environment.  This approach has 4 major steps:

  1. Establish a solid risk management process from the project initiation
  2. Discuss and reassess risk management often
  3. Establish a collaborative environment
  4. Ensure risks are documented as one of the five project constraints

It is now time to focus on the third step of this top-down approach:  Establishing a Collaborative Environment. If your risk environment is established at the start of your project, the teams work collaboratively, processes are well communicated, resources are used wisely, the project team can address the risks that are truly affecting the deliverables and objectives.

A structured and collaborative risk environment from the start will encourage proactive communications. This environment should specifically aim to increase the success of the project team. Tools to improve the performance and effectiveness of our projects can include established reoccurring risk meetings, well established and communicated risk processes, consistent reporting and solid metrics showing risk status.

Risk communication lies at the center of any collaborative risk environment to ensure all stakeholders know how to identify a risk, update a risk, escalate a risk and identify a triggered risk. Without effective communications, no risk management approach can be viable.

In order to be analyzed and managed correctly, risks must be communicated to and between the projects within the portfolio. Communications must also provide information flow between the project and organization, to all stakeholders, and most especially to upper management.

Because communication needs to be pervasive, risk activities should be detailed in the Project’s Communications Plan. If the project is a large or complex, it is recommended that the Project Manager write a separate Risk Management Plan to detail the risk environment. The last article, “Discuss and Reassess Risk Management Often” discussed a detailed framework that should be in every risk program.  In addition to the framework, how often the team should meet to discuss the risks, what reporting will be available to track the risks and what the roles and responsibilities are for each team member? These are all additional areas able to increase project success.

Risk Meetings:  Risk discussion should be an agenda item in team meetings. The duration and how often should be determined by the complexity and size of the project, but risk discussions should be done at least once a week.  Projects where the risk program is managed by the Project Manager and never discussed with the team will show signs of failure quickly as there will risks that are never identified.  Projects that put the risk management on the shoulders of a risk analyst to manage will also show signs of failure as the management of each risk is not with the person that is most capable of mitigating that risk.

As a rule of thumb, here is a simple guide to follow when deciding how often risks should be addressed:

  • High Risks:  At least weekly
  • Medium Risks: At least bi-weekly
  • Low Risks:  At least Monthly
  • Issues:  Daily*

*Triggers are critical to determine if a risk has changed from a future uncertain event to a certain real time event.  Triggered risks should be responded to immediately.  Contingency plans for your high risks should be reviewed to determine if they are still viable or if a new response plan should be effected.

Stakeholder Roles and Responsibilities: If stakeholders know their role and responsibility in the risk process, and manage risks they have responsibility for, the success rate for projects increase.  Too many times, the risk process is done by one person in a vacuum void of key people that came provide valuable key information.

Key roles and their responsibilities within the risk framework:

  • Project Manager (PM): Overall responsible person for the project therefore has overight responsibility for each risk.  The PM is responsible to ensure risks are discussed at project meetings, triggers are in place and risks are monitored. The PM should assign risk owners to each risk to further develop mitigation plans and identify triggers.  The PM has the ultimate responsibility to approve new risks and close those eliminated.
  • Risk Owners (RO): Accountable for managing the analysis of assigned risks.  ROs are accountable for the preliminary risk mitigation plan, or the preliminary issue response plan.  They should ensure all risks and issues are added to the risk register and that it is maintained and updated.  During team meetings, the RO should update the team on their assigned risks.  The RO should be a Subject Matter Expert (SME) on their assigned risks.
  • Risk Action Owners (RAO): The RAO is the person the RO feels is the most qualified to implement the chosen strategy to mitigate the risk. For their assigned risks and issues, they should assist the RO in maintaining and upgrading these assignments.
  • Team Members: All team members have a responsibility to identify risk potentials and bring these risk potentials to the PM’s attention.  All risk potentials should be considered.
  • Risk Source:  The person who identified the risk

Clear, Communicated Processes: Processes for how to identify a risk, how to escalate a risk, how to identify triggered risks and assess a risk should all be clear and communicated to the entire team.  When a team knows how or where to initiate a risk discussion this helps to mature the risk environment of the project.

Reporting and Metrics: The risk program is not static.  Risks identified at the beginning of the project should not be the only risks in the risk register with no progress towards mitigation of these risks.  Reporting should show ALL changes to the risk environment.  Consistent reports will allow the project manager and the team to understand the risk environment and the critical changes needed.  The trigger report will show risks that are liable to become issues thus allowing time to respond if needed.

Suggested reports include:

  • Risk Ownership Report/Risk Action Ownership Report
  • Aging Issue Report
  • High Risk Report
  • Triggers Report
  • New Risks Report
  • Net Risk Index Change Report

The Project Whisperer: How to Spot a Troubled Project Before…

by PH Lohnes, PMP

Dealing with troubled projects is indeed a noble and necessary pursuit in the project management discipline; however, more important is the ability to spot the precursors that a project exhibits that may lead to the eventuality of it becoming distressed. Can one review a project and discover these markers? Are there markers in the first place?

The resounding answer is YES! Speaking with many trouble project managers as well as drawing on personal experience, there are four common characteristics that most of the “off the track” projects seem to exhibit. These four tracers, as they can be considered, are:

  1. Lack of objectivity
  2. Lack of discipline
  3. Lack of transparency, and
  4. Lack of experience

A most significant point to understand is a combinatorial principle, paraphrased for our purposes, that the existence of one of the above tracers in a project does not mean the project will become problematic. However, a significant number of troubled projects exhibit most if not all of the tracers. So if we know the markers that show up in projects that are troubled, can we derive useful managerial information from these markers appearing in yet to be troubled projects?

Again, the resounding answer is YES! The whole purpose of project management is to manage the future activities of a coordinated network of interrelated tasks oriented towards a common goal. So if as a project manager, one begins to see the emergence of tracers that distressed projects exhibit, the logical course of action would be to determine the root cause of the tracer and prune it.

What are these precursors? Do they have physical manifestations? How can they be identified? Let’s take these questions in order, briefly in this article, and in more detail in subsequent issues.

Precursor #1: Lack of Objectivity

This can also be referred to as “project personalization.” This precursor occurs when team members, and most importantly, component managers such as leads and subject matter experts (SME) become personally or emotionally invested in the success of the project. This begins the process of project protection which usually leads to the blurring of objectivity.

Precursor #2: Lack of Discipline

One of the most common characteristics of failed projects was an exhibition of a low level of professionalism or discipline to adherence of industries standard practices. Inconsistent behavior in dealing with risks, issues, and problems is a manifestation of this precursor. This is referred to as “professional lethargy.” There are others which will be discussed in more detail.

Precursor #3: Lack of Transparency

By definition projects need to be open, forthcoming, and accurate about their status, performance, and progress. The hiding or obfuscation of project data cannot be tolerated for long since every project has a finite lifetime upon which its conclusion will reveal all problems and issues. Problems cannot be masked forever. As project team members become less transparent, the full data needed to make decisions on the project’s future cannot be considered reliable. This is referred to as “project fog.”

Precursor #4: Lack of Experience

In a previous issue of the Project Post-Gazette, this concept of siphoning off project management experience in order staff program and portfolio levels has been addressed. The reader is directly to the February 2013 Issue <link here>, The PPPM Roadmap column, to read about this precursor in more detail; however, suffice it to say, that most troubled projects are not staffed by highly experienced, well-skilled practitioners. These professionals or sometimes the sources of the project’s problems have left well before the project deteriorated being replaced with less experienced less well-healed individuals. This is NOT an indictment of all projects or programs or their mangers, just a simple observation.

Each of the next four articles in this series will deal with the four precursors, their sources, manifestations, and some solutions to their occurrences. While knowing how to handle troubled projects, an aggressive project whisperer should also know how to prevent them from becoming problematic initially. Remember, the old adage – “a risk in time, saves $2 million in public relations.”

PMBOK® Guide, 5th Edition, Review: Standardization of the AOK Structure

by PH Lohnes, PMP

We have discussed some of the major changes to the PMBOK® Guide with the 5th Edition’s release in previous columns. To begin, all the Process Group and Areas of Knowledge names stayed the same from the fourth edition to the fifth edition. However, in the first AOK, Project Integration Management, the processes are the same with the exception of Process 4.3 where in the fifth edition the word “execution” was changed to “work.” This paralleled the use of the word “work” in Process 4.4 making the fifth edition more consistent in its wording.

Next, let us dispense with the Area of Knowledge that did not change in the numbering, naming, or ordering of its contents: the Project Integration Management. We will cover the internal changes to the Project Integration Management AOK later, but they are minor.

What the 5th Edition did standardize was the processes for most of the remaining AOKs to use the plan – control model. Each of the remaining AOKs with the exception of Project HR Management (go figure) was standardized on the Plan – other processes – Control process structure. In some cases this required the addition of a new “Plan” process, and in others it mandated a “Control” process. We will list the changes for the Scope / Time / Cost AOKs this month, and then the rest in subsequent issues.

 

In Table 1 below is a summary of these standardization changes for Scope / Time / Cost:

 

AOK / Process PMBOK® Guide 4th Edition PMBOK® Guide 5th Edition
5. Scope <no process> 5.1 Plan Scope Management
5.1 Collect Requirements 5.2 Collect Requirements
5.2 Define Scope 5.3 Define Scope
5.3 Create WBS 5.4 Create WBS
5.4 Verify Scope 5.5 Validate Scope
5.5 Control Scope 5.6 Control Scope
6. Time <no process> 6.1 Plan Schedule Management
6.1 Define Activities 6.2 Define Activities
6.2 Sequence Activities 6.3 Sequence Activities
6.3 Estimate Activity Resources 6.4 Estimate Activity Resources
6.4 Estimate Activity Durations 6.5 Estimate Activity Durations
6.5 Develop Schedule 6.6 Develop Schedule
6.6 Control Schedule 6.7 Control Schedule
7. Cost <no process> 7.1 Plan Cost Management
7.1 Estimate Costs 7.2 Estimate Costs
7.2 Determine Budget 7.3 Determine Budget
7.3 Control Costs 7.4 Control Costs

From the included table, it is evident that the above three AOKs were standardized with the addition of the “Plan AOK Management” process – one of the main reasons for the increase of processes in the 5th Edition from 42 to 47.

 

The only other change in the process stack for these AOKs was the change of the 5.4 / 5.5 Process: Verify Scope to Validate Scope. The PMBOK® Guide project team modified this verb to the correct use of the activity since one cannot validate without the WBS being in existence whle one verifies before creating; their use is now correct.

 

Finally, there is much going around about the PMBOK® Guide 5th Edition now being in compliance with the DIKW (data, information, knowledge, wisdom) model of knowledge management. In the opinion of this author, this is another attempt to obfuscate and increase the liturgy of the project management body of knowledge currently making the art of project management more difficult to understand and even more difficult to implement.

 

Remember, Occam’s Razor (Google/Bing it): Keep it Simple!

The PPPM Roadmap: What is a Deliverable-Centered PM?

By PH Lohnes, PMP

While many project managers (PM) know that a project has deliverables, many do not understand their importance and central preeminence. Deliverables are the only reason for a project to be chartered or brought into existence. Without deliverables, there is no project – it is that simple.

Therefore, since project deliverables are the reason for projects in the first place, how is it that some project teams do not know what are the deliverables of the project to which they are assigned? The PM is the lead on each project, and he/she must demand that every team member know definitely what the deliverables are that will direct their time and effort on the project. The first action taken when a project is in trouble, and a project whisperer is called in, should be to discover and understand the project’s deliverables. In many cases, the team members and even the PM cannot articulate the deliverables and their “fit-for-use” performance metrics.

While this may sound somewhat odd, many of us at the Post-Gazette have experienced this precise condition when being called in to support a troubled or soon-to-be troubled project. So getting back to the point of the article, what is a deliverables-centered PM? And what are these “fit-for-use” metrics or performance measurements so often bespoken of at the Post-Gazette?

The first question needs to give way to the second since understanding what “fit-for-use” means is just as important as knowing what your deliverables are for each project. So, “fit-for-use” is the condition or status of the project deliverables whereupon the customer, client, or business sponsor is willing to sign off on the completion of the project’s activities as having produced the deliverables of value to their (the customer, client, or sponsor) business purposes. In other words, “fit-for-use” deliverables are outcomes that can be immediately and purposefully put to valuable utilization in the satisfaction of the project’s business case.

What this means in clear and concise words is that “fit-for-use” deliverables are:

  1. Defined by the customer, client, or business sponsor,
  2. The purpose for which the project is instantiated, and
  3. The business baseline against which the project is compared and measured for success.

Therefore, if you have not already figured it out, the definition of “fit-for-use” deliverables is the specification of quality to which the project outcomes must adhere! “Fit-for-use” is the precise definition of project deliverable quality – nothing more, and nothing less.

While this flies in the face of all the Six Sigma, Lean, and other types of very complex quality definitions and machinations, for a project, this definition of quality is all there needs to be. The customer who pays for the project’s budget defines what they are expecting, at what status of completion, and the value or “fit-for-use” condition which will meet their needs. This should make perfect sense in that if the project is on-time, and on-budget, but fails to produce “fit-for-use” deliverables, it is a failed project while going over-budget, or behind schedule is problematic, but producing “fit-for-use” deliverables could, I say could, render the project a success in the eyes of the only person that matters – the customer.

So what does it mean to be a Deliverables-Centered PM? This question should begin to make sense now that the concept of “fit-for-use” deliverables has been conquered. A Deliverables-Centered PM is one that ensures every action, activity or task is one that moves the project closer to the production of the defined “fit-for-use” deliverables as specified by the customer.

This produces a very stark and rigid code, but one that can mean the difference between just managing an unrelated stream of activities and tasks day after day, and truly understanding the purpose for each action that you take as a PM is for the sole purpose of increasing the probability towards producing deliverables accepted to the customer.

To be specific, every artifact or action from the WBS work packages, to the plans, to the tasks, activities, meetings, reports, audits, gateway reviews, schedules, executions, monitoring, and remediation is undertaken purposefully towards the production of “fit-for-use” deliverables. Each planning item has to therefore be tied back to a specifically identified project deliverable: each WBS work package, each risk, issue, each requirement, each task, each control action, everything and this means EVERYTHING must be tied back to a specific deliverable for the entire life cycle of the project.

Deliverable-Centered Project Management (DCPM) is not just a nice sounding idea or concept, it is a powerful project management philosophy or mindset as we call it at the Post-Gazette and MCLMG. We created this concept when many of our potential clients were floundering in a sea of poor project successes floating on the raft of over-detailed MS Project schedules without even having the map of a sound WBS. This sounds like a cliché, but it is so true for so many project executing firms and government agencies. The current liturgy of the project management discipline has become so complex, so convoluted, so over-governed, and weighed down with increasing regulations and processes, that the simple truth of project management has gotten lost, which is:

The sole purpose of any project, and that means any project regardless of size or complexity, is the production of “fit-for-use” deliverables within the time, cost, quality, and risk constraints of the instantiated project.

Anything beyond the production of such outcomes is truly off-point or “out-of-scope” as it is called in the project management world. For example, while the use of earned value management (EVM) concepts has all the right intentions, if it detracts from the production of “fit-for-use” deliverables then its use is counterproductive to the success of the project. Nothing is as sacred in project management as the production of the project’s deliverables. Nothing!

While this article may appear at first to be a tirade against the current project management status quo, nothing could be closer to the truth. It is! The rank and file project managers need to take back their profession and discipline, reduce the complexity imposed by self-aggrandizing so-called standards bodies both in the US and European Union, and return to the basics of sound project management whereby the deliverables are the only important focus and measurement yardstick for project success.

Just because an organization produces a series of books called standards, or produces a program of minimum knowledge certification, it cannot be granted the sole purveyor of a discipline’s body of knowledge. There is no such thing as “best practices,” only “your practices” that should be based on experienced successful production of “fit-for-use” deliverables.

Moving back to the basics of simple project management will reduce your stress, increase your success rates, and make life more enjoyable as a project manager. Come back in May and June when we at the Project Post-Gazette really stir up the pot with discussions on why the project management discipline is in need of life support and resuscitation.

Implementing a Corporate Compliance and Ethics Program: What are the Federal Sentencing Guidelines?

by Cheryl Wilson, PMP, PMI-RMP, CCEP

Organizations today are finding increasing evidence for the need to establish some level of a formal “compliance and ethics program.”  Not only will a compliance program increase how the organization is viewed both internally by its employees but it will show to external potential clients, government agencies, and regulatory bodies that an organization is serious about their ethical, legal and fiduciary responsibilities and obligations.

Last month the Post-Gazette Compliance Central told the story of how the Security & Exchange Commission (SEC) and the Department of Justice (DOJ) settled parallel criminal and civil enforcement actions against the Titan Corporation (“Titan”) under the Foreign Corrupt Practices Act (“FCPA”) leading to a $28.5 million fine and a government mandate to establish a compliance and ethics program.  Once L-3 bought Titan, they inherited this government mandated direction which formed the basis of L-3’s current Compliance and Ethics Program.

Over the next several issues of the Post-Gazette, the Compliance Central articles will cover:

  • What are the Federal Sentencing Guidelines?
  • Proposed Corporate Compliance and Ethics (C&E) Framework
  • Initial Risk Assessment to Improve your Corporate Compliance Program

The Titan Corporation was not alone, but was one of many organizations where their misconduct promulgated unethical actions leading to the increased levels of public and regulatory scrutiny of corporate governance.   This misconduct led to additional government regulators, more regulatory and sub-regulatory guidance documents, management standards, and best practice recommendations.

The Federal Sentencing Guidelines (created by the Sentencing Reform Act of 1982) are a uniform set of rules from the United States Sentencing Commission that set a sentencing or remediation policy to be implemented by organizations (and individuals) if they are convicted of serious wrong doing by the government. The US Sentencing Commission reviewed numerous crimes and developed the framework for determining the initial set of sentencing guidelines.  The guidelines and policy statements in “Chapter 8 of the Federal Sentencing Guidelines” apply to an organization convicted of wrongdoing, in addition to detailing how an organization should set up an effective compliance and ethics framework.

Once an organization makes the decision or is mandated by the government to implement a compliance program, the organization will need to determine what the program will look like, how it will function, and how it will be managed.  The organization must also decide about the intended purpose, goal, scope, and the cost of the program as well as the location of the compliance function. Compliance officials, within the pre-existing organizational structure must identified and prepared for duty. While answers to many of these questions may vary from organization to organization, the basic elements essential to a successful compliance program lie in these Sentencing Guidelines.

Opportunity Risk? Is there such a thing? How do you fit Opportunities into your Risk Framework?

by Cheryl Wilson PMP, PMI-RMP, CCEP

What exactly is an “Opportunity Risk?” and can you fit the managing of opportunities in your risk framework?  The definition of an “opportunity risk” varies across the board and is actually very confusing.  This confusion is based on the fact that opportunities are not really risks at all, but positive potential events on our project or in our organizations.  So, I propose if you are going to track opportunities, just call them opportunities!

We know risk is an uncertain future event.  As Project managers or Risk Managers, we are managing the probability or impact of these uncertain future events.  Our goal is to reduce the probability or impact by strong mitigation strategies, and to avoid the risk from triggering into an issue.   CPJ Stoneman has said often, “It is better to mitigate a risk than to attempt to survive an issue.”

So what do we do with these opportunities and how do we track them in our Risk Framework?  I have often been asked this question.   Opportunities as they present themselves could still be uncertain future events but should not be tracked under the same parameters as risks. Also note that some opportunities can actually increase our risks if we pursue them.

If a project team is going to track opportunities, the assessment will be to monitor the Probability and Gain (instead of impact) and manage not mitigate by:

Capture:   Align the opportunity to the project objectives, assign to appropriate stakeholder(s) to track the probability and gain. (Internal opportunities)

Transfer:  Transfer the possible opportunity to senior management or business development team to make the decision to pursue. (External opportunities)

Ignore:      Pass on the opportunity

Share:       Finding a partner either internally or externally to assist us in exploiting the opportunity.

As opportunities can take the project off track of the original deliverables, a clear risk and opportunity management process should be communicated to the project team.   Opportunity Management is an approach to business development and should be aligned with the organization’s strategic goals.  So the caution is to understand project management as the planning and managing of a unique time based set of activities, while opportunity management is more in alignment with the organizations business needs outside of a specific unique time frame.