PPM: Everyone Gets To Play (Part 2)

In continuation to my previous blog post, this one will explain how the PPM needs of organizations drive the overall implementation process. At the enterprise level, we all recognize that different types of businesses execute different types of projects. The project portfolio for an investment bank is going to look a lot different from the portfolio at a company that designs and builds computer products, or a hospital, or a university. Even when we look at similar enterprises, we find differences in strategy, culture, and approach. Since many of these differences are the fuel for competitive advantage and operational excellence they require processes and practices which support those unique attributes.

Likewise, we need to recognize significant differences between functional areas  within the same enterprise due to the nature of the work being executed and the varying ways in which that work is done. The PPM needs for the product engineering groups are not exactly the same as those in HR.

Let’s take scope management as an example. For a company that is building something under a contract for another company, control over the scope of the project may be critical to assuring company profitability and in the most extreme cases the financial viability of the supplier organization. In this case, one would expect a much more structured, formalized set of processes for reviewing and approving scope changes and making changes to supporting contracts, payment schedules, etc. By contrast, when a department in one organization needs to communicate and manage expectations around delivery dates and costs for a sponsoring department within the same company – especially when the sponsoring department has requested the change — they may adopt a less formalized, lighter weight scope change process. In both situations changes the “what” of scope management is the same – scope changes need to be recognized, communicated and approved – but the “how” may be radically different.

We must also take into account that the approaches, tools and techniques used, even within a discipline may change over time. For many years, the construction industry used the Design/Bid/Build phases in their projects where each successive phase was substantially completed prior to the commencement of the next and each phase was executed by different organizations. Unfortunately, as a consequence of this approach many projects were plagued by a fourth phase, “litigation”, with finger-pointing and lawsuits between the parties to establish whether something was a defect in design or a defect in construction. Now many construction projects are using an approach called “Design/Build” where the work is performed and managed as a single, integrated effort. Similar changes have occurred in information technology, where new development tools and approaches have facilitated iterative and agile development of applications and business systems outside of the lockstep waterfall techniques of the past. Each of these has required new techniques for how the projects using them are planned and managed without losing the visibility needed for oversight and control of the outcome.

The most successful PMO’s and ePMO’s are those that understand the underlying goals and objectives of PPM while implementing supporting processes that are adapted  to the unique, changing needs of the enterprise, and the functional groups and disciplines within that enterprise. While this requires open-mindedness and creativity the adoption of PPM across multiple disciplines in thousands of companies is proof positive of the feasibility and be benefit to be derived from the effort. In short, despite the declaration of that gentleman at my first PMI meeting – PPM is relevant to Information Technology. And  to Finance, Marketing,  Professional Services,  New Product Development, Manufacturing, Supply Chain Management, Education and any other discipline or organization that invests in and executes projects. It also still applies to Construction and Engineering…

As a post-script I would add that since that first meeting I have belonged to PMI for many years and attended numerous meetings in a variety of other locations and chapters which were well attended by individuals from a wide variety of organizations and disciplines.

PPM: Everyone Gets To Play (Part 1)

I remember my first PMI meeting.  It was in the early 1980’s and I had just been appointed to manage a fairly large project for the Data Processing Division of a large bank. The meeting had been recommended to me by a colleague who was not a project manager herself but was married to a project manager at a large civil engineering company. I was the only person at the meeting who was not a civil engineer or construction manager and the keynote address was about building a large oil refinery in the middle-east. I should also mention that I was the only woman at the meeting and a good twenty years younger than anyone else in the room. During a break I was chatting with a couple of the other attendees and when I told them where I worked one of them observed that he believed that “real project management” wasn’t really relevant to Data Processing. Needless to say, I didn’t go back.

Fortunately while at that meeting, I joined the PMI and got my first copy of the Project Management Body of Knowledge – which came in a 3-ring binder. I read it and realized that it contained a lot of information that was obviously influenced by engineering and construction but also seemed to be very relevant to the projects we were trying to manage in Data Processing. Indeed, there were a number of others in DP, which eventually became information systems, then Information Technology, who also saw the relevance of methodically applying a set of principles and processes for managing technology projects.

People started writing about and consulting practices were built around introducing these methods into organizations as a way of improving the predictability and performance of projects, not only in Information Technology but in other industries and disciplines as well. In 1975, Thomas Wheelright and Kim Clark of Harvard first published The Product Development Challenge: Competing Through Speed Quality and Creativity which included a number of case studies and arguments for applying what are now considered standard project management processes to managing the development and introduction of new technology products. Wheelright and Clark also expanded the focus from the execution of an individual project to what they called the “aggregate project plan”, which “helps managers focus on a set of projects” and “improve resource allocation, project sequencing, and critical development capabilities” – a recognition that project management and project portfolio management (PPM) are not different disciplines but common views from different perspectives.

Organizations have also changed to recognize the role of project and portfolio management. Project Management Offices (PMO’s) began springing up as an internal mechanism for introducing best-practices and processes into enterprises, providing oversight of the processes, and maintaining and providing specialized practitioners (project managers) who understood and could effectively apply these processes and principles. And while PMO’s have tended to focused on one segment or discipline within the enterprise (most notably IT),  enterprise PMO’s (ePMO’s) are becoming more common as enterprises realize the value of providing oversight and managing the portfolio of projects from the enterprise level.

There are a number of reasons for the proliferation of defined PPM processes and specialized organizations supporting those in different disciplines and businesses. The need for transparency, common language, oversight, and strategic alignment are not industry or discipline-specific; they are the common challenges that PPM is designed to address. What is different is how these processes are applied and executed to support the unique needs of the organization, both at the enterprise and functional level. What is appropriate and effective for the IT division of a multi-national conglomerate may not be appropriate for the product development division of the same company or the IT department of a small start-up. In my next post I will walk you through what makes a successful PMO’s and ePMO’s. Stay tuned.

The Role of the Resource Manager

When we think about resource management, we tend to think about how it impacts projects and the project portfolio.  After all, if we don’t have the resources to execute work, our projects don’t get done.  What we sometimes forget is that resource management and the role of the resource manager goes far beyond assigning people to projects.

So what is a resource manager and what do they do?  Anyone who manages people is a resource manager.  It is the resource manager who  is responsible for ensuring that their organization has the right people with the right skills available at the right time to accomplish the work that needs to be done.  In addition to managing people, a resource manager frequently has functional responsibilities in the enterprise; he or she is responsible for running a group that may provide resources to projects, but may have day-to-day operational responsibilities as well.

The successful resource manager is someone with the ability to do a number of things well.  Obviously, they need to have top-notch people skills and be able to effectively set and articulate performance goals and standards.  They need to be able to evaluate individual performance against those goals and provide meaningful and constructive feedback to the people that they manage.  They also need to be mindful of team dynamics (the strengths and weaknesses of the individuals in the team and how they interact with one another), resolving issues or conflicts and supporting team morale.

The effective resource manager is also adept at managing a limited supply of resources against constantly changing demand.  This requires a good view of what is coming up and creating short-, mid- and long-term resource plans:

Long-Term Planning is taking a longer view of resource demand that is anticipated for six, eight, ten months out, or beyond.  In the long-term plan, the resource manager is not planning an individual’s time against specific tasks, but rather looking at general roles, skills and/or the locations of resources needed against general categories of demand (ongoing operational work vs. strategic projects, etc) using forecasts based on historical data or trends.   The long-term plan gives the resource manager the ability to anticipate resource needs and proactively plan for staff acquisition, training or other activities that typically have longer lead times or may represent their own drain on resource capacity.

Mid-term planning focuses on the next one month to six months and identifies commitments for a specific type of resource or even an individual.  But typically the mid-term plan represents these commitments as a level of effort as opposed to a specific date or time.  For example we may identify that we need an engineer for about 30 hours over 2 months for a specific project – not that the engineer will work for 10 hours on a specific task in a specific week.  The benefit of the mid-term plan is that it can be more accurate and provide more detail than the long-term plan, but is not subject to constant adjustment.

In the Short-term plan, the resource manager can look out a limited amount of time at specific task assignments – either for projects or ongoing work.  The short term plan then provides the information needed to make last minute adjustments due to emerging priorities, schedule changes, scope changes, or changes in the available resource pool due to illness, resignations or reassignments.  Because the short-term plan focuses on a limited timeframe it can be more precise than the long- or mid-term plans since we have a higher level of confidence in what is going to happen.

As a part of planning, the resource manager needs to be aware of the changing needs and priorities of the enterprise to ensure that the resources available to do the work have the requisite time and skills to do the work.  This means that the resource manager needs to understand the skills and interests of the team, and make sure that those skills are being developed to meet both current and future needs of the organization.  Changing business strategies, technologies, regulations and a plethora of other factors can all require significant changes in job responsibilities and the skills needed.  The best resource managers will follow developments across the enterprise, their discipline and in their industries to anticipate and prepare for these changes.

Last, but not least, getting the right things done is more important than working on everything and getting nothing done.  The best resource managers understand both the strategic and tactical priorities for their organization and communicate these clearly and consistently to their teams.  Likewise, they set realistic expectations for people outside of their team regarding delivery dates and standards – and they are able to say ‘no’ when appropriate.

While the scope of responsibilities for a resource manager may vary from enterprise to enterprise there is no question that the resource manager controls a most valuable asset – people.  Applying the skills and talents of that asset to provide the most value to the organization requires understanding and setting priorities, looking to the future to develop capabilities and capacity, and proactively working with the individuals and the team to develop skills and cohesion.

Implementing and Monitoring Organizational Change: Part 3

While its relatively straightforward to monitor the performance of a risky technical component, track defects, and make a binary “go” or “no go” decision as to whether that component can be used,  monitoring and controlling the effectiveness of organizational change activities are often more difficult, given their emotional and typically subtle nature.  How do we know that individual employees are accepting the change or are we about to experience a mutiny?  How do we know that the impacted organizations have been able to adapt and accept the changes, or are the supporting roles, processes and procedures going to undermine or undo all of our efforts?  How fast can we expect a change-averse culture to change?  How do we know if we’re going too fast? Can we go faster?

The solution is the same as for the technical component; we establish a monitoring mechanism which tests the response of the impacted areas against the desired result.  The big difference is in how the monitoring and measuring is done.  In the case of the technical component we establish a performance standard and collect empirical data which measures performance against that standard.  If the standard is met we’re in the clear, if not it triggers a contingency plan.  With organizational change both the performance standard and the data collected may be more qualitative and subjective but it still serves its purpose; determining if there is (or is not) a problem and if a problem does exist, doing something different to influence the outcome.

For example, consider the project where the first indication that training or change management were not successful is when a major business process (like billing or payroll) cannot be executed?  Clearly we need ways to identify and implement course corrections long before they reach the critical stage of final implementation. 

Issue Log Monitoring

One approach to monitoring is to use the project issue log or create an additional log  for concerns; items which are not immediately solvable or actionable.  Assuming that the team is diligent in reporting organizational change related issues or concerns, the frequency and severity of issues can signal a developing problem, especially when sudden increases are observed in a single area.    If the team also compares the issue and/or concerns log with the risk register, which has clearly identified organizational change risks, certain elements in the logs will stand out and can be interpreted as increasing risk probability or trigger a contingency plan.

Surveys

Surveys or questionnaires to monitor critical elements associated with organizational change provide a more structured approach to monitoring organizational change risks.  In this approach the project team creates a survey designed to elicit feedback from the organization about its perception of the project and the organizational change factors which may contribute to the success (or failure) of the effort.  By conducting the survey at regular intervals and comparing result from survey to survey, the team can quickly identify areas which require more attention and intervention.

  While creating and administering a survey represent additional time and cost to the project there are a number of benefits to be considered:  1)Collecting this information forces regular and systematic review of the project as it is perceived by the impacted organizations, 2)  As the survey is used from project to project it can be improved and reused, 3)The survey can quickly collect feedback from a large part of the organization, increasing the visibility of the project and reducing unanticipated or unwelcome reactions. 

Conclusion

In conclusion, organizational changes and the management of those changes can be a critical component for project success.  While the discipline of organizational change management may not be the primary focus of the project,, attention is required to understand what organizational changes may be required and their impact to both organizations and individuals.  Understanding the nature and scope of these changes enable the project team to more effectively plan, execute, and monitor their execution and effectiveness. 

Linking Business Strategy and Projects

Introduction:

Most of us recognize that having a strategy is a critical element for growing and improving an enterprise.  It is the strategy that defines the purpose or mission of the enterprise, establishes a clear vision of what we want to become, and provides goals or targets for accomplishing that envisioned future state.  In short, the strategy defines where we are going and ensures that we are all working in concert toward that same destination.

Unlike strategies, which broadly span the organization and are directional in nature, projects are tactical; they focus on creating specific capabilities, deliverables or outcomes.  Optimally, our projects (what we do) are in direct support of our strategy (where we want to go) and become the mechanism by which our strategies are implemented.  If we undertake projects that do not align with our strategy, we risk expending valuable time and resources on efforts that may not contribute to the long-term success of the organization.

Creating a clear linkage between strategy and projects can be a challenge, particularly in large organizations, but the benefits are well worth the effort.  In this article we will explore some practical approaches to establishing a clear linkage and using that linkage to realize tangible business results.

Create an Integrated Plan

In most cases, the translation of strategic objectives directly to individual tactics (or projects) results in a disjointed, scattershot approach where some strategic objectives are addressed by multiple, overlapping projects while other strategic objectives are ignored at the project level.  To avoid this, the successful organization creates an integrated plan that recognizes and records interim levels of goals and objectives that essentially cascade strategic objectives down through an organization.

Structure the Plan to Establish Alignment  (Top Down)

An integrated strategic plan helps us ensure that we’ve covered all the bases by successively defining how each level within an organization is going to contribute to the achievement of a set of objectives established at the level above.  For example, if the Executive Committee has established a set of strategic objectives, the second level of the integrated plan may consist of strategic initiatives or strategic goals that each division leader identifies for their division in support of the strategic plan.   The level below the division repeats the process to define how they’re going to support the division goals by defining programs, and so on until at the lowest level of the plan specific tactics or projects are defined (see Figure 1).

While the above example uses the organization hierarchy as the framework for creating the integrated plan, other hierarchies like line of business, product line, or geographical location may be more appropriate for organizing and building the top down integrated plan.  Regardless of the structure of the hierarchy, the process is top down, with each successive level identifying and defining their goals.  Each level clearly identifies who is accountable for performance at a given level and who provides oversight for the level below.  One could also argue that the integrated plan provides us with a model for sponsorship, with each level acting as the sponsor for the efforts directly below it in the hierarchy.

Figure 1:  The Integrated Plan

While the number of levels in the plan may vary based on the size and complexity of the organization, the structure of any level must recognize the objectives in the level directly above, thereby encouraging greater alignment as objectives are pushed out across and through the enterprise.

Quantify Goals and Objectives

While the communication of goals and objectives has value in maintaining ‘directional correctness’ for the organization, quantifying those goals and objectives provides clear targets for planning and measuring performance.

In quantifying objectives we need to focus on both sides of the business case: The return or benefit expected and the amount of investment expected to achieve that return.   Quantified cost and benefit targets remove ambiguity from the planning process.  If we create a plan assuming unlimited return or unlimited investment we have no way of evaluating or determining which initiatives, programs or projects actually represent the most advantageous mix in our portfolio of strategic investments.

Validate the Integrated Plan Bottom Up

As the Integrated Plan is created by cascading objectives from top to bottom, each successive level down is validated by the level above.  In other words, the individual or group responsible for a level must review the aggregate of plans from the level below to ensure that the individual pieces and parts from the lower level will, in the aggregate, accomplish the higher level objectives.

Perhaps the most difficult part of the bottom up validation process is dealing with the imprecision of the process.  While we do want to make sure that what is being planned at a lower level will realistically yield expected benefits for expected investment, there are no guarantees.  Consequently, in doing our validation we should not expect lower level numbers to tidily add up to the higher level numbers, but instead manage to realistic ranges of variations and recognize that as the plan is executed, adjustments and decisions will be needed to maintain alignment.

Be Flexible and Iterative

While we have presented a fairly structured top-down approach, it is important to remember that creating the integrated plan is not a rigid, linear process.  For example, it is not necessary to wait to start creating a lower level of the plan before the higher level is set in stone.  In many organizations, the construction of the integrated plan is an ongoing process where each level of the hierarchy is continuously adjusting based upon new information as it becomes available or in response to changing business needs.

Tracking:  Maintaining Alignment

While creating an integrated plan goes a long way in creating alignment to the strategy, maintaining that alignment over time is equally critical.  The primary difference here is that while creating the plan is typically driven top down, information used for tracking progress flows from the bottom up.  The key here is that the flow of information needs to be directed upward through the integrated plan in such a way that each successive level has the appropriate level of information for decision making.

As with any type of tracking, the first challenge is to determine what type of information is meaningful, determining the appropriate source for that information, and creating the processes to collect, analyze, and distribute it.  Additionally, we need to establish accountability and timeframes for information collection.

Collecting Information

Typically data collection for tracking starts at the project level.  Fortunately we have a plethora of mechanisms and processes for doing this and, in most organizations, accountability lands squarely with the Project Manager.

Where it gets fuzzier is when strategic goals and objectives cannot be tied to a single project or measured during project execution.  Tracking the realization of benefits is a good example of where the information from the project(s) is not adequate for tracking progress to a goal.  Let’s say we have a goal of increasing client satisfaction with our website by 20% before year-end as measured by survey responses.  To accomplish this objective, we have identified 3 projects to improve different aspects of the site.  Two of the projects will build on the work done on the first.   We’re making the assumption that each of the projects will yield some improvement in customer satisfaction, but the full benefit won’t be realized until all three projects have been completed.

In this example, we do need to understand projects, both individually and in the aggregate, but this information does not provide any measurement for tracking achievement of the 20% improvement in customer satisfaction.  In this case, we need to recognize that the tracking process that yields the appropriate information resides not in the projects, but instead at a higher level of our integrated plan.  Furthermore, whoever is responsible for setting and achieving the objectives in that level of the plan is also accountable for reporting on the progress at that level.  In other words, when we talk about performance information flowing upward through the integrated plan, it is realistic to assume that additional information and analysis will be added at each level.

Data Collection and Reporting Cycles

Establishing the frequency for reporting against the various levels of the plan may vary widely even within a single enterprise.  That said, establishing minimum requirements including frequencies and content of status reports and plan updates is critical to ensure that the right information is available at the right time.  One approach to establishing these requirements is to determine key review meetings at or toward the top of the hierarchy and work backwards from there.

If the Executive Committee meets quarterly to review the strategic plan, then the level below should be doing their analysis and tracking quarterly – with enough time before the meeting to compile the results.  Lower levels will report more frequently, with the general guideline that each successive level updates its plans and reports at least once, if not twice, before the status report at the next level is due.  Unless there is a compelling business case for doing otherwise, tracking and reporting more than weekly tends to add overhead without much offsetting benefit.

Maintaining the Integrated Plan

Like any other kind of plan, the integrated plan is a model of what we expect to happen.  It gives us a yardstick by which we can measure our progress against our goals.   It is not exactly what will happen nor is it something that will continue to add value if not maintained.

Whether we’re updating the plan to address a performance variance, or changing a high-level strategic goal to respond to market forces, the integrated plan may need to change.  Processes for making and communicating these changes keep the plan relevant and helps maintain the linkage between projects and strategy.

Conclusion

In summary, linking individual project efforts to a strategy is more than throwing a bunch of projects at the wall and seeing what will stick.  Building an integrated plan that cascades strategic objectives down through the enterprise creates a clear linkage between strategies and tactics (projects) while clearly identifying interim level goals, objectives, and accountability.  The integrated plan also provides a practical approach to collecting information for tracking progress and making adjustments across an organization.

While creating and maintaining an integrated plan can be challenging, the value-add of ensuring alignment to a strategy is well worth the effort.