Project Management Overview

A project is a grouping of activities that, when put together, achieves an overall goal. A project is usually distinguished by the fact that it's not an ongoing process—it's transitory in nature; and it is designed to produce some sort of result, either in the form of an invention or offering, that the requesting customers can utilize. A project always h as a recognizable beginning and end.

A project is typically (though not always) requested by a customer; its components are fleshed out by you the PM, and it is then performed by the project team you assemble. Some projects can be "experimental," meaning that you've been requested to develop something that fulfills an industry need or a strategic goal, but the results of which you may not be able to guarantee because it hasn't been tried before.

Finally, it should be noted that a project is launched to produce something new and different. Projects shouldn't reinvent the wheel; they invent something that makes the wheel better.

Here's an example of an experimental project: I once worked for a company that wrote cardiac ultrasound imaging software. You could take an ultrasound scanning device, like the one used to check the health of a baby inside the womb, and use it instead to get an image of the heart. It was very cool. The company wanted to advance the software from 2D to 3D, which meant they'd have to write a ton of C++ code to take lots of 2D images and render them in 3D fashion. The 3D part was experimental and required scads of time and effort on the part of the developers, fueled by venture capital (VC). The "customers" in this case might've been identified as the venture capitalists, but the developers weren't developing a product or service for those people. The true customers—the folks they were developing it for—were the medical community at large; the venture capitalists just happened be the ones putting up the money.

The 3D development wasn't run very well—it certainly wasn't run as a project—and inevitably the company went out of business, simply because it never delivered the product and the VC funds finally ran dry. If the 3D development had indeed been run like a project, where it was recognized that they were developing a unique product, where there was a beginning and end to the development (you had to sell the software to somebody at some point), and where the phases were closely controlled by a project manager, the company would still be in business today.

In the IT world, we can very strictly determine a project from ongoing management by utilizing the above rule. Are you implementing a new e-mail server system? Then you can easily define a start date and an end date, and you have before you a project. How about the development of some code for a new system? Again, you have a very clear start date and an end date when the code is deployed to users, and you can treat the whole thing as a project. Code rewrites and updates involve a different project and are not thought of as an attachment to the previous project. (Though you could write the project in such a way that code rewrites might be Phase II of your initial project.) Are you replacing your network infrastructure with a brand new type of router and switch, including the re-cabling of your enterprise? Then you again have a very definite start and end date, and you can objectively treat the whole thing as a project.

A second key word in the definition of a project is the word unique. The project must be distinctive in some distinguishing way from other projects. You would not call the tape backup process, where by backup operator routinely changes the tapes, a project, because this is a frequent, repeated— not unique—activity.

Was this article helpful?

0 0

Post a comment