Author: Kiron Bondale

To Escalate or Not to Escalate? That is the Question!

Written by Kiron Bondale on November 21, 2011. Posted in Articles. 2 Comments on To Escalate or Not to Escalate? That is the Question!

A review of troubled projects reveals that the inability of the project manager or team to appropriately escalate decisions or issues is a common contributor to failure.

In some instances, the challenge is insufficient escalation. This either results from the “superhero complex” that some project managers or teams develop (e.g. I can fix the world’s problems by myself) or a lack of appropriate judgment (e.g. I can see the light approaching at the end of the tunnel, but I’m sure it’s just the exit and NOT the train).

In other cases, excessive escalation can cause stakeholders and sponsors to get numb – this is the classic “Cry Wolf” effect. When a concern emerges that truly requires attention, no one pays attention.

Like many of the soft skills necessary to be a successful project manager, there’s no silver bullet that will guarantee effective escalation but here are some tips that might help:

1. As part of your stakeholder analysis, find out what their escalation requirements are. Similar to risk bias, stakeholders are likely to have differing views on what kinds of decisions or issues need to be escalated to them for resolution and while you may not be able to tailor your approach to exactly meet these expectations for individual stakeholders this up front requirements gathering can reduce the likelihood of your being far off the mark.

2. Document escalation criteria and processes within your project’s communication management plan. Such criteria should be objective or at least be supported by examples of the types of events that merit escalation.

3. Leverage an external observer who can provide you with unbiased feedback on a situation. Obviously you should not abuse this resource with each and every decision or issue that emerges on your projects unless a formal mentor-mentee agreement exists, but having the support of an external advisor can reduce the likelihood that your own intuition is invalid.

4. Make sure you’ve done some analysis. For example, when faced with a decision or issue you can ask your team to perform a quick expected impact calculation (combining maximum impact and probability of occurrence) based on the question “What’s the worst that could happen if we choose to deal with this without escalating?”.

5. “Once is happenstance, twice is coincidence, three times is enemy action”. If repeated attempts to resolve an issue or make a decision within the team have failed, escalation can at least reduce the likelihood of further project impacts.

Communication is the most important project management knowledge area, and the ability to effectively escalate is a critical competency for any project manager.

Don’t forget to leave your comments below!

Five Uses for a “Dead” Issue Log

Written by Kiron Bondale on October 19, 2011. Posted in Articles. 4 Comments on Five Uses for a “Dead” Issue Log

I couldn’t surpass Simon Bond’s volume of suggestions, but Issue Logs can add value beyond a project’s completion! Although you may be more likely to consider schedules, financial plans or even risk registers as useful post-project artefacts, here are a few reasons to consider doing more than just archiving those issue logs.

Improving operations: A good practice in project closeout is to transfer all open or on hold issues to the team that will be responsible for supporting the project deliverables in their operational state. However, even the data related to closed project issues can help with resolving operational challenges – troubleshooting methods, workarounds that might have been used during the project for expediency purposes or key contacts are a few examples of such useful information.
As I wrote in the article, Quantifying Risk Management Benefits, by reviewing issue logs immediately after a project has completed, you can glean candidate threats to future projects. You can also harvest quantitative impact data and gain insights into how effective specific issue management strategies were.

Helping to develop a Risk Breakdown Structure (RBS): An RBS can be a valuable input into risk identification activities, but to develop one that reflects the relative severity of different threat categories, past project issue logs can provide empirical evidence on issue frequency and impacts.

Proactive identification of portfolio-wide threats: Analogous to the rationale used by security agencies use for sifting through and analyzing terrorist chatter to avert impending attacks, analyzing issues across projects can help to identify significant systemic threats.

Resource evaluation and development: While the normal artefacts in a project can provide data to help resource managers understand how their staff perform under normal conditions and expectations, issue logs can provide insights and supporting evidence into how the same resources deal with unexpected situations. This information can help during performance evaluation time but can also be useful to identify which staff may be better suited to troubleshooting tasks.

Harvesting and distilling operational process assets requires effort, and such post-project activities may necessitate the services of a PMO or PM community of practice (as the project team will likely have moved on to their next project), however, “Those who cannot remember the past are condemned to fulfill it”.

Don’t forget to leave your comments below.

Opportunities – A Positive Rationale For Project Risk Management!

Written by Kiron Bondale on September 21, 2011. Posted in Articles. 5 Comments on Opportunities – A Positive Rationale For Project Risk Management!

FEATUREPtimesSept21st Both the PMBOK Guide (Fourth Edition) and PMI’s Practice Standard for Project Risk Management highlight the need to consider positive events (opportunities) as well as negative events (threats) when performing project risk management activities.

In practice, the majority of the organizations I’ve worked with have demonstrated inconsistency when applying risk management practices. So why should we concern ourselves with opportunity management when threat management should be of greater importance, and yet, does not appear to be succeeding?

Here are a few reasons why a balanced approach to risk management that incorporates opportunities is advisable.

To paraphrase Carlo Muzzarelli, who provided a great response to a question about this topic in the LinkedIn Project Management Questions section, without considering opportunities when planning and executing a project, at best, you are likely to meet your schedule, cost & other baselines. More likely than not, due to the impact of realized threats, you will end up violating one of these constraints. By managing opportunities, you’ll increase the likelihood of shifting the variance bell curve in the right direction.
Risk identification workshops provide both a good team building opportunity as well as a cathartic medium for team members to vent or share the angst that they might be feeling about a project. However, certain participants such as project sponsors or other senior stakeholders might not be impressed by a purely negative focus in these workshops. Identifying and exploring opportunities is one way for the team to gain some credibility “brownie points” with these senior stakeholders.
By including opportunities in qualitative risk analysis workshops, a project manager can get a more balanced idea of individual biases than if the discussions focus on threats alone.
It can be challenging to secure commitment from risk response owners (especially stakeholders that are only peripherally involved with the project) to execute risk response plans and this is especially true if they are being asked to do this to respond to threats. You might find that this reluctance to participate in the risk response process dissipates if the same stakeholder is responsible for a few opportunities as well.

It can be challenging for a Project Manager or team member to identify and analyze threats and opportunities in an unbiased, balanced fashion – it’s common to dwell on what can go wrong instead of thinking about what could go better than expected. This bias could provide rationale for leveraging the services of an Opportunity Analyst.

While some might be context sensitive, most common risk management tools (E.g. Delphi method, Decision tree analysis, Ishikawa diagrams) are as applicable to opportunities as they are to threats.

For those that have struggled with selling the value of project risk management, opportunity management is a good way to show that the cup is half-full and not always half-empty!

Don’t forget to leave your comments below.

Five “Simple” Questions to Facilitate Project Selection & Prioritization

Written by Kiron Bondale on July 12, 2011. Posted in Articles. 5 Comments on Five “Simple” Questions to Facilitate Project Selection & Prioritization

Don’t misunderstand me – project evaluation or prioritization is NOT simple – getting a team of decision makers to come to an agreement on a ranked set of projects while putting aside their individual agendas such that the organization’s objectives are met can make achieving world peace appear trivial!

While I’ve covered in a past article on the project scoring that coming up with a scoring model for a project can be a key input into the decision making process, starting with a consistent set of questions can provide an objective counterpoint to balance the expected project “lobbying” from decision makers.

The following standard domain and industry-neutral questions could kick start this shift.

1. Which business or operational metrics are expected to be improved by doing this project and by how much?

Regardless of what industry you operate in, all “worthwhile” projects should result in improvements to at least one business or operational metric. In some cases, you may not have previously quantified the metric, but that doesn’t mean it doesn’t exist. For example, a project to train internal IT staff on a new technology may not directly impact profitability, but it could improve the capabilities of the organization and could boost employee morale, both of which could be distilled into metrics.

2. Which business or operational metrics are expected to be negatively impacted by doing this project and by how much?

Positive changes in one area will often result in issues to another, and these negative impacts need to be weighed against the benefits expected from the previous question.

3. What is the expected financial and resource burden of this project and over what time period?

Cash-strapped companies might be tempted to focus on financial requirements only, but poor use of resource capacity is one of the greatest opportunity costs an organization can incur. Both one-time and ongoing requirements need to be considered.

4. Does this project satisfy an external regulatory or contractual requirement?

Unfortunately, there will always be some projects that have to be executed to keep the company compliant. This is why it is important to ensure that the cure is not worse than the disease as I had covered in this earlier article.

5. How severe is the project & business risk?

Ignoring negative project risks (i.e. those potential events that could impact the project’s objectives & constraints) or business risks (i.e. those potential events resulting from the project that could impact the realization of the project’s benefits or the business as a whole) will be like jumping out of an airplane without checking that your parachute is viable.

Expending excessive effort in developing a detailed scoring model is academic if executive leadership behaviors don’t change, but consistent evaluation and presentation of holistic project information is one way to start the transition to a more objective approach.

Don’t forget to leave your comments below.

Preventing a Trip Over the Waterfall When Introducing Agile Methods

Written by Kiron Bondale on June 15, 2011. Posted in Articles. 4 Comments on Preventing a Trip Over the Waterfall When Introducing Agile Methods

BATimes_Feature_June7 While I have reviewed some practices to consider when changing methodologies from traditional waterfall approaches to agile ones in Avoiding Speed Bumps when Adopting Agile Practices the input from a participant at one of the roundtable discussions at this year’s ProjectWorld Toronto inspired a few more.

The attendee indicated that his organization had embraced agile methods on a specific technology project but the issues and cost overruns they experienced stymied further attempts to adopt agile practices.

Further discussion of the specifics of this case study yielded some more lessons.

Start simple and expand complexity progressively (also known as “success begets success”) – in most organizations where agile methods have “stuck”. A pilot was done using a small (though highly visible) project that satisfied the 3 C’s of agile – collocation, collaboration & (open) communication.
Leverage coaching assistance – It is very hard to manage your first agile project while simultaneously coaching the overall project organization (customer, stakeholders & team) through this process and philosophy change. If you happen to be the sole agile evangelist within your company, it may be worth justifying the costs of an outside coach to focus on the change aspects.
Trust is mandatory – As with any other strategic change, commitment to the change means more than just focusing on the expected benefits while giving lip service to the costs. As I previously wrote in Trust – a critical success factor for successful agile projects, a lack of trust between key roles on agile projects can sometimes result in worse outcomes than on traditionally managed ones.
Identify “appropriate usage” criteria for agile methods – Not all projects lend themselves to the use of agile approaches (just as not all projects can be successfully managed using waterfall approaches). Developing checklists or similar tools to help project managers decide whether a purely agile, a purely waterfall or a hybrid approach is best suited to their specific projects will help to reduce “square peg in round hole” situations.
Don’t get hung up on specific methodologies – unless the nature of your projects exactly fits a particular agile methodology, it is better to focus on adopting (and adapting) principles rather than to blindly follow an off-the-shelf set of implementation practices. Fanaticism towards any specific agile “religion” is hardly likely to reward you with converts.

Through committed executive sponsorship, appropriate staffing and a “walk before you run” implementation approach, you can reduce the likelihood that an agile initiative will go over the waterfall!

Don’t forget to leave your comments below.