pm-lotus by Howard Vaughan

Posts Tagged ‘Communication’

The Whole is the Sum of its Parts

Project scope is most frequently described in a narrative format, often termed a scope statement. While this may convey a broad sense of what the project will set out to accomplish, a narrative alone runs the risk of being at best insufficiently detailed and at worst ‘fluffy’ and incomplete with all the inherent dangers of ambiguity (see Ambiguity Kills Projects).

3 Steps to Clarify Scope

An effective definition of scope needs to include a formal description of the project deliverables. These are the primary outputs that result from the work performed – what will be there at the end of the project that is not there at the beginning. There are three steps to describing the deliverables completely:

1 – Identify the Major Deliverables
What are the largest, most significant outputs of the project?
These are the major deliverables, that when combined, should comprise ALL delivered outputs and reflect the full scope of the project. Since deliverables are “things” they should have noun or noun/adjective titles, e.g:

Release-Ready Software  |  Prototype Hardware  |  Trained Staff  |  Assessment Report etc.
– they are not activities with verbs (those will be defined later in the WBS).

2 – Describe Deliverable Features and Exclusions
What exactly will be delivered? What will not be included?
The Is/Is Not technique is the best way to define deliverable boundaries, by capturing the attributes that a deliverable “is” (or includes) and those that it “is not” (or does not include); e.g. for a deliverable “Business Model Analysis Report” we might have:

IS – Current marketing assessment, Competitor analysis, Customer needs study, etc.
IS NOT – Plan for an alternative business model, Supplier capability study, etc.

3 – Define Deliverable Completion Criteria
How will you know when the deliverable is finished?
These criteria are crucially important (see Completion Criteria ensure Done means Done); aligning expectations up front among customer, stakeholders and team will avoid painful conflict later in the project. For example:

- Six copies of report in spiral-bound hardcopy provided to Steering Committee for review
- Key findings presented in PPT format to Executive Management in a half-hour briefing.

Bridging the Gap between SOW and WBS

Deliverable descriptions make for sound scope management and effective change control. They exploit and enhance the Statement of Work narrative to provide real benefit in several ways:

• Give the project scope some solid structure
• Align expectations among stakeholders
• Establish the basis for customer validation of outputs
• Bridge the gap between the initial scope narrative and the detailed WBS
• Help ensure that all WBS tasks are comprehensively identified (e.g. completion criteria will often point to needed WBS activities).

Undefined deliverables => unclear scope => undeliverable project.

How do you know for sure when something is declared “Done”, that it really is? By defining completion criteria. These little nuggets are one of the single most important – yet frequently overlooked – aspects of project planning.

Completion criteria root out ambiguity (see The First Law). They align stakeholders, team members and the customer on the conditions for acceptance and validation of the project outputs. And they improve estimating quality by enhancing understanding of the desired work result.

Its a Binary Thing – “done” or “not done”

Completion criteria should be defined first for the project deliverables, which in doing so will actually help identify tasks for the WBS, and second for (ideally) each task in the WBS itself. Well-written criteria:

• Are defined by the deliverable or task owner
• Clearly state the characteristics and attributes of the output  – “what done looks like”
• May include the measurement and validation requirement – e.g. “who reviews what”
• Are defined in a binary way (i.e. totally unambiguous).

Can we really do this for every task? You decide – it’s a tradeoff between increased planning effort vs. increased risk. But consider that while this may initially seem onerous, the reality is that it does not take much more effort to write a statement or a couple of bullets specifying what ‘complete’ means (for example in the Notes field in Microsoft Project). Put in the context of the project overall, it’s a seriously small price to pay for dramatically increased clarity and reduced risk of misunderstandings.

Every project should be closed with a proper review of lessons learned. I’m always amazed at the tremendous amount of feedback, ideas and value that comes out of a well run project closeout review session. Regrouping the team for this one final meeting is one of the most important events in the life of the project.

The agenda for this meeting – best run as a facilitated workshop – should comprise these three items:

1 – What Worked?
2 – What did Not Work?
3 – What must we Do Differently Next Time?

Structure for Best Results

Some structure around each of these will maximize the quality of the output. For example, solicit feedback with respect to specific areas, such as:

• Categories – Planning, Resourcing, Risk Management, Requirements, Technology
• Enablers – Commitment, Competence, Communications (see The Fifth Law)
• Phases – Solution Design, Development, Testing, Deployment.

This provides proper focus and balance for identifying lessons learned. Also, use of the Nominal Group Technique in the workshop ensures the optimal mix of individual contributions and team discussion.

Lastly, just capturing lessons learned is only half the job. In the spirit of ‘kaizen‘ or continuous improvement, they each need to be transformed into action items for implementation, in order to guarantee future projects will use them.

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.

Projects exist in dynamic environments, where change and risk are the only constants and where the delivered outputs are dependent on a team of imperfect individuals. Which is why – whatever the customer may have been told – projects do not carry guarantees. This reality is what I call the Fifth Law of project management.

Success and stakeholder satisfaction depend on a trio of crucial enablers – competence, commitment, and communication. Respecting all the preceding laws will count for nothing if this threesome is lacking in some way, both at the project manager level and at the team level.

Competence

First among our three equals, competence is what gets the work done right. It is founded on knowledge of concepts and methodology, embedded through hands-on experience, and evidenced by the quality of a project manager’s actions (how they lead and manage), artifacts (such as plans) and, to a far lesser extent, accreditations (think PMP, PRINCE2).

Commitment

Excellence in any field has to be worked at and earned. Natural talent helps of course but to be really good at something, to be recognized and respected, plenty of dedication and passion are essential. Commitment is not hard to detect – it does mean putting in those extra hours but its as much about right focus and attitude.

Communication

Great project managers are outstanding communicators. I think of outstanding to mean mastery of multiple modes of expression – spoken, written or visual – in combination with exactly the right mix of human skills and behaviors for interacting with both stakeholders and team. Done well, its reflected in a team that exudes its own buzz – look for healthy relationships, confidence and humour.

The Core of Success

The right combination of competence, commitment and communication is an energizing force for the project, its customers and its contributors. It is at the core of project success and drives stakeholder satisfaction.

Want to do a quick pulse-check of your project? Start with an honest appraisal of the 3Cs – competence, commitment and communication – and do it for both the PM and the team.

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

All projects have an objective but not all projects have a well-crafted objective statement. Its a simple and elementary thing but deceptively powerful. Creating a high level, overarching mission statement should be among the first 5 things that a project manager does with his or her core team.

Short and Sharp

An objective statement should ideally be written as a single meaningful sentence, comprised of no more than 25 words, that reflect the primary project constraints – schedule, scope, resources.  The word limit deliberately forces focus and ensures we get to the core of the project’s main objective, even if a zillion things will be worked on during the project’s life.

To re-quote President J.F. Kennedy as an example:

Put a man on the moon and return him safely back to Earth, completed on December 31, 1969, for US$531m

Call it what you will – a Project Objective Statement (POS), a Project Mission Statement (PMS – less popular), or PROject MISsion Statement (PROMISS) – this declaration is crucially important for a host of reasons:

Clarity

• It is THE stake in the ground that lays out exactly WHAT will be done, by WHEN and for HOW MUCH.

Alignment

• Securing sponsor input and involving the core team in crafting this statement ensures buy-in, commitment and a sense of real purpose. It should NOT be done by the PM alone.

Validation

• It should be formally approved by the sponsor prior to detailed planning and re-validated again before execution begins, i.e the plan MUST demonstrate tactical viability by meeting this target.

Tracking

• It communicates an ongoing point of reference for management and the team throughout execution. The project mission changes only if explicitly required and agreed to by management.

The process of creating this statement is as important as the statement itself. Done right, it begins the development of a performing team and the resultant discussions help identify project boundaries, assumptions and issues early on. Put this as one of the first agenda items in your planning sessions.

The interdependence of truth and trust is a powerful force in projects. When both are prominent, we have a strong basis for effective team dynamics – a key ingredient of project success. Overlooking, ignoring or concealing certain realities inhibits team cohesion and severs trust – as sure as the sun rises. I call this force the Third Law of project management.

Creating an environment of truth helps build trust. This means straight talk, smart leadership and attention to good process. It also means reinforcing positives and not holding back on bad news. (Pop quiz: What’s worse than giving your sponsor bad news? Answer: Giving bad news late).

15 Truth Checks

Here are a few checks to test whether important project realities are being detected, acknowledged and acted on:

• Has a trustworthy process been used to plan and manage the project?
• Is project progress being tracked and reported accurately?
• Are team member status updates consistently submitted in a timely fashion?
• Are issues being aggressively managed?
• Are risks being reviewed at each progress review meeting?
• Are new risks being proactively identified and managed?
• Is outstanding performance being acknowledged, directly and publically?
• Is under-performance being dealt with effectively?
• Are people rewarded for behaviors that promote effective teamwork?
• Have gaps in expertise or credibility been identified and resolved?
• Is the team aligned with a common sense of purpose?
• Are morale and commitment being nurtured proactively?
• Have conflicts been acknowledged and addressed effectively?
• Are team members executing, communicating and reporting as required?
• Is a flexible leadership style in evidence, building trust across individuals and cultural differences?

Promoting open communication and instilling a sense of shared purpose are the starting points for any effective collaborative effort. But they need to be backed up by solid process and savvy leadership. Managing the project includes monitoring both the project and the project environment. It involves responsiveness to the unexpected in both project and human performance. Acknowledge the truth or face the consequences.

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