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.

Life after project completion: Is a project complete without benefits realization?

In our day-to-day project management and PMO activities, the easiest and the most important thing missed is planning ahead for what happens AFTER we cross the finish line. So technically speaking, once project managers hand over the reins of the completed project to the business owner, their job is just half done. For a project to be considered complete, project managers must focus on the other half, which is “Benefits Realization”.

Benefit realization is the confirmation that the value a project was expected to generate really does get delivered.  In our everyday project management lives it is easy to get buried in details around task management, risk mitigation, resource capacity, balancing budgets and all the other moving parts.  We often forget why we set out to do the project in the first place:  the delivery of a product or service, an enhancement or improvement, or a capability.  For example to meet some new regulation, standard or market demand.  But what if, after we deliver the goods, and did exactly what the customer asked for, we realize that all the effort and resources we used to deliver the project don’t amount to what they were supposed to?  That’s exactly what benefits realization is all about.

We’ve all heard of ROI – return on investment.  It is the concept of an investment of some combination of resources (people, money, equipment, etc.) yielding a benefit to the investor.  A high ROI means the investment gains compare favorably to investment cost. As a performance measure, it is one of the best methods to evaluate the efficiency of an investment.  ROI does not exclusively have to be in financial terms.  It can easily be an operational advantage, an improvement in position, or other positive change.  In order to compare the efficiency of a number of different investments we need to compare like measures, which is why a financial ROI is one of the most commonly used.  Unfortunately, without benefits realization, our ROI is simply a guess.  And that is why benefits realization is so important.

I’ve discussed with   many of our clients about this and have found out that there is a need for a wide degree of maturity around the realization process.  This is an indication that while the concept of realization is gaining interest, it is still far from a mature practice.  Which presents a great opportunity for those organizations that are not doing it – now is a great time to implement this practice.

How to launch a benefits realization initiative?

One of the best approaches involves setting goals, tracking against those goals and including a ‘hand-off’ step, similar to the passing of the baton in an Olympic relay race.  Tactical steps you can take include:

  • Set your sights:  using whatever calculation available, combined with experience and validated by results from similar projects, come up with a target for what the value you think the project will deliver.  Set that as the initial estimate.  Enlist the help of a financial leader or controller to help set the original estimates.
  • Continual monitoring:  Using the initial estimates or targets as a first guess, continue to refine the success factors throughout the lifecycle of the project.  These are often called forecasts or committed values and are more accurate than the original estimates.  It is best to continue revising these figures throughout the lifecycle of the project.  The objective here is to have these forecasted numbers eventually match the actuals.
  • Start tracking actuals now:  some project can actually generate benefits even before the project is complete.  What a great win for the project team to be able to report these.
  • Put a plan in place: Add a milestone or stage beyond the Complete step called Close or ‘Realization’ and set a validation step 3, 6 or 12 months after the project is complete.  It sets the expectation that the work is not over at Complete.
  • It is outside of the project manager’s responsibility:  As the project comes closer to its Complete or End date, engage the financial sponsor and the process owner (the person who is benefiting or owning the project’s or product’s outcome, improvement or change) and have them start validating and “owning” the numbers.
  • Go back to the beginning:  how accurate were your original estimates compared with your forecasts and your actuals?  Take those learning and apply them to future estimates.  This is called continual improvement – applying lessons learned and best practices to improve the entire PMO.

One last point is that it isn’t always about the money.  Sometimes projects generate other value, such as an improvement in customer satisfaction, or increase market share by launching a game changing product.  It is important to be able to quantify the value of these types of projects even if they do not generate direct revenue or cost improvements.  Many organizations call these ‘Level 2” or “Indirect Benefits”.

Finally, is a project complete without benefits realization?  To the project manager who’s already run their marathon and marked the project as complete, I expect their answer to be ‘yes’, but common sense tells us otherwise.  As a best practice, one of the most important factors in a projects success isn’t “how we did it” – coming in under schedule or under budget – but “what we did” – that the project delivered what it set out to do.

Organizational Change Management – Part 2: How Does Change Impact Individuals?

When we make a change, individuals may be asked to take on unfamiliar or uncomfortable new roles.  Life becomes less predictable and less controllable.  Individual status and standing is affected as those who used to be considered experts become learners, just like everyone else.   By examining and discussing an organizational change in light of how strongly it impacts individuals and how they are likely to react can provide valuable insight into risks associated with resistance, non-acceptance, poor morale, fear, turnover, etc. While the project team can take an initial pass at this, participation by affected individuals from multiple organizational levels will provide a more realistic perspective as well as valuable input around mitigation strategies.

Questions to use in identifying risks from disruption may include:

  • Are different skills required to use the new process (or tool, or methods)? Are they related to the existing skills?
  • How much of a change does this represent to the person/people performing the work?  Will this create more work or less?
  • Where did the request or idea for the change come from?  Do the new processes address a problem identified by the people doing the work or is the primary impetus external (required by someone other than the impacted organizations)
  • Will this change result in staff changes, reallocation or reassignments?  Do people believe it will?
  • What is the level of additional effort required to make the change?  Do individuals see the additional effort as excessive?  Is the organization willing to accept a temporary drop in productivity as a result?

 How Does Change Impact Organizations?

Organizational structures refer to the organizational constructs which have the potential to support (or derail) an organizational change.   By the organizational constructs we mean the structures that define the organizational hierarchy (who’s in charge, who reports to who), the agreed upon roles, responsibilities and levels of authority.  The organizational structures define who makes decisions and, in some cases, defines the processes for how those decisions get made.  Organizational structures exist at many levels; across the enterprise, within individual departments and in the form of temporary organizations which may include committees, task forces and project teams.  An individual project can both affect and be affected by organizational structures.  Additionally, the organization structure of the project itself may contain risks:  conflicting functional objectives or approaches, different toolset and standards, or different reporting relationships can inject risk into the project.  This is especially true when the members of the project team are from different companies where the interaction between the members of the team may have contractual or financial implications to one party vs. the other (Hendrickson 1998).

All projects are subject to risks related to organizational structures.  Loss of sponsorship or priority resulting from leadership changes, changes in decision-making processes, renewal of commitments from reorganized functional areas all introduce risk into the project.  Also in any project, the structure of the project team itself may be the source of certain risks.  Weak matrix teams must consider the risks associated with negotiating for priorities and scarce resources with functional managers, while dedicated project teams must manage the risks associated with staying connected to and consistent with the direction of other parts of the organization.

There is however evidence that there are two other types of risks specifically associated with organizational change:  1) the impact of changes on the way an organization is structured and interacts with others and 2) how well the project integrates or fits into the larger organization.

When a project is going to impact an organization structure, our organizational change strategy must consider the socio-political implications of the changes being proposed.  Often changes are perceived by an organization or the individuals within it as a threat to power, control, influence, status, access or resources (including people and money).  Concerns may also arise about the dynamics of interactions between organizations based either on past experiences or a desire to preserve the status quo.  In either case the reactions, both rational and emotional, may manifest as vehement objection to total withdrawal of support for the project.  What at the outset of the project may seem like a straightforward set of decisions about who is going to do what, become complex negotiations escalated up to the most senior levels of the enterprise.  In some environments, even a minor change to the composition or responsibilities of organizations may require huge amounts of time and resource to redefine and document the detailed process and interactions of those reconstituted groups.  While some organizations are adept at making these changes, others are much more resistant and may require more time to fully design, document, and review before they will accept or relinquish responsibilities.  In efforts where the organizations cross corporate boundaries (multi-company efforts) contracts may need to be renegotiated or terminated.

In considering organizational disruption consider the following questions about the proposed or planned changes:

  • Will this affect the overall role of an organization?
  • Does this affect the level of control a department has over their work?  Will this be seen as a loss (or gain) of control?
  • How will the project team interact with the departments?
  • How will this affect how organizations interact?  Will it make one organization more dependent upon another?  Less dependent?
  • Does this affect staffing levels or reporting relationships?
  • Do we know the procedural requirements of the functional department.  Are there any processes or procedures which are a mismatch to how we intent to operate?

Implementation Activities

Once the nature and scope of potential changes have been identified and understood it is reasonable to assume that the appropriate activities needed to effectively address the organizational change requirements of the project can and will be effectively executed.  But here again, those project teams not familiar with or sensitive to organizational change activities may find themselves challenged to determine how best to execute the organizational changes needed for successful project implementation.   Fortunately, there are a number of approaches that can be used, individually or in combination, to address organizational change.

Communication and Commitment

Good communication across an organization is always important, but when an organizational change is involved the importance increases.  Communication from the most senior levels of management demonstrating commitment and support of the change is critical and is most effective when the rationale of and urgency for the change is clearly explained.  When Lou Gerstner took over a troubled IBM in 1993 he recognized that employee communication was an essential part of the effort to transform the organization and return it to profitability.  Gerstner knew that the impending changes would cause pain in the organization but that they were necessary given the magnitude of IBM’s crisis.  He recognized that as CEO his role was to “strongly and continuously” communicate both the crisis and the plan for addressing it:

“All of this takes enormous commitment from the CEO to communicate, communicate, and communicate some more.  No institutional transformation takes place, I believe without a multi-year commitment by the CEO to put himself or herself constantly in front of employees and speak in plain, simple, compelling language that drives conviction and action throughout the organization.”  (Who Says Elephants Can’t Dance?: Leading a Great Enterprise through Dramatic Change,  Louis V. Gerstner, 2003)

While Gerstner’s transformation effort was far broader than the organizational changes associated with most projects, the need for strong consistent executive commitment and ongoing communication of that commitment are equally essential.

Two-way communication between the project team and the impacted organizations is also a critical component for successful organizational change.  While executive communication focuses on why the change is needed, these need to focus on the content of the change (the what) and how it will be implemented.  By communicating what and how, impacted individuals and departments have more time to think about and adjust to the upcoming change.  Likewise for the team – open, two-way communication between the project team and the impacted organizations can significantly reduce the “element of surprise”, where unknown objections or problems surface at the last minute.

Phasing and Chunking

Another strategy for mitigating risk is associated with organizational changes is to introduce the changes gradually either by phasing in the changes within the project or by dividing a larger projects into phases or ‘chunks’.  From an organizational change perspective the incremental approach has a number of benefits.  First, smaller changes cause less disruption which in turn may reduce the amount of organizational and individual resistance.  Second, smaller efforts may be seen as more achievable, encouraging support and buy-in from impacted organizations.  Third, lessons learned in earlier stages, about the organization and how it reacts to change, can be integrated into later efforts.  Lastly, individuals and organizations involved in earlier organizational changes can be called upon to assist in “selling” the effort to others.

Coaches

In implementing new products, systems and processes we often ask individuals to quickly acquire and apply new knowledge on the job.  Even with the best most comprehensive training programs turning “what one learned” into “what one does” back on the job can be frustrating and stressful.  Combined with the demands of “getting the job done” these frustrations and stresses can result in a backlash that threatens the success of the project.  One strategy that reduces impact  is providing coaches to support the initial implementation.  The role of the coach is to help people quickly work through problems or issues, share knowledge about nuances of the new product or process, and act as a conduit for feedback to the team on usability issues or other functions and features that were great ideas in the lab, but not in practice.

The most effective coaches are individuals who were actively engaged and part of creating the new product or system being implemented.  These people intimately understand not only the mechanics of using the product or process, they understand why certain things were done the way they were and the intent of certain design decisions. Optimally the coach is able to share that knowledge – enabling the new user better understand the rationale and apply the change more effectively.

Evaluating Organizational Readiness for a PMO

According to industry experts, a majority of efforts to establish a Project Management Office fail because leaders do not sufficiently assess organizational readiness for change. How do you know if your organization is ready to take on the challenges and embrace the opportunities of implementing a Project Management Office?

The best time to assess an organization’s readiness for change is well before you begin implementing a solution. The importance of assessing your organization’s readiness for change cannot be underestimated. Projects, resources and work will form the core of any PMO; hence, project management maturity is a critical factor in determining what systems or practices should be introduced and to what level of functionality.

But remember, just because you are not operating at top levels in every discipline of a Program Management Office does not mean you’re not ready to take the plunge. Deployment of a PMO is a journey–one that goes through many iterations and cycles as it grows and matures.

To begin with, don’t be surprised if you end up spending the bulk of your design session answering just the basic questions. It’s imperative to identify the pain points before finding any kind of solution. The challenge here is that this is often a “rubber hitting the road” moment, where different departments and groups realize for the first time how different they think core processes are managed. Looking at these symptoms will help you to determine whether the need for a PMO exists in your organization:

  • Project Inventory: Do you have a clear record of every project and initiative under your area of control? One of the most basic functions of a PMO is to gather record and track progress of all initiatives so you can make informed decisions on which projects to invest in and on which projects to pull the plug.
  • Strategic alignment: If there is a lack of strategic alignment of individual projects with the overall objective to achieve desired results, the effectiveness of projects delivered will always be unsatisfactory. This is often called “doing the right projects”.
  • Project intake and selection: Without a well-defined project intake process, there is no way for the business to effectively prioritize new investments with business priorities.
  • Project overload: If there are too few resources available to meet project demand within an organization, it will extend the project delivery time and provide very little visibility into individual projects
  • Resource bottlenecks: An immature resource management process can lead to resource contention, underutilized resources and late project delivery.
  • Lack of established processes: Without established processes and consistent use of the processes, the risk of project failure rises.
  • Lack of approved tools: A lack of approved tools can result in each project manager using a different set of tools and will likely be overloaded without a way to make smart tradeoffs.
  • Lack of visibility: An organization that has little or no visibility into the various projects that are currently going on is essentially sailing blind. The ability to monitor projects in various businesses and align them with the strategic plan is vital to a company’s success.

The next step would be to gauge the maturity level of the organization by just looking at some of the most fundamental processes already in place for different projects across the system. For example:

    • Are processes clearly defined or are they ad hoc?
    • Do users use the same tool consistently or is everyone on their own when determining what tool works best for them?
    • How are projects being managed at different task levels?

The answers to the questions will not determine if an organization is ready for a PMO–they will help you set expectations for what is possible and where to focus your energy to set realistic and achievable objectives for deploying your PMO.

Once you have clearly identified the information that must be captured for all your projects, clearly define what processes will take place to execute on them. The level of project detail and the depth of your processes will help determine maturity and corresponding functionality that should be introduced to the business as a part of the PMO.

All this analysis activity is neither a gap analysis nor an “As-Is/To-Be” analysis. Rather, it is an analysis of the needs of the business. It could be compared to a market analysis that organizations do to understand their markets and identify products and services to match that market. The objective here is to identify the challenges, pain points, objectives of the business, and to learn as much about the business and its strategy as possible. These translate into opportunities for the PMO to be a “value-add” department instead of an “overhead” department–and makes it easier to make the case for a PMO to the leadership and the rest of the organization.

In my next article, you will learn more about setting up a PMO charter and how to introduce PMO processes and tools within an organization.

Programs and Portfolios – Striking Strategic Balance

A kid squeezes a couple lemons, mixes it with some sugar and water and sets up a table on their front step. After a few hours of minding the lemonade stand they have a fistful of quarters and dollars to show for the efforts.

Your company is a little more complicated. You develop, market and sell products and services that number in the hundreds or thousands. Your clients’ needs are as complex and sophisticated as the environment you compete in. Your teams in different business functions are working to prioritize demand and try to launch the project that is the most strategic and valuable, while considering risk, complexity and time. How does anyone balance it all? The answer:  programs and portfolios.

First a definition. While the two terms are used interchangeably, there is a distinction between them:

  • A program is a grouping of projects aligned by a common theme from an organizational standpoint. Examples can be seen as aligned by a product launch or a corporate strategy. Typically all projects in a program are aligned with that program exclusively – projects tend not to contribute to multiple programs at once because it makes aggregating information, especially financials, very difficult.  One last and important point is that there is a common understanding of the program’s themes and goals and every project in the program is working toward furthering the objectives of the program.
  • A portfolio is best described as the “dotted lines” where the project is aligned. Your project may be aligned with the ‘Mobile Apps’ program, but it is also aligned with the ‘Customer Service’ department, the Seattle office, the ‘Customer Retention’ strategy and the ‘high risk’ project category. Portfolios also tend to be personal:  “I’m the operations manager.  Show me all the active projects that are aligned with our Cost Reduction initiative, that are based in Paris, Pittsburgh and Sao Paolo, where Operations has contributed resources.” With all the dimensions of a portfolio, the common understanding is that projects can have a many-to-one relationship with multiple portfolios.

A great ‘real world’ example of programs vs. portfolios is that you report to your immediate boss (program), but also have responsibilities – the dotted lines in an organizational chart – to other groups or business leaders (portfolios).

So what is the best way to organize project? The most common ways are by business unit, by overall location, or by business function – all of these structures help group projects along a common theme or user community. All HR or IT project are grouped together, or all Aerospace or Currency Exchange projects are grouped together. This gives us a manageable size of projects to deal with. As a best practice, however, if you find that your organization reaches 50-70 active projects, it is likely time to further divide your program into sub-programs.

A best practice on portfolios is to treat them as personal lists of projects based on what is important to each key user. Since portfolios are “invisible” and can be as unique as the people who define them, it is not unusual to have dozens of portfolios for every program.  Portfolios also tend to be dynamic in that projects are launched and completed, and realigned based on the stage they are at, which can add and remove them from portfolios almost daily.

So here is the take away: when reviewing your project groups, ask yourself these questions:

  1. Is this grouping something that most people in the company are familiar with?
  2. Does the grouping remain constant – is it a fundamental structure in the company that does not change often?
  3. Does this grouping have common properties, and are they used by homogeneous groups?
  4. Do we often want to control or direct a group of users to this list of projects?
  5. Do the projects in the group align with other groups equally?
  6. Does this grouping look like it only serves a small group of individuals in the organization?
  7. Do projects listed in this group frequently change?

If you answered yes to the first four questions, you probably need a program. If you answered positively to the last three questions, a portfolio is probably better suited for this organizational structure.

Ultimately, there are no hard and fast rules for structure or size of a program or portfolio. Gather feedback from your user community to determine if the current structure works, or if it is too complex, too deep, tpp confusing or simply doesn’t meet the reporting requirements of the business leaders.