Does your organization see every opportunity as a "must-win" project, even when it"s a poor fit for your in-house talents? If so, this is one of several viewpoints that can blind your company to potential problems ahead. In Part 1 of this series, we explored how to recognize six common project traps. Now in Part 2, we"ll review 10 major mistakes to avoid (or risks to flag) when choosing, estimating, and staffing your projects.

First, it"s important to recognize that your organizational culture sets the tone for how you approach projects. For example, does your company always expect people to do more for less? Does the management routinely insist on or agree to unworkable schedules? Are team members encouraged to underestimate their realistic efforts? If so, these are signs that your organization may have a "must-win-at-all-costs" view of projects. You may want to consider how idealistic but impractical expectations could set the stage for project failure.

In any case, if your business faces challenges with project budgets, schedule, quality, or features, try asking these 10 questions the next time you"re considering a project:

1. Is the project non-compelling or a bad fit for the project team?

A bad fit means that it doesn"t fall within the general professional or technical arenas in which your company has accomplishments or your colleagues have expertise. Note that if your projects normally entail working with subject matter experts who would supply the information you need, this is not as great of a concern.

2. Will the project scope entail operating in unfamiliar territory?

Even if it"s a reasonable fit, if a project involves requirements your team has never worked with before, you could be overly optimistic in assuming everyone can come up to speed quickly enough to be successful on the project. You may need to seek outside expertise, although this can introduce its own risks (see #6-7 below).

3. Are project requirements, such as product features, complex?

A project that requires many complicated features to interact correctly vastly increases the potential for problems. One risk strategy could involve agreeing to phase in and test the complexity over time. Another could be to negotiate a reduction in the number or difficulty of the features to be completed.

4. Are the requirements pitted against an aggressive schedule?

Time limits of some sort exist on almost every project, and drive nearly every other project expectation. Will there be enough time to implement the requested features at the desired quality level? If not, you may want to negotiate a longer schedule, agree to reduce the requirements, or phase in some features later. You could bring in more people, although this will involve more coordination.

5. Are too few personnel and resources available for the project?

Project managers routinely lose sleep at night over what would happen if key project members were to leave. Or if the funding or resources were to get chopped or significantly delayed. It"s one thing to have snafus occur later in the effort, but it"s another to start off unrealistically. So try not to underestimate your needs.

6. Will coordination with many different collaborators be needed?

Involving many people means complex hand-offs. If your project will include client or third party collaborators, how will people interact? Should all parties remain in direct communication? Or should each group have a single point of contact? Also think about the division of work, and each group"s responsibilities to the others.

7. Are the primary collaborators unfamiliar to the project team?

If it does become necessary to recruit one or more new contributors, will you be able to verify whether they can do the job? If the unfamiliar parties have stretched the truth about their capabilities, you may be in for trouble. If there"s a way to have them prove themselves first, that"s ideal - or else have a contingency plan.

8. Are project team members discouraged from raising concerns?

Before and after the project starts, team members will identify all kinds of challenges. Do you want people to raise red flags when they see potential problems, or do you prefer everyone to keep quiet, maintain a stiff upper lip, and work 24/7 if needed? The team culture will determine whether the members verbalize and address in a timely fashion the many pitfalls that can appear along the way.

9. Are there insufficient review and test cycles in the schedule?

Allocating enough time for review and testing iterations commonly presents a challenge. Regardless of your initial planning, if project delays begin to add up, what will people want to cut? Can you afford to reduce testing and still deliver quality?

10. Are there no standard protocols for managing scope changes?

When the inevitable "add-on requests" materialize, consider how they"ll affect the project. Unless you have a tool, such as a project change request, to adjust the official budget and time frame, you"ll always be at risk for cost and schedule overruns.

If you answered "yes" to one or more of these questions, it means that each is an area of risk that you"ll need to manage to ensure project success. Either create a workable plan for managing these risks, or consider whether pursuing the project is in the best interests of your organization.

Copyright 2005 Adele Sommers

Adele Sommers, Ph.D. is the creator of the award-winning "Straight Talk on Boosting Business Performance" success program. To learn more about her tools and resources and sign up for other free tips like these, visit her site at http://LearnShareProsper.com.

One of the first consulting jobs that I ever got was in project management. And let me tell you, there is no greater overwhelming responsibilty than being a project manager and it is something I will NEVER do again. So what exactly is project management and what does a project manager do? Well, that depends on what the business is. Some projects are more overwhelming than others. Since I want to keep this article strictly to my own experience I will go over project management of an automated packing company.

This company packed ladies" shoes. But not through the conventional method that you might think. The actual packing was done by real flesh and blood people but the system used was totally automated and mind boggling to say the least. I"m not going to get into the specifics of how the system worked as this is an article on the actual project management itself but you do need to understand the pieces involved so I will cover them as needed.

Well, the first thing as project manager that I had to do was work with the budget I was given. A project manager is not the ultimate decision maker. That"s the person above him, who is usually an executive vice president. In my case it was a divisional manager. A budget was presented to me and I had to set up the project within the constraints of the budget. To do that I had to determine what the project needed to succeed.

In this particular project this was what was needed. The hardware of the packing system itself had to be built from scratch so engineers had to be brought in to construct the system. These were contracted and paid by the hour, so a time estimate of how long it would take to complete construction was made. Then there was the computer software to run the equipment after it was built, so programmers had to be hired. Also it had to be taken into consideration that the programmers would need to be kept on even after the project was finished in case there were bugs found or enhancements that needed to be made. Then there were the workers themselves, the ones who actually packed the shoes, which also included managers to oversee the workers, so a personnel budget had to be made and stuck to. In this case we were way over budget so personnel had to be cut which cut down production.

Then there was the quality assurance team that had to be put together to make sure that the boxes were packed correctly. Then there was the security team that had to be put together to make sure there was no theft. All of the above ultimately came down on yours truly. I"m not ashamed to say the project was a failure on several levels. The machines didn"t work as efficiently as expected. The programmers were not very competent and there were a lot of bugs. Production didn"t meet expectations. We couldn"t pay enough to get skilled packers. It was just one thing after another. After one year the project was abandoned. I was out of a job and I never did anything like this again.

Yes, project management. It"s 2 little words with a ton of responsibility.

Michael Russell
Your independent guide to Project Management