Easy in theory, difficult in practice

There have been a few impasses in recent years over resolving the U.S. debt ceiling issue and the resulting shutdown of the government brings to mind an unfortunate tendency on the part of some project managers to focus on winning arguments or on resolving conflicts in their favor at all costs.

This behavior is rarely intended to be self-serving as those project managers are operating with what they perceive as being the project’s best interests in mind.  While this can result in short term tactical benefits to the project, it may also create longer term issues to the project or to the project manager themselves.

Examples of this habit include:

• Progressively escalating conflicts with team members and their functional managers when performance or communication concerns are identified
• A single-minded, overly aggressive focus on avoiding scope changes (even in those cases where the scope changes are necessary)
• Conflicts with peer project managers over the allocation or availability of shared resources
• Aggressively pushing for deliverable acceptance or project closure even when the customer is unhappy with what has been delivered

On the surface, these might all appear to be reasonable tactics aimed at protecting the triple constraint.

Unfortunately, they might also result in one or more of the following unintended consequences:

• Reduced individual team member or overall team morale resulting from bruised egos – this will translate into productivity impacts
• Strained relationships with key functional managers.  While they might grudgingly go along with a short term tactic which is not in their team’s best interests, they will also be much less likely in the future to invest any of their influence or political “capital” in supporting the project manager.  This can be especially dangerous in functional or weak matrix structured organizations.
• Contractual correctness but reduced customer satisfaction. This in turn reduces the likelihood of that customer providing repeat business or of acting as a positive reference for the company’s products or services.
• Impacts to relations with one’s peer project managers.  This can be lethal in companies with lower levels of organizational project management maturity as it might result in complete isolation or ostracism of the offending project manager.

Don’t misunderstand me – I am not a fan of weak project managers as they can be a greater source of risk to projects than overly strong project managers.

Project management is like poker – you have to know when to hold ’em, and know when to fold ’em.

(Note: this article was originally written and published by me in October 2013 on my personal blog, kbondale.wordpress.com)

There was an important point made on page two of the PMBOK Guide (Fifth Edition): the organization and/or project management team is responsible for determining what is appropriate for any given project.

This advice is not provided to encourage a free-for-all whereby each project team does as they please.  Some practices consistency is crucial when one needs to evaluate a portfolio of projects, and it can also help to reduce ramp up time when staff are assigned to projects.

The guidance is there to remind us that we need to assess a project to determine which practices can be used as is, which need to be tailored to fit, and which are simply not applicable.

So what’s the problem with not hitting the “sweet spot”?

If insufficient practices are applied, or if the practices are diluted too much, there is an increased risk of partial or total project failure.

On the other hand, if teams are applying a “one size fits all” approach, the risk of project failure is reduced, but is replaced by increased cost of project delivery and frustration with project management in general.  Over time, this frustration will translate into teams following project management practices just to pass a delivery gate instead of applying them to improve their odds of success.

For companies which have assigned an individual or a team (e.g. a PMO) to be responsible for assessing and improving project management capabilities, ongoing feedback from project teams can be a good way to progressively develop a knowledge base to help practitioners with adapting practices to the needs of specific projects.

Going a step further, in companies with strong internal policies or regulatory requirements, an independent (internal) consultant might be engaged to provide such assistance.  Their responsibility could include the review and approval of the compliance of the adapted practices with the overall philosophy and intent of the organization’s project management policies.

Unfortunately, for those companies which have not centralized the responsibility for project management practices, the onus for doing this falls solely on project teams.

In such situations, project managers may need to develop a “play book”. Such play books could include the following details for each key project management practice:

• What benefit does it provide?
• Is it mandatory for all projects, and if not, which project attributes or criteria would merit its usage?
• What are the issues or risks of not performing it?
• How can it be adapted to fit a minimal, moderate or full usage model?

The benefit of such a play book is that it can facilitate a structured discussion with the team at the start of a project.  It can help to educate team members as to the necessity of certain practices whose rationale might not be intuitive and it can also demonstrate that the project manager is taking a right-sized approach to the project.

A well written practices play book could be the project management equivalent of this knife which you COULD bring to a gunfight!

Information radiators can help stakeholders remain informed and can reduce effort spent by a team in handling requests for updates but to reap these benefits we must ensure that the information published meets their needs.

As with any type of communication, if the content published cannot be trusted due to obvious inaccuracies or a lack of currency, stakeholders will cease to consult the radiators and will demand that traditional reporting methods are re-established.

Such defects will also reduce the credibility of the team in the eyes of the stakeholders.

This is one more reason to ensure that if Kanban boards or other work visualization views are made accessible to stakeholders outside a delivery team that team members are diligent in updating them while work is being done rather than after the fact.

If an information radiator generates more questions than it answers, it will become a burden for the delivery team. Not only does this mean that legends, titles, and thresholds are clearly presented, but it also requires that any information which could be misinterpreted should be accompanied with some context so that stakeholders get the correct story.

For example, if a sprint burn down chart is being published daily and by the midpoint of the sprint it appears that very little has been completed, a stakeholder might reasonably assume that the team is going to complete significantly less than what had been agreed to during sprint planning. However, if some context is provided that the team's delivery process includes an independent review by an external inspector who is only available one or two days per sprint, this apparent lack of progress might be perfectly acceptable.

This also means that we should review what is being published to ensure that stakeholders can perceive the forest as well as the trees.

Publishing a sprint burn down chart or Kanban board without providing a team's Definition of Done is only part of the story. Posting a release burn up chart without indicating what is being delivered in the release will not promote shared understanding.

Finally, it's important to educate stakeholders so they can effectively pull information from the information radiators and to set expectations that radiators are to be consulted as the first source for updates.

Poor information radiators are a constant reminder of George Bernard Shaw's caution that "The single biggest problem in communication is the illusion that it has taken place."

A LinkedIn question on the topic of PMOs in the future made me think about the benefits of having a PMO once a company has reached a high degree of project management maturity.  This is not as fantastic a vision as you might think – after all, PMI’s tag line used to be Making Project Management Indispensable For Business Results and it is not outside the realm of possibility that many organizations will (at some point in the future) have project management institutionalized as an organizational competency instead of a skill shared by a select few.

When such a time arrives (See, I can take a “glass is half full” position at least once every year!), will there still be a need for a PMO?  After all, if project management skills become as natural to staff as operational competencies, do we still have a need for a group focused on the discipline?

Absolutely!

The first analogy I would make is to quality.  Even those companies that have reached stratospheric altitudes of quality and have embedded this competency into all aspects of their organization would still have a staffed quality department.

Here are some of the benefits that a PMO can provide to higher maturity companies:

• Guardians of the methodology – even in a high maturity organization, if there is no PMO, who is responsible for the ongoing evolution of PM methodologies and the tools which support them?
• Consultation & facilitation – even the most skilled PM can benefit from an unbiased external observer when faced with tricky decisions.  PMOs can aspire to be “neutral territory” by providing consultative services to project teams such as delivery assurance reviews or risk identification & assessment facilitation.
• Support for portfolio governance – If the organization has embraced project portfolio management practices (which is highly likely if it is at a high degree of maturity), the PMO can facilitate governance practices such as intake reviews or prioritization discussions.
• Consistent, strategic reporting – No tool can (yet) replace the benefits that a centralized staffed process can bring to portfolio-level reporting.  The benefits go beyond the communication of project status to looking at trends, systemic risks and issues and key lessons and reminders that can be shared organization-wide.

No matter how good a professional golfer is, they will usually benefit from a coach to help them maintain their performance and to improve.  An effective PMO will still be a valuable coach to your  organization no matter how low your project management handicap goes!

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

Many project managers have doubtless exclaimed “giving birth would be simpler than managing this project”!  This may be truer than they ever imagined…

Initiation can provide the same euphoria as finding out you are going to be a new parent – getting assigned to a new project is an exciting but also unnerving time.  There are hundreds of questions, but also plenty of stakeholder input!  There are myriads of sources of information, but it can be challenging to separate the useful lessons learned from “old wives tales”!

Planning can prove to be as unpleasant as the first trimester – with frustrating stakeholders, challenging constraints, uncertain scope and storming teams,  project managers might be excused for acting as though they suffer from prolonged morning sickness!  With appropriate attention & resourcing combined with a healthy dose of risk management, the project manager should strive to lay a solid foundation for the rest of their project/pregnancy.

Project execution can feel a lot like the second and most of the third trimesters.  This is where the (literally) heavy lifting takes place, the peak resourcing/food intake, and careful monitoring & tracking of vitals, but if planning was done well, it should be a fairly smooth ride.  Resource shortfalls need to be addressed in a timely fashion to avoid impacting the project’s outcomes and cutting corners on quality will come back to haunt you long after the project/baby has been delivered!  While change is to be expected, it should not be rushed into without  appropriate governance.  The need to prepare the environment for the impending arrival is also crucial.  Procrastination on implementing effective organization change management will be extremely costly as anyone that has had to decorate a baby nursery at the last minute will attest!

Finally, project closeout can range from the very smooth to the highly painful.  Challenging project “deliveries” can be the result of poor planning and execution, but they might also be through no fault of the project team’s, but rather a result of external or environmental factors.  Closeout can also be a time of intense conflict between the project team and key stakeholders (e.g. mother-in-laws, new fathers)!

Throughout the project/pregnancy, the need for effective, timely communication is critical.

Having a baby is the first step in a long rewarding journey for new parents just as successfully managing a project should be the start of achieving expected business outcomes.

(Note: this bouncing baby blog post was originally brought into this world in September 2012 on my personal blog, kbondale.wordpress.com)