For All The Right Reasons

Doing projects is hip. At least, that's the impression one might get given the number of projects and project managers around. It's not that surprising when you keep in mind that our ever changing world asks for activities with ever increasing complexity. We have to keep reinventing the way we do things. Invent it, and then throw it away, because of it's obsolescence; what works one time, has no use a second time. It's the environment where projects survive as the fittest.

Links of Interest
Project Management Code: Why Do You Do What You Do?

A project, by definition, is a temporary activity with a starting date, specific goals and conditions, defined responsibilities, a budget, a planning, a fixed end date and multiple parties involved. You know what you have to do, do it, once, and that's the end of it. That's a project. However, being hip has it's disadvantages. Our local housing office has a permanent project manager for financial controlling. This is a on going activity for the office, and the project manager does it as his full time, never ending job. What ever he's managing, it surely ain't a project.

There is no real harm in naming a tiger an elephant or vice versa. No one gets hurt by naming his job a project, even if it doesn't fit the definition by a mile. But don't be surprised if techniques for projects don't work on 'projects-just-by-name'. Don't be amazed when applying the techniques may seem like killing a bumble-bee with an machine gun. Don't get mad when other people don't know why you're doing an easy job the hard way, by making a project out if it.

Start a project, but only for the right reasons. Not for the heck if it. Not because of the cool acronym. Or the status.

For a project definition, look for the following aspects:

• Starting date
• Specific goals and conditions
• Defined responsibilities
• A budget
• A planning
• A fixed end date
• Parties involved

And then, if it looks like a duck, walks like a duck and quacks like a duck, it probably is a duck. However, if it doesn't come close, raising the question of treating it like a project is the right thing to do. There may be an easier and much simpler solution.

Often (…) top management has no project; it merely has a problem and does not know how to, or does not want to, find a solution. So, it expects the players to find the way. Much social and industrial unrest can be caused by top management not having real projects, but only having the desire to get rid of a problem. (Managing Sensitive Projects)

If you don't find all the aspects named above at this moment in time, it is possible. Wait, and make the final judgement at the end of the intake. Working on one of the subjects, might cause one of the aspects to popup.

Movies are great. Women get pregnant and 5 minutes later their kid goes to college. One moment the family has the need for a vacation, the next shot they're floating on the canals of Amsterdam. And that's all just swell. Not many people want to view the hours of discussions around the kitchen table on deciding what country to go to. Not many people want to see every moment of a woman in labor, and watching the growing pains of a teenage kid, for hours and hours. Living a movie is great, you can skip the boring parts.

Being in the highest ranks of management is great. One moment you're in a wooden cabin in the mountains together with your fellow priests reflecting the need for the strategic development of a new product line. The next moment you're reviewing the results after taxes the new product line brings in. Life is good being at the top.

Meanwhile back in the jungle of middle management, lesser gods are struggling to pick up a vague comment made up in a wooden cabin up in the mountains, make something of it, and turn it into reality. Being a software project manager you meet strange objects thrown toward you from above. It could be no more then a little statement, or it can be a complete part of an organization coping with the remains of old mission impossible. The thing they have in common though is their label: project.

If you're a permanent member of the organization, you're just new, or you're from a third party supplier, the moment a software project manager comes into the picture, there is already something labeled as project. The 'chicken-or-egg-first'-dilemma does not apply to project management; first is the project, secondly the project manager. Sadly. The first task of the software project manager is to reengineer the situation that led to the project. The stakes of the people who initiated the activities now labeled as project should be clear. The requirements resulting from that should be known. These are the tasks during the intake of the project.

All may not be crystal clear. Time schedules may already be stated, without any one knowing what should be done in the first place. Goals can be formulated with such an ambiguity that anything produced satisfies the goal. The sad part of it is that stakeholders have already formulated their requirements. They may not have communicated them, but in their minds expectations are already in a particular direction. You should sort it out. It's a dirty job, but someone's got to do it.

At the end of the intake the project manager has aligned the project in such a way that he/she is willing to take the commitment for it, or he/she found out it is impossible and gives the job back (Yes, you have that choice!).

Related links

How Do You Describe A Project Problem?

Towards Speedy Assessments Of Project Problems