The Tailoring Rule

"Professionalism is knowing how to do it, when to do it, and doing it.”

                                                                                                - Frank Tyger

When people choose to complain about project management, one frequent refrain is the burden and overhead of all that process.  (I believe this is often a red herring, used by detractors who are concerned that project management best practices will expose their delivery weaknesses, but today’s discussion is to address the valid concerns for appropriate levels of process.)

A typical organization does many different types of projects of different sizes, styles and complexity.  For example, an IT department might have projects for:

• Infrastructure
• New software development
• Enhancement and maintenance
• Product selection, acquisition and installation

Since all projects, regardless of size, style or complexity have many common elements necessary for success, does that mean that the organization only needs one methodology?  Well, yes.  And no.

If the organization has one bloated methodology dictating that all projects must produce all deliverables from identical templates, then those people who complain about too much process have a (partially) legitimate complaint.  It’s legitimate because for most projects there will be too much process, but they are complaining about the wrong thing.

However, there are so many common and essential elements for project success that no organization wants to manage multiple (many?  dozens?) of different, but similar processes.  How to resolve this contradiction?

Both SEI’s CMMI and PMI’s PMBOK® Guide provide for Tailoring.  Tailoring is an important but rarely formally practiced principle.  In fact, in all of my years of consulting across a broad range of companies, I’ve encountered numerous cases where formal practices are ignored or circumvented because they are too onerous or just irrelevant, but in only one case have I worked at an organization that formalized process tailoring.

Even the description in PMBoK does little to suggest that the organization should establish tailoring in the formal processes:  Initiation and Planning includes “guidelines and criteria for tailoring the organization’s set of standard processes and procedures to satisfy the specific needs of the project” (27).  This description makes it sound like tailoring should be done inside the project to customize the organization’s standards rather than that the organization’s standards should specify the tailoring appropriate to different projects.

For example, an IT software development project, an IT software implementation project, an IT infrastructure project and a business process redesign project all have many similarities on how they should be run (they should all have charters, business cases, status meetings, risk logs, change management, etc.), but also significant differences (a new software development project won’t need the RFP activities in the implementation project and the BPR project will need a host of training and documentation activities that will not be needed for a back-office infrastructure project that has no end-user visibility).

Further, for a sufficiently small project, the charter could be fully contained within an email and the change approval process will need to be sufficiently streamlined, since long decision timeframes would jeopardize the delivery of the project.  In contrast, a long, complex, risky project wouldn’t want to make change decisions too informally or too quickly.

The process burden needs to be appropriate to benefit the project – designating those best practices that best assure project success – while addressing project risk without over burdening the project.  A requirements document for a small project might be a few pages, whereas the requirements document for a large, complex project could be a tome, with sections and subsections for business requirements, functional requirements, technical requirements, non-functional requirements, etc.

One size does fit all in project management, as long as that one size addresses the principles of successful project management.  (Is that a tautology?)  Organizations with best practices are clear about what processes are required and how those processes are customized based on type of project, complexity, size, risk.

The mistake often implied by those that complain about excessive process is that the situation would be better if there were no process.  But processes evolved because lack of process (chaos) could not be relied on to consistently deliver successful projects, whereas the use of the processes improved the project success rate.  The solution to excessive process burden (or bad process, for that matter) is not eliminating process.  Rather, the solution is to fix the process through lessons learned and continuous process improvement.

Of course, organizations are even worse at lessons learned and process improvement than they are at projects.  Look for my eventual series on lessons learned to address just this subject.

© 2014 Chuck Morton.  All Rights Reserved.

Project Governance – Maturity Level V

"There is a universality to comedy.”
                                      - Simon Pegg

We have been building to this post for a while now.  This is the final installment of my series on project governance – or, more accurately, governance in the project context.  In the first post I introduced my arbitrary, tongue-in-cheek governance maturity level (gml).  Having covered all of the descriptions for project governance maturity up to this point, it is now time to reveal the ultimate state of governance of interest to project managers.

Historically, the highest level of governance is some variation on the theme of continuous improvement or optimizing, but I announced in my previous post that that was not the case for this maturity model.  And that post described the penultimate maturity level as alignment with organizational strategy, so what remains for the highest level of project governance maturity?

For strategic projects, there are really only three reasons that justify the project:  it increases revenue;  it reduces cost;  it is a regulatory requirement.  (Do you know of any other reasons that legitimately justify a strategic project?)  For most enterprises, what department has the highest stature?  Marketing?  HR?  Procurement?  FINANCE (hint hint)?  Of course it’s finance.  And it’s time finance started seeing projects as generating revenue or reducing expenses.

In May, Angelo Baratta presented a webinar for PMI’s Information Systems Community of Practice titled “The Value Triple Constraint: Project Value Left Behind” (PMI and ISCoP membership required).  In it, Baratta reminded us that projects have an economic benefit to the organization.  So often as project managers, we are focused on cost (along with time and scope) and leave benefit and value to the cost-benefit analysis or the charter – and to bean counters or stakeholders with “higher pay grade.”  But because there is this positive financial component, delays (among other choices) have a financial impact to the organization.

The highest level of project governance maturity, then, is when projects are recognized as enterprise assets.  Just like raw materials and capital investments, we (the PM community) should be lobbying to have our projects recognized as corporate assets.  This would immediately transition us to the big leagues.  Our babies would be elevated in stature within the corporate and political pecking order.  Project choices (delay, increase scope, cut scope, etc.) would have clear financial impact to the organization.  Getting resources, as Baratta noted in his presentation, would be straightforward to justify when the alternatives can be quantified.

Of course, these benefits don’t come without perils, but such is the consequence of maturity.  We will no longer be able to operate informally.  We will operate in the spotlight.  We will have to learn to speak “executive” (cut your vocabulary in half!).  Risk management will impact the corporate risk profile.  Governance in the project context will be integrated into the organization’s financial governance (think Sarbox).

One of the objectives of PMI is to have “Project Management” recognized as a discipline (or profession) distinct from “Management.”  A step in this direction is to elevate the governance maturity and to transition project delivery from a technical discipline to a financial discipline with direct consequence for the enterprise bottom line. 

From gml-I Chaos, gml-II Solution, gml-III Consultancy, and gml-IV Alignment, we have climbed the maturity staircase.  Getting to gml-V Capitalized is governance your CFO would recognize – the next stage in PMI maturity.

Has this journey been worth it?  What changes would you make to gml?  Or how would you define a project governance maturity model?

© 2013 Chuck Morton.  All Rights Reserved.

PM Journal – Risk in Complex Projects

Thamhain, Hans.  "Managing Risks in Complex Projects," Project ManagementJournal, April 2013 (Vol 44 #2), pp 20-35.

From discussions and networking with my peers and colleagues, I don’t think there are very many that read PM Journal.  I won’t suggest that’s a mistake because the applicability of the content varies – some articles are so academic and esoteric they are only of interest to the author’s mother, some are only applicable in narrow contexts, and some are a challenge to decipher.

In contrast, Hans Thamhain has written a very approachable and relevant article that I recommend to my readers (Yes, both of you).  He reports on the result of research on managing risk in complex projects (hence the title of his article).  Thamhain’s discussion of the current state of research and knowledge of risk in enterprise projects is both enlightening and disheartening:  “Predicting and controlling such [unknown] risks appears impossible with the existing organizational systems and management processes in place” (21) and “there is no framework currently available for handling risks that are either unknown or too dynamic to fit conventional management models” (22).  “…Many of the organizational tools and techniques that support early risk detection and management … readily exist in many organizations ….  Project managers, while actually using these project management tools and techniques extensively … do not give much credit to these operational systems for helping to deal with risks” (29).

The model he provides on pages 22-24 describing the three-dimensional relationship of risk characteristics (Uncertainty, Complexity and Impact) is easy to grasp and is probably valuable to introduce in your risk log for classifying risks.

Thamhain covers a variety of topics beneficial to PMs and, as the article’s title indicates, the focus is on the outsized consequences of risk effects that are not effectively managed.

I did find that since Thamhain shifts between discussing risks (a possible future event) and looking back after-the-fact to discuss the consequences, his terminology is sometimes confusing.  It’s like reading an article written by someone a few years in the future about something that for them happened a few months earlier.  They’re talking about something in their past that is still in my future.  I’ll offer a bit of guidance for readers of this article.  The word “contingency” appears throughout the article.  Late in the article he provides a couple of contextual definitions, undesirable events (29) and risk situations (30), which don’t help clarity.  However, from the article context it appears that he uses “risk” to refer to a future event and “contingency” to refer to a past event that was formerly a “risk.”  I would have used the term “risk event” to describe these, but I understand his difficulty.  The other confusion is the use of “issue.”  PM purists will no doubt object to Thamhain’s use of “risk issue,” but in context it translates to “the project issue that results from the occurrence of a risk event.”  I caution newbies to have a firm grasp on the distinctions between “risk” and “issue” before tackling this article.

One specific takeaway from the article that I want to share is worth noting by both PMs and managers.  PMs “blame project performance problems and failures predominantly on contingencies that originate outside their sphere of control … while senior management points directly at [PMs] for not managing effectively” (30).  Thamhain’s further commentary on this topic in the article should be read by both PMs and executives.  It probably deserves reworking for broader distribution, such as an article in PM Network.

For reference, my previous posts on project risk management:

·         The Project Manager’s Cycle – Review Risks & Mitigation Actions [Published:  03/06/2011]
·         The Schedule – Risk Buffers [Published:  12/28/2012]
·         Where to Find Risks  [Published:  03/20/2013]
·         Estimates, Schedules, Assumptions and Risks  [Published:  04/03/2013]

© 2013 Chuck Morton.  All Rights Reserved.

PM Network – 6 Rookie Mistakes

"You only get one rookie season.  So, I hate that we lost, but this was one of the best games I’ve ever played in.”
                                                                                                - Chris Paul

I’ve been reading the April issues of PM Network and PM Journal, two key PMI publications available to all PMI members.  I’m going to interrupt my regularly scheduling programming to comment on a couple of articles that I found noteworthy.

The first, “6 Rookie Mistakes,” is by Ashley G. Richardson and is in the April issue of PM Network starting on page 44.  (I’ll cover the other article in a subsequent post.)  PM Network is not exactly the reference for scholarly or deep content, but Richardson identifies a half-dozen truly devastating mistakes that can derail any project.  While she labels her list as rookie mistakes, I don’t believe any of these are limited to rookies, but any PM who makes one of these mistakes should be truly embarrassed.

I’ll tease you with a couple of quotes, but urge you to read the whole article.  “Sometimes managing the team’s personalities can be more challenging than dealing with the tasks – especially if a member unwilling to pull his or her own weight is dragging everyone else down.” (46)  “If your organization lacks a set of standards around risk, seek out others who have done similar projects within the organization or find a more seasoned professional willing to provide guidance.” (48)

The nature of my blog is such that it has been much more focused on the “hard” or “technical” side of PM skills rather than the “soft” skills (something that will eventually transition).  There are a lot of PM bloggers out there who provide good advice on soft skills;  I saw an opportunity to add content where there wasn’t as much commentary.   But the soft skills are generally much more visible, harder to master and weakness is more severely penalized, so every PM needs to master both types of skills.

One thing I would like to know, though I wouldn’t expect to find this in a PM Network article, is how Ms. Richardson arrived at this specific list of six mistakes, especially if there is research backing the importance of these in particular.

I won’t ask you to embarrass yourself by posting a comment of your own rookie mistake, so I’ll instead ask what rookie mistakes you’ve observed and what happened?

© 2013 Chuck Morton.  All Rights Reserved.

How Should Project Manager’s Be Measured?

"Being in power is like being a lady. If you have to tell people you are, you aren't”

                                                                                                - Margaret Thatcher

“How should I measure my PMs?” is a frequent question (in a number of variants) on various LinkedIn discussion boards.  The classical answer to this question, of course, is that the Project Manager is measured on their success at delivering the contracted/ chartered scope on time and within budget.  The practical answer is not so simple.

The traditional response is based on the purist PMI definition of a project and project manager:  a Sponsor funds a specific project (agreed-on scope, time and cost) and the PM has complete authority and autonomy to deliver the project.  In this scenario, it is proper to base the PM’s performance on those criteria.

I don’t know about you, but I’ve never worked on a project like that.  So let’s look at a couple of scenarios more consistent with what I’ve experienced.  In the first, the PM is assigned to a VP or senior manager and is their agent for delivering their project.  (From the purist PMI definition, the executive is the PM, but that’s not how it’s recognized in the industry.)  In this scenario, the PM is the agent of the executive;  the executive makes the strategic and significant controlling decisions;  the PM is responsible for tactical and operational delivery on behalf of the executive and for monitoring and reporting.  The key PM skill is proactive stakeholder communications.

This PM should not be measured on the traditional criteria:  they don’t have the authority to make significant or strategic resource reallocations to meet the project objectives.  However, this PM should be measured on the quality of the plan (relative to the organization’s delivery capability), the quality of the schedule, delivery to plan and frequency, appropriateness and quality of communications.  On this last point, communications, for example, the PM should be measured on how well they keep the stakeholders (particularly the executive) informed about variances from plan, but the PM should not be assessed on the magnitude of the variations, that there are variations or the response to the variations.

Another common scenario is that the PM is assigned to a PMO or that the organization has a formal, well-defined project delivery process.  In this scenario, the organization, not the PM, takes on the responsibility for delivering scope within time and cost by specifying the process.  In this scenario, the PM should be measured on adhering to the process, the quality of the deliverables and the contribution to improving the process.

There is an important lesson in this scenario:  if the PM follows the process and the project fails, the PM was successful;  if the PM doesn’t follow the process, regardless of whether the project is a success, the PM has failed.  This may sound heretical, but is the difference between how GM and Toyota manufacture cars.  For GM, delivering a car on schedule is paramount, regardless of the process disruption.  Thus, each car becomes a one-off craftsman product with inconsistent quality (results are not in statistical control and quality is tested in).  In contrast, for Toyota the process is paramount.  If the process is not working properly, they will stop the process until the problem is corrected.  That is a true assembly line and the product quality is consistent.

If your organization has a project delivery methodology, the only way to know if it works is to apply it absolutely and allow it to succeed or fail.  If it fails, then do the appropriate root cause analysis and problem resolution to improve the process.  Thus, a PM who shortchanges the process is not benefiting the long-term quality of the organization.

The bottom line is that the PM should be evaluated based on their performance within their span of control and to the organization’s delivery objectives.  Use of any other criteria creates dissonance between what you say you want and want you are rewarding the PM for.  To paraphrase Sgt. Esterhaus, “Let’s be consistent out there.”

What experience do you have with inconsistencies between the reality of what the PM does and how the PM is measured?

© 2013 Chuck Morton.  All Rights Reserved.

Project Management Research Topics

"Avant-garde music is sort of research music.  You’re glad someone’s done it but you don’t necessarily want to listen to it.”

                                                                                                - Brian Eno

I am a regular reader of the Project Management Journal and take a keen interest in the latest research on the project management profession.  While some of the content is abstrusely academic and some just doesn’t apply to me, it is rare that I don’t find several articles that interest me.

While I appreciate the research that Project Management Journal brings me, I am a practitioner, not a researcher.  That said, my experience affords me a direct exposure to anecdotal evidence of themes, patterns and practices relevant to our profession.  What I don’t know is whether these anecdotal observations are representative or outliers.

Therefore, I’ve reviewed all my posts and tagged a few with “Project Management Research” to indicate I’ve made an assertion in that post that would benefit from an objective application of the scientific method.  I thus invite and encourage any students looking for project management research topics to review these posts and conduct the appropriate research to (in)validate my premise.  I offer these topics freely.  I ask that you provide me with the published results.  I’ll post them here, supportive or non, with generous credit to you.

To get you started, here is a summary of all of the posts I’ve tagged and the outstanding research question in each.

A Philosophy of Projects and Products (Part 3 of 3)  [Published:  01/13/2011]

Hypothesis:  Consultancy PM environments can be distinguished from P&SD PM environments (core skill, priority, metrics, milestones vs deliverables, scope vs cost, domain knowledge vs monitor/ control, shared with support/ maintenance).

Hypothesis:  Consultancy PM organizations are more successful at delivering projects than P&SD PM organizations.

The Project Manager’s Cycle [Published:  01/31/2011]

Hypothesis:  That the activities documented constitute the Managing & Controlling cycle.

Hypothesis:  That PMs (or organizations) that follow these best practices are more successful at delivering projects.

The Project Manager’s Cycle – Redux  [Published:  12/31/2012]

Hypothesis:  That the activities documented constitute the Managing & Controlling cycle.

Hypothesis:  That PMs (or organizations) that follow these best practices are more successful at delivering projects.

Project Failures & The Chaos Reports [Published:  06/26/2011]

This post identifies a host of research opportunities:  distinguishing between success rates for professionally managed projects versus ad hoc managed projects;  perception of success vs failure by different stakeholders on the same project;  different “types” of project failure;  etc.

The Root Cause of IT Project Failure [Published:  07/04/2011]

Hypothesis:  Failure of novel projects is due to the project team committing to a schedule too soon.

Ode to ETC – The Task Overrun Early Warning System [Published:  10/04/2011]

Hypothesis:  That Estimate to Complete (ETC) is superior to Percent Complete for determining accurate project status and providing earlier indication of problems.

The Schedule – Basics [Published:  11/27/2012]

Hypothesis:  Organizations that well-formed schedules have superior project success rates than organizations that do not use these practices.

The Schedule – Risk Buffers [Published:  12/28/2012]

Hypothesis:  Organizations that apply quantitative risk analysis have superior project success rates than organizations that do not.

Estimate Confidence – A Demonstrative Example [Published:  03/02/2013]

Hypothesis:  That PERT practices for determining standard deviation are valid.

Hypothesis:  That schedules developed using PERT scheduling techniques more accurately reflect actual results than schedules developed from other techniques.

I look forward to learning about and learning from the research you conduct on any of these topics.  Further, I’m happy to assist you with defining and refining the research instruments.

© 2013 Chuck Morton.  All Rights Reserved.

Estimate Confidence – A Demonstrative Example

"Each time we face our fear, we gain strength, courage, and confidence in the doing”

                                                                                                - Theodore Roosevelt

In my previous post, The Schedule – Improving Estimate Confidence, the conclusion likely leaves the impression that for any meaningful project, to get a reasonably high schedule confidence is impractical.  In fact, PERT teaches that you can get high confidence in the schedule with task confidence of only 50%.

It is true, as I said, that the probability of completing the project (a series of critical path tasks) on the expected date is determined by the product of the individual task priorities.  But this isn’t really meaningful.  For example, a series of 10 critical path tasks, each estimated for 10 days at a confidence level of 50% has a probability of less than 1 in 1,000 of completing in 100 days.  But our stakeholders are generally not that rigorous – we are usually allowed to complete within 5-10 days either way of that date for acceptable success, and this dramatically changes the results.

At a task confidence level of 50%, PERT assumes that there is an equal balance between tasks finishing early and tasks finishing late, which at project end will balance out the noise of individual task variance.

An example will better illustrate the situation.  As shown in the Table 1, here is a project with ten critical path tasks.  For simplicity, I’ve given them all the same estimates, but the estimate values aren’t relevant.

In Table 2, the Expected (statistical mean) and Variance values are plugged into a standard deviation z-table so I can show the duration ranges for selected probabilities of success for this hypothetical project.  StdDev is just the square root of Variance and is in the same units of measure as the estimates.  The appropriate multiplier is applied to StdDev and subtracted from (added to) Mean to get Low (High).  Range is the difference between Low and High.  I have taken liberties with rounding throughout this table.  This table would be read that for a 50% project probability of success (for the hypothetical project in Table 1), one would schedule for 109-121 days duration for the project, a range of 12 days.  If a sponsor needed a higher confidence level, they could get 90% confidence with 101-129 days (a range of 28 days).

There are a number of gleanings from this exercise:

• Specifying a fixed completion date sets you up for failure, with a less than 0.1% probability of delivering on that date with just 10 critical path tasks.
• If that is bad, Optimistic scheduling is a disaster.  If you planned to deliver in the optimistic duration above (50 days), your odds drop into the billionths.
• According to PERT, it is possible to deliver a project successfully within a statistically sound range that should be acceptable to most stakeholders.

But all is not champagne and roses – after all we are project managers and the gods do laugh at us.  So what can go wrong in this model?  Let’s review the validity of the assumptions:

• That there is a correlation between PERT and statistical analysis.  I know of no research that supports or confirms this assumption.
• The data points (project estimates) present as a Normal Distribution.  In fact, we know this is not true and that the values skew to the right (meaning that results are more likely to be late rather than early).
• To be statistically meaningful, you need a large number of data points.  Most projects will not have the volume of critical path tasks needed to validate this assumption.
• That results of one task are independent of any other task.  This is talking about statistical dependence rather than project task dependence.  But to be true would have to mean that variance (overage or underage) in one task does not influence the variance of any other task.  Earned Value Management (EVM) results would tend to invalidate this assumption, because EVM experience shows that variance early in a project is a high predictor of comparable variance later in the project.

To round out this discussion on estimate confidence, I will note that PMBoK and the Practice Standard for Project Estimating both consider PERT an analogous estimating technique (though I challenge that if applied at the task level by the task owner).  The only recognized bottom-up estimating technique is the Delphi Method.

Has this series on advanced scheduling techniques provided any insight on weaknesses in the techniques you use?

The Project Manager’s Cycle – Redux

“What does a project manager do?  What value do I add to your project?  It’s true that I don’t contribute directly to the product or service for which the project exists.  However, if I’m doing my job well, then I add significantly to the productivity and value of the team by improving communications, eliciting priorities, and focusing the team on the key deliverables.  Further, I am your agent, seeing that we perform to plan and communicating back when we diverge from it.”

Note:  I originally wrote this in April/May 2011 and it was intended to be the final post in The Project Manager's Cycle series, but on reviewing my archives today I realized that I never published it.  My apologies... and here it (finally) is.

The Project Manager’s Cycle includes these activities:

• Validate the metrics
• Validate task status
• Incorporate approved change control
• Reschedule/Replan
• Check variances and progress/productivity
• Communicate planned/expected resource utilization to resource managers
• Develop earned value reports
• Review risks and mitigation actions
• Review issues and action items
• Review commitments
• Conduct client/sponsor status meeting
• Conduct project team meeting
• Publish the project status report

A baker’s dozen posts on the core project management elements of monitoring and controlling a project.  This series on The Project Manager’s Cycle been a pleasure to write and has also been beneficial for me.  I developed the outline of the series several years ago, but this journey required that I really flesh out the details, relationships, and components.  I appreciate all of my reader (yes, that would be you) who stayed with me through this.

A picture is worth a few words, it’s said, so I’ve tried to rough out the series in a diagram.  If I ever figure out how to make it available as a download, I’ll enable that.  In the meantime, leave a post or drop me an email and I’ll reply with a full-size PDF of version 1.0 of the diagram.  Next time I’m feeling ambitious, I’ll add the inputs and outputs, though I’m concerned that will make the diagram too busy.

We stepped on the ferris wheel together in January to start this ride.  We’ve gone around the cycle and now it’s time for us to step off.

What of this series has been the most beneficial to you?  Where have I not been clear and need to expand or improve the discussion?

The Schedule – Risk Buffers

“The first step in the risk management process is to acknowledge the reality of risk.  Denial is a common tactic that substitutes deliberate ignorance for thoughtful planning.”

                                                                                                                - Charles Tremper

With this post, we conclude the series on developing the well-formed schedule.  We have taken the WBS, which defines the project scope, added the task dependencies, estimated the effort for each task, assigned resources to each task, and resource-leveled the task assignments.  The final step to complete the well-formed schedule is to add risk buffers so that the schedule has the intended probability of success.

A schedule without risk buffers has virtually no probability of success.  Since you probably want to present a schedule with some probability of success, it obviously follows that you must add some risk buffers.  So now you probably want me to tell you how many and where.

I’ll briefly identify two common practices for identifying risk buffers.  The first is built from the standard risk management process.  The PMI PMBoK risk management process includes the step “Quantify risks.”  You’ve probably wondered what this means.  For risks that should be mitigated, determine the probability of occurrence (a percentage) and the time and cost that must be added to the project if the risk event occurs.  Let’s say for a specific risk you determine there’s a 25% probability that it will occur and that if it occurs it will add 12 weeks (I’m just going to deal with time in this example, but you can extrapolate for costs) to the schedule.  The 25% probability times the 12 weeks is 3 weeks, meaning that you should add a risk buffer of three weeks to your schedule.

Depending on a variety of factors, you can either add all three weeks to the end of the schedule or spread it in appropriate points over the life of the project.

You repeat this for all significant project risks.

A very common alternative to this approach is to use the Critical Chain approach developed and promoted by Elihayu M. Goldratt.  It uses a formulaic approach to determine the appropriate amount and placement of the risk buffers.

This overview is obviously too high a level for practical application.  But with this post I’ve finally presented enough of the PM foundation so that I can introduce some of the more interesting and complex concepts.  I’ll do this starting with a couple of posts on advanced quantification of the schedules, then maybe transition to more fully explaining the development of risk buffers.

It’s taken me two years of posts to get to “the fun stuff.”  What area of project management best practice would you like me to tackle?

The Schedule - Basics

Success is neither magical nor mysterious. Success is the natural consequence of consistently applying the basic fundamentals.

                                                                                                - Jim Rohn

On completing my recent series on the Work Breakdown Structure (WBS), I promised to continue the series on project management fundamentals with The Schedule.   In this post, I’ll discuss the basics of a well-formed schedule, to be followed in future posts with advanced scheduling techniques and best practices.

A schedule is more than just a timeline.  Most “schedules” that I see are actually timelines.  That is, they are a graphic representation of what the PM wants the schedule to look like, how the PM wants the project to flow.  A well-formed schedule, in contrast, is how the PM plans for the project to flow based on a given level of certainty (probability).  It is for this reason that a (time) schedule (and equally a cost schedule) can only be done integrally with appropriate risk management.

A well-formed schedule is built in these steps and, if any steps are omitted, it is not a well-formed schedule and therefore is not reliable:

• WBS
• Dependency chain
• Task effort estimates
• Resource assignments
• Resource leveling
• Risk buffers

We’ve already talked about the WBS.  Over the next few posts, I will expand on these other necessary elements of the schedule.  In addition, there is an optional step to quantify the reliability of the schedule.  This topic is challenging to explain and probably requires a full book to do it justice, but I will at least address the high-points.

One final thing before I close this post:  If you follow these steps and develop a well-formed schedule, will that guarantee a good schedule?  The short answer is: No.  Ignoring the obvious path that “good” is subjective and the pitfalls that leads to, my point is that following the “process” or steps of producing a schedule does not compensate for experience or fate.  That is, if an experienced PM produces a timeline without resource leveling, they will not have a reliable schedule.  On the other hand, if an inexperienced PM follows all of these steps, they still may not have a reliable schedule.   There are lots of ways to produce an unreliable schedule.  And sometimes God just laughs.

Other references on scheduling:
                PMBoK v4, chapter 6 (Project Time Management)
                The Practice Standard for Scheduling v2

Ode to ETC – The Task Overrun Early Warning System

History is a vast early warning system.

                                                - Norman Cousins (15Apr1978)

Sometimes you have to use the tool you have available, whether it is any good or not.  So it is with getting task completion status as percent completes.  Much better though is using the best tool for the job.  This blog exists to share project management best practices, so today I extol the virtues of ETC.

As PMs, our job includes delivering a project according to plan, knowing when the project is off plan (and acting to get it back), and communicating status to stakeholders.  Other people – our project team mates – do the important work and we rely on them for the information to do our job.  To be successful, we need a tool that helps our team mates communicate that information and for us to receive it accurately.

The well-defined task is the starting point.  Knowing whether the task has not started, has started (is in progress), or is completed is beneficial.  It helps us with history, with past events, but doesn’t communicate enough about the future.  Looking back is easier and more comforting, but it’s not the most beneficial nor the most important activity.  The most important objective with task status is to look forward, to be able to determine that the task will progress to plan.  Only by looking forward effectively are we appropriately serving our stakeholders.

The best tool for tracking progress is Estimate to Complete (ETC).  ETC works best when tasks are estimated, scheduled and reported by effort (as they should be), but even with duration scheduling is still superior to other methods of communicating what remains to complete the task.  When you ask the task owner “How much more work is (or how many more hours are) required to complete this task,” it forces them to re-estimate the remaining work, but with the advantage of everything they’ve learned by progressing to the current state.  The values get progressively more reliable.  Further, as the task gets closer to completion and the ETC value gets smaller, the task owner has an incentive to complete the task (just to get it off their plate), as opposed to the negative incentive system with percent complete reporting (see my next post).

No predictive system works effectively if it is rule based.  That is, if the task was originally estimated at 40 hours and the owner has completed 24, they can’t satisfy the ETC just by reporting 16 hours to go;  that defeats the predictive value of the technique.  They have to actually re-estimate the remaining work, which could be more or less than 16.  Tip:  be very suspicious if a task owner just keeps reducing ETC by the number of hours worked on the task.

ETC, when used consistently and properly, is a PM’s best friend.  ETC is an early warning indicator into task delays, under-the-cover scope creep, or a task owner that may be over their head or not performing.  As an early warning indicator, ETC is much more reliable than other methods.

One thing I’ve found using ETC is the necessity to frequently reinforce that the task owner must re-estimate the task each week.  Do you have any examples of problems using ETC?

The Root Cause of IT Project Failure

Art is making something out of nothing and selling it.  Frank Zappa.

There exists anecdotal evidence that Information Technology (IT) projects fail at a greater rate than other types of projects.  Why is this?  Are we that bad at delivering projects?  Or is it that we’re that bad at planning?

Have you ever asked an artist to predict how long it will take to create a novel piece of art?  Or tried to get a marketing team to plan the schedule for coming up with the next campaign?  Why are we as IT teams so ready to come up with these precise, scientific – even optimistic – schedules?  What we do is often just as novel and just as creative.  But we’re ready to plunk down numbers on a schedule with the confidence of divine inspiration.

Project Management is a special kind of management.  That is, project management is the poster child of Management by Objectives (MBO).  The unique aspect of MBO – and thusly project management – is the objectives (milestones) with which are either tracking or off track.  To have objectives entails planning.  In project management, we call the objectives milestones and they are points on a (time or cost) schedule.

I want to distinguish here among varieties of projects.  Like the abstract water colorist who can knock out wilderness landscapes with the reliability of an assembly line, some shops do many very similar projects.  With those conditions your planning can get fairly precise.  It’s those other projects I’m talking about.  Not high risk, no, not those.  Rather, the high novelty projects.

Projects where you and the team have never really done anything like this before.  You’re breaking new ground and every design activity is a unique creative effort.

How can you say up front how long this will take or how much it will cost?  But we do.   And we commit to these numbers.  Why can’t we be like the artist or the marketer?  Why are they so much smarter than us when it comes to these commitments?  Is it because they’ve learned from their mistakes?

I assert that what we’re really predicting in our plans is not that it will take this long, but rather that it will take at least this long.  That it can’t realistically be done in less time.  And some of the engineering work can be planned.  For example, we can lay out that we will complete requirements in x days.  Or that development will take so many weeks.  But how long does it take to research alternatives?  How many prototypes will we have to do before we get it right?

IT projects – that is, novel IT projects – are just as creative as the artist carving the block of marble or the ad team brainstorming the perfect campaign.  And we should be just as resistant as those artists to committing too much (too little?) in advance.  We do ourselves, our team, and our stakeholders a disservice otherwise.

The root cause of IT project failure:  committing to a plan too early.  We don’t fail on delivery.  We fail trying to deliver to a faulty plan.

What happened when you promised when you should’ve waited?  What stories can you tell about trying to deliver to the wrong plan?

Project Failures & The Chaos Reports

Diane, the Chief Financial Officer, had invited the partner of the local PwC office for this meeting.  She had only done that once before, so he knew this discussion was special.  “How do I guarantee project success?” she asked.  He didn’t need it explained that this was probably a make-or-break project for the company.  He grasped all of the nuances of this question.  After carefully considering his thoughts, he responded “There are many ways to improve the probability of project success, but none of those guarantee success.  In fact, you really can’t guarantee project success.  But there is another way:  Call the activity an experiment or research or a prototype.  Regardless of the outcome, you can claim success.  Just don’t call it a project.”

I want to take a couple of posts and discuss project failures.  In this post I’ll discuss the often quoted Chaos reports, which applies to all types of projects, and in the next post will discuss more specifically IT project failures.

Let me start this discussion by stating up front that I’ve never read a Chaos report.  The Chaos Report is published by The Standish Group and costs hundreds of dollars (or more) to purchase.  My guess is that most people who reference the Chaos Report are, like me, only familiar with the press releases, headlines, and secondary references.

Because I haven’t read the report, I can’t criticize it.  I can, however, criticize all the people who reference it to make a point about project failure.  Allow me to present a couple of examples of why the headline number of project failures is misleading and misrepresentative.

In the first example, I will use an analogy.  Assume that most people who get a dog want it trained and that most of those people choose to do it themselves rather than hire a professional.  Further, most people who go it themselves don’t dedicate enough time, don’t have the experience, don’t follow through, and thus don’t succeed.  Now, let’s survey all the people who bought dogs last year and ask them about the success of their dog training efforts.  The results, of course, will show that most dog training efforts ended in failure, despite that virtually all professional training was successful.  The headline (most failed) completely misrepresents the success of professional dog trainers.

My second concern is with the definitions of success and failure.  “Strategies for Learning From Failure,” (Amy C. Edmondson, Harvard Business Review, April 2011) describes a spectrum of failures ranging from blameworthy to praiseworthy.  Just because it didn’t meet the original (optimistic) objectives does not mean that the project was a failure.  In addition, different perspectives of the project can produce completely different opinions.  For example, both the Sydney Opera House and the Ford Taurus went tremendously over schedule and budget, but both today are regarded as tremendous market successes.  In another example, a project could be started to introduce a new product into the market.  During the exploratory phase, the team determines that it cannot meet the business objectives and it’s cancelled. The brand manager considers the project a failure because the product did not launch;  the CEO, however, considers the project a success because the company did not over invest into a failing proposition and could redirect the funds to other more promising opportunities.  So how can I accept the Chaos report headlines when the same project can elicit either success or failure results depending only on who I ask?

There are many other reasons why the headlines should be ignored:

·         If the organization has failed projects, what is their success with operational efforts (i.e., what is the organization’s success baseline in general?)

·         How does organizational project management maturity correlate with project success?

·         How do the respondents differentiate between project vs product success and failure?

·         How does The Standish Group address different viewpoints of success vs failure on the same project?

·         How does project manager experience, autonomy and authority correlate with project success?

Taken together, if a barely profitable organization with poor manufacturing processes and that had no experience delivering projects asked one of their middle managers to lead an effort to bring out a revolutionary new product, told the manager how much was budgeted, how long it would take, and who would comprise the project team (but the team members would continue to report to their current units), who would be surprised when, after a few months, they cancelled the project and called it a failure?  How many of the projects in the Chaos Reports fit this model?  If The Standish Group reported that most projects with these criteria failed, would it be newsworthy?

I have every expectation that The Standish Group conducts their research professionally and competently.  Again, I’m not criticizing The Standish Group or their Chaos Report.  I am saying that we can’t use the headlines to understand project success or failure rates;  we need the demographic details that are contained in the detailed report.  Those details, I am sure, would provide clarity on something much more important than the frequency of project failure – they would provide insight into conditions for project success.

Wouldn’t you bet those details show that projects in organizations with mature PM processes and run by qualified project managers are successful at a much higher rate?