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

What's blocking your benefits realization?

Is your project information system of record the grapevine?

What's in YOUR sprint backlog?

Lessons in agility from wine tasting…

Control partners should have skin in the game!

Organizational team culture – the Achilles Heel of concurrent project management?

I attended a thought provoking session at PMI’s 2010 Research & Education Conference which covered factors necessary for project managers to successfully manage multiple concurrent projects.

The research was done based on a single large financial organization focusing on their IT project portfolio.  However, the findings from the research align very closely with anecdotal evidence from past clients and industries I’ve worked with.

The top two factors (in order of priority out of a set of five in total) identified as contributing to effective multi-project management were:

  • Teamwork oriented culture (organizationally)
  • PM competency

The second factor is no surprise – good staff can overcome bad processes and tools to deliver expected results so long as they are pointed in the right direction and suitably motivated!

The first factor is less obvious, especially since it trumped other factors including consistent PM process & methodology, sufficient & sustainable people allocation and consistent practices for selecting & assigning PMs to projects.

However, think about the challenge of managing multiple projects when you DON’T have a good teamwork oriented culture.  There will likely not be individual commitment to work products, reward for performance, open communication & team work.  If these attributes are not present, a PM spends a significant amount of time escalating people performance issues, trying to motivate disengaged team members and chasing after “invisible” stakeholders and sponsors.  While this is aggravating on even a single project, a PM with sufficient experience and influence can still succeed.  However, when managing multiple concurrent projects, the PM does not have the luxury of time to focus on this and this will impact their overall effectiveness.

Understanding that the need for concurrent project management is not likely to go away anytime soon, organizations need to ensure that they increase their PMs odds for success by fostering a suitable organizational teamwork oriented culture.  This could start by introducing team member evaluations tied to performance on projects, providing basic PM training for all team members, and requiring commitment to accountability for all staff.

(Note: this arrow was originally shot in July 2010 towards the target of kbondale.wordpress.com)

Posted on: December 19, 2018 07:00 AM | Permalink | Comments (6)

Six reasons to not punt kickoff meetings

Holding a kickoff meeting as the first “real” event on a project should be a fait accompli, but you’d be surprised as to how many projects launch without one.  This mistake is growing in frequency as the proportion of projects with virtual and/or global stakeholders & team members increases.

The causes for skipping kickoff meetings could include:

  • The project has been “on hold” or pending resource availability for so long, that there is no patience to do a true kickoff as everyone just wants to “do it”.
  • Everyone is so busy that it is impossible to schedule everyone’s time (especially across international time zones) to hold it.
  • So much effort has gone into the pre-project justification or sales work of developing a business case or negotiating the Statement of Work or contract that the kickoff is perceived as an academic activity.

To counter these excuses (because that is really what they all are!), here are some legitimate benefits of holding a proper kickoff meeting (preferably in-person):

  1. First and foremost, it’s the best opportunity for the project sponsor to present the vision and purpose for the project to the overall team (many of whom might not have been assigned during the pre-project phase) and to sell them on the benefits the project will bring to the organization and themselves.
  2. It’s a chance for the project manager to review project rules of engagement with all stakeholders and team members, and to be able to get the project sponsor to back him/her up visibly!
  3. It’s an opportunity to have a very quick, informal “fear, uncertainty & doubt” – the formal risk identification session will likely come later, but this meeting does give the PM the chance to start to understand the risk biases of project participants.
  4. While not a formal planning session, it can be used to voice and discuss assumptions and constraints to ensure they are in fact, valid.
  5. It presents the PM with the first real chance to see the body language and interpersonal behaviors of the team members and stakeholders.  If the PM has not worked with this group before, long running department or individual conflicts might start to become apparent.
  6. It starts the team development process in (what should be) a non-threatening and neutral environment.

Skip your kickoff meeting, and your project could end up as flat on its back like Charlie Brown!

(Note: I originally punted this article downfield in February 2011 on kbondale.wordpress.com)

Posted on: December 12, 2018 07:00 AM | Permalink | Comments (13)

Projects are like springs…

Some of our greatest achievements are realized through the willingness of people to strive for what seems to be impossible. Without this will, we likely would not have reached the moon or split the atom.  But constraints are one of the most important elements of a project. They are the gatekeepers on what is and is not possible.

So what happens when decision makers insist on trying to deliver fixed scope with unrealistically low timelines and resources?  A common outcome is that something gives. Scope is only partially delivered, quality suffers or schedule and cost baselines are exceeded.  What’s interesting is that when such project overruns are analyzed, many times we see that the final actuals are in fact fairly close to what the initial estimates were.

Is this a self-fulfilling prophecy on the part of team members? 

Sometimes it can be!

If the team is not convinced that their objective is achievable, there’s a good chance that they will fail.

But in many instances, it is caused by the analogy I’ve used in this article’s title – like a spring, a project can be compressed.  But after a certain point, sufficient linear restoring force has built up that the spring will return (usually violently!) to its original size.

But let’s not ignore the reality that a project needs constraints.  Without these, it consumes resources indefinitely without delivering proportional value.  Like a spring, you can stretch a project to a defined extent, but once elastic potential energy has exceeded the spring’s design, it will either snap or be permanently deformed.

As project managers, one of our responsibilities is to facilitate appropriate decision making.  If your attempts to convey the impossibility of a requested project scenario are falling on deaf ears, leverage the power of analogy, and illustrate your concerns by using a toy spring.

(Note: I stretched this metaphoric spring in January 2012 on kbondale.wordpress.com)

Posted on: December 05, 2018 07:45 AM | Permalink | Comments (14)

Improving organizational culture through retrospective recognition

After observing the frenzied shoppers competing with one another at Black Friday sales this week, one might be forgiven for forgetting that Thanksgiving was originally about expressing gratitude.

The Scrum Guide doesn't specifically identify expressions of appreciation as a key ingredient of sprint retrospectives, but it does list activities which can incorporate appreciation such as the inspection of team member interactions and the role of the Scrum Master in encouraging the team to not only be more effective but to also have a more enjoyable time in the next sprint.

Retrospective facilitators often encourage participants to identify what went well or what they liked. This provides a good opportunity for team members to appreciate the efforts of others during the past sprint in a genuine, heartfelt manner.

Similar to identifying opportunities for improvement, team members should not only recognize big accomplishments but also small ones which can add up over time. We are quick to recognize a team member who dropped what they were doing to help us out for a couple of hours on a really tricky issue, but how about that team member who took us out for a coffee because they happened to notice that we seemed to be particularly stressed on a given day?

Just as with providing constructive feedback, we shouldn't wait for an upcoming retrospective to recognize one another, but this ceremony provides a good opportunity to provide belated thanks to those whose efforts made a difference over the past sprint. A Scrum Master might introduce this practice in one retrospective using chocolates or some other small gift to be given by team members to those whom they wish to recognize. In subsequent retrospectives, the team can identify novel ways to do this to keep the practice fresh.

A recent Washington Post article described how kindness can be contagious.

Anyone who has participated in or initiated a "pay it forward" chain would likely agree with the article's author. When someone verbally appreciates what we do, we feel an urge to do likewise. Expressing positive sentiments to one another on a regular basis might incrementally improve culture within our teams, our departments and eventually our overall organization.

Posted on: November 25, 2018 07:00 AM | Permalink | Comments (9)

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)

"If you think you can, you can. And if you think you can't, you're right."

- Mary Kay Ash



Vendor Events

See all Vendor Events