The world is (slowly) moving toward a shared understanding of the term “program”. There are still widely varying interpretations of project vs program but the most common themes are that programs typically drive significant strategic change, involve the integration and coordination of multiple component projects (and sometimes non-project work too), and focus on outcomes rather than outputs.

Alignment and Integration

Where all these criteria are fulfilled, major problems arise when the program is treated simply as a large project, meaning that planning and oversight is overly tactical to the detriment of the more strategic activity necessary for program success (see Big Programs, Basic Flaws).

Seven Key Elements

Ensuring the program delivers what was intended requires special emphasis given to areas such as strategic alignment, stakeholder management, scope and schedule integration, and benefits planning.

The following major elements of program management help provide appropriate focus:

1 – Business Case

Programs should have a well-articulated justification for the investment, that centers on the estimated costs of implementation and ongoing operations against the anticipated benefits to be gained and offset by the associated risks.  The business case lays out the strategic context of the program and shapes its overall mission and vision. Once approved, the business case provides a point of reference throughout the program (updated as necessary) in order to ensure a continued business rationale for the initiative.

2 – Program Organization

This should comprise a single program manager with unambiguous reporting lines to an executive steering committee (program board) that adequately reflects major stakeholder interests, budgetary control and resourcing. Other advisory committees may be set up to review and guide specific aspects of the program but the board always has ultimate decision-making authority. The program manager should have ready access to an individual program sponsor to resolve issues and obtain guidance not requiring involvement of the other board members.

3 – Stakeholder Alignment

The sheer scale of a program will usually infer involvement of many parties with vested interests. Stakeholder analysis will help to identify individual concerns and parties needing the greatest attention, and subsequently define appropriate response strategies. It also assists in identifying risks associated with (real or perceived) negative outcomes. Properly managing relationships with key stakeholders requires detailed communication plans and, (sometimes forgotten), ensuring adequate time and effort is expended in acting on those plans.

4 – Benefits Realization Plan

Since programs focus on outcomes (vs. projects which focus on outputs), a core element of program setup is the development of a plan that (a) assigns metrics to identified benefits, (b) forecasts when and how those benefits will be realized and (c) maps program deliverables to the benefits which are in turn linked to program objectives. This helps ensure that assumptions in how each benefit will be realized are validated and that all required deliverables are clearly identified.

5 – Program Architecture

The program architecture identifies component projects and the major interfaces between them. A vital aspect of developing the architecture is scope integration, whereby the boundaries of each component are validated to ensure that program objectives can be fulfilled without gaps or overlapping effort among the constituent projects. A high-level program roadmap is an important tool in depicting anticipated sequencing of the projects, target dates for key interfaces, review/approval gates and other milestones, and successive stages of funding.

6 – Integrated Master Schedule

An effective integrated master schedule (IMS) consolidates all component project schedules and links them at the task level with specific, clearly defined interfaces with explicit completion criteria. Depending on the schedule criticality, the use of simulation tools and optimization techniques are often essential tools to properly manage schedule risk and greatly increase credibility of the plan and confidence.  The IMS re-validates the program roadmap and benefits plan and together with an interface tracking log will therefore provide the basis for much of the program manager’s performance monitoring focus during program execution.

7 – Tiered Governance

While project managers within the program will typically track progress against schedule, cost and technical performance, the program manager needs to ensure not only proper roll-up of this data (possibly via a program office) to control overall program progress but also to implement tracking of benefit metrics, as per the benefits realization plan. A well-designed program dashboard reflects both types of metric to provide the board with a holistic view of both the strategic and tactical performance aspects of the program.

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.

Team Alignment, not Team Building

One of my favorite blogs is Glen Alleman’s “Herding Cats”. Solid project management commentary, a wealth of experience and expert guidance with no fluff. Glen recently posted on Team Building and like me he doesn’t have too much time for ropes in the forest and artificial partying as a means of ‘building’ teams.

Effective project teams are built on purposeful activities centered on the project in question. Confident facilitation of a clear agenda that engages the team in understanding and elaborating the project mission is a good starting point.

Five Principles for Aligning the Team

If project startup and planning activities are well conceived and facilitated then team alignment should be a natural outcome. Maintaining alignment is subsequently a function of proper control, engagement and communication. Five principles guide the project manager in developing a unified, cohesive and productive team:

1 – Know the Objective

Shared vision and common purpose are the starting points for building an aligned team. Review the project business case, then craft the project mission statement together with the core team. Ask yourselves what’s missing? Is it specific enough? Is it realistic? Does it properly reflect the tactical objectives that should in turn yield the anticipated benefits?

2 – No Moving Targets

Establish clear boundaries. What will be included? What will not be included? What deliverables will be produced? How will we know when those deliverables are complete? If key stakeholders keep moving the goal posts, we’ll never complete the plan. So force agreement on a phased or iterative approach if necessary.  What is needed now? What can be done later?

3 – Lay Out the Detail

Creating alignment means setting expectations – at a deep level. Far too many projects are underplanned and insufficient detail promotes ambiguity, conceals the realities of time, effort and cost, and leads to unvalidated assumptions. Secure ownership and trust among team members by ensuring they are involved in defining the work, agreeing the details of hand-offs and validating completion criteria.

4 – Use a Trustworthy Process

A solid process for defining, organizing, planning, tracking and controlling the project is at the core of good project management. Talking the team through the process builds credibility. Implementing that process (walking the talk) generates motivation and commitment. Recognizing the difference between PMBOK and a practical, step-by-step, end-to-end project management process is a pre-requisite here.

5 – Feedback Smart and Often

Insist on efficient and frequent review cycles. Avoid wasting people’s time in meetings by getting status updates beforehand. Use the meetings to review overall progress, solve problems and decide on adaptive action. Check in with team members regularly and reward good performance swiftly. Keep key stakeholders appraised of progress and ensure bad news is acted on, not hidden.

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