In yesterday’s exciting installment of “Project Management 101,” we established that projects are temporary endeavors with start and end dates. So what happens between those dates? A flurry of activity and—Voila!—a new product emerges?
In a way, yes, but the flurry is organized into distinct phases (our next Project Management vocab word) which unfold in a pre-determined sequence. Whether it’s a construction project, engineering, software development, process improvement or something else, projects are organized into phases which go something like this:
Six or seven phases is about all anyone can stand. Not that all projects are awful; it’s just that it’s often difficult to sustain momentum. The exciting phases are Planning and Launch. Those in the middle, not so exciting. The worst (my opinion) is Test. By then everyone just wants the thing to work, meanwhile testing is revealing all the problems, while impatience is mounting, also defensiveness on the part of the people who thought it was good enough already. You get the idea. No fun.
But not everything in those middle phases is sheer drudgery. There are occasional ah-ha’s, good meetings, even good times, amid the hard work and confusion. But if you were to map the emotional state on most projects, the high points would likely be Planning and Launch.
Next bit of vocab: Project phases are defined in a Project Life Cycle, or sometimes called a Project Methodology. (I prefer the former; “methodology” has too many syllables.) The Project Life Cycle is often in the form of a book (usually online), which everyone talks about but few people have actually read, or at least they haven’t read much of it. Everyone generally knows the project phases, what they’re called, which comes next, and what you do in it. They assume that how it’s written up in the Project Life Cycle lines up with their assumptions, and are surprised when sometimes it doesn’t.
You think I’m kidding?
But enough about day-to-day realities and a bit more about vocabulary.
The “D” Word
Projects are all about delivering. Whatever it is—a product, service, improvement, whatever—the point is to deliver. (Ever notice that “deliver” spelled backwards is “reviled”? Not, perhaps, especially relevant, but I bet there are projects to which that adjective can be applied.)
But the real “d” word I want to tell you about is this one: “Deliverable.”
A deliverable is nothing more than a work product, something you create as part of the project. Could be a document, a diagram, a piece of software, a PowerPoint slide deck—anything that’s produced that is part of the project. Officially, I think “deliverable” is probably jargon, and we all know we’re supposed to avoid jargon, but I’m afraid that working on a project without using the word “deliverable” would be like explaining to your dentist where it hurts without using the word “tooth.” It can’t be done.
So a project is organized into phases, and within each phase the project team produces specific deliverables. One project, many phases. For each phase, many deliverables.
And that’s how it’s done.
Tomorrow: More about deliverables. If you were working on a project, what deliverable might you be working on?