Easy in theory, difficult in practice

Baselines are often perceived as a hygiene factor when it comes to project administration – they don’t make your pulse race any faster, but they are required for performance monitoring.  As this is their primary function, some organizations feel that establishing schedule or cost baselines is of marginal value given their current PM maturity.

Can baselines help us other than to provide a set of data points for comparison purposes?

Here are a few value propositions, and I’d encourage you to provide me with other use cases:

1. In the absence of baselines, all we have are current forecasts and expectations on the part of our stakeholders and customers.  Baselines provide a tangible means of defining and setting these expectations.

2. For someone that has just arrived on the project, baselines provide some insights into the project’s past and can help the newcomer gain some insights that could not be derived by merely looking at current project metrics.

3. Baselines can provide a metric to assess the overall predictability of project & portfolio planning.  One could measure  the number of re-baseline occurrences over the lifetime of a project as well as the driver for these changes (internal or external to the organization).  While this churn might have been generated with the best intentions (e.g. providing customers with a better deliverable or stemming from an external funding impact to a project) it comes with a cost as the effort required to assess and implement project changes has to be paid by someone.  With this data in hand, the organization could look at justifying the adoption of agile methodologies or could use it as a KPI to measure the success of reducing the volume of internally-driven changes.

Anthony Robbins’ quote for individuals equally applies to projects: “If you don’t set a baseline standard for what you’ll accept in life, you’ll find it’s easy to slip into behaviors and attitudes or a quality of life that’s far below what you deserve.”

(Note: this article was created and baselined in April 2011 on my personal blog, kbondale.wordpress.com)

A LinkedIn question a while ago asked whether Murphy’s Law is inevitable on projects.

The very definition of projects favors the conditions for things to go wrong as we are striving to create a unique product, service or result.

In addition, projects (most constructive ones at least!) would appear to run counter to the second law of thermodynamics as they are an attempt to bring order to chaos or to reduce entropy.

Given these conditions, one would expect that Murphy would run rampant in projects, and in many organizations this seems to be the case.  I’m not a fan of pessimistic project management as that state of mind can result in a self-fulfilling prophecy.  Blind optimism isn’t an appropriate state of mind either.  Instead, Murphy’s Law should validate the need for project and resource management practices:

• Right-sized project risk management can help to reduce the impact and magnitude of uncertainty – Murphy could still apparate, but by thinking through (realistic) scenarios on what could go wrong, responses can be developed to reduce the likelihood of firefighting.
• A work breakdown structure and project schedule provide a model for what will be delivered and in what sequence activities will be performed.  This reduces the potential points of impact from uncertainties when compared with a project where the team “just does it”.
• Striving to plan resource allocation at sane levels (at or below 100% on a weekly basis) means that if Murphy does strike, team members might actually have capacity to deal with it.  If you’ve already planned resource allocation beyond 100%, no such capacity exists and you will simply make Murphy stronger by introducing further risk through resource fatigue,  morale issues or burnout.
• Kickoff and regular status meetings provide an opportunity for team members, sponsors & stakeholders to reinforce their alignment towards the shared vision for the project.  This is akin to the approach used by many animals to protect themselves from predators (a very material form of Murphy’s Law!) – solidarity provides security and stragglers are usually picked off.
• Conducting retrospectives or lessons learned sessions on a regular basis (and not just at project closure) can cultivate and disseminate organizational knowledge which can also help to reduce Murphy’s visits.

Through consistent use of PM practices, you too can embrace Captain Kirk’s belief “I don’t believe in the no win scenario”!

(Note: this article was originally published by me in May 2011 on my personal blog, kbondale.wordpress.com)

As project managers, we may occasionally feel like secret agents 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.

“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.“ - Guinan, Star Trek: The Next Generation

(Note: this article was originally beamed up with me in November 2011 on my personal blog, kbondale.wordpress.com)

We have all experienced this: a key contributor announces their departure and a mad scramble ensues to transition their knowledge to the rest of the team.

But does this change when the team is using an agile lifecycle?

On the surface, it might appear that there wouldn't be any significant differences in how it is done regardless of the nature of the work or how it is performed. After all, knowledge transfer is usually a case of a subject matter expert educating others through either a live session or through some sort of persistent record such as a wiki, a video or an audio recording.

While this is true, there are characteristics and specific practices in agile delivery which can impact knowledge transfer.

Traditional delivery usually relies on individual specialists who remain focused on their role and area of expertise. On the other hand, agile delivery encourages the development of generalizing specialists who will develop a broader set of skills and knowledge. Higher levels of collaboration are also expected in such contexts which increases the amount of exposure that individual team members have to each other's knowledge.

While this won't translate into full fungibility across a team, there is less likelihood of only one team member possessing critical information. This won't happen over night. It will take many weeks of working together as well as explicit encouragement by supporting stakeholders such as functional managers for generalizing specialists to develop.

Another enabler is non-solo work - pair programming, hackathons, mob programming and model storming are all practices using this principle. While the primary purpose of these practices is not knowledge transfer but rather quality and speed, it is a valuable side benefit. Rather than having experts share knowledge in an academic manner, demonstrating how their knowledge can be applied towards completing work items is more effective.

Whereas traditional delivery tended to emphasize documentation as the medium for passing work between roles, agile approaches focus on minimal sufficiency. While a newly formed team might require more documentation to facilitate shared understanding, a long lived team might successfully deliver with much less.

The challenge becomes when a new or junior team member joins as there may be insufficient reference material to enable self-learning. But this should not cause any major issues if someone on the team volunteers to pair up with the newcomer to help fill in the blanks.

While the need for shared knowledge is there in all contexts, effective agile delivery can reduce the critical of explicit knowledge transfer.

I always found the narrative in the tape scenes in the Mission: Impossible TV movies amusing: “Your mission SHOULD you choose to accept it…”  The word “should” implies a choice that IMF team leaders and project managers rarely are able to take advantage of.

This is not the only analogy that could be drawn between the series and the life of a project manager so let me present a few more points of similarity.

1. “As always, should you or any of your I.M. Force be caught or killed, the Secretary will disavow any knowledge of your actions.” – Project managers are often the scapegoats for projects that failed long before they were assigned.
2. Infinite diversity in infinite combinations – while the IMF team leader had some discretion in choice of resources for a given mission, many times he was provided specific team members, some of whom did not play nice with each other, and yet, would still have to plan and execute a successful mission.  This was the most apparent in the first movie where Ethan Hunt is able to get his three team members to execute the Langley file retrieval in spite of the fact that two of the three were actually plotting against him!
3. If you fail to plan, you plan to fail – although the missions handed to the teams are usually quite challenging, the series regularly showed the benefits of the planning work done to achieve success.
4. The team leader shouldn’t lead from behind – while the average project manager won’t be expected to scale the sides of the Burj Khalifa, Ethan Hunt’s willingness to pitch in and apply his specialized skills to the mission while not undermining the role and skills of his team demonstrates a degree of balance that is sometimes missed by PMs.
5. Be like water – okay, this one is a stretch, but the use of those amazing face masks in both the series and the movies is a good reminder that successful project managers do need to adapt to a situation and should sometimes be chameleons.
6. No peace for the wicked – at the conclusion of the first movie, when Ethan is looking forward to some much needed downtime, he is presented with a new mission.  This should sound familiar to most PMs who lament the lack of a break between projects!

This tape will self-destruct in five seconds. Good luck, fellow PM!

(Note: this article was recovered from a malfunctioning IMF self-destruct cartridge created on kbondale.wordpress.com in April 2012)