Conveying Program Strategy

Dealing with project deliverables and conveying status in the form of success metrics or timelines (with milestones) is a key attribute of the project/program manager’s general responsibilities. Stakeholders, sponsors and team members will want to continuously be kept up to date on the various particulars pertaining to the successful movement of a project (or program) towards its net tangible outcome.

It goes without saying that projects and their superset programs generally have a set of quantifiable deliverables that are meant to be the natural outcome of the effort. Whether that be improvements in infrastructure, a product release, or a general process change or consolidation effort, every project and program will have some net outcome associated with it.

When one is dealing with the program level, often times, it is important to convey to stakeholders and the various team members of the constituent projects exactly what the end game of the program is. While it may seem obvious to some, as programs get instantiated and grow organically, they can periodically become more ambiguous or vague with regards to their overall strategy. A good example may be a ‘cloud’ strategy that is being adopted by a software company. While many may understand the concept at a high level, the actual strategy of execution for the program becomes a little more difficult to discern. And this often stems from the fact that some new initiatives are often the result of a brainstorming session at the executive level, which then percolates down.

Most project managers will understand how important it is to define ‘scope’ for their projects and ensure that actions being taken align with that predefined scope statement. In the same vein, a program (which can also have an aggregate scope), needs to very often define its overall strategy. And that strategy needs to be something with a little more bite than just a buzzword that was floating around during an executive offsite or brainstorming session.

From the standpoint of the program manager, what is often of paramount importance is to take the ‘high level’ strategy provided by the executives and give it some more tangible weight, through strategy discussions with the main stakeholders, key team members and the program sponsor or sponsors. So while ‘cloud’ may be a completely viable buzzword at the executive level, it is insufficient at the program level to convey the exact nature and long-term goal of the program as a whole.

With that being said, how should a program manager work towards defining the ‘core’ strategy of the program and how should that information be presented so that it is readily absorbed not only by the team members, but by the executives?

What is the Strategy?

While it may seem as almost a rhetorical question, in fact, it is often surprising how frequently you will get a diverse set of answers when one posits this question to a group of senior leaders. Their answers can often be attributed more to their position in the company versus the actual strategy itself. So in many cases, the answer provided by a marketing manager may differ from that given by a director of engineering, and so forth.

When it comes to strategy, a simple rule of thumb to follow when attempting to define it is to use the following three question approach:

1. Where are we today?

By this, the question is essentially alluding to what resources are available, what ideas do we currently have in the pipeline and what is currently in progress?

2. Where do we need to be?

In this case, the simple question can be summarized as asking what are the goals of the company or team? By positing this question after the initial one, it can almost immediately be determined if the current focus is matching the future expectations of everyone involved.

3. What are our options for getting there?

Once the corporation or team has a firm understanding of any and all discrepancies between their current focus and their desired focus, it becomes easier to discern what steps are needed in order to re-align current activities in order to achieve the desired goals. Also, specific constraints will surface during the discussions that will itemize what, if any, obstacles or bottlenecks might hinder the movement toward the desired goal.

Going from Point A to Point B

Based on the above, strategy can often be simplified in terms of simply going from one point to another. While it may seem like an oversimplification, that is essentially the crux of what a strategy defining exercise is attempting to convey. So something as simple as saying ‘We are currently a company that focuses on application level products but we are moving towards a client-less strategy’. The good thing about a simplified strategy statement is that, when it is well written, encompasses the business case in a simple, one line answer.

One very effective way to actually display the strategy in a graphical format, showing progress and dependencies is to use a PERT chart. For those unfamiliar with PERT, it stands for “Project/Program Evaluation and Review Technique’. A PERT chart is actually a pictorial way of showing movement of a project or program through its various paces until completion. The diagram below shows a simplistic representation of this concept:

As one can see based on a cursory view of the chart, it clearly shows movement from start to finish. PERT charts can actually become quite complex and often have intrinsic project timelines and completion dates as part of their function. But at a high level, they can also be quite effective to simply display where one is, where one would like to go, and the steps one must take to get there. The additional benefit of a PERT is that it can easily display activities that are dependent on one another versus those that can be accomplished in parallel with others.

Note: For further details on PERT charts and using them in your analysis, please consult the following posts:

PERT Analysis – Part 1

PERT Analysis – Part 2

Maintaining Focus on the Strategy

One of the most important aspects of a strategy session and its likelihood of success depends heavily on how much backing it has within the confines of the team or corporation. One must remember that a fundamental definition of strategy is not simply a brainstorming session. (Although it may start that way) It could often times be a fundamental shift in thinking, process and focus. With that being said, it is absolutely imperative that the mantra of the strategy be continuously re-inforced. People, when left to their own devices, can often become complacent as it pertains to any new ways of thinking or re-focussing of their efforts. Louis Vincent Gerstner, famous for changing the corporate culture at IBM, fought an uphill battle in moving the strategy of the company. Now while the strategy focus in your case may simply be a re-emphasis of existing efforts, a moderate shift in strategy, of a complete overhaul, what is important is that one maintains a high level of visibility of the strategy and ensures that everyone involved understands the focus and the movement forward.


If one wants to think of strategy, it is a simply a plan of action to achieve a specific goal. In military jargon, it might be a way to gain advantage over the enemy (destroying a supply line, taking over a key bridge, etc). In project terms, it is a goal to produce an end outcome or deliverable to achieve a specific result. (Usually increased revenue) Strategy can exist at the highest levels of a corporation or at the lowest levels of a small project. Regardless, the primary imperative is that the strategy is defined effectively and consistently applied. So long as everyone involved is aware of the strategy, can itemize it relatively easily and is aware of their specific tasks as to how it relates to that strategy, half the battle has already been won.

Understanding Project Management

Projects are a common term in day-to-day vernacular. People use them to define home improvement efforts, homework assignments that involve teams, and of course, specific initiatives in a corporate setting whereby some intrinsic deliverable or improvement is the net result.

The term ‘Project Management’ is often splashed around between individuals in both corporate and external settings. Yet in many instances, when people are pressed for a more in-depth synopsis of what project management actual is and what is involved, the answers can sometimes be wild and varied. The line between the responsibilities of the standard project manager can also be obscured and overlapped with other areas of expertise, such as product management, product marketing and business analysis, which can often complicate the true definition of what a project manager does and what project management actually is from a definition standpoint.

In order to be able to clarify these ambiguities, it is important to first begin with the definition of project management. That can be summarized as follows:

Project management is the discipline of planning, organizing, securing, managing, leading, and controlling resources to achieve specific goals. A project is a temporary endeavor with a defined beginning and end (usually time-constrained, and often constrained by funding or deliverables), undertaken to meet unique goals and objectives, typically to bring about beneficial change or added value.

(***Source: Wikipedia:

While the above definition is wordy, a point form breakdown of project management can also be defined as follows:

  • A project has a specific objective that is meant to be completed referencing certain specifications (scope)
  • A project has a defined timeframe, with definitive start and end dates (time)
  • A project utilizes specific resources, both human and monetary (cost)

**Note: For those savvy enough to spot it, the above three points are the basis of the famous project management triangle, or Triple Constraint. (For further reference, please read the post: Scope, Time and Cost – Managing the Triple Constraint)

Now that a working definition of project management has been provided, the next logical question to ask would be: how does someone ‘run’ a project and produce its net deliverable?

To understand that, we turn to the PMBOK Guide, which identifies project management as being broken down into five specific parts, or ‘Process Groups’. These groups make up the functional life-cycle of the project, from inception to conclusion and add granularity to project management as a whole. The group’s themselves, and their corresponding functions are itemized as follows:


1. Project Initiation

This is the first step in the project management process whereby the actual criteria of what the project is or is attempting to achieve is defined. Some of the high level planning, initial stakeholder analysis, and preliminary business case would all be handled at this stage. Additional attributes of this process group would also be:

  • Allocation of specific resources and skills
  • Outline of the project and its primary benefit(s)
  • Initial documentation (which becomes part of the overall project management plan)
  • The assignment of a project (or program) manager

2. Project Planning

The second step in the process is a more deep assessment of how the project is going to be executed. This is where actual assignment of specific tasks, the primary schedule, and the work breakdown structure will all be defined. Additionally, the communication plans between the team members, stakeholders, project sponsor and any customers in the ‘early adoption’ program will also be set up. Overall attributes for this process group can be summarized as:

  • Work requirements and their specific definitions
  • The project quality plan
  • Breakdown of resources across tasks
  • Finalization of the schedule
  • Risk assessments (this will be ongoing throughout the project)

3. Project Execution

The is the official start of actual implementation as it pertains to the project. All planning activities should now be complete, work assignments should have now been made and all parties should have full understanding of their role and duties as it pertains to this project. Primary attributes of this process group are:

  • Any final negotiations pertaining to resources
  • Providing direction to the team
  • Formulating the process to monitor the work moving forward

4. Project Monitoring and Controlling

We are now at the stage where the project is under way. While this may seem to be the ‘reprieve’ for the project manager, this is arguable, the most important phase of the overall project life-cycle. If anything is likely to go wrong with the project as a whole, it will most certainly occur at this stage. This is the point where we have moved from the ‘theory’ of how we envisioned the project to move forward to the actual ‘practice’, where the engine is running and we are on the road. And as life has often demonstrated, any amount of planning does not always yield to a smooth ride. Which is why it is imperative that the project manager is at their most diligent during this phase. The main attributes of this process group can be itemized as follows:

  • Tracking the progress of tasks
  • Monitoring completion rates of tasks to determine if project timeframe (schedule) is still intact
  • Analyzing the outcomes to ensure key deliverables match predictions as defined in the master plan
  • Monitoring dependencies to ensure problems in key areas do not cause slippage to the project as a whole
  • Making adjustments and variances as needed to ensure project does not run into trouble
  • Maintaining communication with team, stakeholders and sponsor in the form of sync-ups and reports

5. Project Closure

This is the final stage of the project life-cycle and generally means one of two things: either the project has completed and delivered its net tangible or it has been stopped for other reasons. Regardless of circumstance, a project MUST be closed and lot allowed to ‘linger’. Often times, projects can be in limbo due to uncertainties about execution, disagreements about implementation or simply changes to corporate dynamics and a realignment of strategy. Whatever the case, a project does not ever simply sit in a non-closed state indefinitely.

Assuming the project completed ‘successfully’, the key attributes of this process group are:

  • Verification of work assignments (no lingering tasks to be completed)
  • Any open contracts are closed and deliverables verified
  • Any financial obligations and budgeting aspects are finalized and closed off
  • Final sign-off on any paperwork that remains

How Does One Determine If a Project Was Successful?

There are many ways one might answer this question, but the response may not be as obvious as one might expect. Take a simple home improvement project for example: does simply re-doing a bathroom and competing the work denote success? Does the quality match expectations? Does the shower now leak? Is the water pressure insufficient? Does the color of the cabinets not look right? All these may indicate that while the project was completed, the actual requirements do not meet expectations. So from that perspective, one may argue that the project was not successful. Similarly, a corporation may roll out a new product (a new car line for example) and discover that the new vehicle simply is not selling as expected and has problems with quality. As one can see, simply meeting a deadline does not always denote success.

From the standpoint of project management, there are essentially five key objectives that should be met before one can consider the project to be a success. Those objectives are:

  1. The project was completed on time
  2. The project was completed within budget
  3. The project met its requirements are dictated in the scope document
  4. The project was able to leverage its resources in an effective and efficient fashion
  5. The project was a hit with the target customer

Note that one may argue that a project can be successful if one or more of these objectives is not met exactly (most projects often have difficulty meeting schedules for example). Nonetheless, the point to make here is that there is more than one factor to consider when determining project success.

Why Use a Project Manager And What Are The Benefits?

It may seem almost heretical for those of us in the space, but many often ask the question regarding the necessity of whether or not a project manager is even required. Many times, a project manager’s duties are sometimes distributed amongst members of a team and the direct line managers, rather than having a dedicated individual working on the task. While some argue this is a perfectly valid option, more often than not, the decision is made due to political or monetary factors rather than any notions of efficiency.

When it comes to the benefits of a project manager, that can be most aptly summarized as follows:

  • Is able to identify functional responsibilities, monitor dependencies, deal with resource conflicts and be personally accountable for the project as a whole
  • Will minimize the need for multiple levels of status reporting from individuals and be able to more cohesively describe project progress as a whole
  • Can constantly monitor the schedule and determine more effectively if everything is on time
  • Can better spot problems and identify risks due to having a more holistic view of the project
  • Can constantly monitor individual accomplishments and factor those completions against the aggregate project
  • Be able to determine if specific objectives can or cannot be met
  • Is better capable (due to experience and training) to deal with project complexities

In conclusion, project management is a highly sought after skill set because both individuals and corporations understand just how complex and difficult to maintain a project can be. As indicated above, projects have multiple levels of process, can have numerous resources working in unison and can have potentially millions of dollars invested in them. Simply leaving the success of a project to chance is a sure-fire way to see the competition outmaneuver your corporation, your customers taking their business elsewhere or your company being forced to write off potentially large sums of money in the form of investments on a deliverable that ended up not meeting expectations or never existing in the first place.