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 will you know when a risk is about to be realized?

When qualitatively analyzing risks, we are taught to have our stakeholders estimate the probability of realization and the impacts to project objectives if risks are realized. If we have good historical data or subject matter expertise to rely on, we can take this exercise a step further and attempt to quantify the likelihood of occurrence or the magnitude of the impact. Based on this assessment, risks get prioritized so that we can focus limited efforts on those risks which pose the greatest severity.

But what if we can’t detect when a risk is about to be realized?

For low severity risks this might not seem like a big deal. Our contingency reserves should be sufficient to absorb the impacts of those.

But how about high severity threats? If we have no ability to know when one of those is going to be realized, unless our risk response strategies have focused on minimizing potential impacts, we are still likely to experience some impact to our project’s objectives before our contingency plans take effect.

How about high value opportunities which present a low likelihood of detection? Again, if we don’t have the ability to benefit from them quickly, a delay in implementing plans to exploit them will reduce realized benefits.

Finally, have you ever faced the scenario where you’ve qualitatively analyzed your risks only to realize that based on the estimated probability and impacts, you have a large number of high severity risks? How do you go about prioritizing your risk response efforts and getting the best returns from senior stakeholder engagement?

This is why we should consider leveraging Failure Mode and Effects Analysis (FMEA) practices from product and process design by adding a third dimension to risk evaluation – our likelihood of not detecting imminent realization of the risk.

A low score is given to those risks whose realization will be seen a mile away whereas those with a low chance of detection should receive a higher score. Just as you would do with impact and probability, it’s important to define a standard for the rating with examples to increase the likelihood of consistent evaluation by your stakeholders. There should obviously be alignment between risk triggers and the detection score – the more triggers which can be identified for a given risk, the lower the detection score.

When this new detection rating is multiplied with the traditional probability * impact value, you now should start to see some stratification of your previous uniformly high severity risks – in FMEA terms, this is known as the Risk Priority Number (RPN).

Prioritizing risks using the RPN can improve the efficiency and effectiveness of risk responses. For example, when faced with a high severity risk which has a very low likelihood of detection, response efforts might best be focused on avoiding or transferring the risk if possible.

Charles Duhigg – Between calculated risk and reckless decision-making lies the dividing line between profit & loss.

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

Posted on: May 19, 2018 06:59 AM | Permalink | Comments (17)

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

Congratulations – you’ve just been given the opportunity to manage a very innovative project – so unique, in fact, that nothing similar has ever been attempted by your organization!

Once the euphoria settles, you realize the significant challenge facing you – how do you go about planning a project without the benefit of expert or historical knowledge?  To make matters worse, if this is a project your company is doing for a paying customer, there are likely to be tangible and/or reputational penalties if you end up significantly missing the mark.

Assuming you have done your research and knowledge of similar projects is not easily available through your professional network, business partners or online sources, some of the following practices may help you out.

  • Have your customer articulate what they feel is a minimally acceptable end state, and then have them give you an idea of the relative priority of all other bells and whistles.  This can help you focus your team on working through the complexities of “must have” requirements without being overwhelmed by the “nice to haves”.
  • Involve your customer in scope decomposition – they’ve likely spent considerably more time in thinking about the scope than you or you team may have and even though they may not be able to materially help you in answering the “how”, they should be able to refine or focus your understanding of the “what”.
  • The more novel the project, the wider should be the skills and backgrounds of invitees to planning sessions.  You don’t know what you don’t know, so by increasing diversity, you should see a resulting increase in the quality of scope definition & decomposition as well as in identifying good approaches to deliver this scope.
  • Apply techniques such as Delphi to be able to refine and distill estimates.
  • Conduct risk identification sessions with as broad a group of participants as possible.  Not only will this help to unearth risks which you may not have considered, but it will help to overcome biases and may even help to identify scope elements which has been missed earlier.
  • Structure the project into multiple phases – the first to deliver a prototype, pilot or model of the desired end state as well as detailed estimates and development plan for delivering complete scope.
  • Embrace agile practices and approach the project as a set of iterations or sprints with the focus being on delivering highest priority customer-usable scope first.  That way, if you do find yourself facing the likelihood of going over budget or behind schedule, the customer can elect to cut their losses but still have received value from the work completed to date.  It is also advisable to focus on tackling higher risk, must-have requirements first – knocking those off will give the team a morale boost, and challenges experienced with completing those can help you more accurately re-forecast budget and timelines.
  • Where reasonable, negotiate to make working conditions for your team as supportive of creativity and productivity as possible.  You may need to request your customer or sponsor’s influence in getting waivers on your organization’s standard operating procedures if this means that your team will be able to hit the mark more predictably.  Employ project warrooms, collaboration sites or any other types of physical or virtual tactics that can reduce distance between team members and increase knowledge sharing.

How do you eat an elephant?  One bite at a time!

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

Posted on: May 15, 2018 06:59 AM | Permalink | Comments (7)

Don’t be an Ostrich!

A systemic lack of predictability regarding resource availability threatens to trump unmanaged scope creep, technical complexity and organization change resistance as the primary source of project risks.  Achieving an organization’s strategic objectives gets impacted as transformational projects require specialized skills that are in high demand and in low supply – this was admirably depicted by Scott Adams in an old Dilbert cartoon

The obvious solution to this is to either add more resources or take on less work in parallel. The first choice is usually unrealistic and success with the second is not achieved overnight.  Reducing the volume of multitasking is a key to more predictable throughput, but convincing senior management that you can actually do more by doing less is not easy. 

In the interim, here are a few tactical steps that a project manager can take:

  • Pity the poor resource manager who has competing demands on his/her resources’ time!  Unless your organization follows an objective project prioritization approach, priorities are likely set by whoever screams loudest.  In this situation, your best chance of improving resource availability predictability is to have a positive relationship with these resource managers so that they will try to be as considerate as possible with your resource needs.  If you are really lucky, they may even be motivated to assess and modify the resources’ operational duties to help you out.
  • Reduce the degree of project internal multitasking – it’s bad enough that your team members are likely working on other projects as well as operational activities, but at least try to avoid their having to context switch between tasks on your project.
  • Multitasking creates inefficiency as a result of context switching. Reduce the effort wasted in context switching by simplifying the ramp up/ramp down for team members.  One way to do this is to decompose work activities to a low enough level of detail, so individual tasks can be accomplished within one or two context switching cycles at most.
  • If your organization does not have a standard PM methodology, work with your peer project managers to define a consistent set of expectations for team member progress and issue management.  If a resource knows that the reporting requirements are consistent across the concurrent projects they are assigned to, that’s one less thing for them to worry about learning (and re-learning!).
  • Walk a mile in their shoes. When team members have multiple projects and operational activities to complete, increase the likelihood that they will want to work on yours by ensuring they understand how their tasks (and the success of the project as a whole) will benefit the organization and them.  Remove as many barriers to their being able to efficiently complete their tasks as possible. That means no unnecessary meetings and be sure to streamline project administration and communications as much as possible!  Take a page from agile approaches and embrace the role of a project manager as being responsible for clearing the hurdles from the team’s path.

Resource availability unpredictability is here to stay. You can make like an ostrich, stick your head in the sand and hope the problem goes away. Or you can take some tactical steps to increase the odds of success for your project, while simultaneously evangelizing the merits of reduced multitasking!

Which is it to be?

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

Posted on: April 24, 2018 07:00 AM | Permalink | Comments (16)

Have you rotated your project's tires?

A semi-annual ritual for many who live in cold climates is swapping all season to winter tires on their cars and back again. This exercise also presents a good opportunity to catch up on any other outstanding preventative maintenance for our vehicles. 

For those of us who live in places which observe daylight savings time, we are reminded to change the batteries in our smoke alarms whenever our clocks spring forward or fall back.

Here are a few questions to consider if its been a while since you've performed preventative maintenance on your projects.

What's the what? It can be too easy to have our heads down and keep executing the project, but what if there have been some shifts in the environment which have eroded the project's benefits? While this isn't a primary responsibility for most project managers, ignoring expected outcomes might be considered negligence.

How's the how? Assuming we are comfortable with the project's objectives, are the solution and delivery approaches still viable? If we chose an adaptive approach, is that still the best choice? Are there any early warning signs that solution design or architecture might be flawed and should be revisited? Is there any waste that's been introduced in our product or project processes which could be eliminated?

Risks revisited? If its been a few weeks since the contents of the risk register have been reviewed chances are some new risks could be identified and the assessment of older ones might need to be refreshed. It's also a good practice to periodically assess the effectiveness of risk responses and see if any key assumptions made to date can be confirmed.

Stakeholders surveyed? Similar to the risk register, if there are cobwebs on your stakeholder register you'd likely want to see if any new stakeholders have emerged and whether the attitude, interest and power of existing stakeholders remains the same. How effective have your stakeholder engagement strategies been to date and do they need to be adjusted?

Team thriving? When's the last time you did a pulse check on the health of your team? Was your last team building activity months ago? Even if no one has joined or left the team, you need to regularly monitor team morale and provide opportunities for individual and team development.

Lessons learned? Has any new knowledge been identified, curated and most important, disseminated and learned? Even on projects following a traditional delivery approach, the team should regularly reflect back on what has been learned to help them and others improve.

Ignoring such good practices won't usually cause immediate issues but paying down project management debt gets costlier the longer you wait!

Posted on: April 22, 2018 07:00 AM | Permalink | Comments (19)

Leverage diversity when boldly going where no one has gone before!

When Gene Roddenberry staffed the U.S.S. Enterprise with a highly diverse set of races, species & genders, he used Star Trek as his soapbox to challenge pervasive social injustices of the late Sixties. However, by doing so, he also provided another benefit of diversity: improved risk management.

When you consider the Enterprise’s original mission, it meets many of the criteria for a large, highly complex project:

  • Scope – to explore strange new worlds, to seek out new life and new civilizations.
  • Schedule – five years.
  • A unique endeavor – its original mission statement “to boldly go where no one has gone before” reinforces how unique the mission was.

In multiple episodes from the original series, and later through some of the movies, we saw instances of where diversity was a key contributor in helping the crew overcome dire situations. One such example comes from Star Trek 2: The Wrath of Khan. Of the entire crew, Spock was the only person strong enough to withstand the radiation within the matter/antimatter chamber to jump start the Enterprise’s engines. Anyone other than a Vulcan would likely have been overwhelmed before the process could have been completed.

So how does diversity facilitate more effective risk management?

When identifying risks, use of checklists and historical data can help surface uncertainties which would otherwise have been missed, but they are no substitute for a diverse range of expertise. If team members and stakeholders have similar educational and experiential backgrounds, there is a greater possibility of key risks remaining unidentified.

When analyzing risks or when monitoring early warning signs of risk realization, diversity is a good way to overcome risk biases and groupthink.

Finally, the quality of risk responses is constrained by the creativity and imagination of the team. It is well known that properly harnessed diversity promotes greater creativity.

So the next time you have the opportunity to tackle a challenging project, resist the temptation to staff the project with team members who are just like you by making diversity one of the key criteria for resource selection.

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

Posted on: April 20, 2018 07:00 AM | Permalink | Comments (16)

A verbal contract isn't worth the paper it's written on.

- Sam Goldwyn



Vendor Events

See all Vendor Events