Easy in theory, difficult in practice

My musings on project management, project portfolio management and change management. I'm a firm believer that a pragmatic approach to organizational change that addresses process & technology, but primarily, people will maximize chances for success. This blog contains articles which I've previously written and published as well as new content.

About this Blog


Recent Posts

Decision requests or just do it?

Evaluate your ceremonies with a W5 check

How lean is your project management style?

Breaking habits requires substituting one routine for another

Identifying and taming “800-pound gorilla” projects

Decision requests or just do it?

Categories: Project Management

On traditional projects, a project change management plan is supposed to provide guidance to project teams on the criteria that make a change significant enough to manage through formal change control.  On agile projects, change is an inherent component of the project as opposed to an exception condition, and hence such formality is rarely required.

The same degree of certainty cannot be stated about decisions - both agile and traditional projects spawn a variety of decisions, but how does a PM go about deciding what level of formality is required to manage those?

If the project team is aware of the triggers and thresholds that may require formalizing the decision-making process, then there should be alignment in approach.  One place to start is to understand the criticality of key requirements for the project - for example, if long term viability of a project deliverable is not necessary, decisions that impact sustainability may not require the same level of formality as those that affect a more critical attribute.

Having a brainstorming session early in the project's lifetime to identify those types of situations that may necessitate formality can help to build some "muscle memory" into the process.  Some risk identification techniques could be utilized for this purpose - for example, reviewing the project's WBS to attempt to identify the significant decisions that could emerge related to each key deliverable.

Of course, no approach is perfect, and it should be tuned based on the feedback from key stakeholders - if the stakeholders are pushing back regularly on the necessity of a formal decision request for a given situation, perhaps the thresholds are set too low.  On the other hand, a few too many "damage control" issues might teach a PM that a greater degree of formality is called for.

It's also important to ensure the decision making process is scalable.  Focus on who needs to be involved in the decision-making process as opposed to the specific mechanics.  A triage approach may work:

  1. Decisions that are of so low impact that verbal decision making is sufficient, and informal communication to those who need to be apprised of the decision can suffice.
  2. Decisions that are of moderate impact may need the formality of a verifiable audit trail - this could be an e-mail chain, or an e-mail confirmation of the decision to the key stakeholders followed by archival of the final outcome in the project control book.
  3. Decisions that are of significant impact should require the use of a decision request document that is formally approved, logged and archived.

Having a peer-level support system, a mentor or a PMO could help a PM decide on a situational basis what makes sense.

The two process extremes are equally scary - a complete lack of formality increases the likelihood that critical decisions are made without involving all the right stakeholders and with insufficient analysis and communication whereas too much formality mires the project in unnecessary bureaucracy and reinforces negative perceptions about project management.

One more example of why judgment is one of the key differentiators of a great PM!

(Note: I originally decided to publish this article on kbondale.wordpress.com in March 2012)


Posted on: February 20, 2019 10:10 AM | Permalink | Comments (6)

Evaluate your ceremonies with a W5 check

I'm midway through Priya Parker's book The Art of Gathering and her insights into how to make an event a meaningful gathering rather than "just another boring meeting" are apropos to ceremonies. A common complaint many team members raise in the early days of an agile journey is that it feels like they are in too many meetings. This shows that they aren't perceiving the value of the ceremonies and, if these concerns aren't addressed quickly, the team members are likely to disengage.

One way to evaluate your ceremonies is to do a W5 assessment on them.


Without a shared understanding of the purpose for the ceremonies, misalignment of expectations and behaviors may emerge. It is critical that a newly formed team understands why each ceremony is needed, but as the team evolves, the purpose of each should be reviewed to ensure it remains relevant. One way to gauge this is to ask each team member to summarize what they believe the purpose of the ceremony to be in three words or less.


Once there is clarity on why, we need to confirm that the outcomes of ceremonies are being realized and are in line with the purpose for conducting the ceremonies. Poll team members on their perception of the effectiveness and efficiency of producing those outcomes.


A common challenge with agile ceremonies and most recurring events is that, over time, you might pick up a number of participants who "just want to observe" or "need to be kept in the loop". If everyone is needed, no one is needed. A self-disciplined, self-managing team will weed out those stakeholders who aren't required but will be equally diligent on ensuring the right participants are at each ceremony. For example, conducting a sprint review without adequate representation from those who will be consuming the outputs of the team is a waste of time. Who is also about the role each participant plays. While new teams might lean on the Scrum Master to facilitate most ceremonies, over time, this can become a shared responsibility, giving each team member a chance to develop their facilitation abilities.


It is a good practice to hold ceremonies at the same day and time but the timing that seemed ideal in earlier sprints may not suit all participants in later ones. It is also worth evaluating the duration of the ceremonies as they should be long enough to meet the purpose and achieve the expected outcomes and no longer. If certain team members are missing certain ceremonies, it is worth confirming whether the timing is still suitable for all participants.


Whether it is physical meeting rooms or virtual video conferences or collaboration environments, it is important to ensure that the location supports the purpose and approach and doesn't detract from it. In physical settings, this could be as simple as the arrangement of chairs around a table and the availability of white board space for spontaneous collaborative activity. Consider alternative environments for physical ceremonies. Could it be possible to conduct some in a more dynamic manner - perhaps as a walking meeting? In virtual sessions, this means ensuring that the tools provided (e.g. polls, whiteboards) are functional and everyone knows how to use them in advance of the ceremony.

How frequently ceremony reviews should take place will vary and one trigger for a health check might be to have team members vote every few weeks or every couple of sprints on how valuable they feel each ceremony is.

To paraphrase Chris Fussell "If your team is trying to be more agile, stop and think, 'Are my ceremonies actually productive, or are we merely having ceremonies for ceremonies' sake?'"

Posted on: February 17, 2019 07:00 AM | Permalink | Comments (16)

How lean is your project management style?

There is no single recipe for how to best manage a project.

Culture (organization & team) and enterprise environmental factors all influence how a project gets managed but personal style and approach also plays a critical role. Within the constraints of the previous factors a project might be managed successfully but the degree of efficiency can vary widely between project managers.

It might not be advisable to invest a lot of effort in analyzing how we are adapting and executing each of the PMBOK processes, but we can lean (pun fully intended) on process excellence to help us identify common sources of project management waste.

  1. Waiting: While we might complain frequently about how long they have to wait for others to approve deliverables, make decisions or complete in scope activities, how many times have we introduced unnecessary delays by avoiding conflict with a team member, procrastinating on having a difficult conversation with a key stakeholder or escalating an action or issue that was impeding our team’s progress? Do you always start and end your meetings on time?
  2. Over-production: Do you print out copies of reference materials for all team members prior to team meetings? How many of these copies actually get referred to? How about reports for executive presentations? Are team members having to produce different status reports for you and their own functional managers?
  3. Rework: Do you encourage your team members to ensure they are balancing quality with speed or is the message they are receiving that you are only interested in having deliverables out on time? Are you giving yourself sufficient time when updating forecasts or putting together proposals so that refinement is minimized?
  4. Motion: Do you encourage virtual participation to avoid unnecessary travel when physical presence is not required to achieve a meeting’s objectives? Are you or your team members printing unnecessary materials and losing time in going back and forth from the printer?
  5. (Over) Processing: How often are you guilty of staring at an e-mail message, presentation or report and tweaking it over and over again. Communication does consume most of a project manager’s day, but are you gold-plating your communications?
  6. (Waste of) Intellect: Are you getting the best out of your team members (and yourself) or do you bog them down with low-value, soul-draining administrative tasks?
  7. Inventory: Is your work breakdown structure decomposed sufficiently that work-in-progress is minimized? Have you leveraged tools such as Kanban boards to visually identify task inventory backlogs?
  8. Transportation: Have you assessed the end-to-end flow of activities from requirements through to completed deliverables to ensure that time isn’t lost in unnecessary transportation? Do you still insist on “wet” signatures when e-mail approvals might suffice?

Is your approach to managing projects as efficient as it could be, or are you stuck in a WORMPIIT?

(Note: this lean & mean article was originally published in October 2015 on kbondale.wordpress.com)

Posted on: February 13, 2019 07:00 AM | Permalink | Comments (3)

Breaking habits requires substituting one routine for another

I was asked to facilitate a lessons learned session for a program team using a retrospective format. After the team had brainstormed, prioritized and discussed most of the challenges they had faced, it became clear to them that there were only a couple of root causes for most of the main pain points they had identified. Neither of those root causes was a true learning but rather they were just simple reminders of good practices to follow for large, complex programs. I then asked them the somewhat rhetorical question: "Remembering now what should have been done then, how will you ensure that this doesn't happen on a future program?"

A project team I've been working with has struggled with judging how many work items they can successfully complete within a sprint. In the retrospective for their last sprint, they identified a number of simple, effective ideas for resolving this chronic concern. Again, I challenged them with the same question: "You've come up with a great list of ideas, but how will you ensure that you actually act on those the next time you are sprint planning?"

Both of these experiences reminded me of how difficult it is to break habits.

In his book The Power of Habit, Charles Duhigg has written about the three part neurological loop governing habits which was discovered by MIT researchers: a cue, a routine and a reward.

In the project team's case, the routine has been to accept more work items than they can complete in a sprint even when historical evidence shows this tactic hasn't worked out well. The cue is that moment in the sprint planning ceremony when the team makes their sprint forecast. It's hard to say what the reward has been but perhaps it's the temporary high which comes when we take on a significant challenge as a team.

To break habits, we need to find a way to substitute a different routine for the old one and soliciting the help of a close, trusted colleague might be one way to do this.

The team could designate a single individual to come to the sprint planning ceremony with a stuffed pig or some other visual gag which represents gluttony. Then, when the team is about to forecast how much they will accept in the sprint, that team member could hold up the pig and say "Oink! Oink!" to remind all of them to be a little more conservative. While the team might not bask in the short term glow of having accepted a bloated sprint forecast, they will enjoy the much more rewarding experience during their sprint review when the product owner and other stakeholders congratulate them for improving their predictability.

Breaking habits is hard to do but by identifying cues and implementing good routines to swap in for the old ones, we can prevail.

Posted on: February 10, 2019 07:00 AM | Permalink | Comments (9)

Identifying and taming “800-pound gorilla” projects

Most organizations regardless of their size or project management maturity will initiate a proverbial “800-pound gorilla” project at least once.  Mega-projects can torpedo a company, but they are often critical to their long term sustainability or strategy.  For the “lucky” program or project manager that is asked to manage one of these, it can either be a career-limiting death spiral or a priceless differentiator for their portfolios.

Failing to plan is planning to fail – this is the mantra of mega-projects.  Organizations that were historically able to successfully complete small to mid-sized projects in spite of themselves will discover that heroics that worked in the past will not work on a mega-project.

To plagiarize Jeff Foxworthy, here are some ways of identifying mega-projects:

  • If the project schedule is longer than 100 tasks at outline level 2, it may be a mega-project.
  • If the project budget exceeds the GDP of most small nations, it may be a mega-project.
  • If you are thinking of submitting your project profile to the committee that administers the Seven Wonders of the Modern World list, it may be a mega-project.
  • If your project is mentioned in the annual reports or quarterly results calls of your primary vendors, it may be a mega-project.
  • If your will lists your project control book as the main part of your estate, it may be a mega-project.

What are a few ways of coping once you’ve identified the fact that you are the proud owner of an 800-pound gorilla?

  1. Tackle it one piece at a time – a phased or iterative approach to mega-projects is one way to avoid “big bang” change nightmares.
  2. Address big risks early – a disciplined, consistent approach to risk management is crucial, and once key risks have been identified try to address them as early as possible to help increase the predictability of future deliverables.  Use a pilot or prototyping approach to validate approaches – fail small but fail fast.
  3. Use (multiple) independent estimates – it’s doubtful that anyone on the project team will be able to provide accurate estimates for the full scope of work.  There are simply too many variables to deal with, so you’ll probably have better odds of winning a lottery than of coming up with a good estimate.  Given this, derive  independent estimates – commercial estimation tools might be an option.
  4. The journey is the reward – slogging through a mega-project with no end in sight, and few wins along the journey impacts team morale and productivity as well as  increasing the likelihood of failure.  Use agile techniques to structure the project to deliver “wins” throughout the lifecycle, and celebrate these wins as they occur.
  5. Find mentors – Whether it is helping you assess options for a decision or validating your perception of a situation, a mentor can help you or other key project participants avoid tunnel vision.

Tackling a mega-project can sometimes feel overwhelming, but remember that even King Kong was laid low by a combination of fighter planes and gravity!

(Note: Neither King Kong nor Donkey Kong was involved in the publishing of this article back in November 2010 on kbondale.wordpress.com)

Posted on: February 06, 2019 07:00 AM | Permalink | Comments (15)