One of the hardest things to learn for me as a project manager is to restrain myself from delegating tasks too quickly. In my mind, I often have decided who in the project team would be the most suitable for a certain task that is being discussed. However, I have seen in the past few years that the best way of assigning tasks is to shut up.
There is a sea of insecurity in the silence between: “This is important, who could do this?” and “I can do that.”
When I started out as a project manager, I thought it was my job to assign tasks and that people would appreciate my effort to get the right task to the right guy.
Nowadays, working with professionals, the situation is quite different. The self-selected tasks seem to be easier, less ambiguous and more fun than the assigned ones.
Of course there are limits to the shut-up-strategy; one pitfall is that some young, eager guy/gal wants to show off by taking on too much.
Another is that nobody really wants to do an activity.
But whenever it happens, it is a signal that this activity maybe does not lead us in the right direction to our common goal…
This is one of the best books on project management I know. Frederick Brooks classic volume on software project management was first published in 1977, and updated/republished in 1995.
The book contains numerous anecdotes and essays on various insights stemming from Brook’s experiences from leading the IBM OS/360 development in the 1960’s.
The most famous statement is alluded to in the title, sometimes called Brooks Law: “adding programmers to a late project will make the project even more late”.
The main reason for this is increased time losses in communication/training for the added “resources”. Brooks goes on to show with clear examples how this works out.
In the summer of 2002 I crashed head on Brooks’ Law at the Saab Automobile factory in Trollhättan, Sweden.
Instead of using the developer programmers to do the integration testing in the pre-production vehicles, new resources were assigned to this task, and I was asked to coordinate the efforts. It took weeks and weeks to get the new people up to speed. In the learning phase they consumed much of the time of the original developers’s time and they introduced new mistakes and miscommunications. Of course it is impossible to know for sure how it would have been if the original plan had been followed, but afterwards I felt very uncomfortable with the project decision to throw more people at the problem.
Another great insight that is eloquently explained is that it is virtually impossible to specify requirements correctly for a new system. Nobody is so smart that he/she can write down what is needed in a unique and non-contradictory way before the system exists in a prototype form.
Therefore, prototyping is a often necessary to get the requirements during the project.
This has re-surfaced as one of the cornerstones in the “Agile” programming methodology.
It is a strong insight and I see this in more domains, not only software. At the R&D lab where I now work, also mechanical designs and mechatronic solutions profit from iterative development instead of trying to get it all right at the first try.
In the coming weeks I will follow a Black Belt training for “Design for Six Sigma”, which claims to enable projects to get it right the first time. (see e.g. http://en.wikipedia.org/wiki/Design_for_Six_Sigma) I am curious and somewhat sceptical… Maybe there is a “Silver Bullet” after all?
I recommend this book to everybody working with project management, not only software.
The main idea is that different people actually like different things. Not so controversial, perhaps, but the clue is that internet helps buyers to find producers in a better way. Interest (and money) will move away from the Top Ten Blockbusters and away in all different directions.
I recognize this clearly from my experiences in the Magic arts community. In the end of the nineties, I was part of the Gothenburg magic scene as an upcoming young part-time magician. I was devouring all books, VHS tapes and bundles about new magic tricks. But they were really hard to find.
Once a year, on the congress in Lund, the Dealers showed up with meters of books from mainly American magicians. Once a year, I had the opportunity to browse through the material and select a handful of quite expensive works. Unfortunately, most of the books dealt with aspects of magic that were not very interesting to me.
Most of the books on Magic, I had never seen. Until I came to Dresden in 1997 for the FISM World Congress on Magic. I was overwhelmed by the width and depth of the genre.
Now there are online catalogs and an unparalleled availability which will help passionate wannabe customers to find what they look for, even at Amazon.com. (And not just buy the book that happened to be available.) The niche is thriving!
I think that the Magic community is similar to other kinds of subcultures. I am convinced that there are harmonica players, pole dancers and macramé knitters who now get connected to hitherto unknown suppliers and can purchase/license what they need at much less effort than previously.
The book has a funny side in a sense that I did not expect, and that is the short half-time of the Internet examples. It was written only five years ago, but that was before Bit-Torrent, PirateBay and Facebook hit hard, and Bing was not launched. Google Maps was really new and yet to become as useful as it is today. Therefore, the book seems oddly outdated, even though it tells of a revolution still in unfolding.
One of my favorite tools of “Lean” is visual control. The idea is that visual information on the wall next to the workplace communicates better than intranet pages or databases.
For each project I run, I have a whiteboard of roughly 1 square meter per project, with the most important information, updated at least weekly. I include: project objectives, deliverables, team members, status, decision log and maybe most important: What are we working on now?
At least half of the project team is located in the same room, so they will invariably see what is going on in the project.
Typically, we have pulse meetings once or twice a week, to get alignment on what we are doing and who is doing what.
For me, this spices up my motivation.
Once in a while there are slow days, when the brain goes on half speed and the weather outside looks alluring. Then it is tempting to log on to [Your Favorite Social Network Site] and just click around. Or read another article about PyUnit, or a long email about a policy document change from HR.
But then I glance at the project wall and I see my name on a task, I am back in focus again.
I think that all tools that remind us about what we should be doing are useful.
And, by aligning weekly with the rest of the team, we can scrap some activities that we actually should not be doing, at least not now.
It is also more fun to finish tasks that have been self-assigned than diffusely delegated!