This Focused Performance Weblog started life as a "business management blog" containing links and commentary related primarily to organizational effectiveness with a "Theory of Constraints" perspective, but is in the process of evolving towards primary content on interactive and mobile marketing. Think of it as about Focusing marketing messages for enhanced Performance. If you are on an archive page, current postings are found here.
Wednesday, October 09, 2002
• Project Conflicts - As pointed out numerous times either in this blog or in it’s parent site, it is useful to define problems in terms of dilemmas, typically between actions assumed as required to support necessary conditions of success. No where is this more evident than in the realm of project management. Here’s a few conflicts that may be familiar.
An engineer's/programmer's/resource's dilemma: On one hand, in order to prosper, I must support the goals of the organization (including the need to deliver things fast); in order to support the goals of the organization, I'm pressured to estimate and promise my work aggressively. On the other hand, in order to prosper, I must perform as an individual (against such criteria as due-date performance) and avoid "pain"; in order to perform successfully as an individual and avoid "pain", I'm pressured to estimate safely and promise conservatively. (I'd suggest that if permitted, the second option would win over the first every time.)
How about a dilemma for project managers: On one hand, in order to prosper, I must promise projects that have minimum planned lead time; in order to promise minimum planned lead time, I'm pressured to not protect the project. On the other hand, in order to prosper, I must assure that project promises are kept; in order to keep project promises, I'm pressured to protect the project more. (This one is usually subject to compromise, which quickly devolve to lose-lose situations -- a little protection, a little late, very little prospering.)
And project owners or program managers aren't immune either: On one hand, in order to finish all projects asap, we must finish existing projects asap; in order to finish existing projects asap, we are pressured to delay the starts of new projects. On the other hand, in order to finish all projects asap, we must finish new projects asap; in order to finish new projects asap, we are pressured to start new projects asap. (Could the usual solution to this one be to start the new projects, and then multi-task to "assure progress" on all projects?)
And looking a bit deeper, maybe there's a core conflict at the root of problems in most of today's projects: On one hand, in order to have successful projects, we must respond to unexpected circumstances impacting key goals of our project (i.e., schedule, scope, budget); in order to respond to unexpected circumstances, we are often pressured to compromise on at least one of the other goals. On the other hand, in order to have successful projects, we must deliver the key goals; in order to deliver the key goals, we must not compromise those goals. (This one's easy -- How many projects ever come in on time AND within budget AND as specified?)
Hey -- who said it would be easy? That's why folks associated with projects get paid the big bucks. Right?
The key, however, to dealing with dilemmas or conflicts like these is to look a bit deeper into the assumptions that underlie the "in order to, we are pressured..." statements or the belief in the conflict itself. Maybe if we identify and address some faulty assumptions, the conflicts can be resolved - maybe we could achieve the "musts" without the conflicting "pressures." At the core of Critical Chain-based project management is the questioning of these assumptions. The resource’s dilemma is rooted in the assumed need to promise task duration performance in order to assure project duration performance. For the PM’s dilemma, there are assumptions about how project promises can be made safe. And the assumption about "starting sooner to finish sooner" can be shown to break down as soon as projects start interacting and drive multi-tasking of resources.
posted by Frank - Permanent Link -