Easy in theory, difficult in practice

I always get a kick out of online discussions referencing agile project managers as if those are some special subset of the project management population!

Yes, there certainly are agile delivery methodologies and adaptive project lifecycles and some project managers might gain greater experience in those, but what might some of the characteristics of an agile project manager be?

• Their primary focus is on delivering value at the optimal pace of change absorption by their customers and key stakeholders.
• They know that the secret sauce to project success is people first.
• They don't follow process for process sake and recognize that tailoring is as relevant to project practices as it is to clothing.
• They embrace Robert K. Greenleaf's teachings on servant leadership.
• They recognize that a good solution today beats a great solution two years from now.
• They accept that changes will occur and they steer their projects to take advantage of these changes rather than rigidly resisting them.
• They favor face-to-face communication and embrace transparency in their reporting.
• They promote a sustainable pace of work as they acknowledge that projects are marathons and not sprints.
• They promote psychological safety within their teams and model the behavior they expect from their team members.
• They instill a culture of continuous improvement in their teams by helping them reflect regularly on what's working well and what could be tweaked.

The attributes in the list above should be applicable to any project manager in any industry managing projects using any type of lifecycle.

So why wouldn't you want to be an agile project manager?

When I wrote “I come to bury PMOs, not to praise them” in late 2009, I covered the challenges organizations experience in establishing PMOs and made the controversial hypothesis that many times, PMOs act more as a crutch enabling continued levels of poor organization project management maturity than as the vehicle to raise maturity. At that time, my point of view was vehemently opposed by some but over the past few years, I’ve started to see more evidence of this situation and have even seen other project management professionals start to share and communicate this belief.

Do I believe that PMOs should never be implemented?

Absolutely not, but I would advise careful consideration of an organization’s current project management maturity before proceeding with establishment of a PMO. While conditions such as committed executive sponsorship or sustained funding are commonly recognized as critical success factors for setting up PMOs, I’d like to propose that appropriate timing must be added to that list.

For many organizations, their first experience with PMOs occurs when they are still at a very early stage of introducing project management as a standard competency. The power structure of such companies is usually either functional or a weak matrix. The most common driver for setting up a PMO in such cases is to bring consistency and repeatability to project selection, prioritization & delivery practices.

Project managers (if any are on staff) report into functional areas and the establishment of the PMO might be viewed as an opportunity to centralize these resources within a single service bureau. If there are no project managers in the organization, the PMO might be setup purely as a Centre of Excellence.

This seems like a reasonable approach, doesn’t it? Having a staffed department responsible for project management should help to generate the visibility and focus necessary to initiate and sustain improvements.

Unfortunately, even if the PMO has been vested with sufficient formal authority to require that staff comply with its practices, the establishment of a separate department at a time when project management is still not truly embraced across the organization is likely to be viewed as divisive instead of a step forward. In fact, having formal authority may worsen this perception as staff will complain that they are following certain practices because they were forced to do so by the PMO and not because they truly embrace the benefits in doing so.

If there are project managers reporting in to the PMO, their work might become more difficult than it was before. While they may gain some benefits from co-location and direct peer support with other project managers, by not being part of the same functional team as their project team members, they are likely to experience greater challenges in escalating and resolving team member issues by themselves, and the functional managers they work with may be less helpful than before.

A different problem exists with regards to improving existing project management and associated practices – at low levels of organization maturity, most improvements will demand behavioral changes on the parts of the leadership team and mid-level managers, and a new PMO or its leader may struggle to get the necessary commitment and buy-in from these groups for such changes to be approved or to stick.

A very real risk of centralizing this task of project management maturation within the PMO is that if the winds of change start to blow against the new department, it’s less painful for the senior management team to shut it down as a failed experiment than if project management improvements are viewed as an organization-wide, cross-functional responsibility. Worse, even if the PMO is not shut down, its role and authority may be sufficient marginalized to a point where capable PMO staff leave the organization.

So when is the right time to set up a PMO?

Timing varies from company to company, and some companies might never be mature enough to benefit from a staffed PMO, so here are some organization-level prerequisites that should be met.

• Basic project management, staff capacity & skills and work allocations practices exist and are being consistently followed by all functional areas.
• A basic work intake process exists and is being effectively executed by governance committees such that low-value, discretionary projects don’t divert valuable resources from strategic or non-discretionary projects.
• Functional managers have demonstrated appropriate behaviors in supporting project planning & execution. In addition, most functional managers have also led cross-functional projects following standard project management practices.
• Project sponsors are appropriately selected considering both capacity and competency and fulfill their roles effectively.
• Project and portfolio monitoring and reporting is consistently done and the members of the senior leadership team hold themselves and their peers accountable for responding to escalated issues, actions, risks & decisions in a timely, effective fashion.

Once such foundational capabilities are in place and the leadership team feels they are sustainable, a PMO can then be the ideal catalyst to help an organization reach higher levels of PM maturity.

Ecclesiastes 3:1 “To every thing there is a season, and a time to every purpose…”

(Note: this article was originally written and published by me in July 2013 on Projecttimes.com)

The November 2014 issue of PM Network included analysis from research focusing on the role of the project sponsor.  While there were no revelations as far as the criticality of the sponsor role or which are the key activities performed by a sponsor, one statistic did catch my attention.

Only 36% of the organizations which were surveyed provided development for the role of an executive sponsor.  This value is low given that the same study revealed that one out of three unsuccessful projects had poorly engaged sponsors as the root cause and having effective sponsors generated a 15% improvement in project success rates.

So why isn’t this happening?

It would be easy to blame low organizational project management maturity – that happens to be one of my favorite boogeyman for most project management “sins”!  However, that does not account for such a low percentage – my own empirical evidence supports the premise that even companies at higher levels of project management maturity rarely have any type of structured development programs in place to cultivate successful sponsors. 

A more plausible explanation is that there is an assumption being made that when someone has become an executive that they have already gained the hard & soft skills required to be an effective project sponsor.

But is this really true?

Many executives reach their positions as a result of a track record of management success.  The competencies required to manage a line of business are very different from those needed to successful champion change.  Dr. John Kotter’s classic HBR article, What Leaders Really Do, covers this in depth and the following paragraph stands out:

Most U.S. corporations today are over-managed and underled. They need to develop their capacity to exercise leadership. Successful corporations don’t wait for leaders to come along. They actively seek out people with leadership potential and expose them to career experiences designed to develop that potential. Indeed, with careful selection, nurturing, and encouragement, dozens of people can play important leadership roles in a business organization.

One word in that last sentence is key – nurturing.

So what should be done?

Developing sponsors takes more than just turning them loose on a project – the same development strategies which are used with project managers could be adapted for sponsors.  Assessing skills and experience is the first step – those can help to provide insights into which executives are NOT suited to be sponsors.  Those assessments can also provide input into the creation of personal development plans which should combine formal training on project leadership with experience-based learning.  The latter might start with roles serving on steering committees and then moves into progressively more challenging sponsorship roles.

A sustainment component required within such a development program is an onboarding process which gets executed whenever a project is ready to kick off.  That process would provide the sponsor with a refresher on their role including expected behaviors and responsibilities.

Lies, damned lies and statistics can certainly be used to support just about any argument, but the better trained a sponsor, the greater the likelihood that they will be able to effectively support a project.

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

There is a strong likelihood that if you have taken a project management training course within the last decade you have heard some variant on the statistic that 90% of a project manager's time is spent communicating.  As with everything else, too much of a good thing can cause problems.

I have worked with junior project managers as well as some seasoned ones who focus on over communication instead of effective communication.  Their concern is that the perceived importance of information is in the eye of the stakeholder. They are concerned that, if the project manager does not provide full disclosure to stakeholders, sponsors or team members, the project manager's information filtering could spawn or worsen a project issue.

This is a valid risk as a lack of open communication of assumptions, issues or risks has likely caused more project failures than scope creep or limited resource availability.

However, to swing the pendulum from limited communication to the other extreme raises some risks.  For a sponsor or stakeholder to find some data that is of value to them, they have to wade through reams of interesting but low value (to them) information.  Additionally, drowning stakeholders in minutiae is a good way to lose their interest or attention in your project, to say nothing about reducing credibility in the project manager's capabilities.

While useful for sharing project information or eliciting feedback, online communication methods such as Twitter, instant messaging, and worst of all, e-mail can dramatically aggravate this situation.  While this information overload issue is dangerous for traditional projects, it is lethal for virtual projects as it increases the probability of stakeholder isolation or withdrawal.

So how does one determine the sweet spot for project communications? 

• Include a thorough stakeholder analysis as part of your project communications planning.  For key stakeholders as well as your sponsor, make sure you understand what, when & how do they wish to be get apprised about.
• Leverage both push & pull methods of communicating - push information that is time sensitive or requires action.  Let other information be pulled by stakeholders (unless they have specifically asked you to push it to them).
• Refresh your communications plan based on feedback.  Meet with stakeholders on a periodic basis to gauge if they feel that your level of communication is effective.
• Be consistent in communication content & structure.  This helps to reduce effort spent by team members or stakeholders in processing information and demonstrates predictability and professionalism.

I wrote in a previous article that a governing principle of project management is Always Be Communicating - perhaps this should be re-framed as Always be EFFECTIVELY Communicating.

(Note: this article was originally written and published by me in June 2010 on Projecttimes.com)

Anyone who has read the PMBOK Guide or taken the PMP exam knows that project management is made up of an interconnected and iterative set of processes. Even a highly predictable project requires a team to iterate back to earlier executed processes when faced with a change request.

So why is it that we tend to forget to re-execute certain key project management processes? It’s likely because they aren’t as well understood by our team, sponsor and other key stakeholders. It’s rare that maintaining schedule or financial baselines and forecasting these project dimensions is neglected as there are usually external forces ensuring that this occurs periodically.

But let’s think about risk and stakeholder identification and analysis. Just like developing a schedule or a budget, these processes are commonly performed early in the life of our projects. But it is very common to find projects where these processes are never revisited.

The risk of ignoring them is significant.

Skipping out on full lifecycle risk management means we could continue to invest in monitoring obsolete risks while remaining blissfully unaware of new threats or opportunities. We might also be missing changes in the profile of existing risks. Some low risks on our watch-list might have increased in severity whereas others which we are actively responding to could have dropped in priority. As risk responses are implemented we want to understand what residual risk remains and update our knowledge of these risks accordingly.

The same holds true for stakeholder information and engagement activities. We might miss a new highly influential or impactful stakeholder that arrives on the scene after our initial stakeholder analysis. Or a stakeholder whom we felt had little interest in our project might become more visible than before.

We expect that overall risk and the relative influence of stakeholders should decrease over the life of a project as we start delivering scope and uncertainty decreases but if we keep looking in our rear view mirrors we are likely to miss the runaway Mack truck bearing down on us.

Avoiding this requires discipline on the part of the project manager. Consciously challenging themselves and the team to periodically revisit risk and stakeholder registers for currency and accuracy can reduce the likelihood of occurrence.

To extend Donald Rumsfeld’s famous taxonomy, we create unknown-knowns by not iterating back through all applicable project management processes.

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