Archive for September, 2016

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.

Many of you who have read our blog know we are fans of the show Aircraft Disaster on the Smithsonian Channel. We do not like the show for the disaster part, but the root-cause analysis aspects. These things are intriguing for engineers. Root cause analysis is an important skill for design engineers, process engineers, and even project management people. The latest one I have watched was about Northwest 85, in which the plane suffered a hard over lower rudder in a Boeing aircraft. On the television show, the root cause was never really determined, though a design modification eliminated the possibility of that incarnation of the failure from coming to pass was introduced. This is not really something we can really take away from this show and apply to our work lives. However, there was a compelling argument made on the show was that cockpit resource management helped ensure the safe handling and landing of the aircraft.

All along the way, the crew was uncovering other potential and likely issues to prevent a safe landing of the already crippled plane. One of the key elements cited, in addition to the quick initial response from the pilot, was cockpit resource management. There is an analog to cockpit resource management to product development and project management specifically. In this case, the crew not only uncovered those obstacles but clearly defined who would be doing what, and when. This is the same approach projects should take even before they end up in trouble. Experience suggests this lack of clear articulation of who is doing what and to what degree ends up presenting significant difficulty for the project and the objectives. For examples, a missing resource allocation matrix, and risk register with nobody identified for monitoring specific metrics.

In any team work environment, the division of work is essential to coordination of the effort, and not letting any part of the work to fall between the proverbial cracks. Resource management is essential for product development success as it is for flying an impaired plane, though perhaps the consequences for failure may be less severe.