It might not come as a surprise for you, after all those articles that I wrote about this subject, but if in a project I have to follow a procedure just-because-the-company-says-so we have a serious problem. I can try to comply, and I may even pull it of for a couple of days. But there comes a point where I cannot hold back, and start ignoring the procedure and will do my own thing. True story: on a project where I was one of several PMs, weekly progress reports had to be written and send to all other Project Managers. After a while I got the impression that no one was actually reading these things, because of the kind of questions I was getting (answers were all in the reports).

As I was not fond of reporting just for the sake of reporting anyway, I started little irritating experiments like issuing identical reports with different dates, adding nonsense risks, just to see if anyone was paying attention. As you might have guessed, no responses what so ever. So, I stopped writing the reports. All hell broke loose. You have to write the reports. It says so in our Project Management Handbook. After a while, still not issuing that particular report, I was getting a name about never writing any reports, or structured information what so ever. Although this wasnt true at the moment (I was writing enough documents and sending enough information about relevant issues), in retrospect, after a longer period this started to be true. When hearing my refusal enough times, I actually started behaving that way: I was really starting to not share information. Was a long time ago and I am cured, but it made me wonder.

What I was experiencing is called deviant behavior, not performing the behavior that is considered normal within society or a particular social group. Although the ideas originate from criminology, the concepts also apply to other smaller pieces of society, like projects. The overall idea is that a social groups has its own perception of the ideal life. There is a general conception of how things should be done, what the right way is to operate as a member in that particular group. Get an education. Get a job. Get married. Get a kid. Get another kid. For a large part of society this is still considered the Golden Formula of living ones life. Conflicts can occur on two levels: the goals that the group prescribes, and the means to reach those goals. In a society where be all you can be is the goal, the accepted means are get an education and earn a lot of money. If an individual is not fortunate enough to get an education due to economic circumstances, he still might go for the goal, but can substitute the means by robbing everyone blind.

If someone is tired of the same old goals of society, has the opinion that it only creates mindless power-driven individuals, he has also a deviance with what is regarded as normal. However, still trapped in the traditional meansof society he might still go on in the education-job-marriage-kid path. Typically one of the silent types.

If within a social group the emphasize is put on some one being different in their behavior, not following the norm of the society, this individual can be labeled as deviant. This labeling can be done in the form of drastic measures as putting in jail (which within my society is not a strange thing to do if someone is robbing everyone blind) or by means of communication with a group (did I say gossip?). Deviance within a group can lead to being labeled as such by the group. This labeling in itself would not be so bad, weren't it for the fact that it can lead to a self-fulfilling prophecy. Individuals being labeled as different can look at themselves in the same way and emphasize their label. In this way it becomes a reinforcing process. In the context of crime, by putting people in jail society emphasizes that they perform non-acceptable behavior and that they are bad persons. By being in jail the individual gets a self-image of being a bad person and keeps on behaving like one. If you put it like that, you just know this will trigger a lot of discussions.

Back to the topic of Project Management, there are project goals to fulfill and the project team gets means to its disposable to get reach those goals. But those means are not only just the money and people allocated to the project, but also the approach that is considered normal by the company or the profession group (think about the discussion between plan-driven and agile approaches). What this view teaches us is that if a team member is not following the normal path, look at its perception and attitude of the project goals and the means to reach those goals; chances are that there is something completely out of sync. And emphasizing this point (labeling) will only make matters worse.

I really hated this management mantra. I thought it was boring, because it turned the cool Project Manager into an accountant. I thought it was naive, as management is a black art. I was convinced it could not be done, you cannot measure everything. Yeah I know by now I was utterly wrong.

Problem number one within projects is communication. The unclear exchange of information. And this "measuring thing" is exactly a tool that can contribute to solving at least part of the problems.

Photography by Corrieb.

The god-father of this mantra must be Tom Gilb. He is screaming to measure things within software management for decades. The eye opener for me personally, was his emphasis on the use of metrics, expressing e.g. requirements using a scale with a range associated to it. You are not going to use it just to measure and if the subject has the wrong value hit the guy who created it on the head. When I first started out, this was really my impression of how these metrics would be used.

Instead, the use of metrics can be used to manage expectations, to help formulated key users their requirements, and to facilitate decision making. Gilb created a structure, Planguage, to express the requirements to process and product in. Every element has a metric associated with it; you define what the scale is, how you are going to measure it, what the past, current and desired values within the metric are.

Tom's son, Kai, has taken this approach towards Project Management, and has written a document about the use of Planguage in his EVO project management method. There is no real shortcut in getting the real power of its use, so I recommend to read the entire manuscript during the weekend or during the evenings of your next business trip. If you just have to get a real fast introduction you can read Kai's paper Agile. Now What?

Since yesterdays posting I am thinking about exactly what kind of features in software would be a real asset to a Project Manager? Features that would really free up the PM of tedious tasks or make a process far more superior than without the supporting system. Therefore my question to you, just before the weekend, what would you really want to be done by your PM software? And please, don't hold back

I always had this vision since playing the SIMS that I could model my project team like that. Wouldn't it be great, you just enter some parameters, and let it run and see where the project goes? For those of you who have played this game: isn't the interaction between people amazing life like? But, it would actually be useless, if you have one small parameter wrong, the simulation will end up in a complete different direction as it would go in reality. Well, too bad. We should get something with a cool 3D interface though. It brights up every boring application. I mean, look at this 3D app for mail… tell me you don't enjoy it!

Of course, new technology will open up new ways of using tools in Project Management. And really, you don't have seen it all. Look at the following presentation about some new kind of user interface. It just opens up the mind in completely new directions (got the tip here).

So, what are you looking for? And it doesn't have to be one of the traditional goals to implement PM software.

Josept Thornley explains the overall principles of Social Project Management, a term coined by Leisa Reichelt who has formed her ideas from building [TAG-Tec]social software[/TAG-Tec]. Cutely dubbed "Project Management 2.0″, mimicking the current Web 2.0 and Enterprise 2.0 hype. Sadly the formulation she chooses makes it standard "agile" (assuming the posting phrases here correctly). For those that didn't hide behind their PMBoK Guides, there is nothing new there. For us PM 2.0 is so 2000.

She hit the nail though with the idea of "Social" Project Management. But not in the trivial sense of sharing files and collaboration. The Project Management style, and the supporting tools have to be "social", and now more then ever. The project landscape is turning mobile, multi-cultural, 24×7, highly distributed and in ever flux. This situation will increase the risks of three social booby traps:

1) Communication trap: proper understanding of what the other stakeholders need in the project;
2) Trust trap: letting go of control and hoping people still do what they are supposed to do;
3) Isolation trap: no sense of belonging to the project through geographical, cultural and timezone differences.

For Project Management 3.0 the real challenge will be a social one. And this is exactly the place were I think social software can bring us insights. But not in collaboration alone, but more in how software can build a sense of community, enhance trust and stimulate open communication.

A nice example of the future can be found in PlanningPoker. With this free tool people can discuss estimates for planning items online in a kind of poker game. The fun element stimulates discussion, by performing it in a group it creates trust and respect and it helps to break isolation by belonging to a small and fun bunch. You should really give it a try. See what your future will look like.

With a title like that, I just had to read it. An answer to an ultimate question. Collapse: How Societies Choose to Fail or Succeed. Wouldn't you like to know why some ancient societies are extinct, while others are still full alive? It also might shed some light on why projects fail or succeed. Society is a group of people living and working together. So is a project, just a wee bit smaller.

[TAG-Tec]Jared Diamond[/TAG-Tec] argues that there are five factors involved in the survival of societies. The remaining 99% of the book he provides examples to support his claims. His examples range from the original inhabitants of Eastern Island to the genocides in Rwanda. The broad spectrum of topics makes it captivating.

What did I learn? Well, first of all, the five factors that cause a [TAG-Tec]society[/TAG-Tec] to collapse or survive are:

• the damage people have inflicted on their environment (use of scarce resources): chopping up all the trees turns the soil into wasteland; "no food, you die", stuff like that;
• climate change: if you are a fisherman and your lake gets frozen, you have some issues;
• hostile neighbors (enemies): war puts a large pressure on the people and the resources, getting killed while you're at it, doesn't help either;
• changes in friendly neighbors (trading partners): a society can flourish because of things that are provided by your neighbors. This dependency can be lethal if something happens to your neighbors;
• the society's political, economic and social responses to these changes: the four previous factors can be devastating on their own, but societies responses to these threats can make things better or far worse.

If we turn these insights towards Project Management, why would project fail or succeed?

• Depletion of resources: if you use too much money, time and resources there will be nothing left in the end to run your project on.
• Changes in constraints and scope: laws, policies, budgets, corporate strategies are what make up the boundaries and the rules of the game for projects.
• Corporate politics: hidden agendas and vice-presidents on a war path can kill a project before you can say "Incoming!"
• Use of sponsors: we all need a helping hand, the people that smoothen the path within organizations. Too much dependence is like too much coffee. Not good.
• Project Management reaction to changes: with measurements the PM can create or break the resilience of the project. Strategies and project organizations limit or enhance the projects survival. Doing "agile" or "plan-driven" is not just a nice discussion!

Back to the book itself. For such a big book about a very broad subject, I found it a delight to read. Diamond knows how to entertain. The views he formulates in this book are highly debated by all kinds of specialists. And that is to be expected when you have such a provocative title. If you say you know it all, people are looking with more skepticism. But to be able to bring forth the ideas he has, you just have to be some Uber-Generalist that begs-steels-and-borrows from all kinds of scientific disciplines. No matter how smart you are, you are never going to measure up in specific fields against the local experts. So I guess the author is taking a few short cuts, is making some moderate assumptions to make the story more coherent. And its the story that makes this book impressive.

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?

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 "[TAG-Tec]Parkinson's Law[/TAG-Tec]": "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 "[TAG-Tec]Student Syndrome[/TAG-Tec]" 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.

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