Skip to main content

Author: Kiron Bondale

Want to Know What You’re Playing For? PM Lessons Learned from Survivor

bondale Aug14In a previous article , I had suggested that there were project management lessons which could be learned from Star Trek (the Original Series) and while Captain Kirk might not always have been the archetype for a good project manager, the challenges faced and the diverse backgrounds, skills and personalities brought by the crew makes the analogy to project management reasonable.

At first glance, it might seem to be a much harder stretch to consider the TV reality show Survivor as a source of useful project management practices. After all, the show centers around a competition to win an individual prize so what parallels could be drawn to the project world where collaborative, aligned effort to meet common outcomes is required?

While this is true, the human dynamics are what makes the show interesting and those provide the source material for some useful lessons which are applicable.

  1. Having a plan is important, but you should be willing to modify the plan as circumstances change: In more seasons than not, the overall winner has developed a plan within the first few days of arriving and has executed it diligently but has not let him or herself be slavishly locked in to it. We know that planning is a cornerstone of project management, but a plan is just a model of expected outcomes and if any of the assumptions or pre-conditions which supported your plan change, you should be willing to adjust it.
  2. Remove hurdles: While there is always the danger of their being perceived as a threat, generally the castaways who have supported and helped their team members in challenges and at the camp without letting their egos get the better of them have made it far, and if they make it to the final Tribal Council, are usually awarded the overall prize. A project manager will succeed if they focus on removing obstacles from the path of their team members.
  3. Clear, consistent communication is critical: Season after season we’ve witnessed what happens when castaways speak from both sides of their mouth or simply don’t keep their entire alliance in the know. Fear, uncertainty and doubt festers and this usually concludes in the castaway being voted off the island. It’s not enough that the leader is speaking to all of their alliance – the message needs to be consistent so that there is no paranoia when it’s time to go to Tribal Council. If project managers hoard information or are inconsistent in their messaging, they will quickly lose the trust of their team, key stakeholders and eventually, the customer.
  4. Use the right tool for the right purpose: While some castaways use school-yard rules or play favorites to decide who is going to perform which tasks on challenges, the consistently successful ones are those who carefully assess the skills required and appropriately assign owners. On projects, it may seem more convenient or less stressful to assign critical tasks to your friends or even to perform these tasks yourself, but this will alienate the rest of your team and may result in project failure.
  5. Learn lessons from the past: Castaways who learn from the mistakes made from other contestants on previous seasons and try to apply these lessons will usually do well. On the other hand, repeat castaways who double-down on their previous strategies usually end up getting ousted far sooner than they had been originally. The key is to understand the context of the lessons and to apply them appropriately – blind imitation can be as lethal as ignorance of these lessons. Completed projects are a valuable source of knowledge if one is willing to take the time to assess the applicability of the lessons to their specific circumstances and adapt them accordingly.
  6. Recognize the contribution of all team members to your success: An important ritual in Survivor takes place on the last show of each season when the final castaways take a walk down memory lane discussing the personality and contributions of each of the competitors who did not make it to the final challenge. It is important to reflect on the value brought by each team member and to recognize it in some fashion before the project ends.
  7. You got to know when to hold ‘em, know when to fold ‘em: Rarely are sole Survivors those who tried to win each and every reward or immunity challenge. Such bravado saps the energy of the team or individual such that they have nothing left to give when a critical challenge takes place. Too often, project managers lose sight of the big picture and focus their team purely on achieving the next milestone even though that might jeopardize more critical deliverables further down the road.

If you ignore these lessons, you may hear the fateful words “, the tribe has spoken, please bring me your torch!”

Don’t forget to leave your comments below.

When Setting Up PMOs, Timing is Everything!

bondale Feature July3When I wrote “I come to bury PMOs, not to praise them” in late 2009, I covered the challenges organizations experience in establishing PMOs and made the controversial hypothesis that many times, PMOs act more as a crutch enabling continued levels of poor organization project management maturity than as the vehicle to raise maturity. At that time, my point of view was vehemently opposed by some but over the past few years, I’ve started to see more evidence of this situation and have even seen other project management professionals start to share and communicate this belief.

Do I believe that PMOs should never be implemented?

Absolutely not, but I would advise careful consideration of an organization’s current project management maturity before proceeding with establishment of a PMO. While conditions such as committed executive sponsorship or sustained funding are commonly recognized as critical success factors for setting up PMOs, I’d like to propose that appropriate timing must be added to that list.

For many organizations, their first experience with PMOs occurs when they are still at a very early stage of introducing project management as a standard competency. The power structure of such companies is usually either functional or a weak matrix. The most common driver for setting up a PMO in such cases is to bring consistency and repeatability to project selection, prioritization & delivery practices.

Project managers (if any are on staff) report into functional areas and the establishment of the PMO might be viewed as an opportunity to centralize these resources within a single “service bureau”. If there are no project managers in the organization, the PMO might be setup purely as a Centre of Excellence.

This seems like a reasonable approach, doesn’t it? Having a staffed department responsible for project management should help to generate the visibility and focus necessary to initiate and sustain improvements.

Unfortunately, even if the PMO has been vested with sufficient formal authority to require that staff comply with its practices, the establishment of a separate department at a time when project management is still not truly embraced across the organization is likely to be viewed as divisive instead of a step forward. In fact, having formal authority may worsen this perception as staff will complain that they are following certain practices because they were forced to do so by the PMO and not because they truly embrace the benefits in doing so.

If there are project managers reporting in to the PMO, their work might become more difficult than it was before. While they may gain some benefits from co-location and direct peer support with other project managers, by not being part of the same functional team as their project team members, they are likely to experience greater challenges in escalating and resolving team member issues by themselves, and the functional managers they work with may be less helpful than before.

A different problem exists with regards to improving existing project management and associated practices – at low levels of organization maturity, most improvements will demand behavioral changes on the parts of the leadership team and mid-level managers, and a new PMO or its leader may struggle to get the necessary commitment and buy-in from these groups for such changes to be approved or to stick.

A very real risk of centralizing this task of project management maturation within the PMO is that if the winds of change start to blow against the new department, it’s less painful for the senior management team to shut it down as a failed “experiment” than if project management improvements are viewed as an organization-wide, cross-functional responsibility. Worse, even if the PMO is not shut down, its role and authority may be sufficient marginalized to a point where capable PMO staff leave the organization.

So when is the right time to set up a PMO?

Obviously timing varies from company to company, and some companies might never be mature enough to benefit from a staffed PMO, so here are some organization-level prerequisites that should be met.

  1. Basic project management, staff capacity & skills and work allocations practices exist and are being consistently followed by all functional areas.
  2. A basic work intake process exists and is being effectively executed by governance committees such that low-value, discretionary projects don’t divert valuable resources from strategic or non-discretionary projects.
  3. Functional managers have demonstrated appropriate behaviors in supporting project planning & execution. In addition, most functional managers have also led cross-functional projects following standard project management practices.
  4. Project sponsors are appropriately selected considering both capacity and competency and fulfill their roles effectively.
  5. Project and portfolio monitoring and reporting is consistently done and the members of the senior leadership team hold themselves and their peers accountable for responding to escalated issues, actions, risks & decisions in a timely, effective fashion.

Once such foundational capabilities are in place and the leadership team feels they are sustainable, a PMO can then be the ideal catalyst to help an organization reach higher levels of PM maturity.

Ecclesiastes 3:1 “To every thing there is a season, and a time to every purpose…

Don’t forget to leave your comments below.

Team-Sourcing a Project Mission Statement Can Help to Build Your Team!

No one can argue that having a cohesive, focused team is critical to the success of a complex project.

The challenge for many project managers is figuring out how to make the whole greater than the sum of the parts. This difficulty compounds when team members are not solely working on your project – maintaining a sense of shared purpose is almost impossible when team members are frequently context switching between activities.

Creating alignment and developing a high performing team starts as early as the project kickoff meeting, but how do you reduce the likelihood of enthusiasm flagging as time goes on?

Assuming you have worked with your project sponsor to come up with an inspiring name for the project, that’s a good start. With the exception of confidential projects, there are few good reasons for baptising projects with code names, techno-babble or convoluted acronyms. A well-crafted name can help to align stakeholder perceptions and can reduce misconceptions about the purpose of the project.

Unfortunately as project names are usually defined before most team members have been assigned to the project, there might be little team building benefit to be gained from having an inspiring name.

While there are multiple exercises and games available to help build teams, a good project-focused exercise for all team members might be to develop the mission statement for your project. A good mission statement creates a sense of shared purpose and is a valuable tool to help answer the “What’s in it for me?” question which those affected by the changes implemented by a project might ask.

Mission statements have received plenty of well-deserved criticism in recent years, but most of these concerns relate to company mission statements. Organizations are expected to be permanent entities and depending on how the mission statement is used, and how specific it is, it could either constrain future direction or come across as trite or too generic to provide much benefit. Beyond this, there have been too many instances of companies that never lived up to the intent of their mission statements through a lack or violation of their core values.

In the project context, such risks are less likely to be realized – by definition, a project is intended to be a temporary endeavor focused on achieving a specific set of objectives, hence a project mission statement can help to reinforce the sense of shared vision which begins with a good project name. If the project morphs significantly over its lifetime, that can actually be a very good reason to discard the current mission statement and write a new one to help team members and stakeholders absorb the change.

What’s a good approach for your team to take when developing a project mission statement?

While you may be inclined to try to develop it within one session for efficiency reasons, there may be greater benefit in developing it incrementally over the course of a few meetings. This avoid the need for team members to try to force creativity and enables mental “refactoring” between sessions which should result in a better quality outcome.

It may also be challenging to convince the team to invest significant effort in a single meeting to work on something which they may not fully appreciate, but if you stretch that same effort out over multiple meetings it might be an easier sell. One way to do this might be to have the development of the mission statement as a regular ten or fifteen minute weekly team meeting agenda item.

Here’s one way to go about developing a project mission statement over multiple sessions:

  1. Provide the team with a basic understanding of why a mission statement is valuable and what are the attributes of a well written mission statement. This information can easily be found by a simple Internet search, but some of the links I’ve found helpful include:
    1. http://www.kinesisinc.com/branding/how-to-write-a-powerful-mission-statement/
    2. http://www.fastcompany.com/1400930/how-write-mission-statement-isnt-dumb
    3. http://www.inc.com/ss/5-tips-on-developing-an-effective-mission-statement?nav=river#0
  2. Facilitate a brainstorming session focused on identifying themes or dynamic, action words related to the project and its outcomes.
  3. Using this list of themes or action words, have each team member come up with at least one (but no more than three) prototype mission statements.
  4. Have each team member vote for the prototype statements they like and then have them identify the phrases within the top ranked sentences which resonate with them. Finally, have a few team members try to construct a new statement which tries to incorporate as many of these phrases as possible.

How will you know if you have developed a good project mission statement?

Have a few team members say it aloud, and watch their expressions as they do so. If they are animated, smiling and enthusiastic, you’ll know it’s right!

Don’t forget to leave your comments below.  

Right-Sizing Project Manager Allocation to Projects

Bondale FeatureArticle May1A common question that arises during project initiation is what is the optimal percentage allocation of a project manager to the project to ensure the “right” balance between cost and risk. This question should be distinguished from the determination of how much project management effort in total is required since multiple staff will participate in project management activities over a project’s lifetime.

In a billable project, this question often generates significant “lively” discussion – depending on the customer’s project management maturity level and the desire of the sales team to win the business, it can sometimes be a tough sell to ensure there is sufficient allocation of effort and funding for the project manager. However, even in cases where the project effort is not being charged to someone, it is possible that there may be preconceived notions regarding what is a reasonable allocation of time.

Most of you will know that the only right answer for most project management scenario questions is “it depends” and this is no exception. Although there is no single formula to help you calculate how much of a project manager is needed as this can vary from as low as 5% to full-time allocation, it may be helpful to understand the factors which could affect involvement.

  • Number of distinct key stakeholder groups – stakeholder management is a critical responsibility for project managers as evidenced by the addition of stakeholder management as the newest knowledge area within the 5th edition of the Guide to the PMBOK. The greater the number of stakeholders or the greater the divergence in expectations and desires amongst them, the greater the amount of effort that needs to be spent by the project manager in gaining alignment and in regularly keeping these stakeholders apprised about the project’s progress.
  • Magnitude of uncertainty – the more conceptual a project’s scope or the more innovative the approach or expected outcomes, the greater the effort required on the part of the project manager to facilitate scope definition, manage changes to scope and support decision making.
  • Magnitude of slack in project constraints – whenever a project has an extremely tight budget or a very aggressive timeline, a project manager will likely be spending a lot of time in ensuring that overruns don’t occur, especially if the project is being managed using a traditional or waterfall approach.
  • Number of team members that the project manager has to directly manage – if a hierarchical structure has been established whereby the project manager allocates work or gets progress or issue updates from a few work package leaders, the project manager will need to spend less time working directly with individual team members and this will help to reduce their work management effort.
  • Level of organizational project management maturity – in companies where team members, functional managers and other stakeholders understand what’s expected of them when working on or supporting project work, project managers are able to focus on project management. In lower maturity organizations, project managers often end up spending their time “filling the white space” to ensure their projects remain on track. While this activity cannot be considered strictly project management, it is necessary and effort on the project manager’s part should be allocated for it.
  • Magnitude of multitasking performed by team members – if team members’ time has been fully committed to a project, the project manager will spend less time in resolving availability challenges with these team members and with their functional managers. The greater the degree of multitasking performed by team members, the more time has to be spent in negotiations and course corrections to keep projects on track.
  • Heaviness of the project management methodology – the more onerous the mandatory project management practices of the organization, the greater the effort that the project manager will expend in managing the project.
  • Multi-dimensional size of a project – for the most part, larger projects usually require more effort on the part of the project manager. On the other hand, it might be possible for a project manager to spend very little time in managing a high cost project if the majority of the costs are resulting from the purchase of a single component. Similarly, a long duration project may have very little complexity and a minimal sized team and not require significant effort on a project manager’s part. However, when multiple attributes of the project are large, project management effort will increase.

While this list might not eliminate disagreements regarding the appropriate allocation of a project manager to a given project, it should help to make those discussions more objective.

Are there any factors which I have missed or can you come up with a formula that combines these to provide a good rule of thumb – if so, please provide your comments below!

Don’t forget to leave your comments below.

Overcoming Biases to Improve Project Risk Management Effectiveness

Bondale FeatureArticle April17Risk management is a project management knowledge area which is very susceptible to individual biases. If not acknowledged and managed, these biases can significantly impact the value realized by taking a consistent approach to risk management.

A common instance of such biases relates to risk impact. Most practitioners are familiar with the relationship between tolerance to a risk and its perceived impact – low levels of impact are likely to be highly tolerated, but as impact increases, we reach a tipping point after which even incremental increases in perceived impact will result in a dramatically reduced risk tolerance, and often times, the cure may be worse than the potential of the disease.

A very tragic example of this took place within the first year following the 9/11 terrorist attacks. A drastic reduction in airline passenger volume in North America was mirrored by a significant increase in the number of road fatalities as tourists chose to employ an alternate, statistically riskier method of travelling.

Media also helps to elevate our fears beyond reason – many will recall that the summer of 2001 was dubbed the “Summer of the Shark” due to a few highly publicized shark attacks, and yet, at year end, the number of shark-related attacks was no greater than in most years.

Risk management training covers the need to assess risks from more than just one dimension, but knowledge of such practices doesn’t help us if we let our natural (but prehistoric) “fight or flight” reaction drive our risk response.

Dan Gardner’s tag-line for his 2006 book Risk captured the essence of these biases best: “Why we fear the things we shouldn’t – and put ourselves in greater danger”.

In the project context, we are usually not having to manage impacts of life and death, but the same behaviors persist. Think back to the last risk qualitative analysis session you participated in – did you feel that there was the same amount of time spent discussing lower impact risks as was spent on the higher impact ones in spite of their likelihood of realization?

You may question why such biases should be of concern as long as there is sufficient air time given to identifying and assessing risks. Unfortunately, these biases usually impact the most important step in risk management which is the development and execution of risk responses. Identifying and communicating risks is valuable, but if that is where activity ends, all we have done is to change “unknown unknowns” into “known unknowns”.

It is important to realize that the project team are analogous to the media when it comes to key stakeholders – where focus goes, energy flows. Risk response owners are rarely likely to participate in risk sessions themselves, hence they are relying on the quality and objectivity of the output and requests made to them. If insufficient highlighting is done of low impact, but higher probability risks, little is done to respond to them and such risks get realized, sometimes repeatedly. The net impacts to cost or schedule resulting from such repeat occurrences may be significant – the project version of creeping normalcy!

So what are some of the ways to deal with natural biases when assessing and communicating risks?

  1. Use an unbiased risk facilitator – trying to play the dual role of project manager and risk workshop leader can be very challenging as we have “skin in the game”. The benefit of soliciting assistance from a facilitator who is not directly involved with the project is that they can identify negative group-think or can call out biases without perception of prejudice. This doesn’t always mean requesting additional staffing from your corporate PMO or having your project take a financial hit by bringing in a third-party consultant – it could be as simple as establishing a relationship with one of your project manager peers such that they will facilitate your risk session while you support them in theirs.
  2. Once bitten, twice shy – while a low impact, high or moderate probability risk presents a lower priority than a high impact, low or moderate probability one, if the lower impact risk has been realized previously on the same project, that should justify it being moved off a watch-list.
  3. Step back to gain perspective – it can get too easy in a risk analysis session to get caught up in working on the “sensational” risks within your project’s risk register, so once the session is over, review the project risk portfolio as a whole and identify whether sufficient effort has been spent on the less dramatic ones. If you find that there does appear to be an imbalance in emphasis, there is likely some value in holding a separate session to address the ones which were perceived to have lower priority.

Jurassic Park captured the danger of risk tunnel vision well.

Volunteer: That doesn’t look very scary. More like a six-foot turkey.

Dr. Alan Grant: A turkey, huh? OK, try to imagine yourself in the Cretaceous Period. You get your first look at this “six foot turkey” as you enter a clearing. He moves like a bird, lightly, bobbing his head. And you keep still because you think that maybe his visual acuity is based on movement like T-Rex – he’ll lose you if you don’t move. But no, not Velociraptor. You stare at him, and he just stares right back. And that’s when the attack comes. Not from the front, but from the side, from the other two raptors you didn’t even know were there.

While your project team or risk response owners might be predisposed to focus on T. Rex, don’t let them forget about the Velociraptors!

Don’t forget to leave your comments below.