Easy in theory, difficult in practice

So you want to buy a PPM or EPM (Enterprise Project Management) tool? 

Congratulations – vendors will be filling up your e-mail Inbox with ROI calculators, dazzling dashboard screenshots and glowing client case studies to convince you that their solution is the only reasonable choice!

But before you finalize the business case to secure funding, let’s run through a simple list of questions.  If you can’t conclusively answer “yes” to all of them and have the data to back up this confidence, it might be advisable to wait until you do.

Are your PM practices institutionalized (and how do you know)? 

If you don’t have some sort of documented methodology, and don’t have the evidence reflecting compliance with those practices, why do you think introducing a tool is going to make any difference?

Do you have sustainable executive sponsorship AND resource management commitment (and how do you know)? 

If you have been trying to sell these two stakeholder groups on the benefits of introducing a tool, how do you know they have sufficiently bought in?  Everyone wants to have pretty portfolio health dashboards and detailed views into staff capacity and allocation, but a lot of effort on the part of mid- and senior managers is required to ensure that accurate and complete data is being entered by project teams.

Who is going to support the tool past the initial roll out (and will you have sufficient funding for these resources)? 

Regardless of whether a PPM or EPM solution is installed on-site or subscribed to over the Internet, you still need to have internal staffing to provide application support to your end users, to identify and address coaching or compliance issues, and to receive feedback from end users and incorporate that feedback into ongoing improvements to your procedures & the configuration of the tool. 

Beyond this, depending on your organization’s needs and the capabilities of your selected tool you may require software development assistance for creating interfaces with your other business systems and report writers to create custom reports from the tool’s centralized repository. 

Will the costs of providing this support be absorbed by the tangible benefits achieved by implementing a tool?  If not, how will you justify ongoing funding for it?

How are you going to “sell it” to the primary end users? 

Vendors tend to target executives when selling PPM and EPM tools as dashboards and reports make for great eye candy, but to populate those dashboards and reports the burden of effort falls on project managers & team members as they are expected to enter and maintain project data. 

Will you be reducing or at least not increasing the administrative work load for these folks?

Don’t get me wrong – PPM and EPM tools can provide significant benefits, but without checking that the prerequisites for successful realization of these benefits are in place you might find that all you’ve done is acquired a costly Rube Goldberg project administration machine.

(Note: this article was originally written and published by me in September 2013 on my personal blog - https://kbondale.wordpress.com)

Scott Adams continues to hit the mark when it comes to the dysfunctions plaguing the corporate world. One of his Dilbert comic strips inspired me to write about a common challenge facing those organizations who are moving from a project-centric to a product-centric delivery approach, namely developing effective product owners.

The funny thing is that this is not a new role – go back a couple of decades and it was common to have senior managers responsible for making the majority of decisions regarding products or capabilities. As organizations shifted away from functional to matrix models, such decision-making became diffused. Also, as a company’s size grows, the authority for product decisions often moves up the corporate ladder to executives who are responsible for multiple products.

We tend to think of the product owner role in the context of agile delivery but it can also apply to traditional delivery approaches too. A key difference is that product owner ineffectiveness creates greater impact on agile projects than on traditional ones.

So what are the most prevalent peeves we have with product owners?

I’ve previously identified Capability, Commitment and Capacity as three characteristics of effective team members. Gaps in any one of these areas will translate into product quality, team productivity or morale issues. These attributes are also important in product owners.

Managers who possess strategic vision, political influence and knowledge of a product are often unavailable to be committed to the extent required to effectively support a delivery team. Faced with this dilemma, executives usually will either still commit these managers or will have them appoint proxies. With the former scenario, delivery teams enjoy good quality decision making but are starved for the product owner’s attention. Decisions which could be made on the spot get delayed. If the team waits for decisions to be made, productivity and eventually morale suffers whereas if they try to proceed based on their knowledge the risk of rework increases.

Proxy product owners might not have the knowledge, vision or influence required to make good quality decisions or to have those decisions stick. What sometimes occurs is that significant decisions need to be blessed by one or more senior leaders which increases the risk of delays. Proxy product owners might also not enjoy having accountability without authority and their commitment to this role wanes over time.

But there’s one more characteristic – Collaboration.

Let’s say we have a product owner who has the first three C’s in spades but they don’t collaborate well with other senior stakeholders. In most organizations there are control partners whose input needs to be incorporated into product decision making to keep the company safe. The solution lead for the product should also have a voice to ensure that technical debt or other sustainability considerations don’t impact the organization.

If the product owner is not able to effectively collaborate to distill these many voices into one, they risk alienating key partners or making decisions which will hurt the company in the long run. While the role has authority over product decision making, this should not be done in an autocratic manner.

The introduction of the product owner role is an ideal way to streamline decision making and develop future leaders but neglect the four C’s of Collaboration, Capability, Commitment and Capacity at your organization’s peril!

(Note: this was originally written and published by me in August 2017 on my personal blog - https://kbondale.wordpress.com)

Ask almost anyone who has worked on a project whether they believe that risk management is important and you will be unlikely to hear otherwise.

So why do we continue to struggle with implementing risk management practices in an appropriate, value-focused manner?

Ineffective risk descriptions – your team might have identified a high severity risk which requires an immediate response, but if the risk description isn’t meaningful to your stakeholders, it is unlikely to generate the sense of urgency you were hoping for. When in doubt, share the descriptions of your key risks with a trusted peer who is not very familiar with your project and ask them if they perceive the need for a call to action.

Insufficient divergence or convergence – when identifying risks, you want to cast as wide a net as possible. A key expectation is that you will be able to transform as many critical unknown-unknowns into known-unknowns as possible. Having a broad, diverse set of participants and using techniques such as brain-writing can push past the inertia of just identifying obvious, low hanging risks. However, once it comes time to analyze and respond, focusing needs to occur on the vital few, leaving the remainder on watch-lists for occasional monitoring.

Addiction to mitigation – I’d written previously about the benefits of considering all response strategies, especially when facing a particularly nasty threat. To channel Mr. Miyagi “Best way to avoid punch, no be there”. Trying to convince your sponsor to reduce scope early in the project to avoid a critical risk might not be a conversation you look forward to, but it’s likely going to be a lot more pleasant discussion than the one you’ll have if the risk gets realized.

Failure to refresh – the risk register must be considered a living document for it to provide any value. As your project progresses and changes occur, if you don’t iterate back through the identification, analysis, and response development processes, the efforts spent at the beginning of the project on these is wasted. A longer term outcome of this behavior is that team members and other key stakeholders will be even less likely to commit their efforts to risk management.

Assumptions don’t get analyzed – assumptions are an important input into risk identification. Until an assumption is validated, there is always the likelihood of it being wrong, and if so, this could impact the project. Not only is it important to capture key assumptions made while planning the project but it is a good idea to review them at a regular interval to test their validity so that appropriate responses can be executed. This is another good reason to have a diverse group of stakeholders involved in risk management procedures – the narrower the selection, the greater the likelihood that assumptions won’t get challenged or revisited.

Lessons don’t get learned – the issues which occurred on one project should provide a clear warning to future projects. As part of the preparation for a risk identification session, a review of some key lessons identified on completed projects which bear any similarity to yours might yield some gems to review with the team during the session. Empirical evidence of the realization of some risks on past projects can go a long way towards overcoming biases.

Letting risk owners of the hook – risk management is only marginally useful if it doesn’t result in any change. If you are unable to secure the attention of your risk owners and maintain it through to the successful development and implementation of response strategies, you’ll be as effective as Cassandra – foretelling doom without the ability to convince anyone to act on it. In addition, if your risk owners avoid their responsibilities without follow-up and escalation from yourself, the message you will be reinforcing is that there’s little value in risk management.

We all know that it’s in our best interests to eat a balanced diet, exercise regularly, get plenty of sleep, and avoid or at most moderately indulge in vices. It’s demonstrating discipline, focus, and persistence to put it into practice where most of us fail. This might happen because the returns of following good personal health habits like these don’t get earned immediately. The same can be said of project risk management – benefits realization lags behind the effort invested.

Johann Wolfgang von Goethe - “Knowing is not enough; we must apply. Willing is not enough; we must do.”

(Note: This article was originally written and published by me in March 2016 on Projecttimes.com)

With all of the tools, techniques and processes within our profession, we sometimes lose sight of the basic principles of project management.  One way to ensure that you are not over-complicating things is to assess your approach from the perspective of a small child.

On project planning, understanding & communicating the five W’s can provide context and perspective for the low-level details found within the individual project plans.

What – at its very essence, scope definition is about answering the “What do we want to do?” question.  It’s amazing how many projects will consume significant resources (and churn as a result) without having a simple answer.

Why (and Why, Why, Why, and Why?) – if there’s one thing we lose as we grow up, it’s the admirable (?!?) persistence that a small child demonstrates when trying to learn about something new.  We might ask the “Why are we doing this project?” question once or twice, but how often do we probe really deep to understand the fundamental root benefits & motivations that are driving its existence?  We should adopt the traditional performance improvement technique which recommends asking “Why?” five times to ensure that we are not presenting a surface-level driver as the main reason for investing in a project.

Who – Although the What might not have been sufficiently decomposed to identify all of the skills or competencies required, there should be some idea of the critical roles that are required to deliver the What.

When – When is the latest that the What must be delivered to enable the organization to achieve the Why?

Where – where is the optimal location for the work to be performed and where will the What be used?

The project manager’s focus can now shift to the question that too often gets all the attention before there’s a good understanding of the five W’s: How? 

This ensures that we don’t spend too much time on approach, methodologies and practices, without having first understood the project’s essence.

(Note: this article was originally written and published by me in May 2012 on https://kbondale.wordpress.com)

Over time companies tend to take on projects with increasing levels of complexity. This happens either as a side benefit of a boost in organizational project management maturity, reactively when responding to regulatory or competitive pressures or organically as an outcome of strategic planning.

Unlike many of my previous posts, the WHY behind this increase is not my focus but rather the HOW.

Do governance bodies within most companies recognize when a proposed project or program is beyond its current capabilities and if so, how do they do this?

Project uncertainty and complexity are continuums and the sweet spot along those continuums will vary by company. There are three company-specific zones within this continuum - low uncertainty/complexity, high uncertainty/complexity and the chaos zone.

The boundary between the first and the second zones tends to become clearer over time, and as a company matures, they will use that boundary to dictate staff assignments as well as the required level of governance. For example, lower complexity projects might require minimal oversight and can be managed by a junior or intermediate project manager whereas those in the higher complexity zone will benefit from steering committees, highly seasoned project directors and regular delivery assurance checks.

But what about the chaos zone - what defines its boundaries?

In the past, when travelling the world's oceans, ships' captains used maps with notations indicating where the edges of the known world were as well as that wonderful warning "Here, there be dragons". Unfortunately, such cartographic aids are not available to portfolio governance teams! Without having the boundaries for the chaos zone defined, it would be easy for a company to invest in a project whose failure could result in catastrophic organizational consequences.

One approach might be to use the same set of criteria which are used to distinguish low and high complexity projects. A radar chart such as the one below provides one way of presenting this. Complexity inputs such as the number of distinct stakeholders involved/impacted, total number of unique delivery partners or the extent of external influence could be assessed using a simple questionnaire.

Assessing and presenting this information is a good start, but it might still not be enough to prevent a sponsor or line of business from undertaking a "bet the firm" project. This is where the checks and balances of effective governance are crucial.

A common misbelief is that Sir Edmund stated the reason "Because it's there" when asked about climbing Mount Everest. In fact, George Mallory is believed to have said it almost thirty years earlier. Unfortunately, George perished on the way to the summit.

Start a chaos zone project and your company could face a similar fate.