Easy in theory, difficult in practice

I’m not asking for your elevator pitch for the discipline, but rather what does it mean to you personally?

When I changed roles last year, the thought process I went through to decide to make a change caused me to revisit a question which I’ve asked myself more than once over the past two decades.

If you see your current work in project management as a stepping stone to a higher role such as a C-level business executive then it might just be a job.

While you will develop and use project management competencies to successfully deliver projects, you generally won’t commit much personal time to the profession such as mentoring junior PMs or giving presentations. While you might seek and attain a credential such as the PMP, that is a means to an end, and you are likely to let the credential lapse once you have moved into your next non project management-focused role. There is nothing wrong with considering project management as a means to an end, and becoming a senior leader who has done one or more tours of duty in a PM role is an excellent way of elevating the importance of the discipline.

Perhaps you are playing the long game with the profession.

A career in project management might give you the opportunity to take on initiatives of progressively greater complexity and scale or to move from delivering individual projects to managing a portfolio or leading a PMO. Instead of a vertical career path, you might pursue a lateral one by switching industries once you feel you’ve developed sufficient domain expertise in any one. Or you might specialize by focusing on a particular aspect of project management such as recovering troubled projects or by becoming a project risk management specialist. You will most likely attain and maintain one or more credentials and might even contribute to the evolution of the profession if you see it furthering your career.

But the third path and the one which will give you the greatest gratification is if you view project management as a calling.

Those who see the profession in this light are easy to identify. They are likely unaware of it, but they smile a lot when they speak about project management. They commit a significant amount of personal time to the profession, not because doing so will help advance their career, but because this re-energizes them and they want others to be as passionate about project management as they are. Being recognized as thought leaders by those they respect is more important to them than a promotion or the latest credential.

So is project management your job, your career or your calling?

“There is no escaping reason; no denying purpose. Because as we both know, without purpose, we would not exist.” – Agent Smith

(Note: This article was originally written and published by me in July 2017 on my personal blog https://kbondale.wordpress.com)

Optimism bias is the tendency for us to believe that we are less likely to experience negative events than others and to act on that optimistic belief – the classic “It won’t happen to me!” assumption.

A thought-provoking research paper in the August/September 2014 issue of Project Management Journal covered a very specific impact related to this bias, namely our reluctance towards or rejection of decisions to terminate failing projects.

The article states that we (human beings) are physiologically predisposed towards having an optimism bias. On a positive note, this was a contributing factor towards our long term survival and growth as a species. Many of the advances we’ve made in science and space exploration might never have occurred if we didn’t occasionally leap before we looked.

However impacts from optimism bias are more likely to put our projects into harm’s way.

Don’t get me wrong, there are times when we want our team members or stakeholders to feel optimistic when faced with uncertainty – a project kickoff meeting, when team morale is low, or when trying to brainstorm opportunities during a risk identification workshop are all examples of this.

Unfortunately, beyond deciding how to proceed with a failing project, there are a number of other common project situations where optimism bias can blind us.

• Selection & prioritization of projects: Even when objective criteria, scoring models and balanced governance committees are used to overcome biases and the potential for pet projects, it can be very difficult to thoroughly validate that a project’s benefits, costs and risks are truly valid. The subject matter experts who have the best knowledge to refute forecasts and underlying assumptions are usually the ones who were engaged in the development of the business cases and rarely do most organizations possess the bench strength required to conduct thorough independent analysis.
• Risk analysis & response: While our team might do a good job of identifying risks, even if we have realized a risk in the past, most sponsors are likely to downgrade the probability of realization which in turn reduces the likelihood of effective responses being developed or executed.
• Contingency planning: When it comes to putting some money aside for a rainy day, many sponsors are likely to feel pretty good that the storm clouds will miss them. In organizations with a low tolerance for open discussions of risk, requests for reasonable levels of contingency funding are more likely to result in teams being chastised for being too negative or not believing in the project.
• Change management: Those who have already drunk the Kool-Aid are more likely to marginalize or ignore the risks of change resistance. Of course everyone will embrace the changes – change is good, right?
• Making significant changes late in a project’s life: Just as rose-coloured glasses are often worn when preparing business cases, sponsors and other stakeholders often exhibit optimism bias when introducing project changes, especially those that are requested late in a project’s life. Risks to cost, quality and schedule may not get the fulsome analysis and presentation needed to ensure that there is a balanced evaluation of the change.
• Health reporting: One of the symptoms of lower organizational project maturity is the dilution of health status as it is shared from the project team up to the highest executive levels. Often this is due to a low tolerance towards bad news or a tendency to shoot the messenger, but it may also be caused by optimism bias on the part of sponsors and delivery executives.

Recognizing that a penchant for optimism bias is hard-wired in our DNA, how do we sidestep it to avoid putting our projects at jeopardy?

• Be mindful – recognize it for what it is and call it out when we see it in action
• Use “designated drivers” – optimism bias could be considered a type of impaired judgment so to overcome it, involve those who won’t either benefit or lose from the decision to review your assessment of the situation before finalizing a decision.
• Exploit diversity – diversity in governance committees creates strength when it is well leveraged. This is not an invitation to get stuck in analysis-paralysis or to indulge constant questioning and reversing of decisions, but it can help to overcome bias so long as the committee doesn’t fall into the seductive trap of the Abilene Paradox.
• Establish control limits and obey them – earned value metrics are just one type of useful “instrument” that will help us to overcome bias as long as we can trust that the underlying data is sound.

While optimism bias has helped the human race survive, it has also been instrumental in a large number of Darwin Awards so don’t let your project become another cautionary tale!

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

If your organization is in the midst of an agile transformation, ideally this change was justified through a business case which articulated expected benefits and the means by which those benefits would be measured. But we rarely live in an ideal world.

So how could you assess whether the initiative is delivering value or not?

You could look at a metric like average time to deliver scope but this has limitations. Averages by themselves mean nothing. If there is an overall reduction in the distribution of release times and ideally a shrinkage in the variation for these release times, that might be cause for optimism if a sufficiently representative sample was taken before and after.

Just because we are delivering scope sooner doesn't mean we are reaping the full rewards of an agile transformation. A team might miss the mark by prioritizing schedule over quality and we would end up producing a product which the customer doesn't want.

And, this says nothing about how we delivered that scope. Over short timeframes using Theory X-type behavior it is possible to whip a team into delivering quickly but we would usually see a corresponding reduction in quality and in team satisfaction.

Perhaps we could look at velocity across teams. While we know that velocity should never be used to assess performance between teams or at an individual level, surely an ongoing, incremental increase in velocity across the majority of teams would be a positive indicator? Unfortunately, without introducing other measures to add perspective, it would be relatively easy for a team to claim such improvements at the expense of quality, or delivery of real value to their customers.
In place of these vanity metrics, consider these:

1. The distribution of lead time to deliver utilized features - by filtering out unutilized features, our time to market distribution will focus on true value add to our customers
2. Features utilized/features completed - this ratio will assess how effective teams are at meeting the true needs of your stakeholders
3. The distribution of defect severities and counts - this will assess whether quality is being sacrificed at the altar of speed
4. The total number of high impact organizational blockers - assuming teams are surfacing and escalating organizational impediments to full agility, a reduction in the number of these blockers should translate into improved delivery outcomes
5. Team satisfaction - this will keep a pulse on team morale to ensure that it is not suffering through the transition
6. Customer or key stakeholder satisfaction - this will be another balancing measure like #5 to ensure that the end is not justifying the wrong means

Developing a balanced, holistic approach to measuring outcomes should help to sustain leadership support and to focus continuous improvement efforts on the right things but just remember:

"...not everything that can be counted counts, and not everything that counts can be counted." - William Bruce Cameron

A common question that arises during project initiation is what is the optimal percentage allocation of a project manager to the project to ensure the right balance between cost and risk. This question should be distinguished from the determination of how much project management effort in total is required since multiple staff will participate in project management activities over a project's lifetime.

In a billable project, this question often generates significant lively discussion – depending on the customer’s project management maturity level and the desire of the sales team to win the business, it can sometimes be a tough sell to ensure there is sufficient allocation of effort and funding for the project manager. However, even in cases where the project effort is not being charged to someone, it is possible that there may be preconceived notions regarding what is a reasonable allocation of time.

Most of you will know that the only right answer for most project management scenario questions is “it depends” and this is no exception. Although there is no single formula to help you calculate how much of a project manager is needed as this can vary from as low as 5% to full-time allocation, it may be helpful to understand the factors which could affect involvement.

• Number of distinct key stakeholder groups - stakeholder management is a critical responsibility for project managers as evidenced by the addition of stakeholder management in the 5th edition of the PMBOK Guide. The greater the number of stakeholders or the greater the divergence in expectations and desires amongst them, the greater the amount of effort that needs to be spent by the project manager in gaining alignment and in regularly keeping these stakeholders apprised about the project's progress.
• Magnitude of uncertainty - the more conceptual a project's scope or the more innovative the approach or expected outcomes, the greater the effort required on the part of the project manager to facilitate scope definition, manage changes to scope and support decision making.
• Magnitude of slack in project constraints – whenever a project has an extremely tight budget or a very aggressive timeline, a project manager will likely be spending a lot of time in ensuring that overruns don’t occur, especially if the project is being managed using a traditional or waterfall approach.
• Number of team members that the project manager has to directly manage - if a hierarchical structure has been established whereby the project manager allocates work or gets progress or issue updates from a few work package leaders, the project manager will need to spend less time working directly with individual team members and this will help to reduce their work management effort.
• Level of organizational project management maturity - in companies where team members, functional managers and other stakeholders understand what's expected of them when working on or supporting project work, project managers are able to focus on project management. In lower maturity organizations, project managers often end up spending their time "filling the white space" to ensure their projects remain on track. While this activity cannot be considered strictly project management, it is necessary and effort on the project manager’s part should be allocated for it.
• Magnitude of multitasking performed by team members - if team members’ time has been fully committed to a project, the project manager will spend less time in resolving availability challenges with these team members and with their functional managers. The greater the degree of multitasking performed by team members, the more time has to be spent in negotiations and course corrections to keep projects on track.
• Heaviness of the project management methodology - the more onerous the mandatory project management practices of the organization, the greater the effort that the project manager will expend in managing the project.
• Multi-dimensional size of a project - for the most part, larger projects usually require more effort on the part of the project manager. On the other hand, it might be possible for a project manager to spend very little time in managing a high cost project if the majority of the costs are resulting from the purchase of a single component. Similarly, a long duration project may have very little complexity and a minimal sized team and not require significant effort on a project manager's part. However, when multiple attributes of the project are large, project management effort will increase.

While this list might not eliminate disagreements regarding the appropriate allocation of a project manager to a given project, it should help to make those discussions more objective.

Are there any factors which I have missed or can you come up with a formula that combines these to provide a good rule of thumb – if so, please provide your comments below!

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

Juliet might have said “That which we call a rose by any other name would smell as sweet” but I beg to differ when we are coming up with project names.

Here are a few of the ways in which good project names can make a difference:

• Motivating and unifying a cross-functional project team that hasn’t worked together in the past and is not 100% dedicated to your project.  Ensuring that your project name is uplifting and somehow captures the essence of what benefits the organization and the team members will reap can help focus team efforts.
• Engaging stakeholders and sponsors.  It might be easy as a stakeholder to ignore pleas from the project manager of the “implement ABC system version 1.2” but you’d think twice of doing this if the name was “reduce patient mortality due to transcription errors”…
• Supporting that “outside in”, business-focused view of projects – this is especially true for technology projects.  IT is forever blamed as being disconnected from the business and purely technology-focused and picking technology-centric project names does not help your CIO foster credibility with his or her peers at the executive level.

So what are the hallmarks of a good project name?  Here are a few suggestions:

• It should reflect the expected benefits or business outcomes of the project.
• It should be short – short enough that you could give the project name & a brief description in the stereotypical thirty second elevator pitch.
• It should be positive (e.g. reduce operating costs is not as positive as increase profitability)

The acid test is to visualize yourself at a conference presenting a case study about the success of your project upon its completion – would you be proud to state its name, or would you cringe and mutter it under your breath?

(Note: this article was written and published by me in June 2010 on my personal blog: https://kbondale.wordpress.com)