Author Archives: Kiron Bondale

About Kiron Bondale

Measurable business value can be realized through the successful initiation, prioritization, planning & execution of strategic projects. Striking a pragmatic, value-based balance between people, process & technology is a key to achieving success with Project Portfolio Management initiatives. Effective change management is crucial when trying to improve PPM or PM capabilities. Having been involved with multiple capability improvement initiatives, what I've learned is that "it's easy in theory, difficult in practice"! Continuous improvement of hard & soft skills gained by assisting organizations in the achievement of their business goals through the execution of the right projects in the right way is my ongoing mission.

Who makes the rules for your team?

Playing a board game without all participants having a consistent understanding of the rules is a frustrating, time-wasting experience.

The same is true when a team starts to work together for the first time. Whether it is done proactively when the team assembles or is done as a reaction to unhealthy conflicts, having a basic set of working agreements can help to accelerate a team’s transition out of the storming and norming phases of development.

While we often think of working agreements as covering team member interactions such as how to deal with conflict, the communication methods to be used for different situations or logistics for regular meetings, a good set of ground rules will also cover the teams way of delivering value. For example, the Definition of Ready or a Definition of Done are two examples of delivery working agreements.

But how do ground rules get defined?

In my past experience, I’ve encountered four scenarios:

  • The team leader defines the rules. In such cases, the team might be permitted to provide feedback, but the leader has the final say.
  • The team defines the rules with support from the leader. In these situations, the leader might act as an advisory facilitator, helping the team through the process but also ensuring that the rules remain within organization policy and standard guardrails.
  • The team defines the rules by themselves. The team leader might observe the process but won’t inject any of their knowledge into the proceedings.
  • The team has no ground rules. This doesn’t mean that anything goes, but rather the rules are never openly discussed and explicitly defined.

Most of the teams I’ve witnessed fall into one of the first two scenarios. Highly mature, self-managing teams will transition from the second to the third scenario. I’ve rarely seen the fourth scenario, and mostly that was with teams who had novice leaders.

I ran a one-week poll in PMI’s LinkedIn Project, Program and Portfolio Management discussion group as well as the ProjectManagement.com community. Unlike some of my recent polls, this topic drew a large number of responses: 236. 53% of the votes were cast for the leader as a facilitator, 22% for the team defining rules on their own, 16% of respondents indicated that no rules were explicitly defined and the remaining 9% were the team leader defining the rules.

It is encouraging that three-quarters of the responses indicated some degree of self-organization and team autonomy, but that still leaves a quarter of teams either having rules imposed which might reduce their motivation or having no rules at all which increases the likelihood and duration of interpersonal conflicts.

“Rules and responsibilities: these are the ties that bind us.” – Neil Gaiman

(If you liked this article, why not read my book Easy in Theory, Difficult in Practice which contains 100 other lessons on project leadership? It’s available on Amazon.com and on Amazon.ca as well as a number of other online book stores).

Categories: Agile, Governance, Project Management | Tags: , , | Leave a comment

All constraints are important but some are more important than others

One of the distinguishing characteristics of project work is that we are usually expected to deliver value in uncertain conditions while facing multiple constraints. While it is important for a team to understand the external constraints they have and to define realistic plans based on those, it is also advisable that they have an idea of the relative priority of these constraints before making delivery commitments.

A typical sponsor or customer might tell you that all constraints are equally important to them, there is always one or at most two which will trump the others. If the team doesn’t take the effort to dig deep with stakeholders to understand the relative priority of constraints, they will be missing a valuable input for their analysis when an issue crops up which makes it impossible to achieve all of a project’s objectives.

For example, if we have an issue which will affect cost, schedule and quality, without understanding which of these three is more important than the others, we may come up with a recommendation which won’t result in a successful project.

And rarely do we find that all of our stakeholders will align on this relative ranking, especially with discretionary projects. Finance departments are likely to prioritize revenue and cost whereas business or product owners might emphasize timely delivery, scope or customer satisfaction. Achieving alignment between the key stakeholders might be difficult in the early stages of a project, but it is better than having those conversations when things have gone wrong and there is time sensitivity on making a good decision on how to proceed.

Even though there are many possible constraints for most projects, I wanted to get some feedback from practitioners on which of the most common ones were the highest priority on their most recent projects.

While the project management iron triangle might represent the best known set of constraints, for the majority of the projects I’ve been involved with, stakeholder satisfaction was the primary constraint.

I ran a one week poll in PMI’s Project, Program and Portfolio Management discussion group on LinkedIn and within the ProjectManagement.com community. I received a total of 128 responses with 30% support for stakeholder satisfaction, 28% for time, 26% for scope or quality and only 16% for cost. A few respondents provided comments explaining their voting choice, but no additional constraints were provided as a primary choice by these practitioners.

Although stakeholder satisfaction doesn’t surprise me given my past experience, I would have expected cost to trump time or scope. This is what I’ve witnessed on many public sector projects where budgets are fixed, but there might be willingness to delay a milestone or reduce scope if that means staying within budget.

Now you know. And knowing is half the battle.” – G.I. Joe

(If you liked this article, why not read my book Easy in Theory, Difficult in Practice which contains 100 other lessons on project leadership? It’s available on Amazon.com and on Amazon.ca as well as a number of other online book stores).

Categories: Governance, Project Management | Tags: , , , | Leave a comment

How current are your risks?

I’ve often referenced Dr. David Hillson’s definition of risk as “uncertainty that matters” in my articles about project risk management.

The last word in that short sentence is critical.

If stakeholders don’t feel that the information presented to them about a risk matters to them, they will ignore it. At best, this means the effort which the project team spent on identifying, analyzing, and communicating risks was wasted, but at worst, it could result in a stakeholder not implementing a recommended risk response.

There are many reasons that risk information might not matter to stakeholders. Here are just a few:

  • Risk event descriptions are too vague
  • Information about critical risks is lost in a sea of trivial risks
  • Stakeholder interests or their risk tolerance level is not taken into account
  • They haven’t been educated about the value of risk management
  • The cost of prevention or reduction outweighs the costs of risk realization

But one of the most damaging and prevalent causes I’ve experienced is when the information provided to stakeholders is out of date.

As with everything else on projects, risks change over the life of a project and if stakeholders are aware that the details reflected in a risk register or in a project status report or dashboard don’t reflect current realities, the team’s credibility will be hurt. And, if those stakeholders were skeptical about risk management to begin with, this will just give them ammunition to ignore risk response responsibilities in the future.

To get a sense as to what others were experiencing, I ran a one week poll in PMI’s LinkedIn Project, Program and Portfolio Management discussion group and in the ProjectManagement.com community asking practitioners how frequently were risk registers reviewed and updated with stakeholders.

Context counts – for example, a lower complexity project might have fewer register updates than a higher complexity one.

Out of the one hundred responses received, 34% indicated a weekly or shorter update cycle, 41% voted for monthly, 21% indicated quarterly or more infrequently and 4% indicated risks were never updated.

While it is encouraging that three quarters of the practitioners were at least updating risk information monthly which might be appropriate for long duration projects, the fact that a quarter of the responses showed either very infrequent or no updates is unfortunate.

While there is some limited value in sharing risk information in the early days of a project, as complexity grows, the likelihood of not experiencing an issue which could have been addressed through more proactive risk management increases dramatically.

A ounce of prevention is worth a pound of cure, but only if that prevention is practiced over the life of the project.

(If you liked this article, why not read my book Easy in Theory, Difficult in Practice which contains 100 other lessons on project leadership? It’s available on Amazon.com and on Amazon.ca as well as a number of other online book stores).

Categories: Project Management | Tags: , , , | Leave a comment

Blog at WordPress.com.

%d bloggers like this: