Helping to build the career you deserve! |
A weekly ComputorEdge Column and Podcast by Douglas E. Welch |
A sure way to project failureJuly 6, 2001 ** Listen to this column on your computer, iPod or other audio player ** Listen to the Podcast
A life in a high-tech career is a life of projects. Your
work will be made of projects large and small. While there is no sure
way of assuring a project's success, there are many specific ways of insuring
its failure. In fact, sometimes it is possible to kill a project before
it even gets off the ground. Below are some of the usual project pitfalls
and what you can do to avoid them. Front line input The single most important task when starting a new project,
especially a high-tech one, is to get input from the people who will actually
be using the system you are developing. For a web site, this would be
the customers who will be using the site to place orders or get information.
Inside a company, this might mean the people working the tech support
lines or placing the purchase orders. I don't think it is too harsh to say that without this very
important input your project will be sabotaged from day one. Too often,
projects are imposed from above without any concern to those who will
actually have to make them work. Some projects will take a 2 step process
and turn it into 4 steps or more when a few minutes spent with front line
people could have shown that one step or another was unnecessary in the
first place. Front line workers understand how processes need to be handled,
in what order, by whom. Get this wrong and the project will sit unused
and productivity will suffer. Talk to the front line people at the start of a project.
Don't wait until you are putting the final touches on the look and feel.
If you do, you will find that no one will be happy; not the users, the
management or yourself. Time is on my side When I started working in high-tech full-time back in 1986
my boss and I often had to give estimates for providing various services
and features on an early online service. The office joke ran, "take
Doug's estimate and Tim's estimate, add them together and divide by 2."
What is sad is this was more reality than a joke. I chronically overestimated
the time required and my boss chronically underestimated. Both extremes can lead to major problems in getting a project
going. If you provide a project schedule measured in years instead of
weeks or months, the client is likely to abandon the project or go in
search of someone else. If you underestimate the time involved you will
be facing missed deadlines from the day you begin the project. Neither
of these scenarios is going to improve relationships with your client. If the project is truly huge, you will need to break it
down into smaller parts, each with their own deadline. Each phase should
have defined deliverables and a firm deadline. This allows the client
to see the scope of the project and gain an understanding of why it might
take years to accomplish the entire task. If you have underestimated the time involved in a project
you need to sit down with your client immediately and detail why the project
will take longer than planned and how you intend to approach it. Nothing
sours a relationship more quickly than missed deadlines. If you consistently
miss deadlines you are virtually guaranteeing that this client will never
work with you again. It can also lead to problems receiving payment for
the work you have already completed. Money, money, money Finally, make sure your budget for a project has some basis in reality. Huge fees will send clients looking elsewhere, underbidding will send your company into bankruptcy. More important, though, is not to be seen as someone who is constantly "nickel & dime-ing" the client to death. Make sure that all fees are carefully laid out and directly associated with some deliverable. Make sure you have a billing structure in place to handle the inevitable "change orders" that arise as the project moves forward.
|
<%=INSERTTEXT%>
|
|
|