Tips for Better Project Baseline Management

Posted on September 3, 2012 by donmcalister

Good Baseline Management is THE most critical factor in the execution and control of a Project. In my experience, more projects get in trouble because of inadequate, erroneous, poorly communicated, and ineffectively managed baselines, than any other single reason.

A baseline is the best available set of knowledge defining “What” the customer wants and the knowledge of the project team defining the “How” it will be done, “When” it will be done and “Who” will do it. You could call the Project Plan a reference point against which future project status positions can be measured. I guess it would be more accurate though to call it a reference vector, since the plan describes the execution as a function of time.

To make the complexities of baseline management easier to deal with, it’s useful to break down the overall Project Baseline in to several subset baselines. Typically those baselines include:
•the Technical Baseline- the specified and derived technical physical and functional requirements for deliverable products and/or services.
•the Cost Baseline – the allocated budget to the WBS elements and Cost Account Managers (and management reserve if the Project Manager allocates it)
•the Schedule Baseline – the Project Master Schedule and all of the logic-linked and resource loaded WBS element supporting schedule.
•the Risk/Opportunity Baseline – a definition of the known uncertainties regarding requirements, assumptions, resources etc. changes to which could impact the performance of the Project.

It’s common for larger, more complex projects for the Project Manager to establish additional baselines that they feel will help them in execution. Examples of these include:
•An organization baseline defining the structure and perhaps even individuals by name, if their expertise and on-going availability is critical to the Project
•A Facilities baseline defining physical resources critical to Project execution
•A Supplier Baseline defining specific sources for procured items critical to the success of the Project

Well-defined baselines are just the start. The Project must have comprehensive, well-documented, disciplined process; a set of meaningful, forward-looking baseline performance metrics; and a Project Manager who clearly articulates and demonstrates through their behavior, the importance of effective baseline management.

Here are a few tips from my personal experience that will help project baseline management and improve subsequent project execution:
•Ensure that all of the appropriate stakeholders are engaged in defining the baselines, their metrics and the trigger threshold for variance analysis and corrective action.
•Since the technical, cost and schedule baselines are intimately interdependent, ensure that the key managers of these baselines don’t work in isolation. Everything is connected to everything else, and an” infection” in one baseline can quickly spread.
•To the greatest extent possible, provide a common collaboration tools that the entire team has access to and can link to all of the appropriate, available data
•For projects durations of less that a year you must be able to look at and analyze performance data on a weekly basis. Even for longer duration projects, weekly performance data is better than monthly
•Proposed changes to any of the baselines must be reviewed by all of the Project disciplines (technical, financial, manufacturing, procurement and quality) for impacts and any impacts thoroughly discussed and analyzed before any acceptance or rejection decisions are made.
•I’ve found it very useful to keep my customers informed of the change traffic in the review process. This requires a lot relationship management effort, but the payoff is that surprises are avoided and valid customer comments can be addressed early.
•Don’t set variance thresholds so low that the trigger team action (and spending) that isn’t of value
•Demand variance analysis that is thorough. Too often I’ve seen superficial variance analysis that allows the real problem to remain hidden and become a bigger issue later
•If performance to the existing baseline no longer makes sense because of customer induced requirements changes or resource constraints, don’t be afraid to exercise the option of re-baselining. I cover this topic in my blog, “Knowing When to Re-Baseline Your Project,” published in April 2012

Posted in Program & Knowledge Management | Tagged , | 1 Comment

A Knowledge-Based Approach for More Credible Management Reserve Estimates

Posted on August 27, 2012 by donmcalister

There is a relationship between the level of knowledge uncertainty at the beginning of a product development project and the number of technical setbacks or failures that can be expected during its development cycle. Recovery from these in-scope failures increases the cost of the project, and that is the cost that must be protected by Management Reserve (MR). The correlation between uncertainty, failures and management reserve is notionally shown in the figure below. Low uncertainty can be considered as product development within the “Known-Known” knowledge domain. As more uncertainty is accepted, the product development effort moves into the “Known-Unknown” knowledge domain, where more failures should be expected, demanding greater MR. More cutting edge product development ventures lead to high uncertainty (the “Unknown-Unknown” knowledge domain), more expected failures expected and the need for even more MR.

Just to be clear, I’m defining MR as the budget set aside to cover the additional costs incurred as a result of the uncertainties associated with the basic requirements and scope of the project. I’m not talking about budget reserve to cover the increased cost of worse than expected performance or the sins of bad estimation. That’s the subject of another blog.

My thinking on this subject has been primarily inspired and informed by the work of Dr. Glenn Havskjold, PhD of Pratt & Whitney Rocketdyne (PWR). Dr. Havskjold has developed the idea of the “Prodecol” (Product Development Control Lever) methodology, for use in estimating the cost of the inevitable test-fail-fix (TFF) cycles encountered during development of complex, technically innovative products. This methodology is described in his American Institute of Aeronautics and Astronautics papers, AIAA-2009-5436, Parts 1, 2, & 3, “Developing Innovative Products on Budget and on Schedule”, published in August 2009. He defines a metric called the Technical Uncertainty Factor (TUF) to quantify the level of uncertainty or risk at the beginning of a product development cycle. For his business, the TUF is a composite of the uncertainty related to the maturity of technology and design, the level of design complexity, and the overall knowledge of, and experience in the operating environment of the design.

By conducting expert opinion assessments of the technology maturity, design complexity, and operating environment uncertainty, a composite TUF is established for the product at the beginning of its development. The product TUF is then mapped to the number of significant TFF cycles encountered during product development. Dr. Havskjold found that for his business, there was a distinct correlation between the TUF and the resultant number of failures during the development cycle. Further, by reviewing the business financial data he was able to determine the average cost of fixing these failures. He combined all of this research into what he calls the Prodecol Chart. This chart, used in conjunction with TUF criteria and the product development history and technical expertise of a business, offers product development teams a way to predict a major portion of the development costs.

I believe that the same approach can be used to address the broader uncertainties of project management, including those associated with the market environment; human, physical and financial resource availability and stability; and customer relationship management to facilitate the estimation of the complete project MR. Specific details of the uncertainties, failures and related cost of fixing those failures will be different for every business. However, I believe that an approach like this can be useful for any business involved in high complexity, technically innovative, product development work.

The following is a set of suggested steps in building an MR estimating tool for a business:
• Every business must examine it’s own uncertainty vulnerabilities to define a suite of characteristics that their by subject matter experts can use to build a composite uncertainty level. The table below offers some thoughts on the kinds of uncertainty drivers that might be considered and how to characterize their level of uncertainty.

• Panels of technical and programmatic subject matter experts (SME’s) must be formed to go back and assess to the best of their ability, the uncertainty levels that existed prior to the development of past projects.
• Quality and cost records associated with those same past projects must be gathered and reviewed by SME’s to identify the number of significant technical and programmatic failures, and determine the average cost of resolving them.
• Mapping the Uncertainty Level and No. of Failures should reveal the correlation curve for product development in that business, and applying the average cost to fix each failure completes the tool.
• The tool can then be used by SME’s to evaluate the Uncertainty level of new proposed projects to determine the number of expected failures and the MR required to resolve them.
• In addition, the tool can be used in reverse to help plan the program. If the MR budget is fixed, this same tool can then define the allowable number of failures and the allowable uncertainty at the beginning of development. Any gap between the current uncertainty and the “affordable” uncertainty, then can be used to define both the nature and broad scope of pre-development technical and/or programmatic uncertainty mitigation effort that could be performed to help ensure that the formal development program will meet it’s cost objectives.

Clearly, this isn’t an off-the-shelf tool for a business. They must put their own SME talent, and cost and quality records to build their own tool. I firmly believe though, that once this effort has been completed, the business and its project managers will have a valuable tool that will make them more successful in the future.

As a final comment I’ll add that any historically based estimating tool like this, must be kept current with the latest product development history. This is a critical knowledge management task for the project

Posted in Program & Knowledge Management | Tagged , , , | Leave a comment

Project Management and the Risk and Learning Cycle

Posted on July 30, 2012 by donmcalister

During the life of a project there is a Risk and Learning Cycle that takes place that is critical to the success of the effort and an important foundation for projects that follow. This blog describes my thoughts on that cycle, and takes a bit of a different approach than you might expect. I believe that we humans are natural risk managers and that we need risk to succeed, learn and grow.

I’ve recently concluded that human brains are “hard-wired” to manage risk. I don’t mean to imply that we enjoy risk, or that we always handle it with expertise and ease. I am convinced though, that hundreds of thousands of years of evolution, exposed to a risk filled environment, has shaped our neurological equipment to instinctively manage risk. In fact, I believe that today, we actually need risk in our work lives to help us: focus our attention; challenge our creativity; bring us together; explore our limits; and help us learn. Further, I believe that through better thinking and thoughtful discussion we can achieve deeper appreciation for, and better ways to apply our inherent risk management capabilities.

As I’ve discussed in earlier blogs, knowledge and risk are two sides of the same coin. Risk is an absence of, or uncertainty in, our knowledge. One of the primary traits of human beings is our instinctive pursuit of knowledge. That pursuit is motivated by something that we sense as a gap in our knowledge, which we perceive as a threat that requires action. In the context of project management, lack of, or uncertainty in our knowledge, is defined as risk.

Having the right knowledge, at the right time in a project, is necessary for both survival and success. If you accept this, and you concur that the pursuit of knowledge is driven by risk, then it must also be true that risk is a necessity for project success.

Does this make sense? Don’t we try to avoid or eliminate risk on every project? My answer is yes, it makes sense. No matter how successful we are in identifying and handling risks for a given project, we know that there are still many risks out there in the form of “unknowable’s” and uncertainties. So every risk management plan, must include a knowledge management plan to develop, route and apply new learning. Further, there is always another project in the pipeline and both knowledge and risks from one project can inform and enhance the performance of the next.

Ironically, there are two products of the project learning process: knowledge; and newly discovered knowledge gaps. The new knowledge gaps may create a new risk, which in turn drives more learning. And so the Risk and Learning Cycle continues.

Posted in Leadership, Personal Development, Program & Knowledge Management | Tagged , , , | 5 Comments

The Critical “Knowing Steps” for Successful Project Management

Posted on July 15, 2012 by donmcalister

The Critical “Knowing Steps “ for Successful Project Management

Some years ago, a friend of mine, and former colleague at Pratt & Whitney Rocketdyne, Kiho Sohn, were discussing the linkage between successful knowledge management and successful project management. I told him of my observations of inefficient startups and flawed execution of projects caused by inadequate attention to identifying and marshaling all of the relevant knowledge resources. Kiho lamented…“if only we knew what we know”, and that phrase has stuck with me over the years. As I’ve discussed in a previous blog, The Interdependency of Project, Risk and Knowledge Management, you can’t be a good project manager without being a good knowledge manager. In my experience, there are four critical “knowing steps” that project managers must go through in the planning and execution of any project.

1) Knowing What You Need to Know
2) Knowing What You Know.
3) Knowing What You Don’t Know.
4) Knowing That There Are Unknowable’s.

The following offers some strategies project managers can apply in the first two “Knowing Steps”. More in another blog about the last two

Knowing What You Need to Know
• Talk frequently and openly with your customer and your internal business sponsor. You need to build a trust relationship with them to get to the heart of what you really need to know for your project.
• I’m not just talking about the customer’s formal stated requirements and constraints, but also gaining knowledge of their market environment, goals, needs, fears and sources of pain. Such knowledge brings understanding, which enhances communication and decision-making.
• Remember, like you, your customers are going through their own knowledge building process and they can’t always tell you exactly what they want because they haven’t completely figured it out themselves.

Knowing What You Know
• What I’m talking about here is the nature, relevancy and availability of all of the knowledge resources that your business, your project team, and you can bring to bear on the project to provide an executable solution that meets the customers needs.
• You and your team will start looking for everything that’s been recorded in written or computer files, and you’ll find some success. That’s good, but you need to know that explicit knowledge probably only represents 10%-15% of the total knowledge on any given topic. The rest of it is tacit knowledge that is locked up in the heads of people. Worse than that, most of those people probably don’t even know what they know, unless they’re prompted by a context, story or event that triggers their memory. So don’t rely on individual interviews with those people. Instead, get them in a room with your project team members, tell them about the nature and challenges of your project and record the stories they tell.
• Network. Tapping in to the minds of those with relevant experience requires that you know who they are. Hopefully your company has established some kind of personnel competency and experience profile database. If you haven’t got that now, you’d better get started. Build yourself a “knowledge map”, or a knowledge registry of both the explicit and tacit knowledge available to your team. It can be as simple as a spreadsheet, or you can use tools like SharePoint and ask potential contributors to write profiles describing their competencies and experience. Make these profiles accessible and searchable by your team. Train the team to check this resource when they need knowledge, advice or ideas. Remember, studies have shown that the collective knowledge of a group of people is greater than the sum of the individual’s knowledge. The reason for this is what I call “interactive knowledge” where people only recall their knowledge when prompted by their interaction with someone else whose comment stimulates the recollection.
• Ensure that your team members act as knowledge managers. Your team needs to know that their success is as much a function of the effectiveness and efficiency with which they process information into knowledge, as it is the way they execute the project tasks. Share, don’t compartmentalize, project knowledge.
• Remember that what you know isn’t static. You and others on your team are constantly learning throughout the project. Make sure that you set expectations and establish the infrastructure to capture and share that knowledge effectively.
• As an individual and as a team, be curious and have a learning bias. Be open to new ideas or old ones, even if they’re uncomfortable. I’m not saying that you should necessarily adopt ideas that are uncomfortable, but listen to them, give them an objective assessment, and then if they look like they add value for acceptable risk, and then adopt them.

Posted in Leadership, Program & Knowledge Management | Tagged , | 1 Comment

Learning to Be A Project Manager By Building on the Basics

Posted on July 2, 2012 by donmcalister

 

 

Sometimes I think that as we work to develop new project managers, we make the subject matter seem more complicated than it needs to be. I’m not trying to say that all of the tools and processes and Bodies of Knowledge, and best practices, aren’t important for the next generation of project managers to learn about. It’s just that as experienced project managers seeking to teach the next generation, I think we get so caught up in communicating the esoteric, complex details of project management, that we miss conveying its essence. This complexity can confuse and distract, and perhaps even intimidate and turn-off aspiring PM’s. Those of us already steeped in (scarred by?) the art and science of project management are of course anxious to pass along everything that we’ve learned over our careers, to allow those that follow to be more successful. However, in our zeal to share our knowledge, too often we use the “fire-hose” teaching methodology, in which we direct an overwhelming flow of information at our students, sometimes “knocking them on their butts” so to speak.

So let’s focus on the basics. In my view of the project management world, the basics are handled by these ten questions and methods:

Project Initiation and Planning.
1. What is the work to be done? = The Statement of Work and the Work Breakdown Structure
2. When must that work be completed? = The Logic-linked Tasks in a Project Schedule
3. Who will do the work? = The Responsibility Assignment Matrix
4. How will the work be done? = Project Execution Plan and the Risk Management Plan
5. What are the risks to our plan? = The Risk Register and Risk management Plan

Project Execution, Monitoring & Control.
6. What accomplishments can we celebrate? = Recognition & Rewards
7. Is the Project on Plan? = Technical, Cost & Schedule Metric Variances and Action Plans
8. Are there New Issues or New Risks? = Registers and Action Plans
9. Who Needs Help? = Action Plans
10. What have we learned? = Lessons Records

I understand that project life isn’t as simple as these questions imply and that the “devil is in the details” as they say. However I believe that thinking about complex things in simple ways leads is a key leadership attribute and sets the stage for achievement and innovation.

Posted in Leadership, Personal Development, Program & Knowledge Management | Tagged , | 4 Comments

The Science Behind Better Project Management Competencies

Posted on June 20, 2012 by donmcalister

There’s been a lot of discussion and a whole spectrum of opinions expressed about what constitutes the best combination of domain knowledge, relevant experience, and personal competencies to ensure project manager success. Domain knowledge and experience are generally considered “hard” project management talent attributes, while personal competencies are considered “soft” talent attributes. The reason for this thinking is that domain knowledge and experience are objective and factual and the role they play in the success of a project manager is fairly clear. Personal competencies on the other hand, although they clearly exist and we “know” they play an important role, are fuzzy and hard to understand. Recent neuroscience research and psychological studies however, are offering us a deeper understanding of how those competencies really enhance the performance of those engaged in leadership activities like project management.

This blog was inspired by a recent discussion in the LinkedIn Group, “NeuroLeadership in Project and Program Management.” The discussion, and its linked reference sources, really resonated with me. It referenced an article from the Huffington Post, “The Neuroscience of Leadership”, by David Rock, Director of the NeuroLeadership Institute . The article describes neuroscience research that finally provides some substantive basis for the “gut-feelings” I’ve had for many years about critical project management leadership and interpersonal competencies. The research clearly shows that:
• Better, more innovative, decisions are made when our brains are focused and cleared     of “noise.” We’ve believed this to be true for a long time, but now there is scientific evidence to support the idea. By developing our ability to notice the subtle signals in our brains that are often obscured by the noise, we can increase the likelihood of finding the real breakthrough ideas. Most interesting to me is that this same research shows that our long-standing use of “brain-storming sessions” may actually be counter-productive to solving complex problems.
• When we can be aware of, verbally characterize, and regulate our emotional responses to situations, we reduce stress and make better decisions. I’ve always believed that this “emotional intelligence” was a critical skill for project managers, and this research provides substantive supporting evidence.
• Our brains are wired to be highly responsive to five social rewards or threats: status, certainty, autonomy, relatedness, and fairness. Understanding that the people on our project teams are driven by these conditions can improve the way we communicate, provide performance feedback, offer rewards and recognition and resolve conflicts.

I believe that domain knowledge and relevant experience are important and necessary talent attributes for project managers, but they are not by themselves sufficient. Adequate project managers will have the domain knowledge and experience necessary for the context of their project. The best project managers, however, know that their interpersonal and leadership competencies are what make the real difference between success and failure.

Posted in Leadership, Program & Knowledge Management, Uncategorized | Tagged , , | Leave a comment

Better Project Reviews Have a Big Payoff

Posted on June 5, 2012 by donmcalister

 

 

 

The likelihood of success for a Project Manager in the execution of a challenging project can be greatly enhanced by the use of effective recurring reviews. I’m sorry to say that I’ve attended too many ineffective project reviews and I’m ashamed to say that I’ve presided at too many of them as well. Here are a few tips I’ve used or learned from others that I’d like to share. If you’ve got tips and tricks for better project reviews please share them with me

They’re ad hoc, rambling, too long, not focused, look backwards, look at the wrong things, and get mired in details. People that should attend are often unprepared, and too many attend who should be off doing other things.

What do want and need from project Reviews?

  • We make a project plan and establish scope, cost, schedule, risk and perhaps other baselines which must be monitored and controlled during execution.  Project Reviews provide us the venue to examine and discuss the causes of variances to those baselines and make decisions on corrective action.
  • We want the project team members to be aligned with and regularly refreshed on the project goals, objectives, and customer expectations.  Project Reviews with the task owners give us this opportunity.
  • Project reviews enable us to make sure the project team members know, what they need to know, when they need to know it, and how their performance is impacting the other contributors and the project as a whole.  This is the place for “Breaking News”
  • Project Reviews provide can provide an open and safe way for team members to ask for help and get it in time to be useful.
  • Project Reviews provide an opportunity to recognize and celebrate team accomplishments.
  • Project Reviews provide us a forum to elevate lower level WBS element issues and risks to the attention of higher WBS element owners.
  • Project Reviews allow us to consolidate and clarify information that should be flowed on to project sponsors and customers.
  • Project Reviews give us a recurring opportunity to communicate/refresh near-term project coming events and milestones.

How do we make Project Review Meetings Effective and Efficient?

  • Make them weekly, and keep them to an hour or less, but make it an hour that is always at the same time and never (or at least almost never) “bumped” by other meetings.
  • Make the reviews agenda driven. Set a standard agenda and use it in a consistently disciplined manner
  • Pick a few key metrics and put them on an easily understood dashboard.
  • Provide access to all of the review information through one team collaboration site. That doesn’t mean store everything there, just use a single site as the portal to wherever the information is stored.
  • The business of the meetings is serious, but keep the atmosphere lite. You want people to want to be there and to want to share and help each other.
  • Start with a brief celebration of something. An accomplishment…a career milestone…a lite sharable personal story.
  • Then Breaking News
  • Then review the progress to the critical path plan during the last week.  What finished that was supposed to finish?  What didn’t finish that was supposed to finish? What started that was supposed to start?  What didn’t start that was supposed to start?
  • Then review Project Key Metrics Dashboard.  EV Performance.  Technical  Performance Metrics
  • Review the top Issues for resolution
  • Review the top 5-10 Risks for changes
  • Ask who needs help and ensure that help needs and offers commitments are made and fulfilled
  • Take a 60-90 Look-Ahead at key coming project events and make sure the list is current and understood.

Investing time and creativity into planning and execution of project review meetings will pay big dividends in project communications, execution performance, team morale. Good regular project review meetings will also reduce the need for other splinter meetings that are often required to make up inadequate reviews.

Posted in Program & Knowledge Management | Tagged | Leave a comment

Making Our Project Schedules More Credible

Posted on May 15, 2012 by donmcalister

 

 

 

 

Project Managers are both the victims and the perpetrators of project schedule credibility gaps. This blog explores the nature of these credibility gaps, their causes, and offers some tips to avoid them. In this blog I’ll focus on schedule credibility gaps, but the ideas and arguments apply equally well to cost estimate credibility. This topic is yet another manifestation of the intimate interdependency between Project, Risk, and Knowledge Management that I discussed in an earlier blog.

When I’ve asked Project Managers about how uncertainties in their project environment impacts the way they perform their jobs, they all acknowledge that it plays a huge role. Yet, when I look at the predominately deterministic way that most project managers make and communicate schedule estimates, you’d never know that uncertainty has ever crossed their minds. That statement may seem harsh, but how often have you seen schedule delivery dates expressed in a way that realistically characterizes the likelihood of achieving them?

At an intellectual level, most project managers understand the concepts of best, worst and most likely estimate variability; probability density distributions; and calculated outcome confidence levels. However, we still typically depict schedule completion dates as single-point estimates. We are usually optimistic when we do this, and even if we verbally characterize the date as “success oriented” or “assuming no problems,” what our customers and our management perceive is that it represents the “most likely” outcome. Now of course, intended or not, we’ve set customer and management expectations that are often uniformed and unrealistic and we’ve added risk and additional challenges to the execution of the project. We’ve also set the stage for customer communications problems because of the unpleasant “surprises” that will no doubt arise as some of the unspoken uncertainties transform themselves into real problems that will take time and money to resolve. (for more about this, check out my blog “Striving for No Surprises Project Management.”)

So why do we do this to our customers, ourselves, our project teams and ourselves?

A key personality trait of most Project Managers is that they are strong competitors with strong egos. This can be both a blessing and a curse. They focus tenaciously on their customers and their project objectives and they stand fast in the face of significant challenges to the triple constraint. On the other hand, they are often reluctant ask for help. They will not admit defeat or display a lack of confidence easily, which sometimes means that when they finally do ask for help it’s too late. They would rather fail heroically than to tell their customers that their requirements and expectations are unrealistic and can’t be achieved.

In addition, we humans have a strong desire for the comfort, false though it may be, of deterministic, predictable outcomes. We want root causes that don’t really exist (see my blog “There Is No Root Cause for Project Failure”). Our brains use past patterns to predict new outcomes and we find the notion of variability in those outcomes to be discomforting. Project Managers know there’s variability (it’s a “Known-Unknown”), but instead of taking it on directly, using a probabilistic approach, we continue to quote singular estimates and then add things like schedule buffers, margins and reserves to protect us from the variability. The use of those risk management techniques is perfectly legitimate and an important project management practice, and I’m not arguing against them. What I am recommending however, is that project managers take a more realistic view of the world, embrace it’s uncertainty and variability and never again quote a schedule date or cost estimate that isn’t accompanied by a confidence level that characterizes its likelihood of realization.

So if you want a more credible, executable, customer friendly project schedule, here are a few tips:
• Layout your project tasks, with their durations and the predecessor and successor logic.
• Force yourself and your team to recognize the task duration variability and make worst, most likely, and best-case estimates.
• Define the critical path and it’s variability. Watch out, the variability of the tasks could introduce more than one critical path
• Pick a probability density function that makes sense in your project context. A 3-Point Triangular approach may be all that’s needed for a relatively simple project, or you can use a Normal Distribution and a Monte Carlo calculation tool.
• Calculate the confidence level for various project finish dates along the critical path(s).
• In conjunction with your customer and management sponsor, use the probabilistic information you’ve just developed to:
o Make more informed decisions on project goals and constraints
o Provide rationale for additional resources or resource re-distribution for “schedule   crunching.”
o Plan schedule risk mitigation activities
o Apply schedule buffers
o Define improved project execution performance metrics

Posted in Program & Knowledge Management | Tagged , , | 6 Comments

There is No Root Cause for Project Failure

Posted on May 3, 2012 by donmcalister

When Projects fail, professionals want to know why, so they can learn and prevent similar failures in the future. A lot of smart people have worked diligently, to research project failures in an attempt to find, and share with us, the root causes. While this drive to find “the root cause” of a project failure is well intentioned, and has some value in helping us find answers, I believe it’s fundamentally flawed. It can lead to incorrect solutions, ineffective corrective actions, and unintended consequences.

This notion about the fallacy of using root cause analysis in complex systems isn’t new or something I invented. It’s very eloquently addressed in the February 2012 article from the Kitchen  Soap Website, Each Necessary, but only Jointly Sufficient . My intention with this blog is to address the concern in the context of analyzing why Projects fail.

Projects are complex systems. Complex systems produce results through the interactions of their network of parts, or people, in the case of Projects. When the system produces its desired output, we don’t look for the root cause of that success, because we understand that the result is the integration of the interactions between all of the contributors. Why then do we assume that, when a Project fails, or produces an unfavorable result, there must be a singular cause?

Our desire to know, understand and fix variances to the plan is a natural behavior of Project Managers. It’s what we do…we solve the problems that prevent us from achieving project objectives. We’ve been trained to use analysis as a technique to solve those problems. When we analyze something, we use reductionist science to break a system into its parts so we can examine each part to determine how its function, or malfunction, affects the whole system. In addition, to ensure that we’re not being too superficial in our search for variance causes, we’re given tools like the “5 Whys?” and encouragement to be “relentless” in our pursuit of “the root cause.”

The problem with the root cause approach is that it seeks to explain multi-dimensional phenomena using a single dimensional cause/effect chain thinking model. The reality of our Projects is that they are an intricate and dynamic weave of interdependent activities, events, behaviors and contexts. I’ve assessed many troubled projects during my career, and in my experience, I’ve never found a root cause for any of them. In every case there were several contributing, “necessary” causes, and only when they were combined, did they yield the conditions that were “sufficient” to cause the failure or dysfunction. Defining this network of contributing causes, each in itself “necessary”, but only jointly “sufficient”, must be the objective of any project failure forensic analysis.

With a “cause network” to inform us we can, with the confidence, plan and implement a comprehensive set of effective project management interventions to correct the problems and prevent their recurrence. That confidence is the product of using a system thinking perspective and the achievement of a holistic understanding of the contexts and interdependencies related to the contributing causes.

So don’t look for the root cause of Project failures…they don’t exist.  Look instead for the network of necessary causes that together form the sufficient conditions for failure.

Posted in Program & Knowledge Management | Tagged , , , | 3 Comments

Technology Driven Emergent Habits

Posted on April 26, 2012 by donmcalister

Last week I attended a wonderful conference dedicated to better thinking about thinking. During a break between sessions, I made use of the hotel restroom and while washing up, I experienced a moment that I can only describe as brain freeze induced enlightenment. As I walked up to the sink, I passed by, and apparently activated an automatic paper towel dispenser, which sensing my presence, issued a sheet of paper for my use. Now facing the sink, I absent-mindedly waived my right hand under the automatic soap dispenser, and was obligingly offered a dollop of liquid soap. However, as I gently waived my left hand under the faucet to initiate the flow of water, nothing happened! I waived my hand a bit more vigorously, but still no water. I then realized, to my great embarrassment, that the faucet was not automatic, and had instead, manual hot and cold valves. Those shinny, chrome plated valves seemed to stare at me, mocking my unrewarded hand waiving behavior. After a quick glance over my shoulder to ensure that no one else had witnessed my brain freeze, I turned on the hand valves and received the water that allowed me to complete my hand-washing mission.

Walking back to the conference session area, I reflected on what I’d just experienced. I smiled as I considered the irony of my thought lapse, occurring as it did, during a conference dedicated to better thinking. However, the experience also made me think about how today’s consumer technologies are stealthily reshaping our everyday behaviors and creating habits that stop us from using our senses and our brains.

Here are just a few of the technologies and associated emerging habits that put us at risk.

• Your car is equipped with a rear facing video camera that’s activated when the shifter is placed in reverse. Have you noticed that when you back up your car, you’re not looking over your shoulder as much as you used to do? Maybe not even looking in the rear-view mirror as much as you used to do?
• Automated Doors. Have you ever seen anyone waving his or her arms in front of a manually opened door, and getting frustrated because it’s not opening? I have. When the person I observed realized the door wouldn’t respond to their movements, rather than stepping forward and pulling or pushing it open, chose to move to another adjacent door that was automatic.
• Digital Reading Devices. Will the proliferation of these devices cause us to forget that when reading a real paper book, tapping the right hand margin with your finger won’t result in the page turning?
• Telephone Caller ID. Will we become so selective about who we choose to actually speak with, that we’ll never speak with a stranger again?
• Telephone Texting. As more of us do more and more texting with cryptic shorthand, will we bring those habits into our other communications and stop using real words and complete sentences there as well?

These are but a few of the habits we’re collectively adopting everyday, as we become accustomed to, and reliant on, the advantages of new technologies. We are by nature, creatures of habit, both good and bad. In fact, we need habits to survive. So I guess it’s good that the relentless development and deployment of consumer technologies will ensure that we will not only be better connected, better informed, and more productive, but that we will also always have an endless supply of new and innovative habits.

Posted in That's Life | 1 Comment