Chemicals & Materials Now!

From basic to specialty, and everything in between

Select category
Search this blog

Planning Backwards™, Part 1

Posted on January 31st, 2018 by in Chemical Manufacturing Excellence


This post is written in two parts. The first explores a journey I started years ago trying to understand better ways to manage chemical development projects.  The second part details experiments run in the classroom that combined to form the framework of Planning Backwards.

The classroom

Many things that are taught in the classroom do not transfer well to industry.  Project management is often one of them.  The classroom is focused on developing a schedule, and industry is interested in getting things done.  These two can exist in harmony, but often the situation where a professional needs to reach into their toolbox and select a different tool are glossed over.  Instead, a narrow set of tools such as Gantt charts, critical path analysis and activity dependencies are focused on.  In contrast, industry wants to move quickly and the excitement of jumping in usually overshadows the value of planning.  Then as the scope shifts, the focus shifts to adapting to the new situation and any planning is outdated.  A common industry phrase is, “The plan is obsolete as soon as it’s created.”  There needs to be a better way to adapt to projects in flux while still capturing the value of planning, capturing the value of both.

When I teach project management I follow a standard curriculum that teaches students to plan forward.  Students combine what they know about activities, building a timeline that propagates forward until a completion date is determined.  When significant parts of the project are expected, milestones are established in the timeline.  Extra time known as slack is added to account for both unknowns and mistakes.  Then a Gantt chart is created to show how the work breaks down into smaller pieces, and the dependency between activates. At this point, most of my classes shift to focus on executing the project, with an emphasis on budgeting.

This is the right knowledge that students need to start with.  The lessons are simple and straight forward, and are the basis for many advanced project analysis techniques.  This framework also assumes a project will follow a model similar to what is taught in class.  It’s probably no surprise that construction projects are common examples, as building a house follows a simple and known sequence.  You have to learn what the rules are before you can break them, because the real world is much different than the classroom.

Saying one thing, doing another

In over 15 years of professional work developing products and managing various projects, none of my projects progressed according to plan.  Chemical development was particularly difficult due to the high ambiguity in the process.  At one point I was convinced that the best place to develop new polymers were universities, and industry should only focus on adapting platforms for different applications.  However, companies continue to develop new products and take them to market successfully, including the ones I worked for.  Several years ago, that forced me to consider, what was so different from what I was teaching in the classroom and what was going on in industry?  More disturbing, were the efforts in the classroom leading students in the wrong direction?  Was I hypocritical, saying one thing and doing another?

One area of industry that heavily uses project management is construction.  The way buildings have been built changes slowly and the basics have been the same for years.  The foundation is laid first, then the walls go up, followed by electrical and plumbing, then the drywall is hung, followed by flooring and finishings.  This basic flow is the same for residential, industrial and commercial structures.  When planning a project, there are decades of data on how long it will take per square footage to build a building.  Building codes are public knowledge, and permit cost and time can be closely estimated.  So much is known that contractors can even supply a bid in a week or two once basic information is known.  This knowledge of how long things take and how much it will cost are perfect to build a schedule and budget around.  It’s not a surprise that construction examples are commonly used in the project management classroom and more advanced classes look at construction case studies.

What else can I use?

Construction is a very different industry than developing polymers.  There are a lot of unknowns in the chemical world, even Phd’s with years of experience often struggle to explain why a certain chemical change happens without extensive analytic data.  The chemical development process tends to be repetitive as more is learned, like following the threads on a screw.  I have yet to meet anyone who can predict what a formulator will produce without running an experiment.  Knowing these things, I decided to screen common project management tools against the ambiguity and experimentation that is common when developing a new chemical.  My hope was to see if there were any good fits, along with comparing how I managed projects back to what I was teaching.

The first stop on this journey were Gantt charts.  I build many of them, they are great to communicate with management where you are, and what is coming.  This works well because management tended to ignore the details and focused on milestones, and the graphic representation was easy to understand.  However, Gantt charts are miserable to communicate with your team once there are roughly more than 30 lines of tasks.  People cannot maintain large amounts of complex information in their short-term memory.  This gets worse with large teams spread across the globe.  There are some project managers I know who’s daily work is to update the Gantt chart so the hundreds or thousands of professionals working on the project can get a constant feed of the updates.  This type of project management tends to also include earned value analysis to help track budget burn rate compared to actual work completed.   However, chemical development work is typically completed by small teams and is iterative in nature.  My interest quickly shifted away from these traditional methods.

The second place I looked was at critical path analysis.  I had a colleague who was very passionate about critical path analysis (CPA) also known as critical path method (CPM).  The idea is that there are several parallel activity chains that need to be completed to finish the project.  These actives are sequenced and look like pathways through a park when drawn on a whiteboard.  The longest sequence of activities is the critical path, and where a project manager will focus the majority of their effort.  This wasn’t helpful though.  The CPA approach assumed that you know what actives are needed, when they are needed and how long it will take to accomplish them.  The cyclical nature of polymer development did not have enough information to build a sufficient model.  If there was a history of project knowledge, this might work and reflecting back on past projects took my journey in a different direction.

What were we really doing?

Before I took my next step, I paused to think about what we knew about a project before it started, what information was used to plan.  What were we actually doing when we guided teams through the product development process?  How were we managing the ambiguity of not knowing exactly how our product needed to perform? One of the things we often spent time doing was to relate to past experiences by telling stories.  We had a database in our heads that we accessed to compare current challenges with past projects. I thought a lot about what if we had access the information for a decade’s worth of projects?  Could that information be used to predict the outcome of future projects, in a structured method?

There is actually a project management technique based on this approach, developed by the NAVY called PERT.  PERT stands for Program Evaluation Review Technique, and is more of an analysis approach than a management tool.  It was initially used to help predict the time it would take to complete a project that had never been done before, but had activities similar to past projects. The process gathers estimates for similar activities including how long it would take in an optimistic, pessimistic and most likely condition. Based on those estimates, a simple weighted average is used to estimate how long it should take to complete the task.  Though any one estimate is probably wrong, the accumulation across the project balances out to provide a reasonable expectation for how long a project should take and how much it should cost.  To do this, significant data is needed.  The assumption is that there is time to gather data or an existing database of past projects to draw from.  We did not have the history of data to draw from, beyond what we remembered.  We were also moving so fast, there was not time to interview and gather the information among other engineers and chemists.

Agile was gaining popularity in project management circles, the software world had shifted to this model by breaking planning down into smaller pieces.  Software is hard to get right, it works well if it can be coded in pieces, demonstrated to a customer and then feedback incorporated in a loop.  This was similar to how new polymers were developed, managing a project like looping around the threads on a screw in an iterative process.  Certain targets were initially created, then later ones and final performance criteria was used to screen candidates.  Could the basic concept of agile, and the background information of PERT be combined to form a new method?  Could it be formalized, taught and reused?  More importantly, could the method address the high ambiguity of projects like chemical development, while preventing the project from drifting too far?


All opinions shared in this post are the author’s own.

R&D Solutions for Chemicals & Materials

We're happy to discuss your needs and show you how Elsevier's Solution can help.

Contact Sales