An Advanced Course On Project Management

On time project completion is a key area of interest to me. I find that delivering a project or product on time is often the first real step up in project management maturity. Once we can get to on time, then this stabilizes the organization enough for other initiatives to assert themselves. These other initiatives include being lean, increasing productivity or quality, continuous improvement, etc.

One of the key questions I always ask, though often in a round-about way, is are we delivering projects (products, services, etc.) on time? On time means that we plan to deliver them at a set time and then we do. The second thing I then ask is to see the evidence (past planning records, briefings, schedules, etc.) — the data — showing the on time completion or delivery. Here, when asking for data, is where I’ll see a quick or subtle backing off of the claim of on time delivery. From here we usually work forward to brutal honesty and to baseline what our on time delivery really looks like.

Most organizations I’ve worked with didn’t regularly or often ever, deliver projects and products on time. Now, since most of these were my employers, I like to say that I’ve been either cursed or blessed for over 30 years with working with poor performing organizations. Some of these organisations, in government and in the commercial world, were world leaders at what they did. I kept wondering how we could be world leaders but be so bad at managing our efforts that made us leaders? Something wasn’t quite right in this dichotomy. Most of the research and studies I read confirmed this notion that most projects, software and IT projects in particular, were not considered successful (by many measures, not just on time). Maybe, I thought, this is just the cost of being good at what we do — by failing often.

Two key findings came out of the “what should we do differently.” The first was that it ranged widely over the domain of things to do (e.g., tell more people exactly what to do, let people decide what to do, more process, less process, “put me in charge”, etc.). The second was while there was a nice collection of ideas to consider, rarely did I find in that collection of ideas the core notions that were eventually used to get us to on time delivery (e.g., use past performance, trust people to do their jobs, put quality first, etc.). Instead, the range of things suggested were often more tactical — directly impacting daily work — and less of strategic overall notions that help teams blend together and be greater than their individual parts.

This dichotomy helped me understand how good organizations could get stuck. I’ve seen many organizations that asked consultants to come in and help “fix” the problems. Some of these consultants were great, came in got good feedback from everyone, and made some very good suggestions to senior management that then got implemented. When these suggestions were implemented, most folks said that things had gotten better. What was interesting was that measures of performance (such as on time delivery, but also task completions, defects reported and defect repair rates) didn’t show much change. The “intervention” was a success but the organization didn’t seem to make much headway.

My observation was that effective leadership and a fundamental insight into what was needed to move the organization up to the next level of performance wasn’t achieved. We did everything right, or close enough to any one’s notion of right, but didn’t quite get there. What was almost always missing was first a deep enough understanding of the notion being implemented (e.g., CMM, Six Sigma, ITIL, agile, etc.) We didn’t truly “get it” and understand how it would make a difference and hence how to implement it. The second was almost always not enough leadership. We were missing an individual or two — with sufficient understanding of what to do — with the drive, leverage and courage to make it happen. These individuals rarely needed to be senior managers, but often just someone well respected enough that people felt safe and confident in changing how they did business as guided by these individuals.

If we feel we are managing our projects correctly but they just don’t seem to be as successful as we feel they can be, then consider two additional steps. First, kick up our level of understanding on what we are doing and why were are doing it. Secondly, empower and support our leaders and project managers who will drive the efforts. We may still fail, but we’ll fail closer to our goal and with a growing certainty that we’ll soon succeed, spectacularly.

Do you have an example of success that came out of what looked like confusion or failure?

One thought on “Project Management Success by Failing Often”

Comments from around the web:

Ted Lester • The failures I’ve seen have primarily been from overcommitment. This takes the form of insufficient expertise — not knowing how parts of the project will be accomplished, but forging on regardless.

Iridium’s failure provides multiple examples of “betting on the come”. Besides other unresolved, it contained two major ones that made the dreams for success unrealizable: Limited bandwidth, and a 2 db link margin. Bandwidth, in this case, refers to total system data carrying capacity. Link margin a measure of communications reliability.

Bruce Benson • Ted,

Thanks for the insights on Iridium. Iridium is a good example of where technical challenges and risks predominately drive the success (or not success) of the effort. Too many mundane terrestrial efforts that fail are attributed to technical details (requirements, expertise, problems, etc.) where a closer look suggests that management decisions (aggressive estimates, ignoring risks, etc.) were more certainly the root cause of the lack of success.