We had just laid out our plan. It included how we would handle any late arriving deliveries and also how we would incorporate any late added requirements.  The business manager spoke up in an incredible and disbelieving voice “you are planning to fail?!”

Yes, if you want to look at it that way, we were planning to fail.  More accurately we were planning how to handle the things that normally happen in our projects.  Inevitably, some features are not delivered on time.  Some were delivered by the milestone but were so defective that they were essentially the same as not delivered (but with the overhead of trying to treat them as a delivery).

I will admit that in this organization it was classic that the schedule we were given (note, we were given it, we did not provide it to management) was very aggressive.  Teams were so use to this environment that they generally agreed to whatever schedule they were given, because we never met those schedules.  They knew they would have more time and even if they turned in their feature, they would have plenty of time to tweak it because other features that were needed would not have arrived or would not be working and so no one would actually use what they delivered.

To fix this situation, we just accepted what was going to happen and we planned for it.  What we were effectively doing, which few folks realized, is that we were taking a project that had been monolithically planned (waterfall style) and turning it into an incremental development and delivery project.

Unsurprisingly, the teams in the past had informally worked with each other to get incremental delivery of functionality so that they could get their part of the projects working as others got parts of their projects working.  What we did was to adopt this simple time honored technique as the way we did business and we used the whole length of the project as a timetable which within we would do these incremental deliveries.  By setting up the plan to allow “late” deliveries and late requirements we simply admitted what was going on and adopted, somewhat surreptitiously, a new project approach.

So relative to the classic waterfall approach, which was the prescribed methodology,  we had planned to fail.  Relative to an incremental approach, we planned to succeed by planning for the increments.  Relative to good risk management, we had simply planned for “things that could go wrong” when in fact we knew that they were things that had to go wrong, because we had also planned to fail by using an aggressive schedule.

Yes, we delivered on time.  Part of that success was because we also got more time inserted into the project, in response to a predictable crisis (a failure), so that the total time we had was closer to how long projects really took.  However, the extra time would not have been as beneficial, if we had blocked, in the classical manner,  project tasks because waterfall style milestones had not been achieved in the prescribed order.

For more, see Project Management Crisis? Hurry, But Do Nothing

In project management, we are always planning for failure, but we don’t obviously plan for the project as a whole to fail.  Failure is something we become very familiar with and our ability to handle things that go wrong comes with experience and the willingness to plan to fail.

Does your planning or risk management include what to do when typical things go wrong?