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

Will all improvement ideas from a retrospective consume capacity?

Why are companies good but very rarely great at project management?

Humility is a prerequisite to agility

Tips for coping with multiple concurrent must-do projects

What are the tipping points for your agile transformation?

Tips for coping with multiple concurrent must-do projects

Long-time readers of my blog will know that I support the concept and principles of objective project prioritization. However I am pragmatic and recognize that a significant percentage of the organizations who aspire to having objective rankings of their active and pipeline projects can’t get there overnight, and even as their practices mature, they still must successfully deliver multiple parallel projects with constrained skills and capacity.

If this sounds like your organization, what can be done to meet commitments while not ignoring the practice improvements required to achieve a more manageable active project portfolio?

  • Make sure must-do projects are REALLY must-do – As with any negotiation, the starting point for a project customer will be the one that is in their best interest, namely that their project is the most important one in the portfolio. However, the discussion around priority should always ask the questions “What’s likely to happen if we don’t do this project?” and “What’s the impact if we don’t do this project right now?” to get a more objective understanding of a project’s criticality.
  • Understand constraint flexibility (no, that is NOT an oxymoron) – Similar to the previous point, the initial response to “What will happen if we pushed the project back by a month or two?” or “What would happen if we added some external resources to the critical path?” might be negative, but you’ll need to dig deeper to ensure that the portrayed constraints are in fact immovable. The reality is that not all project’s constraints will be fixed – you can either be proactive and have those conversations up front, or back into them when issues arise!
  • Don’t overplan – With more concurrent work underway than can be easily delivered, issues are going to emerge and plans must be flexible and scalable to adapt to these challenges.
  • Prioritize milestones – Once a small set of must-do concurrent projects has been identified and preliminary planning has been completed, the focus of prioritization should shift to the truly critical milestones within these projects. Near term milestones should be given a higher priority as there is less flexibility or time to resolve issues related to those than with longer term ones. This does not mean ignoring longer term milestones – the confidence level of meeting those should still be reported regularly to leadership teams, but decision making regarding scarce skills should favor near term critical milestones.
  • Establish consistent cross-project resource contention issue management at the portfolio level – Significant effort and time can be wasted in dealing with resource contention issues between projects so effort spent up front in defining processes and governance for resolving such contention will pay for itself within the first few milestones.
  • Communicate the reality of the situation to all staff – Although the leadership team may understand the rationale for having multiple parallel #1 projects, if they don’t do a good job of cascading this information down through their direct reports to all staff, morale and productivity will suffer.

Juggling multiple balls might seem like an impossible feat to an untrained novice but just as jugglers develop techniques and practices to do this, it is possible for organizations to improve their ability to manage multiple concurrent must-do projects.

However, even expert jugglers eventually tire, and if the volume of concurrent work doesn’t subside to more manageable levels in time, inevitably one or more critical project “balls” will drop along with a side order of skilled staff attrition.

(Note: this article was originally published in August 2013 on kbondale.wordpress.com)

Posted on: November 07, 2018 07:36 AM | Permalink | Comments (15)

Project lessons from playing pool

A few months ago, I rekindled my enjoyment of the game of pool after having played it sporadically over the past twenty years.

I find something soothing about the clickety-clack sound of balls ricocheting off one another and relish the challenge of figuring out which shot to play to sink a ball and line up my next shot or if I miss, at least prevent others from making their shots.

Racking my brain (pun intended) for a topic to write about this week I thought why not explore whether there are any lessons we can learn from playing pool which might be applicable to project work?

  1. Standard pool is played with fifteen colored balls (not counting the cue ball). Diversity within teams is a source of strength. Yes, it might make the storming and norming phases of team development more challenging, but higher performance, creativity and resilience can be the rewards for persistence.
  2. No two pool tables play exactly the same. Until we understand the unique attributes of a given table, making assumptions based on previous games played on different tables is likely to get us into trouble. With our projects, while historical data can be relevant, we need to understand the specific context of a project to avoid using the wrong tool or technique.
  3. Define the rules of play with your opponents. There are some generally accepted rules for playing pool, but certain practices might vary by who you play with. There are generally applicable principles for project delivery but work with your teams to develop working agreements and ways of delivery which are best suited to them and the needs of the project.
  4. Balance risk with reward. Yes, that tricky bank shot would look impressive to bystanders if you can make it, but if you miss, you might set your opponent up to run the table. But playing it too safe usually won't work out well either, especially if your opponent has a greater ability than yours! When working on projects, we need to find the right balance between playing it too safe and living on the edge. The former might result in mediocre business outcomes but the latter could result in project failure. This is why having good judgment is critical for project team members.
  5. It takes self-control to do well. It can be really tempting to apply full force on a shot, but you could end up scratching or sinking one of your opponent's balls. Being mindful about the amount of force required to make a given shot and leaving your ball well positioned for the next shot is important. Delivering challenging projects takes discipline and sloppy execution will hurt us in the short or long term.

Finally, "Take care of your cue ball, and it will take care of you". Support and lead your team and they will help your project succeed.

Posted on: October 28, 2018 06:59 AM | Permalink | Comments (9)

Does a Scrum Master have to be a techie?

Recently I wrote an article about the potential for a Scrum Master to take on additional roles. While I was teaching a class this week, one of my learners voiced a concern about Scrum Masters who didn't possess deep technical knowledge of the product solution. He felt that without this expertise a Scrum Master would run into difficulties in building credibility with the Development Team. He also believed that a Scrum Master lacking this knowledge might not know enough to ask the right questions when trying to understand specific technical risks or impediments and hence wouldn't be effective in clearing hurdles from the team's path.

Having been posed similar questions in the past with regards to project managers, I believe the answer is consistent for both roles. Some technical knowledge is necessary, but given a choice between a technically savvy Scrum Master who isn't an effective servant-leader and one who has some technical competency but does a much better job of improving interactions within and outside of the team to enhance value delivery, I'll always pick the latter.

To keep myself honest, I decided to double-check my views against The Scrum Guide™. The only activity listed for the Scrum Master role which could be interpreted as requiring technical competency is listed in the Scrum Master's service to the Development Team: "Helping the Development Team to create high-value products". I take this as meaning that a Scrum Master has sufficient competency to encourage technical excellence but isn't necessarily challenging specific technical decisions or contributing directly to solution design or development.

A few years back I'd written an article covering the pros and cons of a project manager being a technical subject matter expert. The same risks apply to a Scrum Master such as the potential for the Scrum Master making assumptions based on their past hands-on experience or the likelihood of their butting heads with team members when they disagree on specific technical matters.

As with all Scrum Team members, I would encourage Scrum Masters to become generalizing specialists and if they possess the capability and capacity to help the team achieve sprint goals, they should, but making this a default expectation of the role suggests that the supporting organization is not able to form a "whole" Development Team. Quoting The Scrum Guide™ again, "Development Teams are cross-functional, with all the skills as a team necessary to create a product Increment".

Servant-leadership is a lifelong journey of self-discovery and personal development. Let's not divert focus from that critical path by requiring Scrum Masters to also develop deep technical expertise.

Posted on: October 21, 2018 07:00 AM | Permalink | Comments (13)

Reduce risk by enhancing estimation

I’ve frequently said that project management is about bringing predictability to uncertainty and while a lot of my writing focuses on managing the impacts of uncertainty through effective risk management, estimation is another area where uncertainty needs to be addressed.

If you are fortunate enough to be managing projects where sufficient historical data exists to account for nearly all sources of variation then I envy you.

For the rest of us, here are some estimation principles which should be applicable regardless of the project’s domain or specific context.

  • Use more than one estimation method: Consider this a form of hedging your bets. If you derive close to the same estimated value using different techniques, the likelihood that your estimates are significantly incorrect drops. Consider combining bottom-up and top-down methods.
  • Document and share assumptions related to the estimates: It’s always a good idea to have a second pair of eyes review estimates, but without understanding the underlying assumptions which those estimates were based on, it can be very difficult to provide quality feedback. If the assumptions are not documented, it eliminates your ability to identify proactively when internal or external changes might invalidate the assumptions & their associated estimates.
  • An estimate should never be provided as a single value: Without some understanding of the variation in the stated estimate, it’s impossible to manage the uncertainty resulting from it. This variation could be stated as a range or a confidence level.
  • Discourage multitasking during estimation: Estimation takes significant mental effort and if the subject matter experts involved are distracted, the quality of your estimates will suffer.  Consider breaking up the estimation process into more short meetings as one way to overcome this.  Also, avoid estimation right after lunch time or at the end of the working day as your team might be less focused.
  • Evaluate estimates across multiple dimensions: Just as it is helpful to use more than one estimation technique, it’s also valuable to analyze estimates in different ways to try to identify flaws. For example bottom-up activity estimation will give us detailed effort data at the work package level. But aggregating these estimates by resource role or by project phase will enable us to evaluate whether the ratio between roles or phases is logical.
  • Remove the person from the evaluation: It helps to have peer-level reviews of estimates without knowing who produced them. This sounds wrong, but no subject matter expert is omniscient and our positive biases about them might cause us to unconsciously miss estimation flaws.

Improving estimation is not a silver bullet to slay all sources of project schedule or cost variation but elevating project management capability is about evolution, not revolution!

(Note: this article was originally accurately estimated and risk reduced in July 2014 on kbondale.wordpress.com)

Posted on: October 11, 2018 06:59 AM | Permalink | Comments (22)

Risk Management is not an island!

Categories: Risk Management

Although the PMBOK Guide has individual chapters covering key project management knowledge areas, it also highlights the importance in an approach which integrates these knowledge areas in a pragmatic, tailored manner to fit the needs of a specific project taking into consideration organizational and team culture.

One of the most common examples of poor integration across the knowledge areas occurs with risk management.  Risk management needs be tied at the hip with other project management practices, but too often it is as isolated as a porcupine at a balloon convention.

What do I mean by this?

Risk is the embodiment of the uncertainty which is inherent in the DNA of projects.  Until all agreed-to scope has been delivered and accepted, risk does not disappear so why do we not connect the dots by referencing it in other key project management artifacts?

It starts with the charter – while expressing the desired outcomes and drivers for the project, there should also be coverage of the key sources of risk which could impede the realization of these outcomes.

It continues with other core planning artifacts such as stakeholder analysis documents and organization change management (OCM) plans – risks from the register should be referenced in specific stakeholder management plans and should form part of the rationale supporting your OCM strategy.

Risk drives variation in outcomes and hence the cost and time contingencies reflected in cost estimates and schedules should link back to specific risks in the register.  Risk responses for high severity risks should show up as line items in the schedule and should have been baked into your baseline budget.

Project changes should directly tie back to items in the risk register – closed and open risks.  Some project changes may eliminate certain risks – this is why one of the ways to implement the risk avoidance response is to reduce scope.  Other changes might introduce a whole new set of risks.  A well maintained risk register should be able to provide a forensic trail of project change.

Issue logs should also show evidence of traceability to risks – when known unknowns are realized as issues, linking those back to the originally identified risks provides the opportunity to assess whether there is a future likelihood of occurrence and can provide valuable input into post-project assessment of risk management practice effectiveness.

All decisions need to consider risk – analysis leading up to a decision should consider the risks associated with each option, and risk register updates should capture the uncertainties tied to the final decision.

Risk management is like quality – if you tack it on, the value derived is less than if it gets baked in as an intrinsic part of your overall project management approach.

(Note: this risk-free article was originally published on kbondale.wordpress.com in September 2014)

Posted on: October 03, 2018 07:00 AM | Permalink | Comments (17)

"Few people think more than two or three times a year; I have made an international reputation for myself by thinking once or twice a week."

- George Bernard Shaw



Vendor Events

See all Vendor Events