Program and Portfolio Management evolution

In the portfolio of solutions and services we provide program and project management team plays an important role in the organization.

Basically the project managers and the PMO team is providing governance to the whole execution of projects through the execution of processes and the projects itself.

We started an improvement plan to evolve about these capabilities and our organization itself and we used Gartner “PPM Maturity Model” as guidelines of the actions we should perform to mature our PPM engagement with the rest of the organization. The methodology we have use to work on this has been Lean Six Sigma approach.

PPM-evolution

Some of the major actions we have done:

  • Define and execute a project review process for all major projects.
  • Economic review of the minor projects.
  • Focus on Change Request processes with sales people to push the Gross Margins up and cover the effect of the gap on scope.
  • Engage the PMO lead on the opportunities. On large opportunities a Project Manager is assigned since the opportunity stage.
  • Account review process and project review processes are linked and coordinated: month by month.
  • Training roadmaps and career paths defined.
  • Communications related to the evolution and changes of the scope and responsibilities of the PMO team.
  • Actions defined systematically on delays and budget splits.
  • Reinforcement of the risk management approach.

There are still so much actions to perform, but the evolution during last 18 months have been great.

 

Finance and portfolio management

I’m working on a set of accounts and solutions for my company, handling a portfolio at country level.

My team is composed by account managers where that handle the day to day relationship with customers, write offers, deliver services with the support of service managers, handle projects directly or with a PM…They do a lot of things, and they understand the importance of the customer touch, and all they need to do to sell.

If you have a team, you will have high potential people and average people. So you can expect that the knowledge differs in general depending of the person behind.

My point today is that I found the knowledge all these guys have about finance is so poor in general. Things like the P&L rules of the company, how the indirect costs are allocated, how are the revenue recognition rules are, how to make accruals… is basic knowledge they need to be able to understand what is happening in their accounts.

The person handling the portfolio before me did a good job organizing finances, having clear figures of pipeline, gap plans, forecast… but s/he never teach or coach the team about all the basic rules that are impacting the account managers.

This lack of understanding has derived into a lack of interest on the results or on understanding why so many of them are delivering poor operating income figures. The second derivative of the impact is the fact that they had not under control the impacts of bad delivery. They know they have problems on the contracts, but they are not able to tell me how much in dollars is the quantity of the impact.

My first step on the portfolio has been to review all the finances with them:

  • Account by account,
  • review the gap of the contracts with respect the expected gross margin, direct cost margin.
  • Understand what are the reasons of our poor operating income (this is outside of the accounts).
  • Explain what are the basic rules of the P&L, and how some behaviors affect more than others.
  • Enable actions at account level and at country level, reviewing periodically all these actions.

The results are being interesting, once this first whole review of accounts conclude, I will be able to focus on growth and sales.

P3M3, what is the priority

This maturity model is very well known by the project/program/portfolio community and one of the questions I would like to ask, is: once we have done an assessment of the situation we have in our project, program or portfolio, where should I start with? We all have limited resources and we cannot fix all.

The classical view of the assessment summarizes the situation with this view:

P3M3-classic-assessmentThe immediate answer that comes to my mind is to start with the less matured aspects. But is this the right criteria? Am I taking into account all relevant aspects?

If we organize the report taking into account the value for the cutomer (which could be a customer, the steering committee or the PMO) we could have a situation as this:

P3M3-value-chain-chart

Our goal is to increase the maturity of the execution of these areas, so the black lines just mark the desired trend we want to give to it. We have limited resources, and to set the right priority is key to maximize the improvement.

  • The vertical position of each area represents the priority of our customer.
  • The horizontal position represents the level of maturity of each area.
  • The blue lines represents the latest desired trends or “urgent” priorities marked by the customer.
  • I have highlighted in red, yellow, green the initial priorities we should take into account for the actions to be done.
  • Special attention of risk management, that, even do that it is more mature of others, it has a high relevance on the benefits management of the program. The improvement on this area will improve the benefits management and the stakeholder engagement.
  • Special attention to Financial Management: initially it’s not a high relevance topic, but the fact that we are closing a fiscal year, makes it important to understand how we are.

Now the difficult side of our real life: Define the actions by area to be launched, performed, measured and communicated.

Sales complaints against the new CRM solution

With SalesForce recently implemented as CRM solution in the organization, I have seen the two major teams complaining about the situation:

  • Business department (sales), argues that the solution itself is not useful, and that it does not cover all sales needs of the sales people.
  • IT organization, argues that the capabilities that exist in the solution are not being used, and hence, it does not make sense to continue evolving the tool if the tool is not being used.

…And then the game starts…

The bottom line is that SalesForce itself is a powerful solution that includes a lot of best practices that SalesForce team has been learning for years. This is the reason it has become a standard in so many organizations. The basis solution requires a good configuration and initial adaptation of the solution for a given organization. Doing this well, the basic solution should be enough for the organization to operate.

Thanks to Force.com, you can customize the tool and improve some of the functionalities and capabilities that the tool offers to the end user.

You can create specific dashboards, reports, background processes, etc. All this is “nice to have”, but in a bare bones organization (which is the case here), we have to discover first what the key priorities we have to attend are. If we do a list of desired capabilities, what are the “critical” ones and what are the “nice to have”?

First, we need the involvement of management teams in different aspects of the sales processes. What can business/management team and its individuals do? Too many things, some of them could be:

  • Use the CRM solution: ask for actions to the sales representatives, ask if they need their support on a key commercial action.
  • Determine that the CRM is the only source of trust in the sales process: all has to be there: reports, actions, planned visits, contacts information, relationship we have with them.
  • Use the reports: do they reflect what they need? Do these reports help them to fulfill their sales goals?
  • They have the tool and the data, they have to use them to turn this data into information that once that they in their minds, they will be able to think beyond.
  • Understand what, how and what the CRM solution does and understand what they really need.

Second, we need the role of Business Change Manager (BCM). This can be a full time person or a partial time person with this responsibility on top of his/her duties. The second option is the more frequent alternative.

When CRM is implemented, it is expected that the solution deliver some outcomes. These outcomes are translated to capabilities for the organization; we have to ensure that these capabilities are translated into real benefits for the organization.

During the implementation of the CRM solution, the project team starts to realize the benefits of the solution, but once the project is closed, the project team disappears and the role of BCM is key to continue realizing and measuring that the benefits are realized.

Staregic-context-benefits-managementI’m sure that the implemented CRM you have has so much capabilities that are not used by sales and that they should be used to improve the sales cycles. Again, sales leadership team is the organization with authority to change the situation.

Third, once the CRM solution is implemented, new needs appear, they are detected by users, and they have to be managed by the BMC. There will be so many needs, and we have to define the way to manage them: what are critical, nice to have…

Fourth, competitive intelligence (CI) team has to interact with the CRM tool. They analyze the market, define areas of improvement by regions, by division, etc. These analysis needs to be followed by actions from the sales teams. The interactions of sales and CI team is key to push the achievement of new customers and new opportunities.

This case has some specific actions that are related to the specific situation of the customer, but they can be moved to other organizations.

Planning and controlling transition

The sample below comes in the managing successful programmes book. The diagram describes a simple example showing outputs, transition management and benefits realization.

MSP-planning-and-controlling-transition

  1. Benefit baseline measurement, done during the development of the blueprint to understand how we go from the situation “as-is” to the desired state “to-be”.
  2. Output, the project has been delivered.
  3. which is received by the business unit as Enabler,
  4. to take into its operations (Sustained business operations).
  5. Business change management, changes may be required for this single enabler to embed it into operations.
  6. Operational outcome, is the achievement itself at operational/business level.
  7. Benefits realization, must be tracked by the Business Change Manager (BCM).
  8. Embedded change, a change that sticks.

The cycle is simple, and so much times is not understood by people around a program. I recently have seen how the role of Business Change Manager was lost after a program concluded, and there were no follow-up of the business benefits after that: a completely waste of time/money/effort for an organization who invested a lot on such program.

Program Control

A Program is controlled from different axis and these controls are required by different stakeholders. To attend all of them in a efficient way requires understanding of all this.

Program control is a process composed by activities where corporate group ask about the evolution of the program in one area (Finance, legal, quality assurance…). This process has to be established since the program inception.

The aim of a program and project are different. The aim of the program is the realization of expected benefits, through the achievement of desired outcomes. The aim of the project is the delivery of the outcomes and capability. The difference may lead to tensions between project and program control processes. So much people know this and if the program has detractors, they will try to use this tensions to add more pressure.

Re-use communication channels. The communication flow between the program, its projects and the business operations should be based on the governance standards. In this way, when control activities are required, if documentation and communication channels are well established, the addition of these stakeholders is easier.

Manage a program does not mean micro-management of its projects. Projects should be empowered but need tolerances and limits, in order to ensure that they do not  exceed their delegated authority. Allowing the project managers to manage their projects within the tolerances set by the program is a essential part of good program management. It will also give a clear view to the “controllers” about the situation of the program.

Ask Delivery Assurance. Big corporations have DA groups or QA teams that execute audits on programs and projects. Even if you have go through these processes, it is good to ask during the definition of the program, when the QA audits will be performed, what type of information they are going to require, and if there are extra requirements.

Keep your map of dependencies. You will have 1) internal dependencies to the project, 2) intra-dependencies on other programs and 3) external dependencies. When something fails in a program and you are reporting to a control audit you will be asked about “why” this is affecting you and what is the impact. To have a dependency map, looking into the projects as back boxes with inputs/outputs, will provide a crucial control tool for the program manager. Project assumptions is a source of information for program dependencies: use them, and ensure they are coordinated and understand the program dependencies that could affect to them.

MSP, Benefits management

Programs are primary driven to deliver benefits, this is done by projects that create outputs, which builds capabilities, which transition into outcomes that serve the purpose of realizing benefits.

Benefits-Realization-GovernanceI created this template based on the principles mentioned on the Managing successful Programs, so I can use for guidance during the execution of the programs:  MSP-Benefits-realization.

To take into account that the communication plan of the program contains a lot of the aspects related to benefits.

MSP-Training-benefits-management

Dashboard for organizational changes

In the improvement program I’ve worked, we have done a set of improvements and definition of processes for the different areas of the business we decided to work on.

Every aspect of each process has their details, and they also are linked with the others.

I created this chart to represent how they are going on in terms of evolution, try to discuss and prioritize next steps.

Process-improvement-DashboardWe could not put in place all the improvement actions at the same time as operations and business day to day do not stop, so we planned it in this way: launching each improving at different quarters and introducing others once the previous ones were matured enough.

Process-improvement-Dashboard-calendarIn some areas we have advanced a lot, in some others we still have to improve, but in general the adoption of these standards have improved the efficiency of the operations and the understanding of “what the others are doing”.

Program organization and its own transformation

Programs evolve as all in life, mainly because the different phases of a program requires different skills, teams, and resources. We go from a high degree of ambiguity in the inception phase, progressing and gaining shape during the definition, moving to a delivery mode during the execution and “get the job done” during the closing.

In some major programs, you can change the people leading the program organization to reinforce the skills required for each phase with the best profiles of the organization. In the majority of the cases there are not changes, but the organization and its leadership have to adopt different attitudes/styles depending on the phase of the program. This is important because we have to be able to change the pace of the program and transmit to the rest of the teams that the focus changes.

  1. Program identification: The nature of this phase is so focused on research and analysis and there are so much SMEs working on different activities. An environment like this can best be lead by facilitating, provide guiding, offering suggestions and finding the right people to complete the goals of this phase.
  2. Program definition: For the design of all aspects of a program, different topics and groups are involved. The preferable style must focus on coordination, provide priority to the main elements of the program that evolves in different ways and promote the work done in peers of different groups.
  3. Program execution: We know what to do and have authorization to do it, so let’s concentrate on the delivery. Here an instructive style must ensure the task completion with a minimal disruption.
  4. Delivery of the capacity: During the program execution, the capacity starts to be delivered too. Here the business change manager should be measuring and cheking that the expected capacities are delivered with respect the program plan.
  5. Benefits realization: The focus of this phase is on the preparation of the organization for the changes and communications. Here good business analysis and planning skills are key to anticipate to the transformation and cover all gaps of the operational space, so a soft transition can be ensured. The acceptance of the changes by the operational teams is the key and an eye on it is paramount.
  6. Program closing: All activities are focused to complete all aspects of the program execution and the realization of benefits. Here the style desired has to focus on “get the things done”, combined with the analysis of results and the communications of the changes done and the benefits for the whole organization.

Behavioral attributes on program management

Cranfield University did a research related to behavioral attributes of the leaders when working on programs. The summary table of this research is added to the Managing Successful Programs book.

Attitude and aptitudes of leaders are summarized in a scale from 1 to 4, where 4 represents more awareness and capacity to lead the complexity of the programs. The research is focused on programs, but it’s perfectly applicable on other areas.

Program-Management-Behaviors