Santa Claus, PMP

Twas the night after Christmas after trying to fulfill 7 billion hopes, Santa Claus was relieved because he had delivered required scope.

There are multiple project management lessons to be learned from old St. Nick, so here are a few to consider:

1. Time boxing works – a lot has been written about the evils of pre-determining project end dates before sufficient information is available to properly plan, but there are benefits to having a deadline that can’t be moved.  If nothing else, it provides focus and removes one variable from the inevitable triple or quadruple constraint negotiations.  By having December 25, 12:01 AM as an immovable deadline, it helps Santa focus scope and resources.

2. Projects are about integrating different skills together in alignment – they might not be the Seven Dwarfs, but the nine reindeer likely all have their own personalities, strengths and weaknesses.   Santa’s team building abilities are evident in that the reindeer team is at a high-performing level but we are all aware of the initial “storming” challenges Santa faced with poor Rudolph.

3. Scope definition is crucial – what Santa would call his “Naughty or Nice” list is analogous to our scope exclusions & inclusions list.  Without this, there’s too much room for mis-interpretation and scope leap.

4. Delegate what should be delegated and then get out of the way – with his magical capabilities, it would be easy for Santa to meddle or take over the elves gift creation work, but he doesn’t.  But, for what’s really important – defining scope and being the face to the customer, Santa is highly visible.  It would have been equally easy for Santa to have delegated gift distribution to his hundreds of elves, but as should any good PM, Santa knows that accountability for a merry Christmas falls on his shoulders, so he is the “face to the customer”.

5. Be predictable – imagine the dismay that would be felt by Santa’s customers if they had no certainty about when he would deliver his scope, or whether or not they would even receive anything.  Cookies and milk will spoil if left out too long, but people leave them out feeling comfortable that Santa will not let them down.  I’ve often heard executives say that they don’t like surprises, and Santa’s epic reliability is something that PMs should take too heart.

6. Greet the day and everyone you meet with a smile (or a Ho Ho Ho!).  It would have been easy for Santa to throw up his arms in despair at the “Death March” nature of his project, but he knows that good cheer is infectious (“And I laughed when I saw him, in spite of myself”) and this positive attitude motivates his team.

On the other hand, if you wish to be cynical, you could quote Victor Borge: “Santa Claus has the right idea: visit people once a year”

Resolving deliverable transition headaches on phased projects

In the ideal world, as project deliverables are produced, the necessary support and governance pieces required to effectively transition them to an operational state are ready so that the project team can move on to the next set of deliverables and the functional owners are comfortable being able to use these deliverables.  A lot has been written about resolving the common issue of a project team poorly handing over deliverables but a tougher challenge exists on those projects where scope is delivered in a phased fashion over a long duration and future deliverables are based or tightly linked to earlier ones.

In this situation, how does one define what transition or a warranty period means?  On one hand, the project team has completed the work on the early deliverables and would have the reasonable expectation that the operational support team should be able to own the ongoing care and feeding for these.  On the other hand, if the functional owners are changing the intended use or nature of the delvierables due to gaps or other causes, such activity should involve the project team as it may either impact the quality of future deliverables, or might present an opportunity for the project team to come up with a more elegant product in a future “release”.

This situation is well understood on agile projects – the role of the product owner is to incorporate feedback on released deliverables into the product backlog for prioritization purposes.

But what can one do on traditional projects?

Establishing some rules of engagement for operational handover up front can help – one approach is to define timelines and procedures for two distinct phases of post-handover support:

1. Pilot period: Over this time period, all defects and desired modifications will be fielded by the project team.
2. Warranty period: This starts once the pilot period ends, and details specific situations or criteria that merit the project team’s involvement.  For service request consistency, the first point of contact should always be the operational support team (e.g. a level one help desk analyst), but the request should then be forwarded to a specific, designated project team member for review & assessment.  Each request can be handled in one of three ways:
• It is incorporated into the design of a subsequent deliverable (following appropriate project change management practices)
• It can be considered as out of scope for the project, but of low risk or impact to future deliverables, hence the functional owners can modify its usage as they choose.  This approach is analogous to a normal product warranty exclusion.
• It is considered out of scope for the project, but of measurable impact to future deliverables, and the functional owners should not pursue it. This response is similar to clauses in a normal product warranty that specify what behaviors will void warranty coverage.

As with most project management challenges, a little planning can go a long way and defining standard practices for handing over deliverables on phased projects will avoid the inevitable tug-of-war between the “Hotel California” and “toss it over the wall” syndromes.

 

Standardizing the rules for NON-PMO project leadership

Most staffed PMOs will rarely have sufficient Project Managers to manage all of an organization’s projects since the average size of a PMO is still fewer than ten full time staff and an average project portfolio is likely to have at least a dozen active projects.  The one exception to this would be true projectized companies.

Faced with this common situation, one choice is to employ contract PMs within the PMO to address such resource shortfalls, but such a model is not likely to be considered if there are capable, willing staff within functional areas of the organization that could manage some of the projects.  In addition, by encouraging project management functions to be somewhat decentralized, it increases the likelihood of PM practices being institutionalized (i.e. the outcome difference between giving a man a fish, and teaching a man to fish).

Two fundamental questions that should be answered before executing this approach are:

1. How do we identify which projects are appropriate candidates for management outside of the PMO?

2. What expectations regarding methodology and practices should be required for the non-PMO managed projects?

If these questions are not considered, there is an increased risk to project outcomes and potential for political “churn”.

To answer the first question, a set of objective criteria should be defined, approved and communicated.  Common criteria which could be considered include:

• Size of project as measured in person days, cost, function points or a similar parametric measure
• Degree of cross-functional or cross-organizational involvement or impact
• Degree of strategic alignment
• Inflexibility of key project constraints such as schedule, quality or cost
• Overall risk score or profile

Just like project identification and approval practices, it is best to apply multiple criteria to define the thresholds that are used to identify those projects that should be managed by PMO staff.

The trickier question relates to consistency of execution and practice.  In some organizations, the PMO holds sufficient formal authority to be able to mandate compliance with established methodologies whether or not its staff are expected to be directly involved with project execution.  Even in these seemingly utopian environments, the challenge is that without significant automation, there is no guarantee on compliance and it is very difficult to measure the quality of PM practices and outputs even if the processes themselves are being followed.

A different approach, and the only realistic one in those environments where the PMO does not have formal authority, is to define a minimum set of rules that should be followed for the projects managed outside the PMO over which the PMO has some responsibilities.   For the remaining projects which are managed outside the PMO and are are of a sufficiently low profile, providing a proactive, comprehensive project management foundations training curriculum and relying on functional leadership and oversight should suffice.

A PMO should not assess the enterprise project portfolio as a single entity for oversight and reporting purposes – acknowledging there are many “shades of grey” will help a PMO establish the right working balance when defining who and how to manage individual projects.