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