Has your milestone become a millstone (round your neck)?

“This is not mission difficult, Mr. Hunt, it’s mission impossible.“

As project managers, we may occasionally feel like agents of the IMF, having to walk the tightrope between optimism that our project objectives will be met and the educated cynicism of having lived through the impacts of Murphy’s Law on more than one project!

Nowhere does this balancing feel more precarious than when we are facing a potential delay to a key project milestone that cannot be absorbed.

Should we raise the flag early which might get us points from our team members for taking their concerns seriously but risk antagonizing our sponsor or other stakeholders who don’t share these concerns or do we remain optimistic that we’ll be lucky but alienate our team members which could in turn run the risk that their pessimism become a self-fulfilling prophecy?

While there is no fool-proof panacea, the following questions might help.

1. Have you got an independent opinion of current status?  Sometimes it helps to just have a fresh pair of eyes review work remaining relative to the looming milestone date to either refute the “doom and gloom” or to suggest a creative solution that has not been considered yet.

2. If you are in a matrixed organization, do the functional managers support their resources’ concerns?  Having good relationships with the resource managers enables you to engage them in either validating the concerns of the team members or supporting your efforts to meet the deadline.

3. Have you truly assessed and eliminated all viable options for meeting the dates?  Fast tracking, crashing, multiple resource shifts to take full advantage of remaining days and scope reduction or deferral should all be considered.

Assuming there is no natural way in which the deadline can be met, present the grim news to your customer and key stakeholders backed up by evidence that you’ve “done your homework” and supported by options that should help to mitigate the impacts of the delay.

On the other hand, if you feel that the milestone can be met, a potentially harder task remains – how do you reinvigorate your team with the drive and optimism crucial to maintaining the productivity levels required to meet the date?  This is where you’ll need to pull out every soft skill you possess.

Guinan - “When a man is convinced he’s going to die tomorrow, he’ll probably find a way to make it happen.  The only one who can turn this around is you.“

Favor bridges over overpasses

After reading the title of this post, you might (naturally) be confused as to its link with project or change management.

Seek and you will find the connection!

In an article which is shortly to be published on ProjectTimes, I’ve written about the benefits of appropriate escalation for timely decisions or resolution of issues.  Unfortunately, I’ve also frequently run across situations where escalation is used as the first resort by project managers, team members or stakeholders for fairly minor decisions or issues which could easily have been resolved through direct conversation between the parties involved.

The dangers of excessive or premature escalation include:

1. The “Cry Wolf” syndrome – senior stakeholders to whom frequent escalation is directed will begin to marginalize the repeated requests for assistance and when a genuine requirement emerges, they may ignore it.

2. Lost in translation – depending on the number of levels of escalation or the diffusion of the original message, the perceived intent and priority of the request can be misinterpreted or mangled resulting in the potential for greater delays to decision making.  In addition, decoding confusing on the part of the targets of the escalation can result in further needless churn.

3. The chasm widens – frequent escalation over minor situations can cause participants to reinforce their positions, strengthen their stereotypes about “them”, and reduce the likelihood of efficient communication bridges from getting built.

Establishing some simple objective criteria for escalation within your project’s Communication Management Plan can bring some consistency to the process, but beyond that, a couple of simple practices can save unnecessary thrashing.

1.  It’s never a good idea to escalate when you are angry.  Allow yourself the time to get some perspective before deciding that escalation is the best option.

2. Explore alternatives to escalation and evaluate the expected impacts of those alternatives on the project’s constraints or objectives.  In conjunction, work through the secondary risks of escalation to reduce the likelihood that you’ll win the battle but lose the war!

If you feel certain that escalation is the only way to avoid measurable impacts to project success, then by all means, go for it.  However, as with many of project management’s soft skills, with great power, comes great responsibility.

Divide and conquer

It is a well recognized concept that the overall risk inherent in a project generally decreases as you reduce its scope or complexity.  This leads to the common practice of splitting complex projects into many small “mini-projects” to divide the risk across them and hopefully improve the predictability of the overall initiative.

While this is a good approach, the challenge comes when putting it into practice – how do you decide on a method for slicing the larger project and how many projects should you created?

Here are a few ideas:

1. Split the initiative by value chains – the benefit of this approach is that the integration risk for any single customer or consumer is reduced, and if the need comes to reduce the scope within the overall initiative, you can terminate an individual project and still deliver some tangible value.

2. Split the initiative by the nature of the deliverables – For example, on a systems development or implementation project, technology deliverables might benefit from being created within one project to avoid cross-project integration challenges, and it may be possible to have operational readiness deliverables (e.g. SOPs, training documentation, or maintenance procedures) created in another.

3. Split the initiative based on resource skills or availability – One method of reducing risk is to match the skills of the project managers and team members to the work they are most comfortable with delivering.  This might result in increased complexity from an integration perspective in which case it might make sense to remove the responsibility for integration from each mini-project’s team and centralize it in a separate integration project management function.  Resource availability might be another driver – if there are multiple resource bottlenecks, is there a way to spread these bottlenecks across the projects as opposed to focusing them within a single one?  The overall guidance here is to avoid splitting resources across multiple mini-projects if at all possible.

4. Split the initiative based on deliverables with maximum inter-dependencies – To reduce integration risks, review the deliverables list from your WBS and group the ones that are very tightly related into a single project.

Regardless of which method you use to split up complex projects, the key is to perform the rough cost-benefit analysis related to reduced complexity risk but increased lines of communication (don’t forget N*(N-1)/2) and integration risk.