Project Management Operational Problem Solving Implementation & Change Management Strategy & Alignment

Frank Patrick's Focused Performance Business Blog
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.

Thursday, September 30, 2004

September was Multi-Project Management Month -- The 10-part September series on Multi-Project Management is done. Contents included:
I - Intro
II - Organizations are Multi-Project Systems
III - Organizational Effectiveness is Resource Effectiveness
IV - Multi-tasking multiplies time to complete projects
V - Constraint-Savvy Multi-Project and Resource Management
VI - Protective Capacity
VII - Next Month - How Much Should We Take On?
VIII - Today - What Should I Be Working On?
IX - Next Year - How Much Can We Work On? (Current and Strategic Constraints)
X - It's Not How Much You Start. It's How Much You Finish.
(I need to say thanks to Heath Row (I smile every time I say, think, or write that name) over at Fast Company for sending a lot of traffic to the series.)

OK. That was September.

A lot of October's going to be a bit slow for blogging here while I head off for a bit of a walkabout next week, although I might blog my travels over on my more personal Unfocused weblog. In the meantime, allow me to direct your attention to Tony Rizzo's soap box, where he seems to be fleshing out a nascent book on Robust Project Design (tm) with a couple posts on Robust Project Planning (tm). As I've gushed entirely too much recently, Tony's one of my compadres and influences in the world of TOC, Critical Chain, and Multi-Project Management. I leave you in his capable hands while I refresh and rejuvenate on the other side of the world.

File under , ,

Labels: ,


posted by Frank - Permanent Link - |

Multi-Project Management and Organizational Effectiveness X -- It’s not how much you start. It’s how much you finish. Too many organizations act as if by packing the pipeline and keeping everyone heavily loaded with work, a combination of filled queues and busy resources will result in rapid and reliable project completions. Instead, projects bump into one another, adding delays usually unanticipated in individual project promises, and resources burn out jumping between unfinished tasks that then further delay task handoffs and project completions.
Suggested exercise: Survey some of your project participants. Ask them how many different tasks they currently have open? How many different project reviews do they attend each week? Ask them how long they expect their current collection of tasks to take to complete? Then ask them if they set aside most tasks and just picked one and finished it as if it was the only thing they had to do, then another, then another... when would the individual tasks and the total collection be complete? How much less time would it take them to complete them all if they focused on one at a time?
Constraint Management suggests instead that projects only be launched at a rate that can be handled by the organizational system, and as its surrogate, by the system’s constraining resource. This constraint is easily identified as a heavily used resource, skill, or facility common to most projects in the portfolio. Once the pipeline of projects quickly settles down to stability through such an approach, it becomes a matter of systematic constraint management to grow the capacity and capability of the organization to meet strategic needs.
Suggested exercise: Consider your organization. Even if it is in a chaotic state in which every resource feels overloaded, ask around where, if you could double the capacity of one and only one resource, skill, or facility, it would be most beneficial for the organization in terms of helping more projects move to completion quicker? In most organizations, it usually quickly narrows down to a consensus on one or two candidates. Those are your initial candidates for designation as project pipeline constraint.
Every organization needs to consider how it manages the collection of projects it requires to sustain itself. Whether the business is based on delivering project work or process improvements require attention from a limited pool of players, or if the business depends on a steady flow of new product development, maximizing throughput of completed projects is critical to organizational effectiveness.
Suggested exercise: Consider your organization. Determine how many people are involved in project work. Is this project work revenue enhancing or primarily supporting process improvements? (Don’t forget your IT department.) What would be the impact if you could finish most projects in 25% to 50% less time than you typically do today by eliminating multi-tasking? More importantly, what would be the impact if you could double or even triple the number of projects completed in a year by synchronizing project launches with your constraint?
In summary, it’s not about how many projects you launch. It’s not about how busy everyone is. It’s not about success with one major project that’s got everyone’s attention anyhow. It’s about how many projects you finish in a period of time. It’s about finishing many projects rapidly and reliably. It’s about maximizing the throughput of your project pipeline, and the key to moving more through a pipeline is not in by forcing too much through it, creating turbulence, leaks, and spills. It’s about understanding the bottlenecks and constraints, rationally loading them, and systematically growing their capacity.

posted by Frank - Permanent Link - |

Miscellaneous Multi-Project Management Links --
Managers Listen Up—Multitasking is Not for Everyone from Knowledge@Emory via the Business Pundit.

Thinking Beyond Lean: How Multi Project Management is Transforming Product Development at Toyota -- A book link.

If It Worked For Kelly Johnson, Why Isn't It Working For Us? from Shareholder Value, a second blog launched by multi-project maven Tony Rizzo.

Are you too busy to think?

Advanced Project Portfolio Management and the PMO -- Another favorite book around here.

Program Management - Multi-Project Management with TOC -- My early writing on the subject.

Slack - Getting Past Burnout, Busywork, and the Myth of Total Efficiency -- One more book.
Check 'em out.

posted by Frank - Permanent Link - |

Tuesday, September 28, 2004

Multi-Project Management and Organizational Effectiveness IX -- Managing the Present and the Future III -- Next year - “How much can we work on?” - Current and strategic constraints. In the previous section, the stabilization of the system around the organization’s current constraint was described. That current constraint is the result of past actions and staffing levels; it may not be an ideal leverage point for maximum strategic benefit. Once the system is stable, the organization can manage itself proactively by designing a more appropriate system based on what one might call a “strategic constraint.”

An appropriate constraining resource would be one that is commonly and heavily used across a range of anticipated projects, but is also hard to augment. If it’s easy to get more of it by acquiring more people or improving processes, then it’s probably worth doing so to easily grow organizational capacity, assuming the protective capacity around it is also easily grown. If hard to augment, it becomes a matter of offloading and/or improving processes to grow capacity. A constraint that is hard to get more of while commonly and heavily required is a natural candidate for a long-term constraint against which to manage the organization.

Additionally, such hard-to-grow resources are often critical to the organization’s competitiveness. For example, a system architect who know the ins and outs of the firm’s software products is far harder to replace, and is inherently more important to its capacity than some “plain vanilla” developer skill that can be augmented with contractors. If there is some other, easily elevated constraint in place, it behooves the organization to develop plans to grow it’s capacity along with any others who might be limiting what can be gotten through the expert. Understanding this relationship also highlights and justifies the need to grow that expert skill as well, perhaps through shared work or by determining what it is in the work usually performed by the expert that really needs the expertise.

An interesting offshoot of effective constraint management is that if one considers a limiting factor -- a constraint -- to be a weakness, then the system’s strength -- the resource and skill that defines its core competency -- should probably be that weakness. After all, you don’t want any other aspect of the organizational system to limit the ability to maximize the benefit of that strength.

Developing such a strategy for growth that either grows resources around an appropriate constraint while increasing its capabilities, or provides a clear path to grow the necessary capacities to move the constraint to somewhere more appropriate provides a smooth transition from one level of performance to the next.

posted by Frank - Permanent Link - |

What You've Been Reading This Quarter -- Thank you for supporting this weblog through your Amazon.com purchases.
Critical Chain Project Management (Artech House Professional Development Library)

Practical Management Science (with CD-ROM Update) : Spreadsheet Modeling and Applications

Advanced Project Portfolio Management and the PMO: Multiplying ROI at Warp Speed

Manufacturing at Warp Speed: Optimizing Supply Chain Financial Performance

Good Business: Leadership, Flow, and the Making of Meaning

Strategic Navigation: A Systems Approach to Business Strategy

Operations Management for MBAs, 2nd Edition

The Advanced Project Management Office: A Comprehensive Look at Function and Implementation

Thinking For a Change: Putting the TOC Thinking Processes to Use

Portfolio Management for New Products

Creating the Project Office : A Manager's Guide to Leading Organizational Change

Waltzing With Bears: Managing Risk on Software Projects

Competitive Strategy: Techniques for Analyzing Industries and Competitors

The Deadline: A Novel About Project Management

Connecting the Dots: Aligning Projects with Objectives in Unpredictable Times

Building Project-Management Centers of Excellence (With CD-ROM)

Beyond Boredom and Anxiety: Experiencing Flow in Work and Play

Management Dilemmas: The Theory of Constraints Approach to Problem Identification and Solutions

Michael E. Porter on Competition

Great Boss Dead Boss

Developing Products in Half the Time: New Rules, New Tools, 2nd Edition

Influence (rev) : The Psychology of Persuasion

Lean Strategies for Product Development: Achieving Breakthrough Performance in Bringing Products to Market

Deming and Goldratt

Throughput Accounting

Slack : Getting Past Burnout, Busywork, and the Myth of Total Efficiency

Six Thinking Hats

Critical Chain

Teach Your Child How to Think

Developing Products in Half the Time (Industrial Engineering)

Turning Goals into Results: The Power of Catalytic Mechanisms (HBR OnPoint Enhanced Edition)

The Balanced Scorecard: Measures That Drive Performance (HBR OnPoint Enhanced Edition)

Putting the Balanced Scorecard to Work (HBR OnPoint Enhanced Edition)

What Is Strategy? (HBR OnPoint Enhanced Edition)

Strategy as Simple Rules (HBR OnPoint Enhanced Edition)

From Competitive Advantage to Corporate Strategy
Thank you for supporting this weblog through your Amazon.com purchases.

posted by Frank - Permanent Link - |

The Language Constraint -- Recently entering the blogosphere, Tony has let the floodgates of his mind open...
Language channels thinking. For example, consider the banking industry today. Many in the banking industry continue to use the term, information technology (IT). Virtually all banks have IT departments, and the IT departments have people who perform IT projects. Or so they think.

In fact, the use of the IT label in reference to the projects undertaken by the so-called IT departments of banks is misleading and even damaging. The IT label disguises the true value of the projects. It leads many to perceive such projects with far less urgency than the projects deserve and with far less value than the projects create for the banks.

In reality, the IT department of every bank should be renamed to the New-Service Development Division. [more...]
And it ain't just banks. As we grow at DigitalGrit, we've just had a bit of a reorganization, splitting our technology group into production to deliver the things we offer and know how to "build" and R&D for the development of new product/service offerings.

posted by Frank - Permanent Link - |

If You Are In Or Around Iowa... -- The Central Iowa Constraints Management Workshop.

posted by Frank - Permanent Link - |

Thursday, September 23, 2004

Multi-Project Management and Organizational Effectiveness VIII -- Managing the Present and the Future -- The present...

Today - “What should I be working on?” - Clarity of priority at the task level. If projects are not overloading the system, the question of which task to work is simplified by the mere reduction of active tasks in play. In-boxes are less loaded. However, due to the vagaries of project plans, and of variation in task performance, occasionally it might occur that a resource faces the need to choose one task to pick up and finish before addressing another one that is waiting. There are several options to providing such guidance.

Assuming that the individual projects are being actively managed via Critical Path or Critical Chain processes, one consideration is whether any of the waiting tasks are on the critical path or critical chain of the project in question. If so, that task would most likely be the appropriate first choice over a competing “non-critical” task.

If there is a choice of two or more “critical” tasks from different projects, the relative health of the projects in question can be easily assessed based on working one, then the other, and vice versa. The scenario that leaves the best combination of the resulting health of the projects’ promises in best condition (or maximizes the benefits associated with both projects) would be preferred. In an environment based on Critical Chain Scheduling and Buffer Management, project buffers provide not only the ability of projects to absorb such decisions, but also make the assessment process straightforward. Critical Path-based projects, usually relying on smaller, if any, schedule reserves, might have to add some additional recovery activities. (Note that this constraint-based approach to multi-project management comes from the same source as Critical Chain Scheduling and Buffer Management; the Theory of Constraints, and the two processes work together by design.)

If all queued tasks are “non-critical,” it’s less of an issue, and while usually a first-come-first-served process will suffice, a consideration of the general health of the project promise, or in the case of a Critical Chain project, buffer consumption, could also provide useful guidance.

Labels:


posted by Frank - Permanent Link - |

Keeping the Wow Alive -- Tom Peters – an acquired taste, to be sure, best taken by some in small doses – has recently launched a weblog. One of his posts about nurturing and striving for the “Wow” in what one does didn’t really grab me the first time around, but the comment thread it engendered has some pretty good nuggets in it. Some of the discussion reminds me of something I wrote a few years ago about Joy in the workplace when I had time and energy to think about such things.

It got me thinking that in various places I've worked, we sometimes get so caught up in the hassles of the day-to-day stuff that we forget about the WOW aspect of what we are doing. I know I have sometimes found myself getting a bit cynical in the face of upbeat cheerleading from folks that one typically finds in sales functions and from other visionary evangelists. But as I think about, I do owe those kinds of folks some thanks for reminding us to appreciate the WOW that we are accomplishing.

posted by Frank - Permanent Link - |

Big Applause -- It's September. That means it's the restart of the professional association rubber chicken dinner season. As a former independent consultant, I've done plenty of those over the last 7 years, networking and speaking at a long list of APICS, IIE, ASQ, and PMI meeting. There's a few more left on my calendar this year -- presentations that were committed prior to re-joining what I've come to refer to as the world of regular paychecks and group medical insurance. Last night I spoke to the Tappan Zee section of ASQ on the subject of Beyond the Fishbone: Root Cause Analysis for Complex Systems, and got the biggest round of applause I've ever gotten at such a talk.

Unfortunately, the applause was at the beginning, not the end of my presentation...

In my introduction, I referred to my recent change of employment situation and mentioned that one side effect was that I didn't have to worry about sneaking a sales pitch into or under the content of the presentation. That simple comment "brought down the house."

Oh well...      

(That said, it was one of my better, most comfortable performances, without the stress of feeling I needed to impress someone for possible near term business.)

posted by Frank - Permanent Link - |

Tuesday, September 21, 2004

Multi-Project Management and Organizational Effectiveness VII - Managing the Present and the Future --
Once an organization understands the constraints associated with it’s ability to deliver projects, whether for customer-driven deliverables or for internal process improvements, it has the basis to not only avoid overloading its current capacity and capability, but also to smoothly growing the capability to take on more work in the future, whether next month, later this week, or next year.

Next month - “How much should we take on?" - Gating project launches. At the border of portfolio management and project management lies pipeline management. Nothing will bog down a project delivery system faster than the premature push of projects into a system that can’t really handle them.

Once the portfolio management or sales acceptance process determines the relative ordering of projects, the process for synchronizing project launches to constraint capacity is a simple matter of staggering them at the point of use of the constraint. Once it is known when the constraint can take on a new project, it’s a simple matter of placing it there in the calendar, perhaps with a bit of buffer to avoid cross project impacts at the constraint, and examining the resulting schedule to determine where it’s appropriate to start the upstream activities.
If project launches are staggered in this manner, then the constraining resource will not be overloaded. And if the constraining resource is not overloaded, then the other non-constraining resources will also, by definition, not be overloaded, thereby reducing pressures to multi-task and simplifying the question of priorities when the occasional need to choose which task to work comes up.

posted by Frank - Permanent Link - |

Friday, September 17, 2004

Multi-Project Management and Organizational Effectiveness VI -- Protective Capacity -- The current constraining resource in a multi-project system could be located anywhere. By definition, other resources are non-constraints and have more capacity than would be technically needed to support the possible throughput of the system. But to start cutting and slashing this extra capacity indiscriminately would be a mistake. At some point, that would merely shift the constraint from where it is to another, potentially unpredictable part of the system at the same or lower level of capacity, or worse, set up a situation with hard-to-manage interactive constraints.

Instead, the means of managing the constraint for growth of throughput starts with stabilizing the system so that the extra capacity upstream of the constraint assures that the constraint is not starved for work. The only resource that should be kept near high utilization (note “near high” is not “at full”) is the constraint, since the output of the system is tied directly to its output. Project launches that are synchronized with the ability of the constraint to deal with them will, if sufficient protective capacity is available up stream, flow smoothly to the closely managed possible bottleneck. Similarly, once through the identified constraint, no downstream resource should be so tight that it delays the conversion of constraint output to a complete accrual of project benefit. Again that implies a necessary level of protective capacity downstream as well.

Once stabilized and ridden of the effects of overload and multi-tasking, the true capacity of the system and of its components is far more easily identified. At this point, the organization can take rational steps to grow its capacity and capabilities by systematic constraint management.

Implications for project portfolio management. Once the constraint of the system is understood, it will have implications beyond just project delivery performance. It will also provide useful input to the project portfolio process. If the organization is limited to taking on projects at the rate that they can pass through the bottleneck, then those projects that have a higher relative benefit value per time required of the bottleneck will be more valuable to the organization than those that require more bottleneck time, all else being equal.

One project may seem to have small face value, but if barely involving the constraint, it will be able to deliver that value while barely displacing some other project and its benefit. It’s almost a “free” project, taking advantage of the slack in the non-constraint resources. On the other hand, if a project that looks very valuable when complete, but requires so much constraint time that many other projects are denied or delayed, it becomes a serious strategic decision to move forward with it. If, by the nature of a bottleneck or constraint, taking on one project forces us to forego or delay another, then this metric of benefit per constraint usage becomes an important factor in the decision to launch.

posted by Frank - Permanent Link - |

Friday Fun: Rands Management Glossary --
Interview: The day you wear a tie. Interviews are a pitch where you, the hopeful candidate, pitch yourself to a group of folks who have thirty minutes to figure out if they want to spend five years listening to your dumb jokes.
Also...
Doomed: An essential unscheduled product milestone where the product realizes they are way behind and choose to kick it into high gear.
More at the link. Some hysterical, most amusing, all realistic and useful. More about it from the lexicographer here.

posted by Frank - Permanent Link - |

It was (just about) 20 Years Ago Today --


My first personal computer, $2,495 (1984 dollars). That doesn't count the money I later sunk into it to upgrade to a 512K ram "Fat Mac" and later to a full 1000K "Mac Plus." (I've never had the heart to add it up.) Forgetting about inflation, that price tag can almost get you 2 of these today.

And by the way, if you're a Mac user with a .mac subscription up for renewal, you can get a better deal at Amazon than from Apple.

posted by Frank - Permanent Link - |

Tuesday, September 14, 2004

Multi-Project Management and Organizational Effectiveness V -- Constraint-Savvy Multi-Project and Resource Management -- In order for a multi-project system to operate effectively for an organization, it needs to assure that the project pipeline isn’t overloaded. Also, when there are decisions to be made between project tasks vying for the attention of a resource, it needs to provide a clear priority that is aligned with maximizing the benefit from the total collection of projects so that the resource in question will pick up and work the “right” task without multi-tasking. The first of these requirements is directly related to understanding and managing the organization through its constraints.

Constraint = Capacity = Throughput. Unless artificially forced otherwise, or unless mismanaged to the point of non-recognition by overload, systems put together for a purpose typically have one or at most very few constraints limiting their ability to deliver that purpose. Like the clichéd “weak link of a chain,” a potential bottleneck resource can usually be identified as a limiting factor associated with project throughput.

The capacity of the system is the capacity of this constraining bottleneck. It doesn’t pay to try to push more projects into launch mode than this constraint can handle. They’ll only back up waiting for it to attend to them and they’ll distract and unnecessarily overload all the resources working upstream of the constraint. Rather than trying to tightly balance the load on all resources (and killing throughput in the process), a rational approach to managing such a system is to identify (or design in) a clearly understood constraint and manage that one piece of the system very closely.

posted by Frank - Permanent Link - |

To Plan Or To Iterate -- After too long a wait, Tony Rizzo of The Product Development Institute has joined the blogosphere with The Soap Box. If you read me, Hal, and Clarke, I encourage you to add Tony to your regular perusal. His first weekend of posts includes the following...
"The conflict between those who would use an iterative approach and those who would define specifications and develop appropriately detailed models of projects is really no conflict at all. Both sides of this conflict are correct. An iterative process is needed. But we also need project plans and well-designed project models. We simply must recognize that we cannot plan an entire, large development effort to the same level of detail. Instead, we design a strategy for the overall development effort, and we construct plans and detailed models only for the few steps immediately before us. Therefore, little has changed really, other than the scope of our project plans and the corresponding models. Instead of trying to define the mother of all project plans, we define many smaller project plans, in rapid succession."
You won't find me disagreeing.

posted by Frank - Permanent Link - |

Thursday, September 09, 2004

Multi-Project Management and Organizational Effectiveness IV -- Multi-tasking multiplies time to complete projects. -- In environments where full utilization of peoples’ time is valued, there will usually be time-sheets to fill out, or measurement and reward systems -- formal or informal -- that drive people to keep busy. In addition, in such a situation, projects are usually launched with an eye to making sure that no one is starved for work. As a result, there are usually plenty of choices of things for everyone to work on. With many active projects expecting progress, there is pressure to work on several at one time, splitting one’s time and attention across them. Unless an effective multi-project management system provides clear priorities for resource attention, people will strive to make the “measurement” look good by keeping busy and keeping several balls in the air. This is multi-tasking -- working on several significant pieces of work simultaneously, switching between them before any one is completed and before it’s output is handed off to the next task in the project.

What happens in this situation is that, as a result of trying to make sure that everyone is always fully utilized (a seemingly efficient means of controlling costs), the time it takes to convert a task input into an output that is usable by the next task is expanded by the time it sits while another project gets the attention. In addition, the context switching cost -- the time involved in the question, “Where was I?” when returning to a set-aside task -- adds to the actual work time, adding further inefficiencies to the project. Throughput associated with these projects is lost as their completions are delayed beyond when they could have been achieved.

Resource efficiency is not necessarily organizational effectiveness. By striving to be “efficient” through high local resource utilization -- by striving for cost control through avoiding “wasted” idle resources throughout the organization -- the real objective is sub-optimized. Throughput of completed projects and their benefit -- paid invoices, improved processes, or new products that will ring new cash registers -- associated with those completions is threatened, lost, or delayed.

posted by Frank - Permanent Link - |

Clayton Christensen - Interview --
"...if you look at any company that you would say has transformed itself over the last 30 years or so, it is GE. In every case, they achieved the transformation by setting up or acquiring new disruptive business units and selling off or shutting down ones that had reached the end of their lives. In no case did they transform the business model of an existing business unit to cause it to catch the disruptive wave.

"So it's like in biological evolution, you and I as individuals will just die, and the mutants will take over. A corporation can evolve, really quite effectively if you know how to do it. It's just the individual business units have a hard time."
From the first part of a Gartner Group interview with the author of The Innovator's Solution. (Linkage via Dave Pollard, who provides good, in-depth commentary on the piece.)

posted by Frank - Permanent Link - |

Tuesday, September 07, 2004

Multi-Project Management and Organizational Effectiveness III -- Organizational Effectiveness is Resource Effectiveness -- The old saw defining efficiency largely as doing things right and effectiveness as doing the right things definitely applies to multi-project systems. How individual tasks are defined and delivered are key to the efficient completion of individual projects. And choosing the “right projects” from the portfolio of possibilities is clearly related to the contribution of the efforts to the organization’s success. While these single-project and portfolio management concerns are beyond the scope of this chapter, strategies for managing the interaction of various active projects as they vie for the attention of the limited resources are not.

Understanding the importance of getting the right things done at the task level, and behaving accordingly are significant contributors to efficiency as well and are the basis for multi-project resource (organizational) effectiveness. Unfortunately, too many organizations overlook this and instead emphasize control of costs to the detriment of what they are trying to accomplish.

Maximizing throughput or controlling costs? In the previous section, the dichotomy of managing today’s deliveries as well as setting up for the future was discussed. Another pair of necessities for organizational effectiveness is found in the need to maximize throughput of the system and, at the same time, control costs. Many managers look upon these as conflicting requirements, as pressures to keep expenses down have the potential to threaten the ability to deliver more completed projects quickly and with quality.

This sense of conflict comes from confusing organizational effectiveness with efficiency, and even worse, with resource utilization. Assuring that everyone is fully utilized all the time may seem like a reasonable strategy for getting the most out of the individual resources, and, by extrapolation, out of the organization. On the surface, this feels like it makes sense. However, if a system wants to maximize its throughput, keeping resources fully loaded across the board actually hamper that objective for several reasons.

The first reason to avoid striving for full resource utilization is that if everyone is fully loaded, there is no slack to deal with the inevitable run-ins with Murphy’s Law. Given the uncertain nature of projects as unique endeavors, any negative deviation from planned expectations will require capacity to recover. If that protective capacity is not available, problems in a project will result in either cascading problems that will threaten the promises of other projects, or burnout of resources, or both. In either case, future throughput is threatened.

Similarly, without protective capacity set aside, there is no ability to capitalize on new opportunities that arise. Potential throughput is lost.

posted by Frank - Permanent Link - |

Thursday, September 02, 2004

Multi-Project Management and Organizational Effectiveness II -- Organizations are Multi-Project Systems -- Let us assume that the goal of an organization is to sustain itself so that it can profitably deliver products or services not only today, but also in the future. If that’s the case, then because it’s market environment -- the demands of its customers and the responses of its competitors -- cannot be reasonably expected to remain static, said organization must efficiently deliver today’s business and effectively change to address its future circumstances.

Projects as the business. Drawing a distinction between production-based organizations and project-based organizations, the former is usually dependent on delivering a lot of copies of identical (or at least very similar) units of a product or service, with minimal or easily manageable uncertainty and variation of process. In production environments, the “touch-time” associated with an individual piece of output is usually very small compared to the total duration of building that output, as components tend to spend most of there time in queues awaiting attention or the setup of the machinery that will transform it in some way.

Project environments, on the other hand, are characterized more by uncertainty of expectations, greater variation in the performance against those expectations. Projects also involve larger chunks of “touch time” as a proportion of total project duration. If one’s business is based on directly “selling” the outcome of projects developed with a shared pool of resources, as it is in industries such as custom software and IT systems, consulting, construction, maintenance and repair, and engineer-to-build custom manufacturing, projects are “the business.” In such arenas, the ability to maximize the throughput of multiple completed projects is directly related to both current and future success.

Projects supporting the business. The ability to effectively implement change is clearly related to what most would recognize as projects and project management. Such efforts are typically temporary efforts, with a reasonably finite span of time between launch and completion. In this context, change projects are not only related to tactical, local process improvements or highly visible strategic initiatives, but also to the ability to re-define one’s offerings to meet future needs -- research and new product/service development and deployment. Regardless of whether the business of the organization is production- or project-based, its future success needs to be supported by effective delivery of change -- effective management of multiple projects.

And whether the organization’s project portfolio is dominated by today’s deliveries to customers or clients supported by future-facing development projects, or primarily limited the latter development efforts that will deliver its future, these projects will be done largely with a limited source of time and attention of the people and processes that define the organization.

Organizations and their resources constitute multi-project systems.

posted by Frank - Permanent Link - |

Wednesday, September 01, 2004

Multi-Project Management and Organizational Effectiveness I -- Every organization is dependent on projects. From its strategy, which could be considered the “meta-project” against which it tracks its performance and growth over time, to its portfolios of “improvement projects” and product development projects that keep it effective and competitive, to its day-to-day delivery of unique efforts for which customers or clients pay, projects are the source of every organization’s ability to sustain itself over time.

Every organization has constraints limiting what it can accomplish. With a finite source of time and attention available from the human and other resources that make up the organizational system, it behooves it to assure an appropriate answer to the question, “What should I/we be working on today?” This question, asking about the most effective use of limited resources, combined with a similar question, “How should I/we organize and perform the mass of work facing me/us?” which addresses the efficiency piece of the equation are the basis for the science and art of project management. These are the critical questions for which project management is meant to provide answers.

Most writings on project management focus on project management related to the delivery of individual projects. While it’s necessary -- and nice -- to be able to deliver a single project as promised, it’s not sufficient to assure the ability of an organization to address its multiple needs.

Watch this space for more thoughts on the subject.

posted by Frank - Permanent Link - |

Current Posts (Main Blog Page)

Previous Posts

It is a common delusion that you make things better by talking about them. - Dame Rose Macaulay



What's this XML thingie all about?


View Frank Patrick's LinkedIn profileView Frank Patrick's profile



Google
Web focusedperformance.com


FP's Recommended Reading
- From the FP Bookshelf...

...from My AStore

...and some ideas from Amazon...


Best of the FP Blog Archive
- The really good stuff...

Strategic Thinking and Improvement

Enterprise PM - It Starts with Strategic Interdependence

Face Reality

How to Think With Your Gut

Hugger-Mugger and Helter-Skelter

Managing for Murphy, Satan, and Yourself

More of the Same (Local/Global)

PMI Congress Notes: Using Risk Management for Strategic Advantage

Tell Me How You'll Measure Me and Ah, But What to Measure?

What's in Your Strategy?

Why Can't We All Just Get Along?

Why TOC Works
Project and Multi-Project Management
Critical Chain and (not or) XP

Defining Project Success (But for Whom?)

Down 'n Dirty w/TOC and PM (Part 1 of 5 consecutive posts)

End of Project Review

If Project Management is the Answer, What's the Question?

In Defense of Planning

It Ain't the Tools

Lessons Learned, Revisited

Predicting Uncertain Futures

Project Conflicts

Project Determinism (and other myths)

Project Portfolio Management

Promises, Predictions, and Planning

Removing Bottlenecks - A Core Systems Design Principle

Stage Gates and Critical Chain

Ten Top Sources of Project Failure (The Executive Version)

The Meaning of "Schedule"
Leadership and Change Management
Consistent Leadership Behavior

Invisible Dogma - Perpetuating Paradigms

Nothing But Value

On Assumption Busting

Personal Productivity - An Excuse?

The Psychology of Change Management

FP's Blogroll
- Other weblogs and sites I read


FP's Ryze Page


FP's Technorati Profile
- Click the pic



Who links to FP?


For Your Charitable Consideration:

Give Something Back Foundation

Global Virtual Classroom


FP's Link List
- Selected Sites and Resources

Critical Chain Discussion Group

Lilly Software: Visual DBR

Sciforma PS (Critical Chain Software)

Spherical Angle (Critical Chain Software)

Synchrono Supply Chain Planning Software


FP Blog Archives
- All the oldies, but goodies...

Current
10/09 | 09/09 | 08/09 | 07/09 | 06/09 | 05/09 | 04/09 | 03/09 | 02/09 | 01/09 | 12/08 | 11/08 | 10/08 | 09/08 | 08/08 | 07/08 | 06/08 | 05/08 | 04/08 | 03/08 | 02/08 | 01/08 | 12/07 | 11/07 | 10/07 | 09/07 | 08/07 | 07/07 | 06/07 | 05/07 | 04/07 | 03/07 | 02/07 | 01/07 | 12/06 | 11/06 | 10/06 | 09/06 | 08/06 | 07/06 | 06/06 | 05/06 | 04/06 | 03/06 | 02/06 | 01/06 | 12/05 | 11/05 | 10/05 | 09/05 | 08/05 | 07/05 | 06/05 | 05/05 | 04/05 | 03/05 | 02/05 | 01/05 | 12/04 | 11/04 | 10/04 | 09/04 | 08/04 | 07/04 | 06/04 | 05/04 | 04/04 | 03/04 | 02/04 | 01/04 | 12/03 | 11/03 | 10/03 | 09/03 | 08/03 | 07/03 | 06/03 | 05/03 | 04/03 | 03/03 | 02/03 | 01/03 | 12/02 | 11/02 | 10/02 | 09/02 | 08/02 | 07/02 | 06/02 | 03/02 | 02/02 | 12/01 | 11/01 | 10/01 | 09/01 | 08/01 | 06/01 | 02/01 | 01/01 | 12/00


Powered by Blogger

If you are interested in adding an easily updated weblog to your site, I would suggest you look into the free service provided by Blogger.

Who is FP?
Contact Focused Performance