Posts Tagged ‘Organizing’

PostHeaderIcon Program Management Essentials

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.

PostHeaderIcon Principles of Alignment

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.

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 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 Project or Program?

    Is my project actually a program? Its a question sometimes asked by project managers unsure of whether their project has the right management approach. Oftentimes it is the lack of a clear distinction between the terms “project” and “program” that causes confusion. While “program” is usually associated with an initiative of larger scale, size alone is an inadequate differentiator – there are plenty of large projects that do not necessarily require program management practices.

    The Project-Program Continuum

    In reality we cannot easily draw a line between the two since the project-program transition occurs on a continuum, not a discrete point of separation.  Also, this continuum really comprises a number of parameters beyond natural considerations of size and cost – the graphic below may help to clarify:

    Mapping an initiative against each of these factors may provide some guidance as to how it should be managed.  The more scores to the right side, the more likely that program planning, control and oversight methods would be appropriate.

    Ultimately, a key question to ask is: “Can we obtain better control and better outcomes by managing as a program?”