Schedule pressures can keep project managers up at night. Frequently the project schedule is not entirely driven by logistics from within the projects but by external pressures such as market or executive pressure.  There are metrics that can be used to help predict, sometimes these are not created, gathered, maintained or have the appropriate follow through required. When these metrics are used, they may tend to predict those things we wish not to happen.  This adds stress to the project manager as they learn that failure is becoming increasingly more probable.  Either way, measure and maintain, or neglect to measure, the stress of keeping a schedule together can be wearing, especially when the end date for the project, that is the delivery of the project results, is fixed and not adjustable such as a project to meet some legal or regulatory demand.

Resource availability is another area that can keep a project manager up all night.  In some cases, the project may start off with the appropriate resources for successful delivery. Over time, some of the key resources may be stripped from the project and substituted for other personnel; however, people are not fungible. The original staff of the project may have been our best talent, and other traumas may hit the organization from operations, the fire of the day, and the organization responds with the best talent to put out the metaphorical (and perhaps literal) fire.   The original project plan and the schedule becomes compromised.  Even when (or if) the project manager brings this to the attention of the sponsor, it is unlikely there will be a dispensation from the original project objectives, schedule or cost constraints.

The scope is another thing that can keep a project manager awake at night, or more appropriately, the lack of clarity or the fluctuations in the project scope.  It is not unheard of for the customers to either not have a solid understanding of the scope of the project or an inability to technically articulate the entire boundaries of the scope.  In these instances, the contract for the project may be secured based upon this loose scope and there will be many subsequent changes. These changes can slow down the project as the project is inundated with change requests that require approval and coordination at best.  In the worst incarnation, these changes are not understood, not coordinated and not taken into account for the cost and schedule impacts, but just acted upon.  This situation is much slower and costly due to rework.   Even if there is a good understanding of the scope, it is possible to fall into this trap through informal (often verbal or email) change requests without a systems view. The project manager is often not privy to this backroom communication and therefore will not know there is even the possibility of a problem until the parts are put together and the change is discovered, often at the customer site or late in the project. 

Communications can be another area of consternation.  In fact, this is partially coupled with the previous scope management and control problems.  The project manager can’t and probably should not be in on every conversation on behalf of the project. There are conversations going on all of the time regarding the project work and objective.  Some are benign and some can cause a catastrophe if the project manager is not involved.  This is another area in which the precipitating event happens early and finding the consequence maybe after considerable time; talent and money have been expended.  Finding this late in the project will mean rework – cost overruns and schedule delays.  The worst part is the uncertainty, is this happening or not?  There are tools and techniques such as communications plans and resource allocation matrix that can help.

Experience also suggests, in a software product development environment, sufficient time to verify or test the results of the project all along the way is another area for a project manager to fret and lose sleep.  Delays in deliveries of product iterations or the misguided belief that there should be only one delivery of the product or software means finding defects along the way is not possible. Finding all of the defects compressed against the launch date often means insufficient time for testing and defect resolution.  The assumption that there will be no defects in the product after hundreds of interactions and interpretations is just foolish and naive.

There are many areas in a project that can keep a project manager up at night, grinding their teeth.  These are but a few, as each project is to varying degrees unique, so too are the challenges that will keep the project manager’s stomach churning and mind racing while trying to sleep.  The best a project manager can do is to drive a common understanding of the way of working (sometimes called processes) and adapt the best way possible.  This is coupled with spending considerable time with those involved in the project to uncover these issues and collaborate and guide team members toward paths that will reduce these disturbances.