If you’re going to be managing projects, it certainly helps to know what they are!
As per PMI‘s Project Management Body of Knowledge, a project has the following dimensions:
- A project is an endeavor undertaken to create a unique product, service or result.
- A project is temporary; it has a beginning and an end.
Project managers should be careful to distinguish projects from business operations. The classic example used by most educators to distinguish projects from business operations is the traditional help desk. If you’re working at an IT help desk receiving service calls, when you respond to those calls, you’re probably not undertaking projects. When you respond to a call to fix a hard drive, it’s likely that you’re following a routine that you’ve followed many times before… there is nothing unique about the work you’re doing. Even if you’re repairing a new problem with the hard drive, or fixing it in a new and interesting way, it is unlikely that by doing so you’re creating a unique product, service or result.
Another common mistake project managers make is to combine multiple projects into one. If you have to estimate how long it will take you and what methods you will use to create a piece of software before you can start planning how to tackle the development of the software, that’s probably its own project. If you can’t break down a project into manageable tasks – in a Work Breakdown Structure (WBS), for example – there is likely work to do before the project can even begin. I’ve had developers tell me during scheduling they have no idea how long it will take to develop a piece of software because they don’t know what needs to be done in order to create it. In response I might ask: How long do you think it might take you to research the software that needs to be made, so that afterward we can estimate how long it will take to code? I’ve created an estimable, albeit small, project for the developer to undertake so that we can eventually start the actual software development project.
In my own position as Enterprise Program Manager I manage a series of projects – unique, individual releases of a software application. Although the releases are point releases of a single software product (2.1, 2.2, etc) each one has a definite beginning and end and results in a unique product. I manage the projects, and the program that envelops them. As such, the software application persists – I have no idea how long the life cycle of our software application will be, nor can I definitively say what functionality will be in the product three releases from now – that’s part of the program. But the point release we’re working on right now I have a very good view of, know exactly when it started and when it will end, and, barring changes, what it will contain. That’s the project.