The earlier the customer sees your work, the earlier you’ll find out if you’re on track.

By MARK RIFFEY for the Flathead Beacon

When I was young and a bit green at project management, I somehow managed to have responsibility for a number of big projects. Some came in OK, some never seemed to get rolling properly, some were late, and some seemed to take on a life of their own. A latter group tended to include projects whose scope was a moving target or had many unknowns.

The worst of these have a way of being the unknowns you never see coming, often gestated from a family tree of assumptions and incorrect or changed information.

Secretary of Defense Rumsfeld famously said that decisions are made while dealing with “known unknowns and unknown unknowns“. Anyone with large project experience knows exactly what he meant. Interestingly, Rumsfeld credits a NASA manager with the terminology.

Project management requires discovery

The software business has a sketchy reputationfor delivering projects on time, despite a lot of internally-driven improvement over the last two decades. This reputation is sustained by the memory of failures of very large software projects.

Agile project management and related methodologies have helped a great deal. Many of these methodologies can trace their roots back to Lean manufacturing / management methods taught by Deming in Japan after World War II.

Success with these management strategies depends on early discovery of issues, challenges and changes in the information driving your decisions. This, combined with our human tendencies, is part of why the MVP (minimum viable product) construct works. The earlier the customer sees your work, the earlier you’ll find out if you’re on track.

Usually, you get to decide how this discovery occurs: organically as the project work occurs, or in advance, thanks to discussions of expectations, requirements and manufacturing options during the design phase.

Poorly managed projects are often started without sufficient discovery and discussion. Even today, many projects are started and finished with very little advanced thought. No one would build an airliner as it rolls down the runway. While that sounds a bit ridiculous, this is exactly what happens.

The context of the design is critical as well. Work done in a vacuum, even with the best of intentions, often produces incorrect assumptions thanks to the aforementioned unknown unknowns.  The project’s scope is an known unknown and the unknown unknowns are often a simple matter of lack of experience with the environment where the completed project will be used. The gap between expectations and results matters whether you’re building a crescent wrench, a software program or a Mars rover.

When will it be done?

While you may not have an accurate answer to that question, better design will improve your ability to give an estimate that someone can actually trust.

Better design? How?

The most common problem I see is not breaking things down into small enough pieces of work. Granularity is critical to the design and estimation of highly detailed / technical work. The volume of dependencies and unknowns in this type of work compounds the miscalculations and omissions resulting from a lack of detailed analysis, resulting in inaccurate estimates and missed expectations.

An estimate of days, weeks or months without a detailed breakdown of subtasks is symptomatic of the problem. I find that estimates require subtasks no larger than two to four hours to create a design that’s thought out well-enough to meet expectations, discover obstacles in advance, while producing a reasonable estimate.

But it’s not perfect!

Human nature also creeps into the equation: We like completing tasks.

It’s such a part of our us that people tend to focus on less important tasks simply because we can complete them before the end of the work day. We feel accomplished despite leaving big projects untouched.

If you’ve ever written things on a checklist that you’ve already done so that you could check them off, then you know what I mean.

Rather than fight the fixation on small projects that we can “download” and complete in a work period, feed it with subtasks of your big, important projects that conform to the need to complete something the same day.

Life has a way of being incredibly creative when it comes to finding ways to delay a project’s completion. Build these project management tactics into your design, estimate and build workflow so that you can get better work done faster – even on big projects.

Want to learn more about Mark or ask him to write about a strategic, operations or marketing problem? See Mark’s site, contact him on Twitter, or email him at mriffey@flatheadbeacon.com.