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

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?

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

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 (4)

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)

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)

The Serenity Prayer is a mantra for project managers

An unfortunate analogy that can be made of project managers is that in many respects they are like worrying parents.  They invest a significant amount of effort, credibility and emotion into the nurturing of their projects, so anything that is likely to impact the success of their offspring is going to affect them in a very similar fashion.

There is a broad range to this type of behavior – some parents (usually those who have more than one child) are mature enough to monitor things from a distance but to also be prepared to act if required whereas others micro-manage their kids lives to the point of almost smothering them in bubble wrap! 

The same can be said about project managers – some trust their team members and stakeholders to be professional enough to come to them proactively when concerns are identified, whereas others won’t be comfortable if they are not constantly touching base to make sure all is well. 

This behavior extends beyond risk and issue management to quality – just as some parents have the need to mold and hammer their children to fit the parents’ vision of how they should turn out, some project managers exhibit the irresistible urge to constantly tweak or tune deliverables, frequently alienating their teams in the process.

While such behavior is detrimental to healthy team development and the perceptions created can linger well beyond the lifetime of an individual project, it is also not conducive to a good work-life balance. 

Project managers who demonstrate the compelling need to stay on top of absolutely everything and to worry past the point of reason can end up neglecting spending quality time with their families or their own professional development.  When challenged about their lack of attention to these critical activities they will rarely indicate that they felt they could have taken an alternative course of action.

Should a project manager be vigilant and take ownership for getting actions, issues & risks addressed – absolutely, if not, they will likely satisfy one or more of Neal Whitten’s ten signs of “too soft” project management behavior!  However a project manager also must recognize the limits of their ability to positively influence project outcomes – in spite of these efforts, the project may still suffer for reasons outside of their control. 

This is where that critical but elusive project management competency of judgment is required to help them accept the things they cannot change, draw on courage to change the things they can and have the wisdom to know the difference.

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

Posted on: May 10, 2018 07:00 AM | Permalink | Comments (9)

What makes project management fun? Let me spell the ways!

Categories: Project Management

This thing we do can often be very challenging – having to deal with suspicious sponsors, squabbling stakeholders and Teflon team members can make us question our rationale in choosing this over any number of other professions.

To counter such thoughts, let me provide some reasons as to why, while frustrating, project management is also fun!

P is for People, without which our projects won’t succeed

R is for Risks, which we hope our risk owners shall read

O is for Objectives, though our projects sometimes have none

J is for Jargon – you’ll agree our profession has some!

E is for Effort estimates, which can make sponsors cry

C is for Communication, which can be hard if you are shy, and

T is for Teams, which we strive hard to build

M is for Milestones, on schedules they look like diamonds in the rough

A is for Assumptions, of which we never log enough

N is for Negotiate, which we have do each day

A is for Authority, which we’d have if we had our say

G is for Gantt, we secretely love his charts

E is for Emotional Intelligence, with which we hope to win stakeholders’ hearts

M is for Monte Carlo, where some day our luck we want to try

E is for Earned Value, which we’d all like to apply

N is for Network diagrams,  which we don’t like to draw, and

T is for Templates, which our PMOs insist we use, because they lay down the project management law!

I is for Issues, projects have those, never doubt, and

S is for Schedule, which newbies think project management is all about!

F is for Float, which is good for your schedule AND your boat

U is for Unanimous agreement from key decision makers, which our decisions need to pass, and

N is for Near-critical path activities which (if we ignore them) can bite us in the ***

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

Posted on: May 08, 2018 07:00 AM | Permalink | Comments (11)

"There is nothing more difficult than talking about music."

- Camille Saint-Saens



Vendor Events

See all Vendor Events