Showing posts with label accelerated projects. Show all posts
Showing posts with label accelerated projects. 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.

Friday, March 4, 2011

Who or What Is To Blame for Late Projects?

The problem with late projects has reached epic proportions. To help get a handle on the problem, various organizations conduct surveys from time to time to try to quantify such things as the average percentage by which projects overrun their schedules and the percentage of projects that are obsolete by the time they are delivered. I tend to agree that, as a whole, there is a serious problem with late projects, but I am wary of taking statistics at face value. There are several reasons for this:

  • The method by which the statistics were obtained are seldom revealed and may be suspect
  • Surveys can be biased simply by the way the questions are posed
  • Statistics can be manipulated by the person doing the analysis of the data
  • A national statistic probably doesn't tell you much about your own organization
This last point is particularly pertinent to the point of this blog. Rather than stand alone statistics, I would like to hear qualitative explanations for why projects overrun their schedules. In other words, I would like to have some narrative to go with the numbers ... something that tells me in words what people are experiencing and why. Also, if you've experienced a certain problem and found a way to deal with it, that would be helpful to know as well.

This is a tall order, so to narrow the scope to get the conversation underway, I suggest starting with the following simple question and seeing where this random walk will take us. Here is the question:

From your experience with late projects, who or what is to blame for these project overrunning their schedules?

There is no deadline for answering the question nor a limit to the number of explanations you may offer, but I believe it would be instructive to see if patterns emerge. Also, if and when you post a response, tell us something about yourself ... as a minimum, whether you are a project manager or individual contributor and also the kinds of projects you work on.

From time to time I will compile the data and share the results. Also in a subsequent blog I will share some "generic" explanations that managers and individual contributors often give for why projects overrun their schedules. Hopefully we can learn from each other.

And now, it's your turn!