A practical 3 step approach to kicking off programs in different Business Units (BUs)

Okay, your company has committed to a PMO and has agreed formally or informally to the overhead. Having implemented in a BU, senior leadership is finding it useful and wants to rapidly expand the matrix organization.

Programs are kicked in different BUs and PMO is asked to sync them up and run them up to a common process. While the tactics may vary  from organization to organization (As there are different types of PMOs) , my experience is that it is possible to classify actions into just 3 broad steps

1. Setup Governance
2. Establish Teaming
3. Sign-off on portfolio/program scope [Not the project scope which is usually part of the Project itself]

What do I mean by this?
1. Setup governance - Getting the sponsor and resource managers to agree about project objectives and agree to review the same (together is important). Setting up a chair to resolve conflict if there is disagreement and agree on time commitments/schedules for reviews

2. Establish Teaming - Getting atleast the PM nominated (who will then estimate and track resources)

3. Sign-off on program scope - especially important as there will be a lot which will not be covered in the first pilot . Important to say what will not be in the new process


While there is a lot of verbose documentation on how to setup programs and follow a standard process, I feel that this is a kind of jumpstart guide (3 steps) to PMO nirvana rather than stall and run in circles in a large organization. Communicating this to executive management and getting their buy in is also easier.(Most of it is their intervention in these tasks)

References of some links on PMO setup
http://www.qaiglobal.com/downloads/Internal-PMO.pdf
http://www.projexc.com/pmo-set-up.html (Talks of a parts but not quite the steps)

Share

Subscribe to A.Karthiks blog

Path to process maturity - establishing benchmark processes

Simplify, understand, deploy and then enrich

Establishing a process from a benchmark, is not straightforward. While most people beleive that the benchmark shoul help bring them to maturity,

The process of establishment is a 4 step process

1. Take the benchmark and simplify - water it down and you will hate yourself for doing it

2. Get people to understand the elements, intent and purpose. Very often a complex process evokes fear, hence, having a process with just the core (obvious) intent fulfilled is a good starting point.

3 and 4. Use the process a couple of times, each time enriching the process. Ensure that the next project builds on the past projects process

One of the key roles of the PMO is to identify with the help of the senior management, the key deliverables from programs and work the above process to the benchmark. We have all heard the statement, it (the benchmark) works in company Y not here. It needs to be suited to our culture and organization. The above are 4 steps to align and get to the benchmark in your organizations context.

Challenges in moving to a project matrix organizations: People change management

Changing organization structures from a deep functional to a project matrix, involves substantial challenges in people management. There are  broad guidelines that may be useful 

1. Keep the end in mind - very often it is "courses for horses". You do fit your organization to the best people you have, period. Hence, neither your organization structure nor your role definitions for the new structure will be perfect. It is critical to identify what are the 1~2 items that you will NOT compromise [ Example, when establishing a program management organization, having it function neutral may be a critical rule. You can still accommodate people and new structures , provided you stick to this broad rule]
2. Changes have to be enforced once decided. There are 3 techniques - most textbooks talk of just two to handle the resistance to change
   

• (a) Carrot - make people comfortable and show them the possible growth paths/career plan in the new structure
  
• (b) Stick - make organizational compliance mandatory. Preached easily, but difficult to practice with your best guys
  
• (c) Inaction! or wait - Several fears arise due to fear of the unknown. In any change management effort, the only way to overcome this residual fear, is not by more written definitions, but often , by pushing the people into their new waters and waiting for them to settle down. [For those of you who have travelled by Indian Railways, passengers are finicky and fight for their seats only till the train starts. For the next 6-10 or 24 hrs they all settle down into well oiled positions without any external intervention. This is probably cultural, but then thats what change management is all about!!]
  

These may sound simplistic, but having a gameplan like this in mind and also documenting the new org structure, rules and approaches help to improve on a continuous basis.

PMO Maturity Model with respect to Project Issues: Value add from PMO

Most senior management expect the PMO to be aware of risks in projects based on (1) their interactions with project teams (2) cross project experiences



The 3 levels of maturity of a PMO are

1. Initial: The PMO is still getting to be aware of the programs/structure and processes. Further, the rapport with the program manager will determine the extent of the risk awareness

2. Reporting: The processes have been established. Techniques to effectively capture risk and resolve are commonly accepted by program teams and PMO. The project leaders are also confident of the methodology and the PMO is aware of the risks known to the project teams

3. Value added : The PMO has been well established and is working over a range of projects. Cross functional project experience enables the PMO to foresee risks in the program not self evident to the project teams.

Every organizations leadership wants PMOs to ramp up as fast as possible to Maturity level 3.

PMO survey and the PDCA

The PDCA (Plan do check act) cycle is a great tool in deploying any process. Simply put, the PMOs critical role is deploying project management best practices for value delivery. In this context, 

• Plan - Training and competence building + staffing / resource planning for programs (This includes involvement of PMO in strategic planning)
• Do - Support for greater functions and projects
• Check - Metrics and tracking
• Act - Continuous improvement

As PMOs mature (Over 3~5 years) , the check and act become more critical and important. For nascent PMOs, the first 2 are important. I think, this has come out very well in this excellent survey - PMO survey and webcast

Buridans ass and developing a human infrastructure for performance

Buridans ass is a classic where there is a thirsty and hungry donkey and lack of random events(a nudge of the donkey)  could be standing equidistant from both Food and Water.

In real-life there are 2 learnings from this - 

1. The difficult thing is to create ways by which you establish a means to measure and reward setting up the infrastructure for performance (getting food and water and the thirst donkey) in its place. Otherwise , there is always a winner take all of a new person who could potntially reap the benefits of the predecessor by nudging the donkey for performance

2. Innovation is the nudge. Most of us are in the process of hunting for food and water (incentives) with a process of linear thinking. The nudge creates the move to food or water in a different way since the world is full of opportunity anyway.

Credits: Fooled by randomness for leading me to Buridans ass

Program Metrics Dashboard design guidelines: 10 useful guidelines from experience

I have been experimenting with some metrics design dashboards for pipeline tracking of programs. I have used these guidelines and tricks

1. Keep it simple - the chances of making a super heavy dashboard is high - stick to fixed number of metrics (You want to add something, You have to delete something! - crude but effectie rule)

2. Let users use an excel sheet or a web page - dont make them use a complex database

3. Make users fill directly into a dashboard like page - that way they know how it will look rather than them filling a form and you creating a dashboard. This also provides them instant feedback on performance

4. On most companies, poorly performing programs report far fewer metrics than better ones. [A symptom of what you dont measure you dont manage (I dont beleive that you manage by just measuring though)]. More in the "red" zone is a better sign than No metrics. REPORT % of metrics filled in your dashboard

5. Achieve balance - report on cost, quality, purchasing, sourcing, delivery , issues et al. Failing to achieve balance will scuttle all-round execution and delay programs.

6. Follow  some simple xls rules: Validate everything using Data Validation rules, Use input messages that are descriptive, use comments in xls, format each cell based on the input format you need, unlock entry cells and protect worksheets,Test with sample data before distributing! - It is much better to do all this before you get it to the programs than to send out a poorly validated set of measures dashboard

7. Use charts were possible to break monotony

8. Keep improving and standardizing - it is important to let users know where to look for what information.

9. Create a mapping file for creating a summary from all project xls files and load into access or any enterprise database that you have. It is improtant to archive both plans and actuals on the monthly or quarterly rates at which PMO collects information.

10. Create also a reverse mapped dashboard to generate any of the metrics dasboard reports from the database.

Structuring the PMO

The debate between heavyweight vs. light weight PMO is less important than the freedom/authority and reporting given to Program Managers. Often the structure of the PMO is done only to facilitate span of control and less by decision on design of the PMO.


The structuring of projects into logical blocks or programs is an interesting way to control span of control without having a heavyweight PMO (This provides accountability with program managers and also the required span of control). Delivering a KRA definition of Program Managers is critical to success of the organization.

See article from where I picked the picture above for the reference.

Systems thinking and Product planning - Theres a hole in the bucket dear Lisa

Systems thinking and Product planning - Theres a hole in the bucket dear Lisa

Most product planners (program managers and PMO) spend a lot of time taking calls to break negative loops and establishing positive spirals. It is easy to get caught in organizational politics and a new process into the "hole in the bucket" scenario.

The process vs. experience paradigm: Establishing the PMO and managing the change

Establishing the PMO ,especially a process for product introduction is a challenge. Any established company trying to establish a new process is "running the trains and laying the tracks" at the same time.
Any process that does not match with intuition (experience based) is discounted as a poor process. Similarly, any new process that does not throw new insights is also discounted as a heavy process for doing something intuitively or from experience. Hence, establishing benefit of a new process is balancing the fine line.
We have also heard common complaints that there is no spirit in the templates and deliverable. People are churning the wheels without the spirit - so what is the "spirit". There are also numerous form vs. content debates
A proposed methodology is
1. Fill the forms/templates/deliverable
2. Check with common sense, get feedback on the content from experts
3. Create a conclusion from the deliverable
4. Highlight issues and closure plans, force learning's from the team (and incorporate in process)

The benefit of the process is only if we can ramp-up learning and standardize across programs to get the benefits of experience standardized.

Every one of these steps must be orchestrated for key programs by the PMO. Hence, while PMO strives for training members on the deliverables, it is crucial to drive debate on the content and signoff on outputs.