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 wasn't 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.
Read more

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.
Read more

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.

Photography by Mayr.

Josept Thornley explains the overall principles of Social Project Management, a term coined by Leisa Reichelt who has formed her ideas from building social software. 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.

Jared Diamond 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 society to collapse or survive are:
Read more

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.
Read more