The project' s schedule is also something that you' l l watch like a hawk. There are several areas where the schedule can drive off into the weeds:
Team member is slow in completing his assigned tasks.
■ Team member takes on work he shouldn 't , thus enlarging scope and getting him off schedule.
■ Team member has an illness or catastrophic event that takes his time away from the project.
■ Team member falls in love with another team member and spends his time sending romantic e-mails instead of concentrating on project. (Think this doesn t happen?)
■ Team member is on the team but doesn' t want to be (or has similar ax to grind)—spends his time figuring out how to derail the project.
■ Team member doesn 't feel like he fits in with the rest of the team.
■ Team member' s duties have not been specifically defined; he winds up wandering.
■ Team member doesn 't have the skill set you thought he had—cannot meet the task deadlines, might not be able to complete the task.
■ Team member is a "cube-hopper" (also known as a "gopher") who spends more time catching up on the office gossip than he does at his desk knocking out the project' s tasks.
■ Team member is jealous of you—thinks he should've had the job. Hey, he passed the IT Project+ test too, didn' t he?
■ Vendors fail to produce goods or services on time.
■ Technical snafus enlarge the project ' s scope (code presents an unforeseen problem, etc.).
■ An integrated-systems component fights you more than you had anticipated.
■ External forces, such as a change in company strategy, drive down the priority of the project.
You get the idea. Anything that could hinder the team or the project' s efforts will likely result in an increase in the project ' s schedule. Now, if you were smart, you built a little leeway time into the schedule. However, too much leeway and your project will wind up well beyond schedule, and you ' l l be "called on the carpet" to find out why.
Was this article helpful?