Did you know that most projects fail?  That is a stunning idea which, if you are like me, doesn’t match what you see.  For 2016 my organization’s metric for “Strategic Projects without Deficiency” was over 98%.  If 98% of the projects don’t have a deficiency, how could they fail?

Well, it depends on how you count failure 🙂

Looking at the same period, less than 28% of the projects I tracked actually completed based on the original constraints of time and budget.  All but a few went through at least one major re-planning session.  So, though the projects  were all delivered,  they were late, over budget, reduced scope or a combination of all three.  They were not considered deficient since they met the constraints of the last re-plan.

Okay, so Projects are progressive, and things do change, so technically, this was correct, but it also got me thinking.  What was the root cause of these re-plans?  What efficiency gains could we see if we were right the first time?

It sounds simple, but reasons why Projects go off plan are many, and worse, often subjective.  I tried to put the reasons in buckets:

Business Resources Not Available On Time    24%
Technical Resources Not Available On Time   18%
Business Dependencies Schedule Not Met     18%
Vendor Related Delays                                                 15%
Added Scope                                                                       15%
Technical Dependencies Schedule Not Met    10%

Though these are the reasons, these are not really the root cause.  Let s look a bit deeper into one sample project:

• Why were the business resources not available on time? Because the primary SME resources were out of the office.
• Why were the SME resources out of the office?
  They were in a trade-show and could not be working on the project and the Trade Show.
• Was this an unscheduled event?
  No, it was a planned event which was known for a year.
• Why wasn’t it considered in the Project Plan?
  No one thought about it during Project Planning.

Digging down, at least 5 of the 6 reasons come down to poor planning (Resource Planning : 42%;  Activities Estimate:  28%; Incomplete Requirements:  15%).  In fact, at least 85% of the Project issues were items in which better planning could have avoided.

Just think …. What would the efficiency gain be if we were able to deliver on-time and on-budget even most of the time?

But, gosh, all this paperwork, is it worth it?

Okay, we discussed the Benefit, but whats the Cost?  Nothing is for free.

The cost of better planning, is, as you can imagine, spending more time before executing the project.  Though it sounds great, especially for a, ummm, seasoned associates, but the  “Measure Twice, Cut Once,” philosophy many of us grew up with, doesn’t hold up when speed to market and experimentation means everything.

or does it?

There is a myth that all Project Management really cares about is paperwork.  Like most things, it is based on a grain of truth.  The PMI’s PMBOK has 47 major processes, and lists 72 different documents, 21 of which are associated with just Initiating and Planning the project.  Holy Cow!   29% of the documents are needed BEFORE we actually do anything of value!

This is true, as far as it goes, but of those 21 documents, 14 of them can come directly out of your Organizational Process Assets (OPA) and be standardized for your organization.  Tweaks, of course, can be done for the specifics of the project, but  the bulk of the work can (and should) be standardized.  Sure, planning takes work, but really the time isn’t as bad as what some people believe, especially if a good library of OPA is built.

Now, lets talk about capturing requirements …..

Since I am in the IT world, many people equate this planning work to relate to the “Waterfall” SDLC model.  Both the PMBOK and Waterfall do share some common aspects (the belief that the earlier in the process something is caught, the easiest it is to deal with it), it is easy to see the connection, but is it really possible to capture all of the requirements up front?

My experience tells me that End-Users rarely know exactly what they want, and more often than not take requirements off a pre-selected product.   When the customer knows what they what, unless it can be delivered in less than three months, their interest level starts to decline.  This is why “Agile,””Progressive Elaboration,” “Prototype,”   “Rolling Wave,” are all good practices.  It doesn’t stop us from having to define high-level requirements, but all of the Phased methodologies are great for many projects.

Some projects, like ERP installations, are much more challenging.  In many cases, new processes are being developed (or best practices adopted), and the business doesn’t see the value until a large percentage of the project is complete.  I have my own thoughts which we will discuss in a separate post on handling progressive elaboration under these circumstances.

My conclusion is that the costs associated with formal project management is worth it.  If 85%  of the projects came in as expected, even at the cost at an additional 2 weeks of planning, a year or more of FTE would have been saved (much less good will, etc.)

The trick is making sure the Organization Process Assets are built up, and that the management processes are “right sized.”    All applicable processes have value, but depending on the size, complexity, risk, the processes can be minimized.  All projects, for example, need a Change Control Board, but that Board could be just the sponsor and the team lead (for a simple project).  The OPA material can have this all spelled out so everyone has the right expectations (and much of the material already created for the Project Manager).

Your thoughts?