Showing posts with label project leadership. Show all posts
Showing posts with label project leadership. Show all posts

Tuesday, June 21, 2011

Impediments to Accelerated Projects: The Discipline Block

In a recent presentation I gave at the SAVE International Conference in Portland, Oregon I elaborated on five impediments (or blocks) that limit the opportunity for accelerating projects.  As I described in the presentation and the conference paper, every project involves a system that is larger than itself.  And since most approaches to accelerating projects tend to be based on partial solutions, all too often we end up settling for 5% to 20% improvements in project cycle time, rather than the 40% to 80% improvements that are possible when a systems approach is employed.

In this blog, and several subsequent blogs, I will share some of what I have learned from research as well as my own field experience about the barriers that stand in the way of realizing the full potential for accelerating projects—barriers that are typically masked by suboptimal solutions that fail to take into account the larger system of which the project is a part.  I will begin with the Discipline Block.

Anyone who has passed through the hallowed halls of academia is familiar with the “knowledge silos” that define the boundaries of colleges, schools, departments, and degree programs.  Yet in the real world, we know that boundaries defined by academic disciplines are artificial—artifacts of an age when knowledge was easier to codify and categorize, yet continue to be propped up by institutions where courses, semesters and degree plans are designed to serve an academic end-game.  Nevertheless, the academic process is so effective in shaping our thinking and the tools that we become adept at using, its talons can be difficult to break free of.  This describes the challenge we face when the academic discipline we were immersed in during our “school years” becomes an impediment to seeing opportunities for accelerating projects that do not fit neatly within our discipline comfort zone.  Or as Mark Twain put it, “When the only tool you have is a hammer, you tend to see all problems as nails.”

In his thought-provoking book, “Filters Against Folly,” Garrett Hardin describes mental filters as having two characteristics: they allow some thoughts and ideas in and they keep some thoughts and ideas out, intentionally or unwittingly in either case.  In the context of accelerating projects, the latter often present the greatest challenge—i.e., shutting out solutions that do not fit within our discipline comfort zone.  The diarist, Anais Nin, captured the essence of this challenge when she said, “We see things not as they are, but as we are.”

Remarking on what he viewed as an unfruitful distinction between the arts and the sciences, Hardin said, “Academic people are inclined to forget that most bright people are neither physicists nor poets.”  He goes on to add, “Our intellectual tools are filters for reducing reality to a manageable simplicity …. Most expertise is a single-filter expertise.”  I couldn’t have said it better myself!

A true systems approach to accelerating projects requires going beyond the bounds of our expertise and the discipline we identify with.  Furthermore, quantum leaps in accelerating projects are not likely if the system, of which the project is a part, is not considered in its entirety.  As a minimum, this requires input from people who may otherwise be cut out of the ideation process—people who not only can champion the project, but can point out “hidden” opportunities for accelerating your project.  But it also requires recognition of the somewhat obvious, but often overlooked fact that no matter how well crafted a project may be, if it is not embraced by and integrated into the system as a whole, the idea of setting an ambitious end-date for your project is in reality a moot point. 

In summary, the Discipline Block has three strikes against it.  Directly or indirectly it can serve as a barrier to 1) identifying schedule acceleration opportunities, 2) converting critical stakeholders who are part of the system, but not the project, into champions for your cause, and 3) bringing the project to closure.  Awareness of the problem is a start in punching through this barrier.  In subsequent blogs we will discuss how this barrier relates to the other barriers and, in true system fashion, how dealing with one is helpful in dealing with the others.

Thursday, March 17, 2011

The Blame Game and Late Projects

There is a delightful book titled "Mistakes Were Made (but not by me)" that speaks to a phenomenon that seems to affect most of us when it comes to rationalizing why things go wrong. In the book the authors expand on a condition that social psychologists call cognitive dissonance to explain "Why We Justify Foolish Beliefs, Bad Decisions, and Hurtful Acts" ... which, by the way, is the subtitle of the book. If you haven't encountered the term before, in a nutshell cognitive dissonance is the inner conflict we feel when we try to embrace two or more conflicting thoughts, ideas, or beliefs simultaneously. According to the experts, we attempt to resolve this inner conflict by justifying, denying, and/or blaming something or someone else.

I believe the games we play to eliminate cognitive dissonance have a lot to do with perpetuating the failure to identify root causes for why projects continue to overrun their schedules. But there is another phenomenon called attribution error that adds to the problem. Individuals are guilty of committing an attribution error when they overemphasize personal characteristics and underemphasize situational factors when explaining why other people make mistakes ... and just the opposite when they themselves make mistakes. As a result, most individuals tend to take more credit than they are due when things go right and to blame others more than the latter deserve when things go wrong.

I have witnessed both of these phenomena in action many times throughout my career.  They pose a special challenge to consultants, like myself, who are in the business of helping clients recognize the need for and implement change initiatives. Though I will be the first to admit that I am not immune from either condition, the point I wish to make here has nothing to do with my personal shortcomings and everything to do with breaking the cycle of blame that perpetuates overruns in project schedules ... overruns that currently average 84% in the case of software development projects. In other words, these projects, on average, are taking almost twice as long to complete than originally planned. With the rate of change of technology being what it is, there is little wonder why a large percentage of these are considered to be functionally obsolete by the time they are delivered.

Of course, anyone can play the "who to blame for late projects" game.  But the blame game that pits managers against individual contributors is especially detrimental to the goal of identifying and eliminating the root causes of late projects. More often than not, it results in a stalemate (or truce, if you prefer) where little if anything happens to change the status quo.  The finger pointing that goes on between managers and individual contributors can be seen (directly or indirectly) in the following lists of commonly stated reasons for late projects.

Who or What Is To Blame for Late Projects?

Individual contributors say ...
  • Unrealistic schedules to begin with
  • Lack of management support
  • Changing requirements
  • Resource robbing (taking key players off the project)
  • Outside interference
Managers say ...
  • Lack of user involvement
  • Poor time management by the project team members
  • Developer gold-platting (i.e., design over-kill)
  • Lack of executive support
There is often a modicum of truth in each of these.  Nevertheless, at best only minor improvement in reducing schedule overruns will be accomplished as long as the finger pointing is allowed to persist. I submit that breaking the cycle of finger pointing that perpetuates this condition is a key responsibility of a genuine and effective project leader.