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:
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)
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:
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):
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)
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)
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.
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?
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.