Planning for the Unknown Unknowns

Over many years of developing software and building user interfaces, I’ve seen numerous shifts in technology and been present for multiple evolutions in the way developers craft quality software. Yet, while the development tools and languages available to developers make them increasingly capable, software projects still consistently run into trouble; they miss deadlines, hit intractable technical obstacles and run rampantly over budget.

As an independent software consulting company with broad capabilities and deep domain knowledge, my company ICS often gets the call when a client project goes south. Sometimes, the problems are identified early and course correction is relatively easy. More often than not, the project has reached a point when numerous systemic issues make recovery extremely difficult.

We’d prefer to devote our energy assisting our clients in creating great products rather than recovering from a software development project that has gone off the rails. Thus, I propose planning for the unknown unknowns as the best insurance.

What are the unknown unknowns? One observation I have that is universally true is that on any development project, change happens. Whatever the unknowns are, change by nature has a disruptive cost and the later the change occurs within a project the more disruption can occur. This disruption increases time, cost and accelerates individual staff workloads to manage that change, all with no assurance you will make your delivery date.

So how can you possibly plan for the unknown unknowns? My first recommendation is to start each project with at least 20 percent more staffing than you think you need. That way, when you hit the unknowns you have slack capacity to absorb the changes rather than trying to react and ramp up.

I can already hear the snickering: “If I overstaff by 20 percent the project will never be approved” or “We’ll just be asked to implement twenty-percent more features.” Nevertheless, if you can sell this 20 percent overstaffing insurance to your management, your project’s chances for success -- on-time and on-budget delivery -– increase dramatically. (N.B.: I would never recommend deceiving your management by padding your estimates by 20 percent (wink! ;))

My second recommendation is to have a super-clear design, scope and implementation plan and stick to it. In some way, this is common sense. Every project has a well-thought-out plan and is often vetted and approved before it starts.

However, have you ever really tested your project’s critical constraints before commencing, or made assumptions about things that might bite you later? Two enlightening examples come to mind:

• A client committed to specific hardware, which, ultimately, could not support the performance of the user interface (UI) that was envisioned. The performance of that UI was critical to the overall user experience (UX) and the hardware ultimately had to be redesigned.
• Half-way through the implementation phase it turned out that adoption by some major customer required a feature that was not currently in the spec. The scope of work expanded dramatically, resulting in compromises in core functionality that had to be rectified before the product could be shipped.
• (insert your example here…)

In both cases -- and no doubt in the example you added -- the project’s chances for failure have increased dramatically. Inviting input from all stakeholders, including the developers responsible for 
implementing the project will help focus your design on the important aspects and avoid nasty surprises.

An outside audit of a proposed project is always recommended and we’re thrilled when our clients ask us for our input early in the project-planning phase. Because of our experience with hundreds of 
projects, we can often anticipate issues that internal stakeholders might not and offer recommendations for implementing effective solutions.

I believe that if you invest upfront and commit resources early on in your project, before costly irreversible events occur, you will maximize the potential for greater success. Front-end loading a project allows product management teams more flexibility to adapt to change quickly while the costs are low. Admittedly, to front-load a project will add costs and time to the project. In our experience, these costs are minor compared to the alternative of reacting to unknowns and the overall cost of time and impact to the project at a later stage.

The strongest predictor of project success is the level of development resources front-loaded on a given project. At ICS, we practice this common-sense approach on our own internal projects and we recommend to our clients the same.  

It is much easier to let go and flow downhill toward the finish line than to play catch-up in an uphill race. Planning for the unknown unknowns will reduce development time, costs and ultimately allow for a better product delivery on time and on budget.

We can't predict the unknowns, but we can plan for them.