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.

Agenda

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

• Schedule
• Changes
• Issues
• Risks

Preparation

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.

Attendance

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.

Focus

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.

Approach

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’.

Gratitude

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.

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?

The great Chinese military strategist Sun Tzu had it pretty much spot on:

Strategy without tactics is the slowest route to victory. Tactics without strategy is the noise before defeat.

Having a great strategy isn’t worth a whole lot to anyone unless it’s backed up by solid tactical execution capability – which means project management.  And no matter how good the project managers are, individual excellence in project planning and control won’t overcome cross-project resource overallocations and poor outcomes if projects are not strategically aligned and properly prioritized. The trick therefore is to unite the two in a strategic implementation framework.

The Missing Link

Properly connecting strategy and tactics involves the disciplines of portfolio and program management. This crucial linkage – often missing or incomplete – bridges the gap between the promise of strategy and the actuality of operational results. Portfolio management, most importantly, establishes executive oversight for project selection, project prioritization (see Project Prioritization Criteria), funding and resource allocation (see The Goals of Portfolio Management). Program management provides the governance and architecture for defining, planning and controlling broad strategic initiatives comprised of interdependent projects (see Project or Program).

Important Questions

The hard part of course is putting this all into practice. A few fundamental questions can help maintain the right focus; for example:

• Do we know how strongly each declared strategy is supported by our current projects?
• Do we believe we have the optimal mix of projects to fulfill our strategy – taking account of various business needs, execution constraints and operational imperatives?
• Do our strategic programs clearly lay out the relationship between objectives, projects, deliverables and benefits?
• Is each program properly coordinating the component projects using a single integrated master plan?
• Are cross-project resource contentions identified in advance and resolved proactively before progress is impacted?
• Have success metrics been identified for projects, for programs and for portfolios, and are they being tracked and reported systematically?

Baselining a project plan is essential to facilitate accurate tracking of project progress. Project schedules that lack baselines make progress reporting a combination of guesswork and blind faith, yet it is surprising how often this occurs.

Setting a baseline is typically the final act of planning. It should only be done once the sponsor has approved the project plan for implementation, thereby signifying the transition of the project from planning to execution. All documents that reflect the approved project plan should be designated as baseline records, but most importantly it is the detailed schedule that needs baselining to facilitate accurate tracking of progress.

Two Pre-Steps

Before actually setting the baseline, there are two important pre-steps:

1. Ensure the schedule has been quality checked
   This includes validating the WBS (see A Checklist for Work Breakdown Structures), and verifying the integrity of the duration estimates, dependencies, constraints and resource assignments
2. Obtain approval of the schedule from the project Sponsor
   This should include a review of all major incremental milestone dates and the level of schedule risk associated with each – not just the final deadline.

Quick and Simple

Saving a baseline in Microsoft Project is a quick and simple thing to do and here’s how:

• Select either Project, Set Baseline… (Project 2010), or
  Tools, Tracking, Save Baseline… (Project 2003/7)
• Click to select Baseline
  (rather than Interim plan which is normally used for saving draft versions of plans)
• Select Entire Project
  Microsoft Project now copies all current schedule information such as Start/Finish dates, estimates and costs into Baseline fields so they can be used as comparisons with Actual information once the project gets underway (see image below).
• Select View, Tracking Gantt to see the baseline schedule displayed together with the current schedule.

An updated project schedule showing current progress on each task (Start/Finish columns, blue/red bars) compared with the original baseline (Baseline Start/Baseline Finish columns, light grey horizontal bars). Also shown is the total slack on each task (positive slack/blue horizontal lines displaying the late schedule, negative slack/red horizontal lines).

Re-Baselining

Microsoft Project provides for re-baselining via the “Baseline 1”, “Baseline 2” etc. dropdown selections in the Save Baseline dialog. The options for displaying the Gantt bars for any baseline can be set up in Format, Bar Styles (click Insert Row to assign bar and color options for any re-baseline, e.g. for Baseline 1 select “From” as Baseline1 Start and “To” as Baseline1 Finish).

However, once set, the baseline schedule should only be altered (re-baselined) under extreme circumstances (such as a Sponsor-approved major scope change), that render the original baseline schedule obsolete and no longer a meaningful target to aim for and report progress against. Continually re-baselining is not project management – it’s playing politics.

Much more than a Memory Jogger

Among all the tools at our disposal for managing projects, programs and portfolios, checklists are perhaps the simplest and most productive means of building consistency in work practices. Checklists are useful in almost every field of human endeavor, and in particular where repeatability and systematic action drive performance. Yet they are still much under-used in the planning and managing of projects.

As a good friend of mine, Nick Gogerty, recently posted in Checklists, hedge funds and human behaviour, checklists provide for better outcomes – both individual and team. And the more collective experience that goes into the creation of a checklist, the more value it will have. Well thought-out checklists are indispensable wherever there is a need for control, risk reduction, rapid response or safety – as doctors, flight crew, investors and others the world over can testify, the checklist provides efficient guidance, increased confidence and focus under stress (see The Checklist Manifesto – How to Get things Right - a great-sounding read that Nick highly recommends).

Twelve Checks for Planning

Likewise for project managers – checklists can be used for all manner of things. Where training builds knowledge, checklists facilitate application.  Here is a high level twelve-point checklist for use during project planning:

1. Have the needs and concerns of all key stakeholders been considered and resolved?
2. Does the project have an overall approved mission statement defining the scope, schedule and resources/budget?
3. Has the relative flexibility among scope, schedule, resources and budget been determined?
4. Have all project deliverables been identified and described in detail with unambiguous completion criteria?
5. Are roles and responsibilities defined and agreed upon for all project team members?
6. Has an appropriately detailed work breakdown structure been created with input from key team members?
7. Has a credible schedule with identifiable critical path and late schedule been developed from the WBS and optimized within the project constraints?
8. Have milestones been included in the schedule to track major events, completed phases and/or deliverables and external dependencies?
9. Have workload commitments been identified for each week of the project and agreed to by team members and their managers?
10. Have response plans been developed for the most significant threats to project success?
11. Has a change management process been defined and agreed to by all key stakeholders?
12. Has the governance structure for the project been established with an agreed sponsorship role and expectations set for review frequency and format?

One of the features of checklists is that they can be designed to extend hierarchically, such that a sub-checklist could be developed to facilitate any or all of the checks above (e.g. a stakeholder analysis checklist or a risk management checklist). The PMI, training firms and PMOs would do well to promote checklists more strongly – project managers like to use checklists; not many want to read through an overweight methodology. And managers like checklists because they improve quality and instill consistency. For the converted, I’ll have more checklists in future posts.

Project Management and Culture - not always love at first sight

One of the most critical success factors in implementing project management is ensuring the right fit of processes and systems with the culture of the organization. Yet culture is such a wonderfully complex and seemingly amorphous thing that it can be hard to know what “fit” really means if we can’t define the characteristics and boundaries of the firm’s culture.

The Re-Engineering Alternative by William Schneider provides both a fascinating insight into organizational culture as well as a practical toolkit for determining your own company’s core culture. This is not a new book but it is a gem. Designed as an aid to improving organizational effectiveness by leveraging cultural norms and behaviors, Schneider describes how peeling back the layers of any organization will yield one of four dominant culture types.

Understand Your Culture

Each culture is defined in fine detail by comprehensively describing the leadership and management styles, strengths and weaknesses, structure, relationships and decision-making attributes that characterize them. Discovering the differences will help explain why organizations operate the way they do and, by extrapolation, why project management has to be tailored to be sustainable. Schneider terms the cultures as:

• Control - structured, domineering, task-oriented
• Collaboration - trust-based, empowering, people-centric
• Competence - achievement-oriented, impersonal, excellence-driven
• Cultivation - potential-fulfilling, creative, informal

If you’ve worked in a variety of culturally diverse organizations, you’ll quickly recognize the distinctive traits of each of these four cultures that are described in the book so clearly and with plenty of examples.

Culture Limits Execution of Strategy

As Schneider rightly points out, culture limits strategy. And since culture sets expectations, priorities, managerial practices and communication patterns, it also limits the execution of strategy – and therefore projects. Culture ultimately defines how work is planned, organized and managed – which is why it is such a crucial consideration in any effort to improve enterprise project management.

Knowing the latest dates that we can start and finish tasks without impacting the overall project schedule is key to effective time management, especially for those projects where schedule is the least flexible component (see Flexibility Matrix).

Like the critical path itself however, Microsoft Project does not display this information by default. But we can easily set up the display options to reflect the late dates as in the example below:

Here’s how we configure this. First we display the critical path:

• From the menu, select View, Gantt Chart
• Then click the Gantt Chart Wizard button on the Formatting toolbar
• Select “Critical Path”, then Finish, Format It, Exit Wizard.

The critical path tasks are now visible in red. Next we set up the late schedule for the noncritical (blue) tasks:

• On the menu, select Format, Bar Styles
• Then click Insert Row to add a row just above the Critical Path display row (note that inserting a row at the top of the list may not work)
• Enter “Late Schedule” for the ‘Name’ and select your preferred bar styles for the ‘Appearance’ - (in the example above I used a navy horizontal line bounded by small triangles)
• Select “Normal, Noncritical” for ‘Show For … Tasks’
• Lastly ensure that you select ‘From’ “Late Start” and ‘To’ “Late Finish”
• Click “OK”

Now you should see the late schedule bars showing for the noncritical tasks indicating the latest each task can start and finish.

Useful Information

Showing the columns for Total Slack (the difference between the early and late dates) and Free Slack (how long a task can be delayed without delaying a sucessor task) as in the simple example above tells us the following:

• The critical path runs through tasks E, G, J
• The noncritical tasks have varying total slack
  • Tasks B, C, H, L have only 2 days, so are near critical and should be monitored closely for any slippage
  • Tasks A, K have 7 days
  • Task F can be delayed by up to 11 days before the project finish date is impacted
• Tasks B and C have zero free slack so any delay will immediately impact their successor tasks

Track the Slack

Knowing not only which tasks are critical and which are not, but also how much float or slack there is on each non-critical task, helps us prioritize work (according to slack value) and monitor trends in schedule variance (changes in slack week-to-week).

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

It doesn't have to be complicated

It shouldn’t be hard but giving thanks to team members doesn’t always come easy to project managers. Yet those two small words “thank you” can sustain an individual’s drive and enthusiasm long after the project is completed.

Whether for overcoming adversity, going the extra mile for the customer, infusing the team with drive and energy or just plain hard work, thanking contributors for all forms of outstanding performance should be high on the daily watch-list of any project manager.

Acknowledgement should be expressed in the following ways:

Honestly

• If it doesn’t come from the heart it won’t be valued. And mixed messages, such as conflicting verbal and non-verbal communication, imply insincerity – thanks that will be quickly discounted by its recipient.

Consistently

• Recognizing one person’s achievement but overlooking another’s is the swiftest way to divide a team. Staying in touch with the challenges on the ground and paying attention to what’s really going on in the team is crucial.

Openly

• There’s no point in keeping gratitude behind closed doors. Proclaim it, proudly. Thanking someone publicly, in front of the team, demonstrates how important it really is and sends a meaningful message that inspires and motivates.

A little thanks goes a long way.

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)