Leading Accelerated Projects

Impediments to Accelerated Projects: The Methodology Block

2011-07-18T14:08:00.000-05:00

This installment in my discussion of impediments to accelerated projects addresses one of the most sacred bovines in the herd of sacred cows to be enshrined in the hallowed halls of project management: the structured methodology—in all of its breeds and manifestations. I’ll begin with an analogy.

If you were in the business of racing cars, you wouldn’t want a car that’s built from a blueprint that ensures every car will turn out the same. You would expect your car to be unique, to be customized to fit the circumstances: the racetrack design and conditions, the length of the race, the driver’s style, etc. You would also want to take advantage of the latest and the best in fluid hydraulics, aerodynamics, materials science, and automotive engineering—anything and everything possible to cut time off the race. On the other hand, if you were in the business of building and selling race cars, the opposite is true. Assuming there was a demand for them, it would work to your advantage if all race cars were designed and built the same—cars like cookies that could be made from the same recipe, in the same mold. Consistency, repeatability, and conformity are concepts you would likely embrace.

In the manufacturing arena, consistency, repeatability, and conformity are desirable conditions that fall under the umbrella of variance reduction. Rightfully so, manufacturers put considerable effort into ensuring process variance is minimized. But variance in the project arena is not necessarily a bad thing. By definition, projects are distinguished from processes by the fact that no two are identical. All the more so when it comes to projects that are in a race for time.

Every few years, it seems, a new methodology comes along that promises to revolutionize the practice of project management—at long last the proverbial silver bullet. Each of these comes with its own jargon, a prescribed set of procedures, and a costly price tag for “certifying” people at various levels to be the implementers of the methodology. By their very nature, each is intended to ensure some degree of consistency in the way things are done. In combination these factors have the effect of elevating the methodology of choice to sacrosanct status—putting all heretics at risk of being burned at stake. When this mystical state is achieved, the efficacy of the process ceases to be questioned and the “methodology manufacturers” can begin raking in a fortune selling one-for-all “race cars.” At this point the process serves as its own justification, defended by an army of advocates who have a vested interest in promoting and maintaining it.

Don’t get me wrong, I’m not against structured methodologies—they have their place. But, it’s important to be clear about what a particular methodology is designed to accomplish—or better yet, what it actually accomplishes when it is put into practice, including any unintended consequences. You may not see it labeled as such, but every structured methodology is predicated on an organizing principle. If followed to the letter the methodology would require you to adhere to a prescriptive process for planning and/or executing your projects. The more definitive the methodology, the more restrictive it is. If, for instance, the intent of the methodology is to ensure no detail is overlooked, then you would rightfully expect it to prescribe a set of checks and balances to ensure that if there are any cracks, then nothing will fall through them. An entirely different set of measures would likely be specified if the methodology is organized around the intent of minimizing risks or to maximizing flexibility to accommodate changing requirements.

As with the race car analogy, every project that is deemed critical enough to enter the race for time should be looked at through a new set of lenses. If rapid delivery is truly a priority, any conditions or restrictions imposed by a particular methodology that would slow you down are tantamount to “red tape”—regardless of the good they are intended to serve for other purposes. This is not to suggest that every accelerated project should begin with a clean sheet of paper. But, in lieu of a straitjacket methodology, I suggest a “flexible framework” that will serve as a guide in identifying and exploiting acceleration opportunities that are unique to the circumstances. Also, in lieu of a “Certified Master Poopah” in this or that aspect of a structured methodology, pay careful attention to the person who is chosen to drive the race car—the project leader who is the “best fit” for the project—this project in particular.

An important first step in avoiding the Methodology Block is to remember to remember that the race is not about the vehicle or the satisfaction that may come from driving the vehicle—it’s about getting to the finish line fast as possible.

Leading Accelerated Projects: Impediments to Accelerated Projects: The Disciplin...

2011-06-21T18:20:00.000-05:00

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..."

Impediments to Accelerated Projects: The Discipline Block

2011-06-21T17:48:00.005-05:00

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.

Leading Accelerated Projects: The Blame Game and Late Projects

2011-03-17T15:12:00.000-05:00

Leading Accelerated Projects: 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..."

The Blame Game and Late Projects

2011-03-17T14:56:00.000-05:00

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.

Leading Accelerated Projects: Who or What Is To Blame for Late Projects?

2011-03-04T04:40:00.000-06:00

Leading Accelerated Projects: 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..."

Who or What Is To Blame for Late Projects?

2011-03-04T02:00:00.000-06:00

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!