Chemicals & Materials Now!

From basic to specialty, and everything in between

Select category
Search this blog

Planning Backwards™, Part 2

Posted on February 2nd, 2018 by in Chemical Manufacturing Excellence

checkmate-1511866_640

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

Reality meets theory

To answer any of the questions, the theory needed to be reduced to practice.  At this point I had moved from industry to academia and was given the opportunity to mentor seniors during their cap-stone project.  Part of their learning experience was to face a real project including complexity, politics and ambiguity.  They were also responsible for both an oral and written report at the end of the semester, due around finals week, right before graduation.

This was where Planning Backwards™ was formally implement, though it began years earlier.  I would start each semester by explaining to the students that they owned the project, and I was their guide.  We talked about where they needed to be by the end of the project, what that looked like and where it was.  Teams would quickly converge that they wanted both reports completed the week before finals, to avoid compressing too much into that last week.  They also didn’t know how to get there.  We broke the semester in half, looking at the midterm and writing down where the team needed to be to reach the final reports.  Then we divided it in half again, same process. Where did we need to be to reach midterms?  This continued until we were two weeks away from today’s date.  As each cycle progressed, the details grew and grew, and the students would get more and more excited!

Planning Backwards Figure for Part 2

The picture shows what the beginning of a semester looked like, based on a snapshot one of the students took, with December’s destination not on the board.  I put initials over their names, but notice how they each took responsibility for tasks, and how they estimated they would not have a well-defined scope until a month after the project started.  They were learning to manage ambiguity.

The student teams learned that though very few details may exist in the beginning, they could describe the outcome they wanted.  This outcome was known to a sufficient level of detail it allowed them to predict what was needed in the next week or two, as long as they worked backwards.  The process was similar to scenario planning the military uses, but run in reverse.  In much the same way, the students quickly identified that the complex aspects of their project later in the semester could combine to create some surprising tasks early in the project!

Though the time interval was controlled by the students, they quickly settled on two-weeks.  It turned out that the two-week segment was perfect because not enough changes happened in one week to justify more planning, but there was enough learning to necessitate a course correction in two weeks.  At roughly two weeks the team would re-converge, and look at what they had accomplished.  They would then take a look at the end of semester goals, make any adjustments and work backwards until the two-week mark.  Then off they went again.

When reflecting back on what worked so well developing polymers, I noticed a behavior pattern.  We didn’t know how to plan out several months of tasks, but we knew how to get from today to next month really well.  We also kept the target in mind, progressing steadily towards it while talking with the customer to learn what requirements they felt were important.  We were incorporating information as we learned it, always planning backwards to the product delivery date.

It was this pattern of constant communication that I guided the students towards in their early meetings.  They quickly realized that to coordinate, a communication framework was needed.  They chose Google Drive and specific Apps to stay connected, something they commented later on they would not have typically done on the first day of a project.  Spreadsheets were drafted, and meetings scheduled to gather information.  Though they were developing a business case and engineering model for a solar grid, to me the project felt a lot like developing a polymer; it was both fast and fun. Then the scope changed.

As the semester progressed, about half way through there was a major scope shift.  This was a great learning experience for the students.  It was the first time they faced a project taking a hard-right turn, and being in the driver’s seat the lack of control was an unsettling experience for them.  I was curious how Planning Backwards™ would work, this was its first real test outside of the chemical world.

They identified the shift quickly, and adapted.  Their final goal was different, and they listed out the new requirements. The adaptive structure of Planning Backwards™ forced them to list out new activities tied to the new requirements.  They were able to see that a series of adjustments allowed them to refocus and still meet the deadline. The limit of detailed planning to only two weeks allowed quick adaption.  The system worked and though they weren’t happy about the shift, they knew what had to be done and focused on the project as a team.  I should point out that this last part was significant for moral and momentum, and I didn’t realize until much later why.

I tried it again the next semester, using the same introduction.  Starting with the end of the project and defining as much as possible.  Dividing the timeline in half and defining what we knew about getting there.  Breaking the project into smaller pieces until we reached two weeks out.  The team operated much like the first team, adapting to new information and adjusting as needed.  This team also took their project to completion.  One student made the observation very clearly near the end of the semester, “At the beginning we didn’t know how to start, by the end [of Planning Backwards] we knew what needed to be done in the next two weeks and that’s all that mattered.”

Why did it work?

If strategy is where you are going, then planning is how to get there.  Planning Backwards™ works because of its strategic focus.  The outcome of the project is where the process begins, and then everything is shaped towards it.  The planning portion is only several days out, allowing for easy shifting and can be adjusted if the team feels a pivot is needed. This is different than more traditional project management tools that place the bulk of planning up front.  Traditional methods make the assumption that you know the bulk of a project’s information before you start.  This works well for projects with low ambiguity, but causes havoc for projects that are delving into the unknown.

The Project management Institute publishes the PMBOK® Guide.  It is a Project Management Body of Knowledge that is studied and tested against for a professional to earn a PMP®, the Project Management Professional certification.  The PMBOK outlines five ridged and linear process groups.  These include Initiation, Planning, Executing, Monitoring & Controlling, and Closing.  This approach works really well for traditional projects that have complimentary structure and lots of known information. Fast-paced projects with high ambiguity are like a flooded stream, bouncing around and constantly changing direction.  Trying to manage such a project following the PMBOK would create a situation where people turn on each other with accusatory attitudes as the scope shifts and resource needs change.  The project will quickly become schizophrenic.  Unfortunately, I’ve observed this several times when classically trained project managers try to plan, then lead a team in fast-paced, ambiguity heavy projects.  Watching a team crash and burn is upsetting to the most grounded professional.

Planning Backwards™ is more agile than Agile.  The meaning of agile is to move quickly and easily, and for projects this means to rapidly adapt. The goal of Agile project management is to integrate the product’s requirements as they evolve through a collaboration among the team and customer.  However, one of the tenants of Agile is thou shall not shift in mid-sprint.  Once set and the sprint is started, no additional requirement can be added due to concerns that the velocity of the team will be reduced. The truth is, interruptions are a part of a project just like they are when talking with a five-year old.  Two things can happen when something significant comes up during a sprint and the team does not shift until later.  The first is that time can be wasted, which I argue is more valuable during a project than any other commodity.  The second is that the team can actually loose morale.  When the team knowingly continues to head down the wrong path, members can lose commitments to each other.  Though subtle, over time it can lead to trust issues and team-dynamics problems.

That was the learning from the first student group that took me a while to understand.  When the student faced their scope shift, and used the method to adapt they maintained momentum.  Though the shift was unexpected and the sudden change was unsettling, they knew how to adapt to it.  Like facing a crisis, they approached the unknown using the same tools they had been practicing to manage ambiguity.  The results were their morale and momentum was maintained!  Planning Backwards™, replaced rigidity with a focus on adapting to what the team was learning.

Planning Backwards™ has enough structure to maintain focus with the flexibility to adapt rapidly.  This allows the team to stay on target as the outcomes are defined as the project is executed.  It also provides a way for the team to adapt to changes that are uncovered, the tactical side.  Since teams only move as fast as they learn, breaking the planning down into small timelines allows the teams to focus on digestible chunks information.  Tasks can be structured in a flexible work breakdown structure that changes at the same pace as the project evolves.  The same mechanism that allows the team to be flexible and adaptable is also the same one that keeps the team focused on their outcome, the regular planning.

I wasn’t the only one!

I’ve long suspected that other people working in the fast-paced product development world had to come to the same conclusion I did and wondered if anyone developed something similar?  I’m sure others have had to manage ambiguity and over time gravitated towards a process that was successful.  My answer came from a very unexpected place.  I was attending a conference in San Francisco that focused on disruption and a variety of industries were present.  I was not focused on the conference too closely because my main focus was to coach a colleague on how to prepare for and work a conference. Then two things happened, first the Chief Innovation Officer of Hearst made a presentation.  Hearst is a media and information company founded 130 years ago, and the CIO mentioned during his presentation how he hated Gantt charts.  He commented that failure was an expected output, and that his team’s focus was to learn and pivot.  His goal was creating small experiments to test business models, and his project planning approach was built around learning and avoiding complex plans.

The second thing that happened at the conference was when a Director from Netflix spoke.  She talked about misaligned incentives for product development teams, and her issues with Agile.  She specifically took offense to Scrum’s rigid structure of not allowing shifts mid-sprint.  She made it clear that traditional project management places more value on hitting a deadline than building the right product, and as a result Netflix didn’t use project managers.  She supported her observations with examples, and explained that when you really look at the cost of traditional project management it costs money, it doesn’t save it.  She ended with an exception that Netflix does use project managers on externally, contracted projects that have hard deadlines.

In both cases Hearst and Netflix were working in the area of disruption, having to adapt to the world around them.  They were confronting ambiguity, and learned that traditional project management methods didn’t work.  In both cases, they knew where they wanted to go and needed to adjust in-situ.  They were shifting their approach real-time to adapt to new requirements as they became available.  I shared lunch with the Netflix Director and compared my experiences teaching and using Planning Backwards™ to hers developing software.  They were surprisingly similar!

In a world that is experiencing an ever-increasing rate of change, rigid tools become obsolete quickly.  Being able to adapt to the change and refocus on new goals is more valuable than hitting a deadline that no longer matters.  High ambiguity projects that keep pace with this shuffle need to be managed with an approach that evolves in lock-step.  It needs to rapidly adapt and so far from polymers to solar grids, Planning Backwards™ is the best method I’ve found!


 

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