Are you Plexecuting?

Plexecution was a term I first heard from the woman who ran the Program Management Office in an IT organization I led. I’m not sure if she coined the term but it was her way of asking whether we had done sufficient planning or whether we had launched into execution and then decided we really ought to do some planning.

Now planning ought to continue through out a project so there is nothing wrong with some degree of plexecution. Deming’s famous plan, do, check, act mantra emphasizes the need to re-plan during the check, act part of the cycle. The Project Management Body of Knowledge illustrates that planning should occur to some degree through the life of a project as illustrated by the attached diagram from PMBOK version 3.  However when the hump of the planning effort coincides with or lags the execution hump you are plexecuting to a dangerous degree. We all know that planning is inexpensive compared to the rest of the project and eliminating flaws in our projects through good planning is a very wise investment. 

Many projects suffer from plexeuction in some key areas and knowing where these planning gaps are likely to occur can help you avoid the risk of plexecution. Some of these areas are common to all projects and some are particular to IT projects. I’ll look at a few of the common ones in this post and will list some of the IT ones but explore these in detail later.

The boat in the basement syndrome

The apocryphal story tells of the amateur boat maker who builds a beautiful craft in his basement only to discover that it is too large to fit through the basement door. Either he demolishes a basement wall or dismantles or cuts up his brand new boat.

Many projects do not plan for the deployment of the product they produce. Perhaps you have a great software application but the only way you have to deploy it is to visit tens of thousands of desktops which is impossible to do in a timely manner. Or you’ve invented that better mouse trap but you have no way to get it to market.

Make sure you plan for deployment upfront.

Where is the fundamental science?

OK most projects are not out to win a Nobel prize but most projects do contain activities that we have never done before or we must do to an extent we have never experienced. You’ve all seen the cartoon where the diagram of the project plan converges on the box labelled “and then a miracle happens”. So if your project depends on fundamental science you had better identify these areas at the outset, develop a strategy and test this out before you incur the expense of all the tasks you do know how to do. Otherwise you will wind up at the “then a miracle happens” box and it will be at the end rather than the beginning of your project.

Be careful with the activities you have done before  but not to the extent required. Say you’ve onboarded a hundred employee as part of an acquisition but the current project requires you to do the same for a thousand employees. What might have worked happily for a hundred may fail miserably for a thousand. I was involved in an SAP project where we had to deploy the SAP desktop client to over 20,000 desktops in a very short period and relied on another part of the organization to do this. Needless to say this got a lot of our planning attention.

Do the fundamental science early in your plan.

It would have been nice to have a strategy!

During the lead up to the World Exposition in Vancouver in 1986 tenders were called to build a new bridge at one end of the site. The winning bid far outstripped its competitors in both time and cost.  The winners proposed to build the bridge using a method of continuous casting of concrete — a relatively new technique at the time. It is very difficult to change such a strategy mid project. Getting the right strategy at the outset can make a world of difference and can change outcomes by orders of magnitude.

Many projects start either implicitly assuming a strategy (usually the way we’ve always done it) or worse still begin without an overarching sense of how the project will be landed. I believe that the project charter should provide a statement of project strategy (e.g. we will produce the building by manufacturing components off-site with final assembly on site, or we are going to use a test driven approach to software development). and that this should be thoroughly debated and planned at the outset.

Perhaps this is even more fundamental than planning and maybe it deserves its own term — strexecution.

We have phases for a reason!

Each phase of a project should have it’s own little graph like the one from the PMBOK. We should initiate, plan, execute, monitor and close each phase as if it were it’s own little project. Many projects, in my experience, simply move from one phase to another with out revisiting the plan. How much better to properly close the previous phase, formally initiate the next, and revisit the plan before launching into execution (or plexecution if you don’t do these things).

If you are a project sponsor or sit on a project steering committee you have a role to play to ensure that project transitions properly from one phase to another. Ask what lessons could be learned from the previous phases. Ensure the project risk log is updated and insist that the project plan is revised as appropriate.

Don’t start plexecuting the next phase.

Some IT areas where planning often lags

There are some usual suspects when it comes to IT projects. I’ll list them here but write about them another day.

• Testing in all its forms but especially non-functional testing and end user acceptance testing
• Data conversion
• End user training
• Stabilization and sustainment

Let’s just get going — this is all analysis paralysis

I am very results oriented. I like to see things happen. I am eager for outcomes. However what I have learned is the fastest, most certain path to results leads through good planning before execution.

As they say less haste more speed.