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.

Friday, August 29, 2003

"I'll try to put a positive spin on this. Who Moved My Cheese? is beyond any shred of doubt the worst and most useless thing in print. It's trite, dull and insulting. So far this year, I can say with some confidence that I've learned more from Snapple bottle caps and Eminem album lyrics."

Thursday, August 28, 2003

A Message to My Email Subscribers -- While you have probably been receiving my recent posts fine, the system that does this for me -- Bloglet -- has been inaccesible to me and to new subscribers for several weeks now. If this doesn't improve soon, there is a good chance that I'm going to shift to a YahooGroups distribution system instead. It won't be an email discussion list, but a one-way newsletter that will allow you to give feedback to me but retain your privacy from the public and other subscribers.

If, sometime in September, you get a notice that I've added you to such a maillist, I hope you'll accept it. I'll try not to overlap the Bloglet and YahooGroups deliveries too much.

The Future of Knowledge by Verna Allee -- I'm beginning to see a pattern in the weblogs that I read. There are the project management blogs, the internet/social software blogs, the political blogs (which are starting to influence my personal Unfocused blog), and a new category seems to be congealing in my bookmarks -- Knowledge Management. In that category, Jay Cross of the Internet Time Blogpoints to this book, catching my attention with the statement, "There is really only one management question: What do we need to pay attention to in order to be successful?" Jay takes notes on the book in public, and includes a pointer to the author's site. One of the key takeaways from this and my other KM reading is that, knowledge is a network thing. No one can really grow knowledge alone. It's one of those things that requires and benefits from interactions, interdependencies, and all those other inter-things.

Tuesday, August 26, 2003

"The trouble with being punctual is that nobody's there to appreciate it." - Franklin P. Jones

Project schedules that rely on interim task due dates and the calendar to assess and manage progress against promises set up a whole series of opportunities to be unappreciated. If the person that is going to use your outputs in their task focuses on the due date/start date as the border between the two tasks rather than the handoff itself, then if you are early in delivery, odds are they'll use the extra time for other work, squandering the extra time that you've provided to the project. As a result, your expeditious delivery is, in the end, unappreciated. As a result, you start pacing your work to deliver to the date. As a result, projects managed in this way almost always take longer than they need to, and very often, longer than expected.

Prescription: Get out of the "project schedule as train schedule" mentality and into the "project as relay race" mode of operation, focusing on assuring that resources are there to pick up and run with the hand-offs as soon as they are ready instead of having hand-offs there when the resource plans to start.

Sunday, August 24, 2003

On Compromise and Integrity -- Two short pieces, one from Jim Vornov...

"Look at where you place the boundry of the system. If the border is around self, you act in self interest always without regard for people and things without. That is ego and that is pride. Every choice that fails self is a compromise."

"Sometimes we feel bad when the rules must be broken. They're just rules though. What's important is that we have a moral center, a professional core, that refuses to compromise the quality of our work."

Best Sellers (and others) -- In late June, I added Amazon.com links to the books I recommend in this weblog and in my site's reference page. One of the benefits is that I get a small kickback from Amazon if you buy through my links. To those of you who cumulatively bought almost 90 items in the last two months, I thank you for supporting my efforts here and for funding my recent Babylon 5 Season 3 DVD purchase. Another benefit is seeing not only what you choose from my recommendations, but also what you buy in the same visit. (Don't worry. I don't know who buys what...just what is bought.)

For what it's worth, the following constitutes a bakers dozen of the top sellers from my recommendations so far, with the top two far and away in a volume class by themselves...

Kind of predictable, since two of the top three have been featured in my "currently reading" list over on the right for a while. And I mentioned "Strategic Navigation" on a TOC-intensive discussion list I participate on as well. That said, it's heartening to see the dominance of TOC-oriented books in the list as well, especially my favorite "Deming and Goldratt" sneaking in at number thirteen, since part of my mission here is to introduce more people to constraint management thinking. (Yeah, yeah...You caught me. I expanded the usual Top 10 format to the "baker's dozen" to get that last one in.)

But what is really interesting to me in the Amazon report are the other books that you have bought along with those that I'm aware of. They include (in alphabetical order)...

Friday, August 22, 2003

Friday Fun -- Just finished the DVD set for Babylon 5, Season 3 last night. Eight years later, it's still some of the best television ever, including my favorite quote from the series...

"You know, I used to think it was awful that life was so unfair. Then I thought, wouldn't it be much worse if life were fair, and all the terrible things that happen to us come because we actually deserve them? So, now I take great comfort in the general hostility and unfairness of the universe." - J. Michael Straczynski, via his Babylon 5 character, Marcus Cole

(More memorable quotes here, and suggestions for watching the DVD set here on my non-business blog.)

Somehow, I get the sense that Marcus' mindset could serve a project manager well.

(By the way, 10 bonus points to the first person who writes a comment with the quickest connection between the Babylon 5 series and the Theory of Constraints. You don't even have to go through Kevin Bacon.)

Thursday, August 21, 2003

PMI Congress - September 21-23 -- I just decided to register for the PMI's annual ConferenceGlobal Congress 2003 - North America to be held in Baltimore this fall -- not presenting this time, just attending and networking. If any of you reading this are also planning to go, let me know and maybe we can hook up for a face-to-face birds-of-a-feather gathering, informal or formal, Critical Chain focused or crab cake focused. Leave a note in the comments to this entry if you think you're interested.

"After some pleasantries, I eased carefully into what I saw at his site on Monday afternoon; activity but no progress. He sighed. 'Yes, that's what you saw. And you know why? The concrete subcontractor only owns enough forms to set 45 lineal feet of concrete wall at a time.'

"Indeed. That was exactly what I saw. One end wall of the basement was about 70-80 feet long and only half of it was formed up. This is a classic illustration of constraints. The crew I saw working aimlessly had a physical constraint limiting their ability to create value for the customer; they had a fixed amount of concrete forms. What do you do when encountering a constraint?" (read on for Joe's answer, and the deeper questions he brings up...)

It's interesting that once you start to appreciate the concept of constraints and the all-important effect they have on what you are trying to accomplish, you start to see them everywhere. The one that always gets my goat is the decision to set up a buffet against the wall, cutting in half the potential throughput (and delaying my dinner) by eliminating the possibility of two lines serving themselves from either side of the table. (Can you tell I'm on day two of a diet?)

It Ain't the Tools -- Interesting. I just got finished writing a response to a request for a "tool for project prioritization" with the advice not to rely on tools, but on conversations to do such important stuff, when I visit good old Hal's blog, in which he says something along the same line...

"It's time we stopped acting like good technical wisdom is what makes for good project management. It doesn't. Likewise, accountability, authority, and responsibility (someone needs to explain the difference between accountability and responsibility for me) don't make a project manager. Let's try care, guidance, attention, listening, and openness. Now we're getting somewhere!...

"...What might we be able to accomplish on our projects if we put our attention on learning to increase the relatedness of people on our projects rather than studying for the PMI certification exam? Does anyone really think that doing better work breakdown structures will make our projects successful? No one. That's what I thought. How about learning to repair trust between two important team members? Now that would make a difference. Not the role of a project manager, you say? Then who's role is it?"

The incessant online requests for project management tools and templates drives me to distraction as well. The example of the project prioritization tool request implies something that you apply to an undifferentiated pile of projects and delivers a prioritized pile. There ain't no such animal, in my opinion, unless it involves a collection of human brains.

Effective prioritization involves understanding first what is important to the organization in question...its goal(s) and the strategy that has been determined to be the path to achieve it. Very often, I go into a client that has brought me in to help with project management processes, and one of the first things we need to do is to back up a step and get clarity on the interdependent tactical objectives that make up a viable strategic plan. We need to do this in order to prioritize (in many cases, kill and replace) the projects they have on their plate.

So the first cut of prioritization is alignment with strategies and tactics. If designed to ba a useful, living document, the strategy will also include aspects of interdependence and dependence between tactical objectives and the projects and programs that will put many of them into place, relative to one another. Without being able to have meaningful conversations about goals and strategies, many prioritization processes result in situations in which 80-90% of projects land up in the quadrant of "most important/ highest priority."

This is a common symptom of organizations for which what is important globally is not clearly defined by a strategy. Everything is important to some local part of the organization, but as a result, nothing is recognized as important to the organization as a whole. But we can't say that my silo is important and yours isn't -- it's just not polite -- so I scratch your back by not questioning the value of your desires and you scratch mine. A clear strategy will go a long way to getting leadership on the same page, and understand why it is best to delay "my" local interests in order to use scarce resources for "yours."

Again, we come back to the lack of a strategy as the source of this. Such a strategy needs to recognize current organizational constraints, and where the constraint needs to be in order to move to a defined desirable future. The individual silos then can recognize that their important role is to support the plan to address the constraint (which may not be their area, in which case many local "improvement projects" are a waste of time), and come to an honest understanding and agreement on priorities not for local doorknob polishing or phony cost reductions, but for real global improvement in the ability to achieve more organizational "goal stuff."

Without such real understanding of the interdependencies and dependencies of the projects in a portfolio, too many "tools" end up relying on a "weighting factor," some multiplication factor applicable to some ranking process. Personally, I'm not too keen on any such process. If they have any value at all, it is in the inevitable arguments about the factor -- at least then we're getting into what people really think is important. But it you've already got a handle on your vision, values, goals, and strategy, you already know what is important.

Yes there are important considerations and collections of data/information about the individual projects and programs to take into account, beyond strategic alignment, and there is an excellent summary of such useful information in a book I've recently read and that I am recommending all over the place...Advanced Project Portfolio Management and the PMO, by Kendall and Rollins...but such spreadsheets and grids, no matter how useful they are, are not "tools" that produce appropriate decisions. They are only inputs for a decision/prioritization process that best takes place as a facilitated "conversation." that takes into account cost/benefit, risks, use of critical resources, etc. If you need to rely on a "tool" to avoid having the frank, open, and honest conversations about what is important, then the first step -- definitely -- is to assure the clarity of agreed upon goals, strategies, and tactics.

Monday, August 18, 2003

WaterfallIsSilly -- One last thing for today, before I get back to my project du jour. [A question for Laurent -- What is French for "month?"] WaterfallIsSilly is a wiki-based discussion of the use, misuse, and abuse of "waterfall" project lifecycles. If you've been reading my blog for a while, you'll recognize a number of familiar names providing thoughtful discussion on the topic. This wiki is part of the AYE Conference site. I wish I had the time and funds to join these folks in Phoenix in November. The conference sounds very worthwhile.

Number 1 feels like it's related to the conflicts between local and global optimization. Number 2 is reminiscent of previous mentions of invisible dogma and superstitions. And regarding Number 3, I've recently been describing my specialization as "being a generalist."

Management by Baseball -- While on the subject of metrics, this is the start of an entertaining and wise weblog essay on...

The Seductions (& Giant Sucking Sounds) of Metrics

In business endeavors w/quantifiable results (manufacturing and sales for example) there's a near-erotic fascination with 'metrics'. Measurement with numbers is a great idea I endorse thoroughly, but too many of the folk who create them are not numerate. Those who have a 'tin ear' for numbers are likely to grab onto the most measureable factors or the most well-known numbers or the most obvious (the most obvious are usually the most well-known).

And those numbers frequently are JPI (just plain irrelevant), sapping the organization's mojo and torque in a myriad of ways...

Ah, But What to Measure? -- Keep in mind that every process has one or very few (less than 2?) active constraints that limit its performance at any point in time, and that performance is a matter of maximizing throughput -- the rate of attainment of "goal stuff" -- of the system/process. Therefore, while it is true that every link of the process chain is necessary to deliver more "goal stuff," if working at nominal performance -- if there are no out-of-the-ordinary issues in some part of the chain -- the performance of the entire chain is limited by very few key aspects. It's the good old "weakest link of the chain" analogy.

The purpose of measures should be to encourage all the links to do what will help the constraint (or other near constraints) maximize it's (their) throughput and to discourage links from doing things that sub-optimize system performance by hindering the constraint. So measurements of non-constraint sub-processes need to be focused on their support of the constraint's ability to deliver what it delivers.

Measurements of constraints, on the other hand, need to focus first on maximization of throughput (to the extent it is demanded by the processes customer/market), since the throughput of the system is directly related to the throughput of the constraint.

(In project terms, if the goal of the system/process that is the project is to deliver beneficial value, then the time until that valuable ring of the cash register is the constraint, limiting the ability to accrue project benefit. This is usually defined by the longest set of dependent tasks and their anticipated durations to get from today to the cash register, so it's no wonder that much of project management focuses on the critical path or critical chain of the project.)

That said, since the initial question was about measuring processes, be careful to remember that processes generally live in the context of a larger system as well -- the business unit or company. One needs to be careful not to push for measures at the lower level -- the process -- that will get in the way of the ability of the parent system's constraint to do what it needs to do, or for that matter, get in the way of other sub-systems' ability to contribute effectively.

TOC World 2004 -- My friends at the Goldratt Institute have announced their next big gathering of practitioners of and persons interested in the Theory of Constraints, its applications, and its successes. April 14-16, 2004 at the Mohegan Sun in Connecticut.

The big presentations are usually impressive, but last year, in my opinion, the breakout sessions were the real value of the conference, providing a substantial range of familiar and new tools and techniques that made attendance well worth it for both newbies and experienced practitioners alike. If you like what you read here at the Focused Performance weblog, you should consider attending. (If you do use the web form at the above address to get on their list for more info, use the comments section to tell 'em I sent you.)

Sunday, August 17, 2003

Tell Me How You'll Measure Me -- and I'll tell you how I'll behave. Over at the Gantthead project management discussion site, a question came up on how to measure processes. After someone else started going off with a cost-focused response, I just had to get up on my soapbox and offer an alternative view, repeated here...

There are two kind of measures, performance and operational. Performance measures are primarily historical (and often calculated well after the fact) and only really good for hitting people over the head well after the horse is out of the barn (cost is an example of this). Operational measures are more about short- and medium-term predictions about the expected outcome of a currently operating process and have the objective of guiding people and sub-processes to do what is right for the future performance of the larger system/process.

An easy example related to the operation of an automobile. Fuel consumption -- miles per gallon -- is a performance measure. Miles per hour, oil temperature, tire pressure, and fuel level are operational measures. For that matter, engine noise can be an operational measure as well, as deviations from the usual noise (deviations like pinging, rattling, exploding) indicate something about the future viability and performance of the car. Additionally, you can obsess about MPG (a cost metric, by the way) to the point that other critical functions -- acceleration and safety -- could be hurt.

Since the past is under the bridge (I'm not saying you can't learn anything from it or use it -- recent fuel consumption rate plus fuel level can give you a rough idea of the current possible range of distance you can go before needing to fill up -- but it does often take too long to be immediately useful), operational measures of active processes are the ones that will do you the most good for impacting the future.

Note my example of variation in operating noise. An excellent book about measuring systems and processes comes from the statistical process control world is Understanding Variation, by Wheeler.

Tuesday, August 12, 2003

List-o-Links -- Don't have time for extended comments (barely had time to skim and bookmark for future careful reading), but here's a handful of links that I suspect might be of interest to those of you who read this thing of mine...

The Future of Product Development, from the McKinsey Quarterly. A lean, constraint-focused, conversational future. Sounds a lot like Seagate's implementation of critical chain-based project management, via the rss feed of CNET News.com.

"'What value does this project have for you? Have you ranked this project among the other projects?' Once we start talking about relative value, the other person has a chance of understanding whether it's worth fully investing in the project or not.

"If you have projects you're not willing to fully invest in, stop doing them. Cancel the project. But if you are willing to invest in the project, make sure you've got a project manager or program manager able to manage the project to completion. One person (not a committee) takes the responsibility for organizing, steering, and managing the project. If you're not willing to hire a project manager, don't do the project. Spend your money on something else."

Kind of ties into my #9 (#9, #9 -- sorry, flashed back to 1968 there for a moment); working the wrong project. If it ain't worth doing, it ain't worth doing.

"The tribal wisdoms of the Dakota Indians, passed on from generation to generation, says that 'when you discover that you are riding a dead horse, the best strategy is to dismount'."

(via High Context via McGee via Cubicle Dweller, who I found linked to me on Technorati.com. Isn't blogging grand? Sometimes it's like the old childhood game of telephone, with less excuse for distortion and misunderstanding. And if you scroll down on Anders' page, the comments lead to a previous source as well. Would you believe Tom Peters? For some reason, I would.)

Thursday, August 07, 2003

Giving Something Back - A Global Virtual Classroom -- This is a heads up to my regular weblog readers to expect a lessening of output from me for the next few weeks. I've taken on the role of Project Manager for a new “Global Virtual Classroom” project.

In the late 90's, almost 300 schools participated in an internet-based international program linking elementary and secondary school classes from around the world in collaborative "virtual classrooms." What remains of the old site can be found at this link...www.VirtualClassroom.org

The original sponsor, AT&T, has turned the Global Virtual Classroom project over to the Give Something Back International Foundation, an international non-profit educational organization. AT&T has graciously given all the rights to the name and legacy materials to the GSBI Foundation. While AT&T will not continue as the primary sponsor, the AT&T Foundation has provided us with a small grant to restart the Global Virtual Classroom project.

We are currently in the process of searching for additional corporate support, but with or without it, later this month, we will be relaunching the program. Admittedly, unless a corporate angel appears, we'll probably be a bit more modest with program features and prizes for the best multi-national team projects, but in any event, we believe the real prize is in the learning and the collaboration of the students.

Focused Performance Weblog readers can help with the effort as well. If you could suggest organizations associated with education in your district, state, territory, country, or region that we might approach to solicit wider participation, it would be greatly appreciated. You could also assist us by helping us identify potential sponsors. If your company could provide support (perhaps through the donation of a few gigs of web hosting space), or if you have any suggestions and contacts for potential sponsors, please let me know.

Admittedly, this is going to stretch my technical abilities (What is MySQL and "server side scripting" all about? And how does one set up controlled ftp access to about 100 individual directories? Threaded forums?), but it should be fun...and rewarding. Wish me luck.

"By nature and personality profiling I'm a rather creative type. Don't confuse creative with 'artsy.' I have no artistic skills to speak of. For me, creativity entails pursuing things others say 'can't be done that way.' Often, my response is, 'but what if they could?' In other words, what competitive advantage would you or your business achieve if you actually could find a way to do something that appears unlikely."

This is related to the use of the layers of resistance that says that a vision of value should first be painted before worrying about the obstacles associated with making that vision reality. Only then will one be able to judge the costs of overcoming the obstacles (and the necessity for creativity) relative to the outcome.

Two Years Ago Today -- Multitasking -- Revisiting the early days of my weblog, I find that my obsessions have been consistent over the years, with this link to an NPR feature on multitasking (RealAudio required for the clips). I don't remember noticing it then -- perhaps because I wasn't familiar with Dave Wienberger back then, but a clip from him points out that slicing time and attention is not like slicing a potato, but more like slicing a plum...you're bound to lose some juice.

There's a chapter in the book -- What is a PMO and What Should a High Value PMO do? -- that contains excellent descriptions of two "themes" for PMOs (cost containment or throughput improvement) and four basic PMO Models...

1. Project Respository Model (a low or no value model)

2. Coach Model (a tactical model that can provide some value for a short time)

3. Enterprise Model (a strategic model oriented to central control of all major projects)

These descriptions of what a PMO might want to be when it grows up are worthy input for consideration. It's clear that the PMOs of the Forrester study are likely in the Project Repository Model, serving masters, but not necessarily strategy, and definitely not projects. Obviously the book goes on to focus on putting a "Deliver NOW" model into place, but it does do a good job of describing what can/should be expected (and not) from the other models as well.

The Meaning of "Schedule" -- This exploration of the uses and misues of the word "schedule" by Sheryl Smith from StickyMinds.com (may require free registration) is closely related to what I was going to write as a follow-up to yesterday's piece on late projects and PMOs...the one on the Forrester study that defines project failure in terms of only one factor -- lateness.

This implies lateness of something specific, something planned, something promised -- a product scope, for want of a better term. The agilistas among us are probably going into apoplexy about such a survey, as they tend to do with the hoary old Standish "chaos report" that gets trotted out every time anyone want to point a finger at project management failure in the IT context.

The idea of a fixed scope with a fixed budget and a fixed schedule and due date seems to be anathema to those of the Agile/XP persuasion. Now don't get me wrong. I like agile methods -- they address very nicely a range of issues common to environments characterized by high uncertainty. Some of my best friends are agile. And for that matter, from where I sit (in the Critical Chain PM world located somewhere between the perceived - by agilistas - rigidity of "traditional" project management and the perceived - by traditionalistas - chaos of agility) the idea of fixed scope, budget, and schedule is something that doesn't exist in my reality either. And apparently, it doesn't exist for Smith either...

"An honest, real schedule won't be gospel, and will still slip...A real schedule is hard to predict, and puts a focus on accuracy that some of us don't want to see ahead of time. In our high-stress community, sometimes we expect rewards for busyness and speed, not for accomplishment and quality. People want to believe that longer hours mean more work gets done, whether this is true or not. Managers want to believe that a pushed project finishes faster, whether this is true or not. Studies have cast doubt on both these notions, but the notions live. We're not quite ready yet to give them up."

There may be, or rather, needs to be an initial target scope, budget, and schedule to define an effort as a project and to determine whether or how much of it to pursue. Part of the scope may involve discovery along the way, some of the schedule may seem rather nebulous up front, and the delivery budget may be based on range or as a "not to exceed" target, but they constitute a specific scope, schedule, and budget nonetheless. And they need to be considered as promises until and unless there are rational reasons to do otherwise. As such, they are models of expectations, subject to necessary and appropriate change.

When I hear some of the agile persuasion saying things along the line that when something gets done "doesn't matter as long as it meets business needs" and proudly claiming that this viewpoint is more "agile" than otherwise, I get confused. One one hand, I agree that, in many cases, if the effort is worth doing, it is worth doing. But on the other hand, "business needs" include aspects of timeliness and predictability. As Deming has been known to say, "Management is prediction." Projects -- even IT projects -- don't live in an isolated world of their own, and the highly uncertain parts are being pursued with the idea of delivering something reasonably certain in a reasonably certain timeframe to support a range of business needs, from external promises to customers to the internal means to manage resource capacity and the ability to deliver other projects as well. From Smith...

"High-tech projects are criticized for being "slow"—they're never criticized for being unpredictable. Yet aren't accurate predictions what business needs most? When there is no realistic schedule, people in the trenches conspire to invent one. They have no other choice because they need to do so to plan their work. The actual users want to know what the team in the trenches knows."

And the only way for either to know -- as well as they can at any point in time -- is to compare the reality of the current situation to the model of expectations that is the overarching schedule or plan for the effort.

Sheryl's piece is a definite keeper. The only thing I have to add is that, in her "Schedule=Schedule" section, part of an "honest, real schedule" needs to include explicit acknowledgment of the uncertainty that separates the expectations along the way from the ability to make a reasonable promise regarding final completion of the effort and the ringing of the project's cash register. Things will and should slip or pick up along the way from those interim expectations due to uncertainty and variation, but these slips and pickups are most likely within a reasonable -- and unmanageable -- range of "noise" that is not worth obsessing over. As a model of those expectations that includes a factor to recognize an acceptable noise level (and when it is exceeded), the schedule is a tool for assessing the health of what matters -- the final project promise.

"In the modern world, truly productive companies are staffed by resourceful and inventive employees that strive first to solve problems with available tools and materials, holding costs down as much as possible. They go to vendors as a second, third or even a last resort.

There's a symbiosis between the supply and the demand sides of real markets. But we won't fully understand it as long as "market" continues to mean too many things it's not."

While I enjoyed the etymological excursion about the confusion of markets with demographics and regions, and of my favorite confusion -- that of marketing for "pushing goods" or advertising, the bit about going to vendors caught my attention. The rush to the outsourcing of skilled work is nothing more than reliance on vendors to serve customers -- each of whom someday may start "conversing" themselves and discover they don't need the "middleman" to translate for them.

1. Code for Maintainability
2. Know Your Status
3. Communicate Early and Often
4. Do Things That Matter
5. Fix Your Most Important Problem First

The full article (from the O'Reilly OnLamp.com site) does a good job of laying out these aspects of Extreme Programming, although if one would consider "maintainability" as part of the objective/scope of the project, the same lessons could also have been learned from the serious application of effective project management as well. (Link via Olivier Travers' Web Voice.)

"Most companies have now established project management offices (PMO) to help them enforce standard IT processes during IT/business projects, according to a recently released report by Forrester Research Inc. But many PMOs continue to focus too much time on compiling reports for senior management and not enough on ensuring that projects are delivered on time and within scope.

"That could explain why nearly one-fifth of all new IT project implementations are delivered three or more months late."

Too many PMOs seem to be taking on the role of process cop or high-level recording secretary without getting into what is really needed -- the development of a deep change that brings the "business" and the "IT" together in a holistic culture of projects and project management.

"For purposes of this study, Forrester classified a project as a "failure" if it was delivered one to three months late and affected at least 3,000 end users. According to survey respondents, 19% of their enterprise application initiatives were delivered at least three months late, and another 17% were between one and three months overdue.

"For his part, [Forrester researcher] Pohlmann doesn't expect any dramatic improvements in IT project delivery rates because of what he attributes to IT management apathy. "I think there is improvement that can be achieved, but not from a project management methodology standpoint, because those have been around for years," said Pohlmann. Instead, he said business units have to remain much more involved with IT departments on project requirements throughout the entire life cycle of the project."

Too many PMOs are isolated in the IT shops. They need to come out of their server closets (or they need to be taken over by the "business side") so that they can take a more visible and productive role in the facilitation of the transformation of business strategy into portfolios of programs and projects managed consistently and with coordination.