Posts Tagged ‘Risk’

PostHeaderIcon Making Team Meetings Productive

Avoid a Disappointing Outcome

Much time can go to waste in project review meetings. Mostly this is due to: (a) poor agendas, (b) poor control and (c) poor preparation. The project manager has responsibility for each of these and should recognize each meeting as an opportunity to improve project performance, enhance personal credibility and motivate the team – all as timely and efficiently as possible.

A fine balancing act is typically needed in maintaining meeting focus on project status while ensuring an appropriate environment to re-align the team and foster a positive outlook. Here are some guidelines to keep meetings productive, on-point and on-track.


Set a clear agenda and stick to it-
e.g. Review the:

  • Schedule
  • Changes
  • Issues
  • Risks


Ready the data before the meeting-

  • Don’t waste valuable meeting time getting status updates from team members. Collect this information one day beforehand to allow time for updating the schedule, analyzing variances and identifying specific items needing team review, all in advance of the meeting. Provide team members with any pre-reading that could reduce meeting duration.


Make attendance mandatory-

  • Allowing members to skip meetings without a really good reason will hamper decision-making, dilute communication and weaken the team. Ask the Sponsor to send out a message reinforcing expectations on attendance – and let him/her know how well they’re being met.


Keep meetings relevant and concise-

  • Keep control of discussions, stick to the agenda, ensure cell-phones stay off and stop any side-conversations promptly. Actively solicit inputs from the team on their perspectives of likelihood of success – and probe any concerns thoroughly. Secure clear commitments on actions and due dates.


Rigid or relaxed to suit the culture–

  • It’s a subtle thing but get it wrong and your perceived credibility as an effective leader will be impacted…as will the team’s motivation and commitment. Some cultures respond better to informal meetings, lots of humor and a relaxed environment than others. Know your team members and your organization’s culture.

Virtual Teams

Additional considerations-

  • If the team includes foreigners, speak slowly and avoid using idioms. (Obvious perhaps, but rampantly ignored). If time zone differences are severe, consider rotating weekly meeting times to spread the pain of early morning or late night calls. Consider asking virtual participants to connect into the meeting individually and separately to avoid the risk of co-located groups getting into their own side-conversations while ‘on mute’.


Give thanks-

  • Be sure to take time to express appreciation for any and all noteworthy efforts honestly, openly and consistently. Whether for the efforts of a single individual or a group, conveying words of thanks and using simple positive reinforcement rewards are powerful motivators.

PostHeaderIcon A Checklist for Team Readiness

Just because the plan seems complete and you think you’re ready to go doesn’t necessarily mean that you are. Apparently small details left unattended as the project is poised for execution can become the source of re-work, frustration, delays, conflict and dysfunctional team behaviors later on in the project.

16 Team Readiness Checks

Here are some of those often forgotten pre-launch checks:

  1. Have the overall project objective and scope boundaries been shared with all team members?
  2. Have all known gaps in resource expertise been resolved?
  3. Have clear roles and responsibilities been defined for each individual?
  4. Has real availability been validated with each team member and relevant line managers?
  5. Have time and effort estimates involved input from the team?
  6. Have the team agreed on who owns which deliverables?
  7. Have those owners specified completion criteria for each of their deliverables?
  8. Is the team aligned on deadlines, dependencies, constraints and risks?
  9. Is the project team ready, willing and able to execute the project according to the baseline plan?
  10. Have initial work priorities been communicated to the project team?
  11. Has a procedure for issuing weekly WBS task lists, actions and priorities to the team been set?
  12. Is the team aware of which tasks are critical and will actual slack values be communicated to task owners each week?
  13. Has the team been informed of how and when they should provide status updates?
  14. Has the team been involved in identifying risks and formulating response strategies?
  15. Have procedures for raising, escalating and resolving issues been defined and communicated?
  16. Does the team know how often project review meetings will be held and who should attend?

    PostHeaderIcon Ten Vital Items for Project Progress Reports

    There are countless variations on content for project progress reports but there are ten items that should be on every report:

    1 – Business Context
    Why does this project exist?
    Briefly summarize the desired business outcomes as a reminder to all of the rationale for doing the project – and include the names of the sponsor and customer.

    2 – Objectives
    What are the project’s tactical objectives?
    Always keep the schedule, scope and resource goals in view. The Project Objective Statement provides a concise way of describing these.

    3 – Flexibility Matrix
    Which is least flexible – schedule, scope, resources?
    Reflect the Flexibility Matrix on the report to remind stakeholders of the project priorities.

    4 – Schedule
    What is the schedule performance of the project?
    Identify variance of current progress and forecasts against the baseline schedule for key milestones, phases and/or deliverables. Better yet, include performance trends over the past few reporting periods.

    5 – Cost/Resources
    Is the project meeting cost and/or staffing targets?
    Point out significant variances with the plan such as staffing shortfalls or cost overruns.

    6 – Risks
    What significant risks exist?
    Highlight those risks of highest severity and in particular those with high impact that may occur soon.

    7 – Issues
    What significant issues remain unresolved?
    Identify the key issues and what is preventing their resolution.

    8 – Changes
    What changes have occurred?
    Identify any major changes that were approved and/or implemented since the last progress report.

    9 – Accomplishments
    What has been achieved?
    Capture the most important recent accomplishments such as completed deliverables, milestones that were met, or finished major work components.

    10 – Next Steps
    What major components of work remain?
    Indicate what the focus will be for the immediate future and set expectations of what will be reported on in the next progress report.

    Configuring these vital ten into a 1-page format is ideal for executive presentation. These items are of course in addition to the more obvious title and subtitle mentions of project name, report date and author/project manager name. (Surprising how often the obvious gets overlooked).

    PostHeaderIcon The Best Way to Identify Risks

    There are several methods for identifying project risks but the best approach involves the team (at least the core team members and any relevant SMEs and/or PMO staff) and considers the following:

    • History (review past projects of a similar nature – surprising how often this is missed)
    • Context (assess the stakeholders, implementation environment and constraints)
    • Boundaries (review the project’s SOW, scope and deliverables)
    • Details (review the WBS, dependencies, estimates and resourcing)

    The Nominal Group Technique

    To get optimum input on possible project risks, there is no better team method than NGT. It leverages the advantage of multiple perspectives, can be done relatively quickly and avoids all the pitfalls of brainstorming, which is over-used and usually poorly facilitated. Here’s how NGT works for risk identification:

    1. Each individual reviews history, context, boundaries and details (as defined above) and writes down their own list of possible risks – i.e. with no interaction between members
    2. With the team grouped together, all identified risks are then captured by going around the team, taking the first item on each person’s list, then around again capturing the second item and so on until all items have been captured
    3. Duplicates are removed from the consolidated list and descriptions clarified as needed
    4. Each person reviews all the risks captured and the team decides if any should be removed the listing, on the basis of being extremely unlikely AND with little or no impact

    Once this process is complete, the team can move to assessing the severity of the remaining risks, prioritizing them and defining response strategies to manage them.

    Lots of Benefits, not much Downside

    Using NGT is a great way of aligning the team on project risks. Its thorough, avoids groupthink, rapidly builds awareness, avoids jumping prematurely into risk analysis and prevents outspoken individuals unduly dominating the final risk list.

    PostHeaderIcon Uncertainty is Certain (the 4th Law)

    Plans are not crystal balls. They are at best a logical and reasonable perspective of the future but no more. Every project involves uncertainty and uncertainty implies risk. And there is no such thing as a risk-free project. I call this the Fourth Law of project management.

    All of which has a serious implication for project managers – the need to properly account for risk. The fact that plans are incomplete views of the future means they are always at least slightly wrong. Even if we correctly identify all the tasks and activities to be performed, errors will always exist in assumptions, duration and work estimates, task dependencies and so on.

    Most project managers appear to ignore most risks (witness the lack of risk readiness as evidence) . Yet threats can and do suddenly materialize. But sudden does not necessarily mean unpredictable. Experience and a little structured thinking can expose potential threats that we can get ourselves prepared for:

    5 Essential Steps to Managing Risk

    1 – Get Prepared

    • Determine how complex your project is and how much unmanaged uncertainty you (and the project sponsor) can tolerate, i.e. how important is risk management for your project? Then decide on the process you will use and brief your core team accordingly (risk management is not a solo effort).

    2 – Identify Risks

    • Review project documentation – business case, SOW, charter, plans (WBS especially) and assumptions to seek out sources of uncertainty, potential error and change. Wear the hat of Murphy – “If it can go wrong, it will go wrong.” Remember, this involves core team members, not just the PM.

    3 – Assess Risks

    • Evaluate each risk for (a) the likelihood of the risk occurring and (b) the potential impact to the project if the risk does occur. Rate the severity of each risk on these two dimensions. High likelihood and high impact means for those risks at least, response plans will be a necessity.

    4 – Develop Risk Response Plans

    • Evaluate alternative response strategies. Ask these questions: How could you avoid the risk? How could you reduce likelihood? How could you reduce impact? How could you transfer the risk to another party? Could you accept the risk with a just-in-case contingency or backup plan? If so, how would it work?

    5 – Monitor Risks

    • As the project progresses, risk monitoring should be a regular item on the agenda, week after week. Have any risks occurred? Are the response plans working? What has changed that might cause new risks?

    These are the essentials. Large complex programs will take these steps to a very deep and sophisticated level. But even the simplest of projects will benefit from the same basic steps. Scalability, as ever in project management, is the key.

    Here’s a good way to think about all this-

    Ignoring project risks is the first and biggest risk to the project.

    (See all 5 Laws summarized in The 5 Laws of Effective Project Management)

    PostHeaderIcon How to Describe a Risk

    Its always amazing how small things can make a big difference in the world of project management. Consider the describing of a risk:

    The Wrong Way

    Oftentimes we see a ‘shorthand’ approach used – for example, a risk captured simply as “Insufficient resources”. The danger (the risk?) of such a brief description is that it creates three problems:

    • We misinterpret what exactly was meant (Which resources? On which tasks? With what consequences?)
    • We may not correctly assess the risk’s importance because of the description’s ambiguity
    • We can’t remember what we meant when we revisit the risk log at a later date

    For these reasons, it makes good sense to describe a risk in a way that clearly states the possible situation and its effect.

    The Right Way

    A recommended approach is to write a risk like this:

    EVENT may occur WHEN, thereby causing IMPACT

    So rather than a bland, ambiguous risk statement such as “Lack of training, we drill down and explain clearly what is meant – maybe:

    “Competing work commitments may prevent staff attending the training, thereby slowing adoption of the enhanced project planning process.”

    Now its clear. We understand both the effect and its root cause. Clear statements of what we really have in mind when we identify risks promotes consensus in (1) understanding the risk, (2) assessing its importance, and (3) generates more creative thinking in the development of risk responses. A little extra effort for a big benefit.

    PostHeaderIcon Making Risk Management Real

    Of all the processes within project management, it would seem that risk management is the one that most often turns into a paper exercise. Lots of projects have lists of identified risks, some have plans to manage those risks but only a few properly integrate risk responses into the overall project plan.

    A Small but Crucial Step

    Creating risk logs and defining response strategies is a ‘non-productive use of valuable time’ if performed merely to satisfy management, increase comfort levels or just conform to company policy. Those documents will gather plenty of dust. What’s needed is for that information to become an essential component of the detailed schedule. This is a small but crucial step – and often missed.

    Here’s how to do it-

    1. Once the project risks are identified, define clear mitigation strategies – i.e. specific actions to proactively (a) reduce probability or (b) minimize or alter the impact of the risk occurrence.
    2. These actions can then easily be defined as “tasks” in a verb/noun format – which means they can, and should, be added to the project Work Breakdown Structure (WBS).

    In the example above, a section for Risk Management has been added to the end of the WBS task list in the Microsoft Project plan. Each of the tasks within that section is an explicit risk response activity. Each task will therefore be assigned an owner, linked into the schedule with appropriate duration and resource estimates, and then executed and tracked in just the same way as any other task in the schedule.

    Now, we have made risk management real. Its an integral component of the execution plan – not a paper exercise. Remember – if its not in the WBS, its not in the project.

    PostHeaderIcon Eight Questions to ask your Project Sponsor

    This might have been alternatively titled “Questions we are Occasionally Afraid to Ask”. Here’s the situation:

    You’ve been appointed to project manage a new initiative. You know that effective project sponsorship is a critical success factor and so you set up a meeting with the project sponsor.  You want to be sure you’re starting out with the right kind of backing. The sponsor wants to discuss the budget (or maybe golf) but first, you have some big questions you need answers to…

    1 – Do you understand your role?
    Its a fact – many project managers I meet complain that their sponsor has little idea about their role and responsibilities. You may need to help them out here.

    2 – Do you know what you want?
    There’s not much more frustrating than a sponsor who isn’t sure about what should or should not be included in the project. A fuzzy sponsor means you could be in for a long road trip of about-turns – do, undo, redo, …

    3 – Can I count on your support?
    Or more specifically – will you truly champion our project? This means advocating the project at higher levels, helping maintain visibility and interest in the project with key stakeholders, providing adequate funding and obtaining resources.

    4 – Will you be available?
    No doubt about it, sponsors are typically busy executives. This means their time is limited and they may be hierarchically or geographically remote. You DO need those face-to-face meetings. Lock them into their calendar.

    5 – Can you give me clear priorities?
    What are the primary project objectives? Which is least flexible – schedule, scope or resources? (Hint to sponsor- you can choose only one). Which is most flexible? Why?

    6 – Do you understand that project management is a discipline?
    In pushing to ‘just get it done’, countless projects ignore the importance of proper planning and systematic tracking… and pay a high price. A sponsor who doesn’t appreciate this means we’re already in trouble.

    7 – Do you know what a solid project plan looks like?
    The sponsor has to approve the plan that lays out what will actually be done- so it might make sense to ensure they actually have an understanding of what a good plan looks like. If necessary, give them a Plan Review checklist and an ‘Executive Briefing on Tactical Planning’ (so they know a WBS from a critical path).

    8 – Will you inspect what you expect?
    Not much point in a sponsor’s list of expectations if the relevant questions are never going to be asked. Generating information, reports and updates that don’t get reviewed is a fast track to morale hits and trust breakdown.

    If the sponsor answered these questions correctly, you’re likely to be in good shape. (Hint for sponsors- the correct answer is “Yes” to all questions). If not, then you just identified some additional risks to the project…

    PostHeaderIcon Credibility requires Detail (the 2nd Law)

    Most projects are underplanned. They’re already late before they start. For a host of reasons – the usual suspects include a lack of project management discipline, inadequate tools and training, unclear objectives, top-down influence, overworked and under pressure team members – projects get planned with insufficient detail.

    The reality is that detail is the basis for accuracy in all projects. Plans that lack appropriate detail can’t be believed. This is what I call the Second Law of project management.

    The consequence of a lack of detail is a project suicide spiral:

    Understate what’s needed… Misunderstand what ‘done’ looks like… Miss stuff out… Underestimate time and effort requirements to do the work… Overcommit resources to unrealistic schedules…
    Present bad news to customer.

    Breakdown Checks

    Without a credible plan, a project manager lacks credibility with the team and stakeholders. Only when we get to the detail is the full extent of work revealed, which means developing a great Work Breakdown Structure. Here are a few WBS must-do’s:

    • Ensure tasks are small enough so that-
      • Estimates of effort and duration are as accurate and credible as possible
      • Task durations are typically no greater than the time between progress updates
    • Define explicitly what ‘done’ means-
      • Especially for any task that is unfamiliar, complex or difficult to break down
    • Assign a single owner to each task-
      • Have them verify that the expected workflow minimizes likelihood of any missing tasks
    • Use a checklist of often forgotten tasks-
      • e.g. meetings, defect resolutions, reviews and approval cycles.

    They say the devil is in the details – and just looking for a chance to cause trouble. Good process and a little extra planning time will build protection.

    (See all 5 Laws summarized in The 5 Laws of Effective Project Management)

    PostHeaderIcon Ambiguity kills Projects (the 1st Law)

    Not so clear

    Ambiguity is the enemy of project success. Its one of the first things I instruct new project managers on. I call it the First Law in project management.

    Its not hard to find ambiguity in projects. Look closely at the objectives, the requirements, the scope definition and the schedule. Are they each as clear and as accurate as they can be? Most importantly, do we know what “done” really looks like? This is crucial. (Glen Alleman’s prolific and consistently excellent blog at Herding Cats has a host of outstanding posts on this – check it out). Each ambiguity is a potential source of conflict, rework and failure.

    Clarity Checks

    The antidote to ambiguity is clarity – here are a few items that must be on the ‘Clarity Checklist’:

    Leaving ambiguity unchecked simply increases project risk. The pursuit of clarity isn’t always popular because it makes people have to think ahead a little harder. But its necessary. So put on your flak jacket and go on a mission – seek out ambiguity and destroy it… before it does some damage.

    (See all 5 Laws summarized in The 5 Laws of Effective Project Management)