Projects, by their nature, are uncertain, but not all uncertainty can be treated the same way. Knowing the where your project’s uncertainty lies will help you pick the right approach to managing your project and delivering the best outcome for your team, your customer and the project owner.

Many projects are time bound, with specific dates that must be met. There are known parameters to the project outcome, but how you’re going to execute are uncertain. If you your project is software or product development, which is iterative, most uncertainty lies in the deliverables; you’re not sure exactly what the deliverable will look like. In essence, you don’t’ know what you don’t know until you develop a prototype; you’re learning as you go. In these types of projects, there is little uncertainty in the process, but a lot of uncertainty in the outcome. This is different than say, construction, where the deliverable is quite well defined. What is most uncertain is the events (like weather or errors) that lead to the deliverable. The process has the most uncertainty, the outcome has little.

Two Approaches to Managing

Scrum and Agile methods that focus on iterations to reduce the learning cycles and reduce the uncertainty. The problem with these projects is when there is a date attached, it’s difficult to effectively manage schedule risk without significant time buffers.

If the uncertainty is in the process, what most project managers do to reduce it is create more detailed plans or (attempting to) closely managing the details in the plan. These projects have many moving parts and lots of detail to manage – along with the normal uncertainty they cannot manage, like the weather and mistakes. So – with all this comes complexity.  That complexity is difficult to manage. Project managers lose control of their schedules. Project owners lose visibility into schedule risk. Project run late, firefighting ensues. It’s difficult and messy. Deadlines are missed. Costs go up. Customers are unhappy. Business is lost. Profits suffer.

Detailed Planning is Not the Cure-All

So, the solution is not in the direction of more detailed planning, but in the direction of improving management effectiveness. This is what ViewPoint and VISUM does. Stripping the project plan to its essence. Doing simple things that leverage what we know about process behavior (little’s law, priority control, etc.). Making the process visual to communicate the critical items quickly. Providing feedback on the project AND the delivery process to allow the team to act early on risk and improve their delivery effectiveness.

Taming complexity.

With ViewPoint, the team always knows the most critical items to work on. They are focused on those items. There is less chaos in the project, so less stopping and starting. People can focus on the work, not on the next meeting. Tasks get done quicker. Project durations are reduced. Costs go down. On time delivery goes up. More projects are delivered. Revenue goes up. Profits go up. Project owners have visibility into the schedule risk so they can intervene when they must. Customers are happy. Project Managers are happy. The CEO is happy.

The post Where is Your Project’s Uncertainty? appeared first on Projects in Less Time - Mark Woeppel.

The post Five Ways to Improve Your Project Plan appeared first on Projects in Less Time - Mark Woeppel.

When our consultants find something blocking the process, we use a simple technique to find the hidden assumption(s).  We’re not challenging every assumption, just the ones that create situations that block us from where we’re going.  It does involve asking the question, “Why?”.  Sometimes we ask it 5 times.  But asking “why?” just tells us the “reasons”, not always the assumptions.

A couple of words about assumptions – we’re all familiar with the word game played when someone says “assume” (for those that aren’t aware of that, when you make an assumption, it makes an ass|u|me), but that’s not what I’m talking about here (although I do agree with that statement).  I think of assumptions as a person’s basic understandings of how things work.  This is useful for thinking in terms of cause and effect.  For example, the cause, “I kick you in the shins” will likely result in an effect like, “you will be angry”.  Not very hard, but the assumptions I make in this situation could be, “you don’t like being kicked in the shins” or “your feelings will be hurt by an attack on your person” (actually, this latter statement has another assumption, “when people’s feelings are hurt, they react with anger”.  Each of our processes has causes to create effects.  Sometimes, we don’t like the effects, so, if we want to change them, we should dig into the assumptions around these cause and effect relationships.

In a process, assumptions take the form of management rules (Why are we doing that?  We’ve always done it that way!), understanding of technical process (we have to put a 15 degree radius to allow for a subsequent step), quality requirements (inspection steps), or product specification requirements (dimensions or features).  These are baseline parameters of how the process functions and its boundary conditions.  Most of these are important and needed.  However, over time, these rules and requirements can become like barnacles on our process, no longer needed and slowing down the process.

Our goal is to find the assumptions that are erroneous.  An erroneous assumption is the rule, requirement, or boundary condition that is no longer required. (Why are we doing that?  I don’t know! We’ve always done it that way!).  The only way to find those assumptions is to zero in on the blockages and ask why certain requirements (the ones that are slowing you down) are necessary.

The process we use to find and challenge assumptions is to simply ask why and identify the assumptions that are no longer valid or could be made invalid.  Meaning, not every assumption is a fixed thing.  We can change things around.  Some are not valid in every situation – do we need to take this step for every product or just for specific customers?  Do those policies still apply in this situation?  Can I get the policy changed?  Can I find a different way to satisfy the requirement other than the one in place?

Take, for example, Pinnacle Strategies’ work during the Gulf Oil spill.  When we were working with boom manufacturers, our consultants went to several boom manufacturers to find more capacity.  The companies usually had rigorous specifications from their customers, as the quality requirements were support usage for many years.  However, we wanted as much boom as possible, in as short of time as possible, for a short burst of intensive work.  The companies were building heavy duty products designed to meet a wide variety of situations.  The boom that was needed was for a specific environment, with specific requirements, for a short period of time.  Some features could be left out, thus reducing the time to manufacture and thus releasing extra capacity to make more.

This is our experience over and over.  There is ALWAYS more capacity than you think.  You just have to do a little digging and challenge your assumptions.

Read more about how we achieved great results by challenging the assumptions in lesson 4 in my eBook, Achieving Top Performance Under the Worst Conditions: 7 Lessons Learned from a Disaster.

As always if, you have questions or comments please feel free to contact me by emailing me.

The post Challenge Your Assumptions about the Process appeared first on Projects in Less Time - Mark Woeppel.

If bad planning is responsible for failure, it stands to reason that “good planning” should be the savior. And by “good planning,” conventional wisdom means “more planning”: more pages of tasks, more lines of specifications, and many, many more details.

But after 27 of years as an operations analyst and process consultant on some of the most complex production systems in the world (think automobiles, airplanes and off-shore drilling, for example), I know that good planning – at least as it’s commonly understood – is not the answer: it’s the problem.

The devil really is in the details

What goes wrong? Most planning is based on an earned value systems model of work breakdown structures that make it relatively easy to assess cumulative costs. But the granular level of detail that’s good for accounting is not so good for project managers. By nature, work breakdown structures are linear, hierarchical – they do not reveal (or account for) the dependencies or “hand-offs” among plan elements, the things that must be done before subsequent steps can be fulfilled. While “good” planning does define the work, it doesn’t define the relationships or – just as perniciously – it attempts to define all of them.

But relationships are precisely what a project manager manages. Excessive detail creates a needle-in-the-haystack situation that inhibits corrective action by obscuring the truly relevant. The more details in the plan, the more difficult it is for people on the ground – project managers and their teams – to make the on-the-fly adjustments that are absolutely necessary for successful implementations.

Just as no one would advise commencing a project without planning, I am not advocating planning without details. But I do believe in setting the right level of detail: only as much as an organization can manage. Much of the project detail should be defined in simple checklists and work instructions – and not much more. When the level of plan detail is appropriate, project teams can anticipate the consequences of any change in a given line item; when projects are over-planned, consequences are impossible to forecast and managers become incapable of responding effectively. They become (to borrow a metaphor) lost in the forest, incapable of finding the right trees. As problems arise, the project becomes susceptible to delays. The project team can’t see the right course of action. Deadlines are missed, and to compensate, project meetings become long, tedious affairs in which managers defend past actions to deflect blame. The planning everyone once praised as “thorough” is now exposed as “unmanageable.”

Forget “plans” and focus on “plays”

In reality, project problems are not a possibility, but an inevitability. Things go wrong, and the more “things” there are in a plan, the greater the likelihood that small failures will lead to larger ones. That’s why more planning, in itself, can never lead to timely and efficient project completion. Burdened with details, large plans become boa constrictors that squeeze the air out of any given process, suffocating hopes for success.

The path to success, therefore, is not more planning, but a focus on effective execution that anticipates problems and has the flexibility necessary for addressing them. Consider football: no amount of planning can dictate success on the field; in fact, excessive adherence to a plan would constrain a coach, not help him. What the coach needs is the ability to implement plays – intelligent execution – appropriate to the immediate situation on the ground in front of him.

In order to execute intelligently, the coach needs:

A clear view of the situation: What is core to the status of the project? Good coaches/managers make the work and the obstacles to progress visible. When the project flow is clear to the team, they are able to direct resource time and effort to that smaller subset of activities that make a meaningful contribution to the project goal.

Common goals: There is no room for players trying to pad their “stats” when you’re trying to win the game. Success means perfect alignment among all team members. In a project, there is no such thing as a “balanced” scorecard. Replacing tactical metrics (productivity by discrete tasks) with one metric concentrated on the overall output aligns everyone’s work with the ultimate project objective.

Collaboration: The team must agree on the general strategy of action and their role in it. Instead of pursuing individual agendas, the team cooperates toward the common goals through transparent communication of the project’s status, and the necessary next steps for moving the project forward.

Planning for dynamic action

Planning will not, and should not, go away. But good planning doesn’t mean more planning. More planning defeats its purpose by burying the project team in detail it cannot manage. If we are to replace frustration with success, then smart project plans must fit the size of the team that drives the execution of the plan and manages the uncertainties of execution. Planning is not an objective in its own right, the plan’s sole purpose is to enable and guide execution. Better planning anticipates problems and gives project managers the tools they need to take corrective actions as they are needed. By substituting dynamic execution for static adherence to overly detailed plans, project managers acquire the power to make workflows work.

The post Mass-producing Frustration: Why “Good Planning” Often Leads to Failed Projects appeared first on Projects in Less Time - Mark Woeppel.

A more general application of probabilistic planning also considers the range of project costs and returns. This evaluation focused on the range of outcomes for key project dates, such as first oil. Quantifying the range and probability of outcomes can aid project planning and decision-making.

Probabilistic scheduling provides a method to quantify the risk management process. Quantifying the impact of potential risks improves decision-making affecting the control of those risks, and potentially on the overall financial viability of the project. It specifically aids the upfront recognition of critical issues and proactive management of those issues.

So how does better planning result in shorter project lead times? 

First of all, there are fewer surprises.  Having done a proper job of evaluating project risk and task durations, you’re prepared to deal with the “murphys” that always occur during project execution.  Since you’ve already prepared, you can respond much quicker, without wasting time.

Second, a good project plan moves these potential risk events off the critical path (if possible!).  By moving risk events off the path that determines project delivery, eliminating disruption to your deliveries.  That doesn’t happen without planning.

Third, the tasks themselves are stripped of the safety that most project plans have, with all task safety aggregated at the end of the critical chain.  Saftey aggregation allows you to manage the safety as a project level item, rather than letting it be dispersed to every resource in your project.  That means that you need less, and the overall project duration is shorter with greater certainty of completion on time.

Ok, I have a white paper that explains this much more.  Get it here.

The post Probabilistic Project Scheduling = Shorter Project Lead Times appeared first on Projects in Less Time - Mark Woeppel.