Not all customers are created equal. I have heard stories about close encounters with clients that have realistic deadlines. As a Project Manager you probably think that most clients are asking schedules that cannot be done. They want the software tomorrow. Actually yesterday, but even customers see that this would be impossible. If the person that is hiring you to do the job has no idea about scopes, budgets and requirements, it probably is just plain ignorance, or stubbornness; in either case, not of any interest for me right now, as I want to focus on a different situation. The client is knowing what he is talking about, and still demanding almost unrealistic or, at least, very risky deadlines. Why on earth would you ask something that you know cannot be done, and perhaps not needed in the indicated time frame anyway?

Parkinson's Law

The blame is all on the account of an English author by the name of C. Northcote Parkinson. He wrote during the 1950s a statement that is now known as "Parkinson's Law": "work expands so as to fill the time available for its completion." [1] If you give a person an amount of time to do a certain job, he will use all the time that he gets, regardless if he actually needs this amount. Together with the notion of the "Student Syndrome" it doesn't paint a pretty picture of the morale of employees. The "Student Syndrome" refers to the fact students ask for extensions on deadlines for homework, because they "can do a better job then" [2]. It is merely a kind of procrastination. Same as studying for an exam at the last possible moment. It is this conventional wisdom that makes the customer squeeze his deadline.

If people are using all the time they get, why not give them less, and the work also gets done. If people are procrastinating and start only on their job with the deadline in sight, your risk of a delay when something goes wrong is immediate. You have lost all the buffer you put into the estimate of the task. If you give someone 5 days for a 3 day job, you have two days for "just in case". Your buffer. If the first three days are wasted with nothing, and then something pops up, you have directly a delay. To avoid this, just say that you need it sooner, put pressure on the deadline. A smart manager knows his laws and syndromes and will give you perhaps less time, then he has available. Just so he has his own secret buffer, and he avoids you and your team slacking off, using all the time to surf the Net, instead of working for him. Smart move. Being a smart cookie yourself, you perform the same trick, and before you know it the developer only gets 40% of the time allocated, of the total time available, just because all the organizational layers above him acted upon the common wisdom of management.

Developer Doesn't Get More Productive With Less Time

Does it work? Is this developer more productive when he gets less time? Guess what… No! [3] If deadlines are perceived as unrealistic, and the impossible has to be done, morale drops big time and productivity is beyond repair. The best productivity rates seem to be produced when estimates are thought of as being accurate, by all parties. It seems that skimming schedule is counter productive and therefor a dangerous thing to do. How did this notion come so wildly spread? I grew up with it as a Project Manager. I told programmers always other deadlines I agreed upon with the customer. Even I was convinced of the truth. Parkinson formulated his "law" based upon some anecdotes from a fictional bureaucracy [3]. It became wildly popular because it his a nice sweet ring to it, is incredible funny, and has some truth in it.

The essence lied within the fact that people in this fictional agency were bored out of their skull and absolutely not motivated in their work. The same holds for the much acclaimed "Student Syndrome"; think about why you procrastinated during college. You were not jumping from joy to study for the exam, or to write that final paper. You just keep postponing it as much as you can. The key to both "problems" seems to be a lack of motivation to perform the job in the first place. This managerial wisdom is very common. It is so in the public domain, it is not only known within managerial worlds, the rest of the world is also in on this secret, and anticipates this. The know that if they get a deadline, it will not be the "ultimate" deadline, there is room to negotiate. In the end, it makes the net effect of the whole endeavor almost useless. In the words of DeMarco and Lister [3]: "The decision to apply schedule pressure to a project needs to be made in much the same way you decide whether or not to punish your child: If your timing is impeccable so the justification is easily apparent, the it can help. If you do it all the time, it's just a sign that you've got troubles of your own."

How did this piece of knowledge get so widely known? Like stated before, it is catchy, it is funny and it has some truth in it. However, within the social group of managers, especially of Scientific Management descent, there is a real difference between them and "the workers". Managers do the smart part, the thinking, the planning and the employees execute the tasks that is entirely spelled out to them. So every piece of evidence that workers are indeed not capable of planning work, is instant group folklore. Because the planners are separate from the people that actually do the work and have the knowledge, the estimates are often wrong and unrealistic, leading to bad performance, leading to more fuel and "evidence" of Parkinson's Law. In the end, if the customer want his software tomorrow, he will end up getting it over a month. Perhaps, had he agreed to two weeks, he would have gotten it in two weeks.

[1] http://en.wikipedia.org/wiki/Parkinson's_law
[2] http://en.wikipedia.org/wiki/Student_syndrome
[3] Peopleware, Productive Projects and Teams, Tom DeMarco and Timothy Lister

Project Managers with experience know that the traditional ways of doing PM are not sufficient any more for all our project situations. You need more tricks up your sleeve to pull it all off. That's why I follow eagerly the techniques that are coming from the agile PM camp. But I have a hard time integrating them with my own views, at least in the ways they are expressed by practitioners. Glenn Alleman provided me with the final "aha" I needed in this direction in his posting : Agile PM is not discussing project management as such, but more the management of software development using agile processes (where the agile-part is in software development).

He raises some very interesting issues I agree with. Software development can be a part of a project, but a project always has a broader scope of activities, so limiting yourself to only development leaves out some aspects. And before we go this way, let me just start now : yes, it is important for a PM to know software development practices. Not to perform them personally, but to be able to communicate intelligent about the subject: "where are the risks, is he or she bullshitting me… ?"

It might seem that we are splitting hairs here. Perhaps we are, but it is important in my opinion, even if it is just a mental exercise for a Project Manager to think about what his profession is all about (see WTF: Project Management Theories?). In the decade that lies before us, change is the only constant factor, you are not going to make it as a PM being just from whatever camp you might think of. It is not a discussion about "[TAG-Tec]agile[/TAG-Tec] or plan-driven" it is "agile and plan-driven and everything in between".

But I love the term "agile"… and we can use it properly for PM:

If you are talking about "agile project managers", this would be the key aspect of my definition. A project manager that has a lot of mental models about projects available, and can adopt his mindset according the situation without problems, is what I call a true "agile" PM. As with any social situation, a group of interacting stakeholders is a very complex system. You are never going to come up with one this-size-fits-all model that is usable. The only shot PMs have is being fluent in more than one mental model. (my posting)

Perhaps I should coin the term Resilient Project Management.

According to Alexa these are the top 10 most visited project management software websites…

1.		WikiPedia Explanation of the term "project management software" on Wikipedia. http://en.wikipedia.org/wiki/Project_management_software
2.		BaseCampHQ.com Basecamp PM Software website. Commercial. http://www.basecamphq.com
3.		AceProject.com Ace Project PM Software website. Commercial. http://www.aceproject.com
4.		ATTask.com AT Task PM Software website. Commercial. http://www.attask.com
5.		AxoSoft.com AxoSoft PM Software website. Although emphasis on bug-tracking. Commercial. http://www.axosoft.com
6.		Celoxis.com Celoxis PM Software website. Commercial. http://www.celoxis.com
7.		EasyProjects.net EasyProjects PM Software website. Commercial. http://www.easyprojects.net
8.		ProjectInsight.net ProjectInsight PM software website. Commercial. http://www.projectinsight.net
9.		MinuteMan Systems MinuteMan PM desktop software. Commercial. http://www.minuteman-systems.com/
10.		ProjectManagementSoftware.org Overview site of PM software. http://www.project-management-software.org

New Project Managers are eager to make the right impression from the start. I must have been the same. It is too long ago to remember. If you see how the young members of our profession go about playing Project Manager" it makes you wonder how the outside world views us. I have seen newbies spending days behind MS Project to create a proper Gantt Chart. I have witnessed adults getting all excited when they could inform me that their project had risk of 18%. I smelled the sweat of humans trying to fill every box in a project plan template, relevant or not, just because it is in the template.

Fair enough, I do remember one particular situation from my early days. I spent 3 days creating this Monster [TAG-Tec]Gantt Chart[/TAG-Tec] that I had to plot on A2 to get it printed. I rolled up the paper and went to my client. This client was an elder sales person just before his retirement. He was old school, but one heck of a salesman. I rolled out my wallpaper-size plan, and guided the customer through the steps. All the time he was silent, he didn't say one word. After a while he took the plan and threw it in the garbage bin. While taking his pen and paper he looked up and asked me: What is it that you want me to do? Point taken, Gantt is a Project Management icon, and not every one seems to be a PM.

We radiate to the outside world our icons like Gantt Charts, two-digits precise risk assessments, large documents that seems to cover every little aspect imaginable. If you are a member of our group, you ooze control. I once told my wife that I was unable to comply to her request. She smacked me on the head telling me that she was not my customer. So, I assume that we also have a specific language that sets us apart from other mortals. By adopting our symbols, our rituals and speak newbie PMs try to affiliate themselves with the group called Professional Project Managers.

Group affiliation is what it is all about in our lives. During your life you are a member of a lot of social groups, by default, by choice or by force. I am a Dutch white male, member of a child-less double income household, Project Manager, author and web aficionado, to name just a few of my own treats. The Dutch white male is something that I am by birth, by default (not going into the topic of sex-transformations). All other affiliations are more or less done by choice, even though I can debate if for all I was totally aware of the choice made. The group memberships determine how we see ourselves in the whole of society, it determines our identity. Actually, we have more than one identity. We can choose, we can switch depending on the situation. I like to see myself as an author. With the risk of sounding like an moron: I like the worldly sophisticated aura that is associated with it, even though I now every freak can publish a book these days. Within the professional world I emphasize the software project manager affiliation. You have been dealt a lot of memberships, you can emphasize or down play each affiliation to create your identity.

As an identity is how we see ourselves within the ultimate large group of humans, it not something that is to be seen an an individual level, it is a group thing. Without groups, the whole concept of identity wouldn't make sense. We are shaping identities by combining three mechanisms: categorization, identification and comparison [1]. Although broadminded people like to think they do not put everyone in boxes, everyone does. We always put people in categories, we label them. This is done by looking for signs that we associate with a certain group. These signs are the mentioned use of icons, rituals or speak. To be able to associate yourself with a group, we first have to divide society into groups. Identification is the part where you affiliate yourself with a group.

In the example of the first paragraph in this section, new PMs are desperately creating Gantt Charts to become a member of the PM group. The affiliation is done by taken on the social groups norms and other aspects which are used by humans to label an individual to a category. With the identification you label yourself to the group. To be able to do this, you take on the marks that cause the label. Comparison is looking for differences between groups. With the group affiliation you create your identity, your place in society. For this to work you are also indicating where you are not standing. It is always a comparison between groups. Being an agile project manager is actually saying you are not a plan-driven project manager.

For me personally, the most remarkable exponent of these mechanisms has been the use of a suit within Project Management. Most companies still today have a policy that people in management functions wear representative clothing, being suits. Even to the point where wearing a filthy, non-ironed, to small suit is preferred above a very neat polo shirt with properly ironed Dockers pants. He wears a suit. He must be a good manager than.

[1] http://en.wikipedia.org/wiki/Identity_formation

Turn on your television and try not to look at CSI Miami, NYC or Tonopah. It is amazing how popular crime series are, crime series where the geeks will save the day. It must be a universal thing, as the series are as popular in Europe as in The States. For me as a Project Manager it is a great inspiration. They find a dead corpse and an FBI Profiler is brought on the scene. He looks around, sniffs the air and creates a nice profile of the potential killer. Gut feeling, combined with a mix of experience and science transform a dark alley into a rich source of evidence.

When looking daily at the remains of my planning I feel like an FBI Profiler, or more appropriate, a Project Profiler. I look at the evidence and know the problem: death by control. Its liberating to feel like the lone, intelligent and, most of all, cool project profiler that collects evidence and clues, to build a case. Like at the FBI, based upon assumptions a profile is created. New information can lead to new assumptions and a new profile. But also the underlying assumptions steer the direction of the investigation, hoping to find evidence that support the probability of the profile. So, it is not just a matter of information gathering, and presto, you have a clear cut description of the problem. It is a lot of backward and forward reasoning. Based upon some first sparse info snippets assumptions are made, and as time progresses you get a cycle of "assumptions leading to the direction of investigation" and "information leading towards change in assumptions".
Read more