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.

Conclusions

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.

Collaborative Project Management

As project managers, we are quite comfortable working in our own space and keeping abreast of the various projects that fall within our scope. Managing resources, working with milestones and timelines, monitoring tasks and so forth are all common aspects of the day-to-day duties of anyone within the project management space.

More junior project managers will often be tasked with dealing with projects that are limited in scope and generally self-contained. However, as one matures within the project management realm, projects will become more complex, with various inter-dependencies, shared resource pools and other external factors. Invariably, the notion of either being responsible for or being part of a broader ‘program’ is something that the project manager will likely have to contend with.

With that notion in mind, the project manager is going to have to think outside the box and be mindful of not only his/her own key deliverable and timelines, but also those of other projects that are part of the broader effort. A great example of when such an occurrance is frequent is in the automotive industry, whereby various teams are responsible for specific portions of a fully functioning deliverable (a car or truck). Project managers may also overlap in such cases with other deliverables (eg. a common audio system used in different brands) and as such, have many inter-dependencies to contend with.

With the above being stated, what are some of the key techniques that one can utilize to ensure all project managers are functioning in sync with one another and that the overall program is moving along smoothly?

Regular Project Manager Communication

Whether this is spear-headed by the program manager responsible for over-arching program or is something that the project manager’s themselves take up, it is imperative that consistent communication channels remain open and that all the project managers regularly perform dialog exchanges and status updates between each other. In many cases, utilizing tools can greatly assist in ensuring that this dialog exchange can be performed efficiently. Regardless of the mechanism, these communication channels must stay open and engaged at all times. When considering a large program, inter-dependencies can be one of the trickiest attributes to contend with when functioning in parallel. Often times, a specific portion of one project may have a dependency on another and the timing of those dependencies can easily cause the overall program to derail if they are not handled effectively.

Uniform Usage of Tools & Metrics

Every project manager worth their salt will likely utilize some tools to perform their day-to-day duties. Additionally, these tools likely help the project manager derive the metrics and the primary KPIs (Key Performance Indicators) that they use to ensure their project is hitting on all eight cylinders.

In a collaborative environment with multiple projects functioning in unison, it is of utmost important for the project managers to be working lock, stop and barrel with the same set of tools and metrics. Deviation from specific tools or inconsistencies in KPIs are a sure-fire way to lead to confusion, thereby increasing the likelihood of something slipping through the cracks or a problem manifesting that should have been spotted and dealt with earlier.

The usage of standards (processes) is also important in this context as it will make alignment between timelines and key milestones more easy to classify and monitor.

Tracking Dependencies

As alluded to earlier, one of the key attributes of a broader program consisting of multiple projects is the fact that dependencies exist and must be monitored. In many cases, these dependencies will span the various projects, leading to situations where one project’s forward movement in their timeline may be dependent on the completion of a component in another project’s task list. As such, itemizing these dependencies and ensuring they are being tracked is a key component of the success of the overall program.

From the standpoint of visualizing the dependencies, one classic and very effective technique is to utilize a ‘PERT’ chart. PERT is an acronym for ‘Project Evaluation and Review Technique’. Basically, it is a node and line based way of seeing the various portions of an overall project or program that displays the dependencies graphically, making it a very intuitive and easy way to see how things fit together in the aggregate. An example of a PERT chart is shown below:

The key takeaway from a PERT chart is that specific nodes cannot be reached until previous nodes have been accessed. This step-through denotes the various milestones for a project/program and shows how all the key dependencies are inter-related. (Note: For more information on PERT charts and PERT analysis, please access the following posts: The PERT Analysis – Part 1 and The PERT Analysis – Part 2)

Implement a Planning Framework

A final consideration for an effective collaborative project management strategy is to leverage and implement a planning framework for the aggregate program. What this entails is that the project managers (generally leveraging some template) will perform the due diligence of planning their work scopes independently, confirming (through consensus) that the main line requirements have been fulfilled and then assuming direct control and responsibility of their specific projects and constituent sub-projects. An effective planning framework will allow for the project manager’s to function autonomously within their project scope while still maintaining direct lines of communication and status updates to their peers. This will avoid status overload and will allow for easier distribution of workload amongst the different project managers.

The diagram below shows a diagram of a planning framework using the Dixon Integrated model for PMs:

(Source:  Dixon et al., 1990; Hall et al., 1991)

**Conclusions**

Whenever project managers work together, the results can often vary and much of the success or failure of such an effort depend on the planning and collaboration techniques that were instituted up front. Without such an effort, you can often discover that you end up with various boats paddling in separate directions without any idea of what the other boats are doing. This can lead to severe problems and outright failure of a program if steps are not taken to get the project managers working in unison. Some of the aforementioned techniques can help guide this effort and ensure that the project manager’s understand that the success or failure of their specific area of scope is very tightly interrelated to other projects working in parallel. This understanding, realized up front, is of imperative importance.