|Revision 1.0||3 December 2005|
Peculiar: adj: beyond or deviating from the usual or expected, a curious hybrid accident Wordnet 2.0, Copyright Princeton University
I am working on a peculiar project. I have worked on a few peculiar projects in my life, but they have been greatly outnumbered by normal projects. This time, however, I have been fortunate enough to notice the peculiarity of this project and to enjoy it. I have identified a few characteristics of peculiar projects and have learned how to make these the norm, or at least occur a little more often.
My current project is peculiar. It is, as the definition above states, "deviating from the usual or expected." I think of it as peculiar because all the problems are technical in nature while all the joys involve the people on the project.
Technical problems and people pleasures are not the norm in my career. Most projects have a few technical problems but the frustrations involve the people. People bicker over approaches and processes; people come in late for work and leave early; some people work 16-hour days and become tired and grouchy; other people become bored and leave the project without leaving a guide for what they had and had not accomplished. My list of people-related headaches is almost limitless.
In contrast, the people working on my current project are for the most part motivated, happy, and pleasant to be near. People are not entering and leaving the project at a pace that leaves the rest of us restarting every month. When people do leave, they do so happy and at a good break point. This allows new people to come onto the project and pick up their work without requiring the rest of us to stop and train them.
It is a pleasure to work on this peculiar project. Dare I even say that it is fun?
I cannot take credit for this peculiar project. To my credit, I have grown in my ability to manage work and communicate with people, but I still work on many projects that are normal. This project has gotten me wondering why such a pleasurable project is peculiar. Why can't *most* of our projects be fun? I think the main reason is that we don't expect them to be. Since we don't expect the pleasure of working with motivated people with good attitudes, we don't work to create such projects.
I've examined myself and my practices on past projects. Only once in 25 years have I scribbled a list of attributes about the people with whom I wish to work. (That one project was also peculiar; maybe there's a pattern here.) Instead, I have thoughtfully written a work breakdown structure, sketched a schedule having a critical path, denoted the risks and mitigations, and other such good practices. Most of those projects succeeded; that is, they delivered the desired product on time and within budget. Few of them, however, were fun.
Here is a suggestion for creating peculiar projects and maybe making them normal instead of peculiar. This technique is called "incremental consensus" and was described to me in a private conversation with consultant and author Jerry Weinberg  (I describe this technique in ).
Incremental consensus begins with two people who want to work in a mutually pleasing manner and succeed on a project. This team grows one person at a time. When one team member finds another person who wants to join the team (emphasis on the desire to be on the team), the current team members must agree that they would like that person on the team. No one enters the team without the consensus of the existing team. This team is likely to be peculiar because everyone on the team is accepted by everyone else.
My peculiar project team wasn't formed using incremental consensus, as it comprises some 100 people. The ten team leaders, however, were added to the team one at a time, with each person wanting to be on the existing team (there is that desire again).
My peculiar project may not succeed. We are facing several technical problems that threaten to blow our budget and delay deliveries. There are no guarantees on projects, especially when you are inventing hardware, creating algorithms, and trying to write new software to fit the custom hardware. What is peculiar is that we talk openly about our technical problems and seek ways to solve them as a team devoted to project success and to one another's well being. When the latter is present, the former seems to follow.
 Jerry Weinberg, see http://www.geraldmweinberg.com .
 Dwayne Phillips, "The Software Project Manager's Handbook, Principles that Work at Work," IEEE Computer Society and Wiley-Interscience, 2004. http://www.amazon.com/gp/product/0471674206/103-0814565-7735016?v=glance=28315 5=books=glance