What Is A Project, Really?
This question may sound very academic - but in fact it is not: A lot of project managers seem to constantly forget about what makes a project a project with sometimes dramatic outcomes.
There are a lot of different (some really academic) definitions on what a project actually is. I personally define a project as something which
- has a defined start date,
- a desired finish date,
- one or more specific goals and
- is not routine work.
I owe the last point to Bruno Reisinger, a good friend who recently emphasized this point and I think he is right: Some piece of work can either be a project, or it can be routine work, for the simple reason that routine work is often defined in a process and I think that something cannot be a project and a process at the same time.
However, the main reason why I wanted to talk about this is that in my opinion, much too many people tend to start "projects" without specifying a real start date, without defining clear goals and without mentioning a desired finish date. What these people often don't realize is that this gets them into real trouble:
- Projects without a defined start date tend to get never really started - they are also often not taken serious by the management or even coworkers. It is good practice to not only define a very specific day, but also to host a kick-off meeting (even if it's a small one and only lasts a few minutes)
- Projects without a desired finish date tend to run endlessly without producing a real outcome. The major reason for this is a psychological fact: Most people have the "student syndrome", i.e., they will do 80% of all work in the last 20% of the time. Please answer the following question to yourself: When are the last 20% of time in a project if there is no finish date? My suggestion: Always set a finish date. If you cannot set a meaningful finish date straight away break the project down into subprojects or phases and set at least a finish date for the first phase
- Finally, projects without specific goals tend to produce outcomes which are different from what you expected. This can be especially embarrassing if it is a customer project and I fear that many of you know these words: "This is not exactly what we wanted..." Therefore, be sure that the goals (and also the "not-goals") of the project are clearly specified. Note that bullet points and outlines work best - I have often seen pages over pages of floating text produced, but I seldom met someone who actually read them
Bottom line: If you did not define at least a start date, a finish date and some specific goals it's not only the question if your project will succeed, it's even the question if you have a project at all...