Project

I spend what seems like a lot of time working with schedules and scheduling tools. But in practice the visible product of that work offers a pretty poor return on the effort that went into it.

To illustrate what I mean let me give the example of a large project I'm familiar with. This project involved roughly 2000 people working full-time for several years. Project schedules were developed and tracked at a high level of detail with tens of thousands of activities and a requirement that every person posted the details of their daily work. The end result was a schedule model and some indicators that showed the project was going to be late.

If you take a look at the effort that went into creating and maintaining that schedule and the resulting indicators you would find it was a couple dozen person-years. Now perhaps on a large project that is not too large a price to pay, but in absolute terms it seems immense.

However, on this same project, in some back cubicle someone put together an informal pool and kept a list of people's guesses about when the project would complete. None of these guesses were as optimistic as the results that the schedule produced. All of these guesses were closer (by several months) to what actually happened than the schedule projections were for most of the project. The cost of these guesses was a few person-minutes a piece. Based on this I did a similar exercise on another project. At the beginning I asked the people working on the project when it would finish. I got a range of several months on a project which was to last about a year and a half. It turned out that the average guess was within a week of what actually happened. Once again it took about an hour to actually do this.

My purpose in this is not to say that schedules are useless. They certainly are not. But it is clear to me that their value as a predictive tool is vastly inferior to the informed judgement of the project participants.

Now one can say, "well, if they put what they really think into the project schedule then it will be correct", and in a perfect sort of world I'd be forced to agree. But the world is not perfect and a schedule is a necessary abstraction of what is planned so there is some detail that is lost and some assumptions which can not be embodied. One can not create the Mona Lisa with a box full of dry erase markers. However, the human mind can imagine it with minimal effort. Why not use that same power to predict when your project is going to complete?

What is it about "Project Management People" that causes them to express themselves in aphorisms? For an example check out this blog. Is there not enough truth that they feel compelled to make up some more? Is it that an aphorism reads well on a powerpoint slide? How can "Project Management" have more aphorisms than a more concrete science like physics?

I'm going to go out on a limb here and postulate: "The more aphorisms, the less knowledge"

I just read an article by Roger Martin which resonates with some of my feelings about "Project Management Systems" and the like. He posits the two as opposite ends of a spectrum. The key point is that driving toward reliability (repeatability) requires reducing the number of variables and standardizing measurements. In doing so, your results are less valid - that is they are less likely to reflect reality.

I do a poor job of describing it here so go read it yourself and see which direction you are heading. Personally it helps me justify my bias against big project management tools.

I'm tempted to say "where they are connected" and leave it at that, but that would go against my basic principles. So here is the full story.

A few days ago I came home and found that the washing machine was no longer washing. In fact it wasn't doing much of anything except making a whirrring sound when I twisted the knob. This was a problem because it was filled with soap, clothes and water. So I pulled the clothes out and wrung them dry and bailed out all the water and set to work trying to find out what was wrong. I suspected that I would need a new belt, but it turned out I needed one of these because the little plastic fingers had broken off the old one. While I was doing this my wife was asking "shouldn't we just buy a new washing machine?".

It was actually easier to replace than I thought it would be, but I was not finished yet. I put the rest of the clothes in and ran the wash. It worked, at least until the next day. Then it turned out that water was flooding the laundry room. I seems that in working on it I must have loosened the water level sensor hose and it came off. So I opened it up again and sure enough it was no longer connected. The thing is fixed now - I hope.

So what does this mean? It means that in general things break where they connect to other things and by an extreme generality, projects and designs always are going to have trouble at interfaces, places where your team is dependent on another group to deliver something, places where your module hooks up to another, places where the roof meets the skylight flashing. Certainly stuff breaks in between, but that is usually a slow and predictable failure. The breaks at interfaces are often harder to detect until they occur and then they can occur suddenly.

There is not much you can do about this except design them better, like the part for my washing machine was redesigned. They made the fingers bigger so the thing locked together better. You can do this within your team, by making sure that interfaces and handoffs are well defined and understood - and that people on both sides communicate well. You can do this by carefully limiting the number of interfaces so that cross-site or cross-geography interfaces (where communication is difficult)are minimized. You can do this by standardizing and documenting the interfaces so there is less chance for error.

But to summarize, things break where they are connected.

Johanna Rothman posted something on "Schedule Games" which reminds me why I continue to think that big schedules and big systems are sometimes less of a help than they are made out to be. If people are playing with the schedule then sometimes it is best to take the ball away. Technical indicators of progress are often more reliable and useful.

T.S. Eliot wrote in Choruses from the Rock

Where is the Life we have lost in living?
Where is the wisdom we have lost in knowledge?
Where is the knowledge we have lost in information?


For project management it is clear that information about things is not enough, we must know (have knowledge about) what the information means, but Eliot points out that information (and here I am interpreting) can kill and bury whatever knowledge we have, and further that our wisdom can be lost in a sea of knowledge.

To me this is another stake in the heart of project management information systems which blindly gather data and spin it into project information, or more precisely, pile it up until it looks something like information. A web interface is a huge pipe for information, but knowledge and wisdom are not to be found at the other end of it. People at the wide end of the pipe don't have a box to fill in with knowledge, much less wisdom. Discussion is the key to understanding.

Why does judgement have such a bad name? Isn't that what managers are paid to supply?

The google ads on my site are all showing PMP certification courses and cheatsheets tonight. How embarassing. One of these days I'll get around to putting some details behind my objection to PMI's shameless fund-raising and consultant full-employment actions, but for now let me just say I don't get it. Why pay for something so meaningless? Am I alone in thinking that everyone with a PMP has been conned? Do they really think it means ANYTHING?

For anyone reading with a PMP certification. Sorry if I have insulted you personally. Feel free to leave a comment telling me why I am wrong. I'm flexible. If you can make a good case I might even change my mind

I've seen first hand the hardships that cross-site/cross-timezone projects have to deal with and at one time I had the frequent flyer miles to prove it. However, despite those difficulties I find it somewhat hard to believe that this idea to anchor "offshore" workers literally offshore is going to work out.

Showing the picture of the floating cruise ship puts a pretty face on the fact that the people working there will be thousands of miles from their homes and families. On the other hand, my cubicle is a dull grey color and we don't have a company swimming pool.

Must be spring. Everyone (Brian, David, Frank, Hugh) seems to be talking about culture. Or at least "Technology vs. Culture". The basic problem with this is that it is a false dichotomy. Technology is no more the opposite of culture than a Zachary's Spinach and Mushroom Pizza is the opposite of god. (Actually in the latter case one can argue that they are very nearly the same thing - so substitute "submarine" for "god")

Hugh started it by positing that:

There can be no technological solution without a cultural solution. Cultural solutions are more valuable and profitable than technological solutions.

Now before you start bringing up the industrial revolution and perhaps the Luddites I would say that there are some "cultural solutions". Unfortunately, many of these have a darker side, especially when carried out by governments. I'm sure you can fill in the names of the perpetrators of "the Final Solution" and the "Cultural Revolution". But again, it is a fuzzy definition and one can not be entirely clear what a "cultural solution" is.

Brian in Projectified talks about the implementation of Project Server as being a "cultural solution", but then goes on to say "read process as 'culture'". Well, so it isn't culture then is it? Technology is a slave to process. It can enable you to build a pyramid, but in itself it is capable of nothing. It is not something that can be opposed to "culture". There have been many instances where new technologies have helped to shape culture, but only in their application and adoption, that is to say, only as when included as part of a process.

Processes have always had the capability of being either easy and simple or difficult and complex. Except for the most basic, they do require training. A kazoo is a technology for making music. So is a piano. The process of playing Chopin well may take years of practice. Is this practice a "Cultural solution" vs. the technological solution of a player piano?. I do not think so.

Here is the way I see it.

Culture is the environment, for humans it is a set of rules and ideas and habits which are generally accepted and followed. At times it includes certain practices. Process is the action you are undertaking. Technology is a tool to help you do something. How can you oppose these? How can you say one is more valuable than the other? It is like arguing whether the land or the house is the more important. Process is process is process. Some are easy, some are hard. Some go against culture, some go with it. Some use new technology, some are impossible because the technology does not exist. The dichotomy of Technology vs. Culture is just a red herring.

I suppose this is the genius of Hugh McLeod, to pose questions to which the answer is "um, maybe". But it is just a bit disappointing when you get to the bottom of it and find out that the question is bogus afterall.

Nothing to get hung about.

In response to my post on Project users Joël from Go-Project noted that he would not curse at an oscilloscope which he did not take the time to learn. It is a good point. With all of the different features and modes, project is probably as complicated yet people want to plug it in and have it work. And like an oscilloscope, the function of project is to measure and monitor rather than to perform any work itself. That is to say that Joel can't use an oscilloscope because he is not an electrical engineer. In the same way, those people cursing at Project are a few steps short of being Project managers.

He goes a bit further and accusing me of ranting about Project server (what ME rant!) but it still isn't convincing Joel. Different situations call for different tools and different processes. I'll grant that Project Server is the tool for when you want to do Project Accounting, but I'm still not convinced it is necessary for certain other types of projects.

Anyway, I think we can both agree that Joel is right. Understanding the tool is necessary for proper use.

And if you are one of those frustrated project managers, often the answer is to just ask for help. Try asking here.

I used to have a t-shirt that I got from Primavera. It had an illustration of a artist, a scientist and a large bull. The caption was "Project Management - Art, Science or ...? If nothing else it was an acknowledgement that Project Management is at best an amalgam of the three. It is left as an exercise for the reader to determine the relative proportions in any particular "theory" or approach. Coming from a design background I can't help but recommend this article in Design Observer on the same topic.

Junko Yoshida has an article in EETimes covering vertical vs. horizontal integration. It is a question of control vs. economy of scale and proponents of the vertical approach claim that vertical integration allows them to be more responsive to customer requirements and allows them to differentiate their products. In parallel with these discussions and prognostications, Intel continues with its new "Platform" strategy which, in my opinion, tries to turn what has been a horizontal business for many years into one which almost walks upright.

There are some interesting parallels for Project Management where a PMO is a horizontal model and embedded Project/Program/Platform management is the vertical model. How do PM tools and processes support these different models? Lots to think about...

Eric Hedman writes about the failed DART mission and gives a few examples of what causes projects to succeed or fail. The key factors he cites are choosing projects with a real chance for success, avoiding scope creep and having a project which people will support.

Johanna Rothman usually gets things right (I've posted earlier about her excellent series on "schedule games"), but her recent post about not calling bugs bugs points out an unfortunate tendency in Management Consultants. She suggests to her client that he should "change his naming of "bug" to "defect."' on the premise that bugs are defects and that people do not take responsibility for bugs. She seems to be making the point that people would actually confuse them with real bugs which we all know are incredibly difficult to train and even the best of them refuse to clean up after themselves. And that once we are confused about them we start thinking that they came in through the windows. (OK, so yeah, windows does have bugs).

So how is this unfortunate? Well, most developers know what a bug is. Most testers know what a bug is. I've never seen anyone confuse a "bug" with a cockroach much less an african millipede. Now, in my mind a defect is something which is more ambiguous than a bug is. What is the root cause of the defect? How do you fix it? Did a person cause it or is it something that happened in transit? Sometimes defective things are actually broken by the user. It is foolish to throw away a perfectly usable and well understood term like bug and use an ambiguous term like defect in its place. It is unfortunate because consultants try to clear the air but instead end up with a swarming mass of words which annoy the people who are just trying to get their work done.

Spraying the air with buzzwords does very little to clear the air of bugs.

A hint to Johanna: Bug - 3 letters 1 syllable, Defect - 6 letters 2 syllables. Imagine the saving of powerpoint space alone!

PS: For those who are unclear of the difference between bugs and bugs here is a quick primer on the African Millipede courtesy of the San Francisco Zoo:

The giant African millipedes can grow to be 12 inches long. For every body segment, the millipede has two pairs of legs, so they give the appearance of having hundreds of legs. When born, they only have three pairs of legs, and as they grow, they increase in size and add segments with each molt. In order to grow, they must go through a series of molts which can be dangerous. Before going into molt, the millipede must find a safe place to hide, because during this time, they are vulnerable to attack. All together, millipedes spent about 10% of their lives in molts. Some millipedes do not have eyes, but all have antennae and jaws to chew on plants. When threatened, they can excrete a foul-tasting and smelling fluid from specialized stink glands. Their main line of defense is to coil into a tight ball.

The giant African millipede can live up to seven years.

Hmmm... so maybe they aren't so different afterall.

I've been telling people that the reason that I am fundamentally opposed to tools like Microsoft Project Server is that it does not adequately convey the details of a project. It does not allow for project knowledge to be conveyed. It is great for project accounting, but less so for the active management of the process. For a long time I've been alone in this view. But now Glen Alleman writes that a veteran project manager told him that there are:

two critical attributes of a successful project

1. Have the right people - this means hand picking them
2. Manage the interfaces - this means pay close attention to the send and receive points of the project. Do this "manually" through face to face interaction.

Glen's conclusion - automating project management processes is very dangerous. Nice to know I'm not alone. Face to face interaction reinforces commitment. Face to face interaction brings out latent issues and nagging doubts before they impact the project. Face to face interaction is a fat pipe compared to the thin straw of a web interface. I feel it is a necessary part of the project management process.

I wrote earlier about the propensity of Project Management types to adopt checklists to explain and (I assume) inspire themselves. I keep finding new examples. Am I just convincing myself that it is more common then it really is? I still can't put my finger on what it is about this kind of writing that annoys me. I don't think it is wrong, but it does seem that something is missing. Maybe it is just because they are prescriptive - "do this" - yet offer no reasoning for why the rules should be followed.

A rule is a generalized response to a certain situation or problem. I find it more interesting to read about the problem and the solution rather than some rule which may or may not apply. The only exception is "thou shall not link to summary tasks" the reasons for which should be obvious to all and the penalty for transgression is nothing but sure and swift.

I guess I'm just a "spirit of the law" rather than a "letter of the law" person at heart.

This is old news, but then again sometimes it is good to read the classics. Geert Hofstede starts off his article on Cultural constraints in management theories with the sentence: "Management as the word is presently used is an American invention."

It is certainly worth looking at if you work across multiple timelines and borders. And it certainly argues against the concepts of "one size fits all" and "one size to sell" which are common among consultants.

"One seeks a midwife for his thoughts, another someone to whom he can be a midwife: thus originates a good conversation"
F. Nietzsche

I'm getting ready to start on a "post-mortem" of a completed project. This sort of activity is very useful in gathering and making sense of what happened in the project. The general idea is to review:

I've ranted about the Project Management Institute's PMP (Project Management Professional) certification a couple of times so far. One of my main points is that it has become a cash cow for PMI and for a consulting ecosystem which provides PMP training, books, test prep etc. often at what I'd consider a fairly high price.

One of the most well known of these consultants is Rita Mulcahy. She has built a small empire of trainers and provides training classes, books and software specifically geared at helping you to pass the exam. Her company, RMC Project Management, has 5 principal trainers and seems to be offering exam prep classes about 15 times a month all around the country.

The sad thing about this all is the way that they go about it. In one place her website claims:

The PMP® designation following your name demonstrates to current and potential employers that you possess a solid foundation of experience and education in project management that can have a positive impact on bottom-line results. The certification exam is so important that many of RMC's students are required by their companies to become certified in order to retain their positions. Some have received 15% raises and $15,000 bonuses.

Rules often say a lot more than they intend to. On one hand they describe what to do and what not to do, but they also reflect the motive or intent of their creators and also reflect what the problems that creator is facing. Because of their importance rule creators spend a fair amount of time on them and because of this one can interpret or in effect read the rule backward and understand the motivation of the creator.

For a simple example of this let's look at one of the changes that PMI is making to the PMP certification criteria. From a document that lays out the changes that are going to be effective as of September 30, 2005 we find that

"Candidates will have three opportunities to take and pass the PMP examination within their one-year eligibility period. If candidates do not succeed on the third attempt, candidates will have to wait one year from their third unsuccessful attempt before being permitted to test again."

First, this was in a memo sent out to all of the PMI® Registered Education Providers (REPs). One can presume that they are the ones most interested in this. My previous posts have shown that some of these providers make a business out of PMP Exam cram courses. These courses pay some lip service to broad project management education but are actually guaranteeing that you will pass the test on the first try. Different prep providers actually compete with each other based on how little time you need to actually spend studying project management. What do we learn from this? We learn that PMI endorses and supports this sort of activity.

Second, we can look at the time penalty. Why would you put this in place? What behavior does it drive? The most obvious result is that it creates a situation where it is important to get it right the first time because the penalties for failing are high.

Who does this benefit? Well, it does not particularly benefit the candidate. 3 times seems fairly arbitrary. The candidate is trying to get the certification for their own benefit so why try and limit them? It does not seem to benefit PMI much unless their testing sessions are so congested that "good" candidates are being prevented from taking the test by those who are taking it for the 4th and 5th times. I'm not aware that this is the case. It does benefit them in the short term by getting those who were on the fence about scheduling their exam to now jump to make sure they take it before the rules change in September. This may have a short term financial benefit to PMI, and cynically speaking, a long term one if they can keep changing rules from year to year.

It is obvious that the main group which it benefits is the exam prep providers who now find a larger pool of applicants - people who feel the pressure to pass the exam in a minimal amount of time. With the penalty of waiting a year, the "guaranteed" pass offered by a prep service becomes much more attractive.

So, from one rule (and the way it was communicated) shows that PMI has no qualms about people cramming for the test and instead drives them towards consultants who provide such services. I'm at a loss to understand how this benefits the discipline of Project Management. Knowledge of Project Management can be advanced by deep study and understanding of project management issues, ideas and techniques. Promoting a "cram and take the test before you forget" approach to learning project management is just wrong. The only motivation I can see is that PMI and the associated ecosystem of consultants and trainers are just in it for the money. This is sad to say the least. I believe this approach to certification is doing a disservice to the profession.

I welcome the comments of any PMI representative or registered education provider about this issue. Let's discuss it.

Brian K. digs out some posts from a year ago to see how far we have come. My answer is well, I think we are moving, but while you are up could you bring me another beer? Nothing changes overnight.

But get off your couch and check it out for yourself, and comment and if you have a blog post your own opinions. It is definitely more fun that way.

The other Jack is talking about Brian's article about knowledge management and project management failing because people resist them because they don't feel comfortable. This is making me think I should jump in just to confuse things. Why can't people feel comfortable with the new changes? Why do KM and PM applications have to feel draconian and power-sucking? Is it not possible to devise a system that people are comfortable with? Something that helps them without exposing them? The search engine is a good example of this. Generally search is nearly anonymous. If you run across a problem or someone asks you a question you can google it and find an answer very quickly and not have to ask a stupid or embarassing question of another person.

In the case of a project management system isn't it possible to craft an application that allows you to manage your work (simply and easily) and not have it feel like someone is watching you with a stop watch? I think it should be. But detail freaks like to know what you are doing every waking hour so this will probably never happen.

As for KM. THIS is my solution to KM. I post stuff here. People can find it (by searching among other things). It has very low effort for me to post anything and it offers basic categorization and date based archiving. I can reach it anywhere there is a network connection. A KM application shouldn't feel like an application at all. It should just be.

OK, I'm leaving out some critical details like only a percent or two are actually motivated to share their thoughts - or perhaps even HAVE thoughts so that is perhaps the reason KM is a moribund endeavor, but making it easy, making it obvious, making it private/anonymous when it is useful to be private and making it familiar are all good things for both scheduling and km applications and processes.

"Trust". David Anderson calls it the heart of Agile Management and that which distinguishes it from other methodologies. I think he is stretching here on how innovative Agile is being in this regard. After all, trust and mistrust have been around for as long as I can recall. They figure into every human endeavor so it sounds implausible to me that we are just now incorporating trust into software project management. If so, then I expect that software project management is worse off than even I thought it was.

But he is right. It is essential. The real question is how do you build trust. I'm afraid this takes time. It takes working together. It takes the process of setting some commitments and delivering on them. David does a good job of listing several ways that trust is built. Try and do them to whatever extent you can.

The next question is what about measurement? Do individual measurement processes build trust? I'd say no. In most cultures they signal mistrust. This can make them difficult and perhaps counterproductive to implement. But I think there is a way around it.

Going a bit further I'd say that trust can be banked in a fund. That is once trust is built, you are in a position to stretch a little and implement things which signal mistrust but may actually be useful and good because you have ample trust to spend. There are some times when someone says "trust me" and you do and others when someone says the same thing and you run the other way. (Am I alone in finding it ironic that David works for a company about which many people mistrust completely?). If you have earned the trust of your team then you are in a better position to implement more detailed measurement methods. To be successful in implementing them I'd suggest putting them off until you have built that trust.

Come on Glen, don't take our myth away! How is anybody going to sell books and software? The point that now, or actually once you have adopted method X, you will be entering a golden age is too damaging to voice. No one will like you if you say that the problems have already been solved. It only points out that they are unaware. Please no more rips in the social fabric!

This is the refrain heard from almost every software team when some sort of management process is being considered. The goal is, of course, to avoid what I assume software people believe is an assault on their independence and freedom or perhaps merely a desire to make the bean counting process nerds go away.

While this approach achieves these goals, it has some unfortunate side affects. First, it keeps software project management somewhat retarded and isolated as Glen Alleman points out in his article about the "Not So New Paradigm". Second, it avoids capturing data to know if something is better or not so there is no way of knowing if any one of the "Not So New Paradigm"s are actually working.

The interesting thing is that this ploy usually does succeed, because after all software IS different, or at least sort of different, at least as different from manufacturing as say construction is, which is to say that it is not all that very different in some major aspects, but does have important distinguishing characteristics... When you look closely enough at things they are all different.

The point I'm trying to make here, and one which at least to me is not coming across clearly so far so I'm going to boil it down in this last paragraph, is that for endeavors such as managing a project the approach should be to look first for common ground - look at general classes of problems and their solutions. Then look at ways those solutions can be applied to the specific circumstances. The software people are right, one size does not fit all, but that does not excuse a team for walking around naked. Find a tailor or do it yourself. And be careful not to end up like a certain famous emperor.

I've posted before about how people have issues with Microsoft Project. You could even say some people hate it. I think the reason is that it is hard to figure out. Techically it is part of Microsoft's Office Suite so people expect it to work like Word or Excel. And in fact it kind of does. But it doesn't give them what they want. The reason is that it doesn't give them the result they are expecting.

Word and Excel don't have quite the same problem. I think it is because they are not called "Poem" and "Cash Flow Analysis". They are just generically named and you can produce just about anything you want with them in their general area of applicability. Word can be used for everything from mailing lists to sonnets. Excel can be used for producing everything from timecards to kaliedescopic images.

Project likewise has the same latitude, but I think people just don't understand that. They don't really understand that a schedule is a creative work and can be almost anything you want it to be. It can be a dry as a stack of timesheets or as impressionistic as a Monet. The results are in the hand of the schedule author.

Many of the questions I see about Project are ostensibly about the tool, but at their heart they can only be answered if it is made clear what people really want to tool to do. I am by no means an apologist for Project. There are clear deficiencies, but I think that people do need to look at a schedule as a creative work and acknowledge their part in creating it. Until they do they will be frustrated. Once they do, they are free to develop their own abilities. They can transcend.

Well, I just finish posting about the number 5 and along comes Glen Alleman stating that there are "only a small hand full (5 or less) fundamental principles".

How handy.

Now, what are those five? I'm not going to stay up late enough to go into detail about more than one of them, but here is my take on them:

1) Define the work
2) Plan the work
3) Watch for variance
4) Correct
5) Do it again

Variance is the principle which allows to to spread your limited attention most wisely. Predators eyes (and perhaps others) work on the principle that they sense movement against a background. They sense change. It is really the variation from what is expected which allows us to focus in on things. You can not focus on everything. Whatever tools you are using to help you manage should highlight variation (both positive and negative) so that you can take action and either maximize your gains or minimize your losses.

What do you think? It sounds a bit like the standard Plan, Do, Check, Act but that is too simple for my tastes. Four is an unlucky number of ingredients. Any sushi chef will tell you that much.

Leave a comment or take up the discussion on your blog if you have one. I'd love to hear what other people think the five basic principles are.

Glen offers to set me up on a blind date with a real project manager I think because of this quotation I posted. Thanks Glen, but that was not my slam, it was a slam by the perl script kiddie. It might not seem like it from this blog, but I'm actually a bit familiar with what is needed to manage multi-zillion dollar projects. It seems to me that when solid things are involved such as airports, hospitals, bridges and rockets are concerned people are much more serious about planning. Some of this is due to having tangible measurable progress and where it is almost immediately obvious when it is not being done or is being done wrong. The other major factor is that to do this work contracts need to be written and thus scope is by necessity defined and measurement and payment are specified.

When the results are less tangible (perhaps in something like internal software development) and there is no real payment or non-payment for performance or the lack of, then you end up with these sorts of dysfunctional situtations. Indeed, I have seen this happen where it is in managers best interest to create a fictional schedule as the consequences for not doing so are severe (ie: their team may get liquidated or put on an unappetizing job) and the consequences for failing to perform to schedule are minimal.

The key is to set the rewards structure so that it drives the behavior that you desire. I also think that it is very important to note that rewards are not always financial.

I'm convinced aliens played at least a small part. But it is good to see he is back.

Summer seems a slow time for many PM bloggers, but Glen Alleman has had a fairly prolific summer, even though sometimes I can't quite figure which windmill he is tilting at.

This post is making me think it would be nice to have a long list of project management related blogs somewhere. Respond to this post with your list of favorite pm bloggers and I'll post a compilation.

I've already likened a certain scheduling technique to a peanut butter sandwich. I'm not sure what is driving me to such analogies, but it occured to me that those who are serving up a Project Management System based on the entire contents of the Guide to the PMBOK are delivering a big turkey dinner with stuffing, sweet potatoes, gravy, cranberry sauce and pumpkin pie (add dishes until you reach the 9 practice areas).

Donald Wynes new (well since Mid-August) blog is called 48ideas and is worth a look for his thoughts on Project management and related topics. I think he is selling himself short about the 48 ideas though. From what I can see it will be impossible to put the cork back in the bottle. Keep at it Donald.

Yes, it seems that way. Looking at the latest public announcements from the PDC it is becoming clearer to me that with Project Server becoming a "work management platform" the traditional function of Project as a critical path method (CPM) scheduling tool has finally become just a feature on a larger platform. I'm wondering how long they will take to start calling it something like "Microsoft Work".

But from what I have seen, the transition is not a particularly graceful one. I think this is because they are working from a situation where the thought is "how do we extend project?" when the real question to be asked is "if we have a new platform, what should project be? Are there ways to schedule besides CPM and variations like CCPM (Critical Chain Project Management). But that is only the tip of the iceberg.

It seems to me that we have not moved far from the traditional deterministic models of tasks and dumb dependencies created so long ago. In most areas, computers have proven to be a major help in helping us to compute things which are impossible to do manually so we have fundamentally changed our processes and even the results of those processes. At one time in structural engineering it was (nearly) impossible to calculate the loads on certain structures unless the loading and the connections were idealized (effectively becoming pins and rollers). For this reason, trusses were quite common as there was a method of resolving the forces and loads across each member and the engineer could have confidence that the design would be sufficient.

With the aid of the computer new analytical methods became practical. Things like finite element analysis now allow us to solve what were previously indeterminate problems. Project on the other hand is little more than a box of blocks (tasks), sticks (dependencies) and nails (constraints). Calculating a critical path schedule of a hundred tasks is a job for a computer, but with a sharp pencil and a few hours time, one could easily do it by hand. Isn't it about time that this primitive method be replaced with a more accurate and more appropriate model? Now is the time to do it.

I have in the past proposed an object oriented schedule model. A model which moves from simple dependencies and elevates them to a level where they have relevant properties, characteristics, methods and events of their own. And a scheduling engine which can resolve all of the properties and connections (no longer simple sticks and nails) and can read all the parameters and come out with a better result than just a simple duration. An engine which can find the areas of stress within the project. An engine which can determine where we have been both too heavy and too light in supplying resources. An updated understanding of what work and what dependencies is necessary to get to this point.

But even if this attempt were to be successful, it is still tainted by close association with project. My early model only concerned the schedule and how to calculate it. The information needed to determine this is a subset of the information needed to manage work. A new larger model is required. A new model of work. A platform which can serve many different methods of scheduling (not just CPM or Agile or CCPM, and is large enough to cover other areas of management. A platform with the relevant information to make managing work a reality. The scheduling tool is not the place to start. It is concerned with a subset of the necessary information. The platform IS the place to start. Eventually functions like scheduling would be features of the platform and just as a word processor allows you to write a sonnet OR a specification, the platform would allow you to create an appropriate schedule model for what you are doing.

I am not suggesting Project Server is that platform or even that it could be in the upcoming release. It is clearly not. At this time I do not have a clear idea of what such a platform might actually be. There are too many things to think about and too many engrained ways of thinking about it to solve it in a single post. But knowing that there is a problem and that there may be a solution is a good start. If you have ideas, feel free to contribute. I'll be posting here occasionally as I think things through.

Many thanks to Gary Chefetz for helping to draw these ideas out.

Sometimes I get comments like this:

> Ok I've read all the back entries...
> It would appear that your philosophy is essentially they (meaning project management tools) don't work in their
> current form and therefore we don't need them.

So my warning to readers, if it appears to you that I have trashed something dear to you, I probably haven't. However, that thing might have a mustard stain on the shirt that you should try and take care of before it sets.

Glen and Brian are both interpreting what they think I said here. All I can say is that blog comments as a means for discussion are far from being an optimal method. Oh, and also that they are both right about certain things.

Glen asked what the "underlying principle" for the 80/20 rule is. So instead of letting things get lost in the comments I'm going to give a brief summary of what I know about it.

Vilfredo Pareto was a French-born Economist who on studying land distribution in Italy found that 80% of the land was owned by 20% of the population. Essentailly he found that land distribution followed a power law probability distribution and conveniently 80/20 happens to be one of the most easily spotted points on the curve. You can see that when I graph it in excel a big red arrow shows up and points at it! I'm not familiar with all of the mathematics behind it, but it does serve as a useful rule of thumb and has been adopted by many people as a "rule".

With the easy availability of large data sets (website log data) and the use of excel, it seems to show up quite frequently. In an internal blogging system where I work the ratio of posts seemed to follow this "rule"


Well, it seemed to follow that rule until I realized that I counted all people with a blog and 1 or more posts. If I added in the bloggers who had never posted it threw the curve off. Anyway, fundamentally I think it is more of an observation than a rule. Juran, who you might know from his work in quality management took the ball and ran with it creating the Pareto Principle and derivatives thereof.

That it fits certain observed phenomena is interesting in the same way that PI or PHI (1.61803398874989... also known as the Golden Section) is interesting. As Glen has pointed out to me it is also related to Theodore Sturgeon's maxim that "80% of everything is crap". This and a bit of recursion will get us most of the way to 100%. I'll leave a little room here at the bottom to keep the ratio golden.

Bob Ashley has a nice ran^H^H^Hcomment on Project Management aphorisms here. I'll leave out the part about dying flowers, Tom Peters, Marshall Goldsmith and fantasy fulfilment and just choose this part:

In conclusion, I think we're enthralled with the aphoristic "form", but repeatedly mistake it for "content".

I've written before that project management types like aphorisms and numbered lists. It continues to be true. Part of the appeal is that aphorisms come with an assumption that they are universally true. As W. H. Auden stated:

"The aphorist does not argue or explain, he asserts; and implicit in his assertion is a conviction that he is wiser or more intelligent than his readers"

Thus, implicit in the form (and in the repetition and citing of others) is a false confidence that what is stated in aphoristic form is true. Being concise and compact, aphorisms leave few openings for attack. Politicians have perfected this in the modern "soundbite". As an aside, I'm somewhat annoyed that project management aphorisms are rather boring. We don't see things like:

"Man is an exception, whatever else he is. If it is not true that a divine being fell, then we can only say that one of the animals went entirely off its head" - Gilbert Chesterton

Of course not everyone is entirely pleased with sort of overstatement and oversimplification. There are a few out there who like to skewer some of the claims. For example, here Glen Alleman burns down Ron Jeffries strawman of "waterfall" planning wherein he draws a fuzzy drawing and complains it is fuzzy

As much as I agree with Ron about the benefits of agile planning, a fuzzy drawing is very nearly an attempt at a visual aphorism but is missing the the foundation. He draws the effect but does not draw the cause, leaving us to leap to the assumption that waterfall planning is the universal and sole cause for such miserable and demoralizing execution. Likewise, David Anderson claims he is "doing science" but is missing nearly half of what real science is. Here is what he says::

"What does it mean - "Management science for software engineering"? Why do I say that on this site? I'm not making it up. What are we saying when we say we are doing science? Science is the idea that we can predict the outcome of events given our understanding of how things work. Our understanding is typically expressed using a model. Sometimes those models are expressed as mathematical equations but often times they are simple models or sets of rules or abstractions that appear to be true for a given problem domain."

Of course this is not particularly true. What I'd pose as the "classical" definition of "doing science" is the coupling of experimental observation WITH Rene Descartes' "Systematic Doubt" wherein everything is presumed false until proven true. What is missing from David's "science" is the controlled experiment. The attempt to prove his idea false. Until then it is still built on a foundation of straw and until there is the attempt to disprove he won't have the feelings that Descartes did when he wrote:

"Doubt is thus carried to its extreme form. But notwithstanding this fact, doubt causes to rise in me the most luminous and indisputable certainty"

Science is hard. Science can be expensive. Wrapping yourself in the flag of science is cheap and easy but it does not result in the same sublime reward as doing it the hard way.

The more I think about it the more I am convinced that many people see the schedule as the problem rather than a symptom of some other problem. Schedules even in the best case are an abstraction of the work to be done. They delineate the work to be done and place it in chronological order with some notion of the relationships between tasks and resources required. There is always some art involved in this representation and while some lovingly craft a beautiful still-life others are fingerpainting or making sketches or perhaps even painting by number. But in this process they sometimes forget that the progress of the project is actually being achieved by people/things doing things. And for a large part, schedule "problems" are a result of the problems with those activities.

I'm sure that most people know this, just the same as they know their speedometer is a good measure of engine health only when it drops far below where it should be, but at that point most of the damage has been done. My point isn't that you should ignore schedules, but rather that some other, more immediate measure should also be used to understand how healthy your progress is. If you are not using those sorts of objective measures to drive the schedule you may be too abstracted from the actual work.

Among a segment of the population the PMBOK has a bad name for a number of reasons (some content related, others regarding the organization surrounding it) but it does have one thing going for it and that is in the reduction of confusion. Prior to the PMBOK the acceptance of a common taxonomy across Project Management was spotty. Certainly there was strong development of many principles and techniques, but they were spread pretty widely. The PBMOK changed that.

Now, I certainly don't agree with the way that the PMBOK is often taken as a bible and think that it is detrimental to those who treat it that way, but as Francis Bacon wrote some 500 years ago in the famous aphorism:

"Truth emerges more readily from error than from confusion"

It would seem that to find some truth, an incomplete and perhaps wrong statement of where we are is a better starting point than a broad selection of conflicting schools of thought.

Indeed the current situation still looks a bit to me like what Thomas Kuhn described as "early fact-gathering, a state of affairs where

"all of the facts that could possibly pertain to the development of a given science are likely to seem equally relevant. As a result, early fact-gathering is a far more nearly random activity than the one that subsequent scientific development makes familiar. Furthermore, in the absence of a reason for seeking some particular form of more recondite information, early fact-gathering is usually restricted to the wealth of data that lie ready to hand"

A recent post to the agile management mailing list where-in the author was searching Google for evidence to support his argument seems to place us firmly in the early fact-gathering era. The reason being that real "Science" is hard and expensive and in the absence of a clear need to do it (to defend one's practices or to remedy an error) it just doesn't get done. In the current world anecdote is enough. Some measure of charisma and perhaps a high Google page-rank helps as well.

However, the PMBOK is not enough yet. What PMI should be doing if they want to advance the knowledge of Project Management further is to commission some experiments to validate the claims which are implicit in the PMBOK. Rather than footnoting (if they even do that) conflicting schools of thought, they should mount an active challenge and seek to design experiments which validate - or invalidate - the positions that are implicit in their categorization of "best" practices. Until they do that we are still picking up facts where they lie, searching Google for anecdote, conjecture and opinion.

Some one please pass the phlogiston...

Found this excerpt from Harvard business review which ties in to my recent "management science" post that many project management myths could use a bit of investigation and confirmation:
Noise Filter: If medicine is the goose, could management be the gander?

A short excerpt of the excerpt:

"Stories are more persuasive, anyway. It's hard to remain devoted to the task of building bulletproof, evidence-based cases for action when it's clear that good storytelling often carries the day."

PMI keeps a very tight control on the PMBOK(c). I've already mentioned that there is no such thing as a  free PMBOK download, at least for several years. This is understandable as it is probably one of their key sources of income and only an idiot would give their works away for free... Um... oh, yeah, I have ads. Clickety click.

But, as Glen has pointed out while PMI is controlling access into the PMBOK, they are also controlling access OUT of the PMBOK. He lists the 5 items referenced by the PMBOK: "A dictionary, two ISO standards, a PMI Journal Paper and a Handbook.". For something billed as "A Guide to the Project Management Body of Knowledge" it appears very thin on the guiding part. Indeed, in an academic setting it would be rejected as being under-researched. How does PMI support the claims implicit in the PMBOK? A cynic might say that they are just making things up. Of course I am not THAT cynical. I know that this stuff came from somewhere and that books and papers (as well as experience) are the actual "Body of Knowledge" so that is why it seems so strange.

Is it to avoid a conflict of interest and to escape from charges of favoritism? Or is it that they want no one to leave the island of information under their control? Anybody know the reason?

I often see this posed as a clarifying question when people are discussing project milestones. In fact, I just saw it this morning as the results of a google search for it led some unsuspecting reader to my blog for an answer. Fortunately google knows all and tells all so I'm happy to pass it along:

"What does "done" look like, you ask? It's when the hot dogs start turning real deep red, and may start having bubbles form on them. They might also crack" Source:http://jweisz.org/food/mac_n_cheese.html

I don't know how you can do any better than that.

There is a Simpson's episode when Bart is confronted with a game of Rock, Paper Scissors (AKA: Jan Ken Poi, ro sham bo ...) and thinks to himself "Good ol' rock". Meanwhile his opponent is thinking "poor Bart, always chooses rock". So what does this have to do with Project Management? Nothing, except that often people go to what they are familiar with, to what they are told is going to be a winning solution or what they have won with in the past. Of course, what makes it funny is that Bart continues even though his choice loses constantly - he is attached to it for some magic reason.

Maybe it is not so much a stretch to think this is true of other people too. I can imagine some people thinking "Good ol' PMBOK" while they pull their copy off the shelf. Of course, going with what you know or what has worked in the past is a very common thing to do. If the situation is truly the same, then the solution that worked in the past should continue to work.

But sometimes the situation is somewhat misleading. Sometimes it looks the same on the surface but is different underneath. Greenland is an example. When the Norse first arrived there it looked on the surface that it was a fertile place on par with their native lands, but over time it was found that the soil was not the same glacial deposits of home and was instead a thin covering and did not have the same fertility and capacity for sustaining agriculture that their homelands did. Of course their solution for survival was the same sort of pastoralism which worked back home and eventually it ended up failing them and they disappeared from the island. Oops... should have taken up whale hunting...

One approach to dealing with the limitations of rocks is to continue to improve or polish them. The Stone axe was a mainstay of many cultures. It was refined in shape and material to be a very useful tool. Yet now it is merely a curiousity in most cultures. Somehow people switched over to something different and better and now we make axes out of steel. Quite an advancement one would say. We can use our technology to make something perform better. We see this line of thought in some project management tools. We add new features or take advantage of new technologies - a better database, better networking, faster machines etc.

But it totally ignores one thing - that is that an axe is not that great for fishing. Sometimes the situation seems like the problem is something an axe may be useful for, but a closer or more insightful look might find that a fishhook is called for if the solution is something which is sustainable.

I guess the point of this is to convince myself that even the most polished rock is not enough. A bag of rocks may be even better, but better than that is time to really assess the situation and a bag of diverse tools from which to draw from, tools which might fit the situation better than good ol' rock.

A recent article in the Scientist:
The Scientist : Battling Bad Behavior outlines some of the obstacles to behavioral change - primarily related to public health, and lists a number of the ways to encourage adoption. Looking at the positive side here are the techniques presented for removing the obstacles:

• Make It Easy
• Don't Underestimate Peer Pressure
• Provide Immediate Feedback
• Be Understood
• Confront Misinformation
• Link to Existing Beliefs
• Effective Presentation

Ah, it continues. A long standing discussion equivalent to the following code:

Glen and David are both smart guys. Why can't they just get along?

I think it comes down to a sort of pride. David is quite proud of what he has done in promoting an "Agile Software Development" point of view. It is a pride both based on effectiveness and on novelty, that is it is the "creation" of something new. As such, there is a reluctance to acknowlege that it is similar or based on any past model. This is not unusual. Indeed it is quite common. "New" is the new "new". Humans are drawn to the new thing and there is excitement about adopting it. This is the ideal situation for selling something whether it is ideas, books or software development tools.

On the other hand Glen is proud too. He has pride in doing his job well and being part of a tradition of people who have done so. When someone slights that tradition (one which is actually rich with the adoption of the new) then it requires correction, and thus is born controversy.

I'd be remiss if I didn't take sides on this. After many years of architectural education it becomes obvious that "New" just doesn't matter all that much in the long haul. A lot of what is new is reworking of the old. And what matters is how effective you are at creating something that is needed or desired.

Just as an ancient statue of Medusa becomes just another block in the drinking water system for Istanbul, the ideas of the past are just building material for the ideas of the future. Failure to look at them and understand how they can be useful is wasteful. Failure to acknowlege that you have build upon the head of the Medusa is vain.

Nope, they don't. Brian is talking cowbell, the Microsoft Project blogs are so dead they don't show up in my bloglines feed along with countless other favorites, Glen seems to be taking a rest after a spurt of post-review entries last week. David A. is happy to be showing off his badge and taking in concerts. Clark Ching is awaiting TV shows and laughing about books.

Summer seems unlikely to be any better. Sound like we need to wait until cold fall weather drives people back into their caves before there is anything going on in this space. We now return you to our regular program of spring foliage.

Tolerance is usually defined as being an allowed variance from a set standard. Just about every profession has some tolerance or ranges of tolerance. For example, buildings are designed to standards which allow certain deflections of floors (Deflection of l/360 is one common tolerance for beam design). The floor can bend by that amount before it is considered a problem.

Projects also have certain tolerances. How firmly fixed is the end date of your project? Is there any leeway one way or the other? If there isn't, there probably should be. The real question is how to determine the appropriate tolerance and to convey it to someone who is less informed about the project than you are. There are people who you give a date to and that date becomes the single acceptable value. They implicitly turn your "plus or minus" into "minus" and allow no plus. What this means is that you have to adjust your target so that even if you reach the limit of your tolerance, you are within the tolerances set by others.

There are a few ways to do this. Theory of Constraints does this with a project buffer. A number of vendors have determined rules of thumb for sizing of these buffers. The problem with them is that they are just rules of thumb. It probably takes a few projects to find out what the real size should be for your project and your team.

Another approach is probabilistic scheduling and simulation. In this approach you build a schedule model and instead of a fixed duration for each task you enter a probability distribution. Then the schedule is calculated based on a large number of random samples. The result is a probability distribution for the completion of your project. If you are successful at this, it gives you a tool which you can use to set a tolerance which you have a high probability of meeting or exceeding. I have a brief article about the basics of this method and a Microsoft Project macro which can introduce you to this approach. You can download it here: Free Download Microsoft Project Monte Carlo Simulation

Have you ever thrown out an old project schedule? Have you ever had to start from scratch? Have you ever had to look at a schedule with no supporting documents and tell if it is "OK" and be unable to say more than "well, it depends"? If you have been managing projects or schedules then I guess the answer is yes. At least once. And one of the key reasons is that the assumptions made are either wrong or are missing.

This might even be true of some of the schedules for projects you are currently working on. One of the tragedies of scheduling software is that it is rather poor at capturing the basic assumptions on which the schedule is built. Sure, you might have a WBS which describes the work, but the manner in which the work will be performed is not really included there. Further, there is often little documentation about whether the estimated work and durations are based on an optimistic or pessimistic view.

The whole point of this is that the schedule "file" is nearly unintelligible to outsiders without some narrative which describes the basic assumptions which it is built upon. I'm still struggling with determining what the proper amount of documentation for this might be, but at the very least, you should have a page or so which describes what you and your team were thinking when they came up with the schedule. And it is worth reviewing it every once in a while to make sure that the assumptions are still valid. Too bad tools like Microsoft Project don't really have a convenient way of capturing this sort of stuff.

There is considerable discussion on the Newgrange discussion list about what scope is and what it isn't. While I find it interesting enough to dip in and read a couple of arguments in the debate about it I think I have skipped more than I have read so I feel out of place commenting on it there. In my opinion scope is simple. It is the definition of what you are going to do. That is inclusive of meeting whatever specifications have been agreed upon and the work necessary to deliver on that agreement.

Any more time spent on it in a hypothetical frame of mind is wasted. For a specific project or program it is wise to spend time on it and get it right. Ultimately scope is determining what you are getting paid for. Not much more to it than that.

At least in my opinion it is not Microsoft Project. I'm starting to think that trust is the most valuable tool in the Project Manager's bag. I'm not sure where talks about that in the PMBOK though. The more uncertain part of Project Management is the people side of things. I'd go on, but time is tight. Let me know what you think is most important contributing factor to a successful project.

Not sure if the other project management writers are on a permanent vacation or not, but I haven't seen much in the way of new work in the past month or so.

Personally I've just been resting on a branch waiting for the winds to start blowing again.

In the mean time, if you are bored, take a close look at the bugs.

At a certain point projects get too big for some people and they just can't handle it anymore. One example is Windows Vista which has slipped extensively over the past year or so. And to the people on the inside (and to any number of people on the outside) the slips have not been unexpected. Philip Su, who was involved deeply in the development writes:

They knew months in advance that the schedule would never work. So they told their VP. And he, possibly influenced by one too many instances where engineering re-routes power to the warp core, thus completing the heretofore impossible six-hour task in a mere three, summarily sent the managers back to "figure out how to make it work." The managers re-estimated, nipped and tucked, liposuctioned, did everything short of a lobotomy -- and still did not have a schedule that fit. The VP was not pleased. "You're smart people. Find a way!" This went back and forth for weeks, whereupon the intrepid managers finally understood how to get past the dilemma. They simply stopped telling the truth. "Sure, everything fits. We cut and cut, and here we are. Vista by August or bust. You got it, boss." (source: http://blogs.msdn.com/philipsu/archive/2006/06/14/631438.aspx

Of course this is not just confined to Microsoft. A look at some of the recent events in the world will bring up any number of situations where a top down version of the truth is imposed upon a certain initiative or action with predictably unsatisfactory results. I have observed similar behavior with large development teams being exhorted to achieve the unachievable through methods which seem laughable in retrospect. I've seen situations where the project managers are squeezed between lying to their bosses and lying to their teams.

What do these situations have in common? Well, one common factor is size. With size comes heirarchy and with heirarchy comes a certain distancing from the reality of the situation. This gives more room for those at the top to believe that their desires actually can influence what the results are. In a smaller group, people are quickly deposed of this fiction as they can see the effects or lack of effects on the team.

Another common factor is that the size is frequently bigger than anything they have done before. Here size is shorthand for a host of things such as complexity, team size, geographical size, duration etc. The skills and behaviors that worked with smaller teams and smaller projects just start to run out of steam. They don't always scale up. It isn't that they couldn't scale up, but rather I think that the issues of scaling up are not taken into account. People take their previously successful tactics and try and make them work. Nothing wrong with that. One rule of successful projects is to minimize risks. One way of minimizing risks is to minimize change. Or at least it minimizes risk except in cases where change is required. The unfortunate truth is that big projects sometimes do require change.

Now is the point where project managers of superprojects jump in and say "In my industry ..." and cite a methodology or process or mindset or all three which does work on big projects. And the response is "great but" and goes on to argue it is a bit heavy for small projects. This can echo back and forth for a while. But it would be just a lot easier if people would just acknowledge that the skills and processes and the people needed on a big project are a bit different than those on a smaller project. Ignoring this is a cause for failure. Pants too small rip embarrassingly when you bend over too far. Pants too large drop at inopportune moments. My only point is to think about these things in advance and if possible try them on before you buy. If you can find a good tailor then go that route. You just don't want to end up in a situation where you are asking the team "does my butt look big in these?" and expecting to get good data back from them.

There is one best way to manage projects. There is one best way to plan. There is one best way to develop new products. There is one best way to engineer software. There is one best way to drink beer. There is one best way to clean the shower. There is one best way to get kids to behave. There is one best way to pray.

Well, on second thought, maybe not. Though you don't hear that much from people. More common is the evangelical acceptance and propagation of "a way" as being the best or only way. People like to be in the group that "knows how to" do something. People enjoy the assurance that they are "right". It is comfortable to be in the middle of a herd of wildebeast when there is a lion on the left and a leopard on the right. Of course some don't also, but that is OK too. Lions have to eat.

These thoughts pop out of my head after reading a couple different things. The first, David Anderson's plea to the Agile community to broaden the description of what "Agile" is to the point where it is almost everything (presumably with the goal of gathering more and more wildebeast into the fold - can you make cheese from wildebeast milk?) - a sort of ideological gerrymandering I think, in which rather than a process, "Agile" is defined as the result. The second a discussion on the New Grange mailing list about the nature of expertise.

Of course, like all thought, the bread rises before it is baked, so I have no special treats from the oven for you yet, but perhaps you can take the half-baked dough and cook it in your own oven. Think about what sort of soil conditions you have around you and what sorts of plants will flourish in it, and which will die. Think site-specific. That is one way to go about it.

Steve at Google has posted something thatlooks like it is getting a fair amount of attention. The basic thesis is that Agile is just a pretty handkerchief for the consulting wizards to wave over a hat as they make their client's money disappear but that Google has discovered the "good" agile in the form of free food and public recognition for shipping yet another beta thingie. According to google steve, google project management consists of task queue, an endless trough of tasks to choose from.

The problem with these sorts of comparisons is that they lead to the logical fallacy wherein by agreeing that one side is bad, you are sort of agreeing that the other side is good. Kinda like the armadillo telling the gila monster "you are ugly so I am beautiful". This claim of google's self evident "beauty" based on the fact that google is currently rich and generous so it MUST be uncategorically correct is commonly known as hubris and there are likely a few Greek tragedies where only a few names would need to be changed to match the current situation. Not that the Greeks were the only ones to recognize it. Take a look at a couple of recent silicon valley situations like that at Intel and perhaps HP and you see things like Craig Barrett reaching back into the bag of tricks which he believed got him where he was in an unsuccessful attempt to bring back past glory by going "back to basics".

This sort of "we did it before so we can do it again" thinking is probably something foreign to the mostly young crowd at google, but I had the foolishness of this handed to me on a plate when I attended a yoga class today. Yeah, I might have done it before, but I'm a long way from doing it again. There is hard work ahead. Chanting a slogan was no help. Ooooommmm. Ooooouuuuchhhh

But google steve does have one point right. People. People are essential to almost every human endeavor. Having the wrong people is generally a bad thing. Having the right people is nearly unstoppable. Now, a qualification. "Right" does not always mean the same thing. I am not the "right" person for a number of things. For the most part I know what those things are and I avoid them. You won't catch me on a basketball court anytime soon, but if you lost a necklace in the warm waters off the shore of a sunny Greek island and need help finding it, I can probably be quite handy.

So now enough of emulating the long-winded short-pointed prose of google steve. I'll bring it to a close. There is no magic. There are only people. Good people and bad people. It is hard to tell which is which. Sometime the team works best if there are people on it who are completely different from you. Likely a team of a hundred copies of you is going to have a pretty wide blind spot. Find the people, find what they want to do. Help them do it by any means necessary, food and fleece jackets seem to get google steve going, so try that if he is on your team. Avoid pushing your team backwards and/or sideways. Clear the path and kick the dead rats out of the kitchen.

I swam a bit more than a mile today. Swimming in a pool is among the most boring of activities as the scenery never changes and there is no talking with your head underwater. A mile is about 70 laps of the pool. In a way it is similar to a long project. Of course with every project people develop ways of coping.

Most swimmers I know dream up one scheme or another. For longer sets I calculate the fraction complete to keep my mind occupied. Other people count strokes to build a rhythm, but perhaps the most common strategy is to break the session into various sets. If for example you were going to swim 2000 yards you might start with a 200 yd warm-up, then a set of 5 x100yd freestyle, then a set of 10x100yd im then a couple sprints and a warmdown. Going beyond this, you can add permutations of what time interval the set is on and also have the items in the set progress as you go along (ie: 50, 100, 150, 200 and then back down).

Back to the comparison with a project... each phase of the workout is kept under control by some agreed bundle of effort to be completed. The advantage is that unlike being told to just jump in the pool and swim, a set has a beginning and an end. It is actually something that you can finish before you go insane from monotony, and it is something you get a breather after. You get a chance to lift your head from the water and perhaps talk to the other swimmers. A project can benefit from a similar strategy. Setting milestones and taking some time to celebrate them is one way to do this. Having clear goals for each phase can help remove that feeling of "are we there yet?" which is discouraging when the answer is not really known.

Another lesson from swimming is that streamlining is key. I'm perhaps not much stronger or more fit than other swimmers I see in the pool, but I can gain several yards on them at every turn just by pushing off the wall with my arms stretched over my head and my toes pointed. Avoid the unessential and you will be yards ahead as well. Make every movement count.

In someways it appears that the US administration is starting to treat the situation in Iraq as a "PROJECT". They are talking about setting up mutually agreed upon milestones for achieving "security" (forgive me for the "quotes". I just use them when way a word is being used by someone else doesn't match the way I would use it)

But it is curious to me that it has taken this long to get to the point where scope is being defined. As far as I can tell from comments made this morning, there is not agreement on what the milestones will be and there is still work to be done to flesh them out. Assuming that the US is taking the role of Project Manager/Owner's Representative, there will be some negotiation following that. To me this is the birth of the plan. From there, evaluating tactics and available resources to craft some set of workable assignments and sub-goals would be next. These of course would have some idea of the time required. Time can not be dismissed as it is a critical resource.

Then everybody would start to work the plan.

This approach sounds reasonable... and in this light it is reasonable to wait until the milestones are clear before committing to a schedule. I just wonder why it has taken a few years and more than a few lives just to get to the starting point.

PS: Note to W. When you state that not having (or at least not discussing) a Plan B is what "positive people do" you start to worry me greatly. Successful Project Management is all about mitigating risk. You don't get there by ignoring it.

At the 2006 PMI Global Conference a few days ago, Microsoft announced three new Microsoft Project 2007 Certifications. The details are a bit hazy as Project 2007 won't be released until next year, but the basic idea is that:

Three new certifications will be introduced to address the needs of people using the Microsoft Office Project 2007 desktop and the EPM solution. The credentials are designed to be incorporated into training programs that provide a progressive career path and promote high standards. These certifications also align with Microsoft’s support for the People-Ready business, the company’s commitment to prepare users with critical skills and competencies that lead to successful project outcomes and greater efficiencies. Microsoft’s Certified Partners for Learning Solutions can now participate in the opportunity of preparing users to migrate to the advanced functionality of Office Project 2007 EPM.

According to the press release (read it here) PMI's PMBOK was used as a foundation on which this certification was built. I can understand that. It is always nice to have something already existing to build upon, but a few quotes from Microsoft Learning GM Lutz Ziob leave me worrying a bit about the whole thing. This quote for example:

"The complexity of project management is driving the need for a more educated practitioner," says Ziob. "Microsoft is committed to advancing the project management profession. This is especially important as project management evolves from a desktop application to an increasingly strategic enterprise level business solution."

UPDATE: An un-named mole assures me that I'm the one who is misunderstanding this quote and the intentions of Microsoft. This is good to hear... I think.

Since when has project management been a desktop application? Don't get me wrong. Project Information Systems such as Microsoft's EPM solution are very good and useful, but they are just tools, tools which help you achieve SOME of the goals of Project Managers. I can't remember who was giving the talk, but I've heard project scheduling and tracking described as being closer to accounting functions rather than management functions. I agree with that to a certain degree. Just as a financial system gives managers information to manage their projects, a schedule/resource/tracking system gives managers information to manage their projects. Most managers don't run the financial systems though, and they aren't expected to understand many of the tools used. Why should Project Information Systems (PIS's) be any different? Shouldn't a group of project analysts or project "accountants" handle that part? If not, why not? I'm just worried that someone, somewhere is confusing information with management.

Of course, I have no idea what the certification will look like. It may be completely different than I expect, but if it focuses on teaching managers the ins and outs of Project Server then I think that the resulting "Certified Managers" are not really managers at all.

In the small world of Project Management Bloggers, the thing which most passes for a year-end tradition is Glen Alleman's book list. You can find it here:

Books of 2006

It is definitely worth taking a look at. My reading is a bit more eclectic. If I get around to it I'll post a few things, but don't wait up.

Hmmm... podcasting? I thought you don't listen to podcasts? Well, today I did. I started with one from Cornelius Fichtner (www.thepmpodcast.com) and also one from Dina Henry Scott (controllingchaos.com). I'm not sure why, but they make me want to put on one of my own. Perhaps I'll give it a try when I find something to say...

Until then, you can check out those two and see if they float your boat. My one comment to both Cornelius and Dina is that they are a bit long. Time is always of the essence.

Yes, so the year is still young, but if you don't take some time and read Hal Macomber's article on the pain of adopting new ideas you are missing something. It may not apply directly to that you are doing, but the beginning of the year is a good time to take stock of what you have been doing and whether it really needs some change. Start planting the seeds now for change to occur over the year.

I was writing a note to someone about the use of PERT and Monte Carlo simulation in Microsoft Project and it made me think about how willing people are to accept simple models.

As Box and Draper said "All models are wrong; the practical question is how wrong do they have to be to not be useful*" (frequently paraphrased as "All models are wrong. Some models are useful"). The margin of error in almost any schedule is going to be in the range of several percent. Building a probabilistic model of the schedule will help give an idea of the range, but even that sort of model has a margin of error.

My point here is to not get carried away with increased precision in the model beyond the point where it exceeds the limit of accuracy**. Schedules are probably only accurate to 2 significant figures so there is no need for five digits beyond the decimal point for % complete.

The biggest holes in the schedule are not going to be from rounding, but rather from things which were not considered or hand-offs which were not properly made. Modeling those events is difficult if not impossible, the answer is to avoid them in execution through proper planning and keeping track of dependencies.

* Ref: George Box and Norman Draper, Empirical Model Building and Response Surfaces, John Wiley, 1987, pg. 74

**Accuracy refers to how close a measurement is to the "true" value. Precision is how finely we can discern differences between values. You can have a highly precise measuring device which is always inaccurate. In a pinch always choose accuracy over precision.

I usually save the humor until Friday, but Crispin (Kik) Piney sent me a copy of his Project Management Immaturity Model which lists the maturity levels that other models such as CMMI and OPM3 leave out. Read it and learn how the familiar 5 levels:

5: optimising
4: managed
3: defined
2: repeatable
1: initial

are extended into a full nine levels with the addition of:

0: incompetent
-1: obstructive
-2: antagonistic
-3: psychotic

Look how long this blog has been dormant! With the Winter solstice approaching I am reminded that darkness can again turn to light so I'm making an early New Year's resolution to post weekly once again. This is the first of those posts.

I've been digesting a lot of claims and ideas about the future. Things like cloud computing and Project Management 2.0 come to mind. One of those is a technology, a capability which may allow new practices. The other is a bit more foggy with a shifting definition. From Andrew Filev at Wrike software comes the Project 2.0 Definition 2.0:

Project Management 2.0 is an approach to managing projects that is brought to life by the use of Web-based, emergent, collaborative project management software and that focuses on collective intelligence, productivity and project leadership as the basic factors of project success.

Personally I think this definition misses at least one of the critical success factors that I've seen in projects. So I'm going to leap over 2.0 and start in with my derivation of Project Management 3.0. .

If you are familiar with my blog, you know I that I use it to help solidify my thoughts. So don't expect a manifesto at first, just some apparently random thoughts. The first is to reveal that the one basic factor of project success which went unsaid in the 2.0 definition is Trust.

I see that the Project Management 3.0 bus has already left.

• Project Shrink - "the real challenge will be a social one"
• Ed Lawler - writing about "Management" but same idea
• Shim Marom - a bit tongue in cheek...
• Craig Brown - talks briefly about leadership in a 3.0 world.

But don't worry, I'll come up with something which is mine alone! Look for it the day the sun returns to work.

I'm in the business of improving project management. That generally means there needs to be change in an organization. One of the most difficult things is getting people to decide to change. This book helps:

Sources of Power: How People Make Decisions – Gary Klein

This book covers the topic of what Klein calls “Naturalistic Decision Making” which is defined as making decisions in a “natural” setting – one with which departs from the ideal by being under time pressure, with high stakes, inadequate information, ill-defined goals, poorly defined procedures, context (Klein gives the example of conflicting goals and stress), dynamic conditions and team coordination. Klein uncovers what he calls sources of power – intuition, mental stimulation, metaphor and storytelling. It sounds pretty soft, but these often are the real factors behind how decisions are made. If you want to influence an organization and help them decide to change, you would do well to read this book.

On the critical side, it is attractive to think of yourself as an experienced decision maker and this book justifies the use of your “intuition”. In the hands of the anti-analytical this could be dangerous, but on the other hand, it makes them no more dangerous than they already are.

Check reviews at Amazon: Sources of Power: How People Make Decisions