Easy in theory, difficult in practice

My musings on project portfolio and change management. I'm a firm believer that a pragmatic approach to organization change that addresses process & technology, but primarily, people will maximize chances for success. This blog will contain articles which I've previously written and published as well as new content.

About this Blog


Recent Posts

Project management lessons from The Martian

Gantt charts still have a place in the agile-verse!

How will you know when a risk is about to be realized?

Agile lifecycles can improve change resilience

So what happens when your new project really IS "rocket science”?

How many concurrent projects following an agile delivery approach can your company sustain?

Organizations that are in the midst of an agile transformation will often track how many projects within their portfolios are being delivered following an agile lifecycle. Obsessing over this number or using it as a basis of comparison, or worse, competition between departments will make it a vanity metric. However, used appropriately, it can be a useful data point for assessing the progress of the transformation.

Knowing how many concurrent projects can be delivered using agile approaches is important because if the organization attempts to execute more than its capacity to deliver, a slew of issues will emerge.

Mandating that core team members will be dedicated to a project or product is important so that many of the beneficial outcomes of agile approaches such as predictable velocity, reduced context switching and increased team cohesion can be achieved. Dedicated product ownership is also needed to ensure that stakeholders needs and wants are being actively solicited and the team is not delayed waiting on decisions or requirement clarification.

But is that enough?

Having sufficient agile leads (e.g. Scrum Masters, XP Coaches) and coaches is also critical to meet increased delivery expectations from business sponsors.

Agile leads need to be focused on a single project. Within that project, they can be supporting more than one team, but to have them juggle different projects will impede their ability to remove blockers, increase alignment and build high-performing teams.

Coaching is needed at the delivery team level but it is equally important to have key stakeholders such as functional managers coached to achieve the necessary mindset and behaviors shifts required for successful adoption. Without this, teams are likely to stall in their agile evolution.

Procuring and retaining competent agile leads and coaches is not easy. They are in high demand due to accelerating demand for agile delivery and finding qualified candidates who have both the experience and cultural fit with your organization is challenging. Like any other hot skill, there will be a limited supply of full-time talent in a geographic area given the number of companies simultaneously conducting agile transformations.

You should certainly have plans being executed to build these skills internally, but this won't happen overnight and if your company has compensation or cultural shortfalls relative to others in the local market, it will be very difficult to build sustained bench strength. You could use contingent staffing to address peaks in demand this is not a long-term, financially viable strategy if increasing organizational agility is truly a strategic objective and not just the "fad du jour". 

But not tackling this will just prove Peter Drucker right "In most organizations, the bottleneck is at the top of the bottle."

Posted on: May 13, 2018 06:59 AM | Permalink | Comments (11)

All troubled projects are red, but some projects are more red than others…

Review almost any project status report or project portfolio dashboard and apart from the names of the projects, the next most common field is likely to be a health indicator depicting project health using red, amber or green stoplights.

While these indicators might seem like a good visual method to quickly understand the health of an individual project or a portfolio, the flaw with this approach is that this is a subjective evaluation usually conducted by either the project manager or the project sponsor. 

While one might argue that these are the two roles best positioned to assess a project’s health, they are also the ones who have the most “skin in the game”, hence, depending on organizational culture and project management maturity, the ratings provided may be as suspect as team members’ use of percentage complete for reporting task progress.

At one extreme you’ll find the project managers and sponsors who are eternal optimists or those who fear repercussion if they report their projects as being amber or red – with such individuals, a project’s health will rarely be seen to stray from green until it is past the point of recovery. 

At the other end of the spectrum are those Chicken Littles who set their project to cherry red the moment they encounter their first issue.  Although most people fall somewhere between these two extremes, natural biases make it hard for stakeholders to truly understand project status, and this difficulty increases when the evaluation is done at an overall portfolio level.

To bring objectivity to the health evaluation process, the use of earned value metrics, standardized healthcheck questionnaires to score the health of the project, and other evidence-based inputs such as the number of open high severity issues or risks which don’t have approved response plans in place should all be considered.

However, not all projects are equally important, and a single quantitative health indicator does not help a governance committee to identify which projects truly require assistance.  Given this, there is value in considering the use of two separate indicators – the first provides a quantitative health score for the project while the second normalizes this score by incorporating the relative criticality of that project to the overall portfolio.

While colorful health indicators can certainly create artistic dashboards, an objective evaluation of project health can help your leadership team overcome the impacts of rose-colored glasses and color-blind stakeholders!

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

Posted on: May 12, 2018 07:00 AM | Permalink | Comments (7)

Why setup virtual PMOs and when should PM templates be standardized?

Dear reader, don't be alarmed - this IS your regularly scheduled article!

I'd like to thank Sante Vergini for providing the inspiration for the first topic and the second one had been a splinter in my mind so I couldn't wait till next week to write about it.

Why oh why would someone set up a virtual PMO?

In one of my past articles, I had written about the challenges of establishing and running virtual PMOs. I'm not referring to a PMO which is staffed by geographically distributed team members but rather one which has not been established as a staffed organizational entity. Virtual PMOs might be setup as a single individual spending a portion of their time delivering PMO services or a group of project management practitioners who commit some time to this.

Given that it might be difficult for a virtual entity to elevate organizational PM capability, mature project portfolio management practices or provide a meaningful delivery oversight function, why would organizations choose to go this way?

The most simple use case is when the leadership of a small functional organization-oriented company starts to realize the need to standardize or improve the company's project management approach. The first person who starts to apply some project management discipline might be drafted into being a PMO of one.

Funding constraints could be another reason to establish a virtual PMO. The majority of PMOs are cost centers and the ROI for the investment in setting up and running a PMO might take a few years. If leadership recognizes the need to do something to improve project outcomes but funding is limited, one approach is to establish a community of PM practice and empower that group to design and implement change on a best effort basis.

Once bitten, twice shy might be another driver. Leadership teams which have lived through the fallout of a failed PMO might try to avoid the sunk costs of Groundhog Day syndrome by going the virtual route. Of course, if they haven't addressed the root causes for why the original PMO failed, they shouldn't expect miracles from a virtual approach.

A standard should be the means to a goal and not a goal unto itself

Repeatability is a good guideline when elevating organizational project management capability. But standardizing how information is captured needs to be carefully weighed against the benefits of tailoring and customization.

So what are some criteria which would justify standardizing a specific project management template?

If the information within it is going to be ingested by some automation to feed other processes then standardizing the format will improve processing efficiency and quality. If the consumers of the completed template are working with multiple project teams, there is a benefit in providing them with a consistent look and feel.

But if these conditions are not present, the emphasis should be on the quality of the content and not on the format or structure. If there is still a perceived benefit in standardization, effort should be invested in developing a template which can be easily populated, easily updated and presents what is required by its consumers in a minimally sufficient manner.

Anything more is waste.

Posted on: March 18, 2018 07:00 AM | Permalink | Comments (6)

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:

  • 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.
  • 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.
  • 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.
  • 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.

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

Posted on: March 17, 2018 06:59 AM | Permalink | Comments (6)

When Setting Up PMOs, Timing is Everything!

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)

Posted on: March 03, 2018 11:28 AM | Permalink | Comments (6)

"We should be careful to get out of an experience only the wisdom that is in it - and stop there; lest we be like the cat that sits down on a hot stove-lid. She will never sit down on a hot stove-lid again, and that is well; but also she will never sit down on a cold one anymore."

- Mark Twain