IT Project Prioritization and PMO Organization Structure

How Most PMO’s Function….

Most PMO’s fall into one of two models – either 1) they only provide overall guidance and governance (they define the process and make sure everyone follows the process) or 2) in addition to providing overall guidance and governance, they also serve as the resource pool for all PM’s.  For the purposes of this writing, I will assume the later.

In a typical PMO, there is a pool of project managers which are provided to the various projects IT engages in who report to a director or Sr. Project Manager who runs the PMO.  Projects requests come and are logged in some form of a tracking sheet (typically an Excel spreadsheet, although some organizations may have a database and/or software packages they utilize).  Because PMO’s typically do not have analyst resources, these activities are done a Project Manager.

As PM’s become available, either via completed projects or projects that are placed on hold, they are re-allocated to the next available project.  Typically the process to determine what project is next is rather arbitrary.  Very little analysis goes into the prioritization effort, sometimes it may be based on which project has been on the list the longest, other times it may be based upon the technology platforms involved while other times it may be based upon a rudimentary cost-benefit analysis (please note this is not a true valuation of the project).

So basically there is no real prioritization process.  Many times the next project is determined more by political factors rather than what is truly in the best interest of the company.  Because there was no effective analysis done, there are no effective benchmarks available against which to measure the project.

 

Here is how I would do it instead….

Organization

Obviously this varies based upon the size of an organization, but in general here is the organization structure I would implement in a PMO:

 

• Director: Owns the overall strategy, vision and direction of the PMO
• Program Manager (Sr. Project Manager): Manages a portfolio of related projects, typically these projects have individual project managers.
• Project Manager:  Manages individual projects
• Portfolio Analyst:  Performs up front analysis for project prioritization, grouped by line of business, depending upon the workload each analyst may support one or multiple lines of business. 

Program Manager would be aligned with each line of business (as well as one for IT).  Under each Program Manager will be a portfolio analyst (in some cases shared among multiple program directors) as well as individual project managers.

Prioritization

As project requests come in, they are evaluated by the appropriate portfolio analyst to determine the priority of the project. All requests are stored in Sharepoint or a similar repository, providing a master inventory of all outstanding project requests. The first step in the process is to evaluate the project request against a core set of criteria.  I would use the following factors:

• Project Valuation (not a simple Cost Benefit Analysis)
• Strategic Goals
• Complexity

Project Valuation is much more than a simple cost-benefit analysis.  A true project valuation will factor the project costs and anticipated savings over a period of time (3-5 years), convert this to present day dollars and evaluate it against the return that would be provided if the funds were not used for the project.

Strategic goal mapping analyzes the level of support each high level strategic goal (both corporate and IT) which is applicable to this project.  These are ranked on positive-negative scale with zero being neutral.

Complexity is the critical factor in analyzing the effort involved with the project.  Based upon the complexity, you can estimate the resources required to complete the project and the expected duration.

Now rather than just making an arbitrary assessment for the prioritization of the project -  one that is usually based upon who yells the loudest - the prioritization is based upon a couple of core factors which directly correlate to the goals of the organization, of which the primary goal is always to make money.  All projects are prioritized within the line of business rather than across the company.  When projects are prioritized across the company, the larger, more profitable business units get all the resources, leaving the smaller, less profitable business units to struggle.  This sets up an environment for the larger/more profitable units to continue growing while the smaller/less profitable business units are basically put in survival mode without the resources necessary to grow or expand.

Now we have a portfolio of possible applications by line of business with a true valuation as well as an alignment with the organizations strategic goals.

Doing the work

Now that we have a core set of factors that the project has been evaluated against, we can evaluate project progress against those factors.  This opens up a wide range of tracking and reporting, such as:

• Ability to show progress against strategic goals based upon project progress
• At a resource level, you can show the “strategic value” of a specific resource
• At review time, a resource can easily show how they contributed to the overall strategic goals of the organization

 

 

 

The Poor Customer Service Rating

The scenario

The IT department at ACME Widgets just received their annual customer service rating.  As part of this survey, business executives were asked to rate the value provided by IT. On a scale of 100, they scored a 29.  The Project Management Office (PMO) has been tasked with increasing this score to a 45 over the next 18 months.  Prior to Mark’s arrival 3 years ago, there were no standard processes within the Application Development group of IT, each team was free to define their own processes.  The result of this was most applications were fairly low quality, resulting in a high number of complaints from the users about the applications not working or not meeting their needs.  Under the guidance the Mark, the IT department has built what they believe to be a solid and efficient process based on industry best practices.  Mark had also established a Project Management Office to oversee adherence to these processes across all application development teams.  This was the first survey to be completed since these changes were fully implements, so Mark had been anxiously awaiting these survey results and was stunned at the poor numbers.

The Players

Stan: An analyst with the Project Management Office charged with making improvements to the existing application development process

Beth: The director of the PMO.  She has ownership of raising the value rating to 45 over the next 18 months.  Stan reports to Beth

Mark: The CIO.  Beth repots to Mark

What typically happens now

After meeting with Beth and receiving her new project, Stan eagerly sets out to solve the problem.  The first place Stan turns is to the internet to search for a better best practice, after all since the processes were based upon industry best practices surely someone else has had the same experience and solved the problem.

What should happen

The entire idea of the IT department having to distribute a Customer Service Survey shows part of the failure.  If the business units are your customer, then that makes you their vendor.  Vendors are external and typically (though not always) brought in to perform a specific task or solve a specific problem.  Many times vendors are also perceived as being concerned with their own self interest first.  The entire concept of the business unit being a customer implies that IT is not a trusted partner and automatically places barriers in peoples minds.  Instead, IT should be a partner with the business unit and seen as supporting the overall goal of the business (which is to make money).  If IT is seen as a partner, you do not need a survey to tell you how much value you are providing, you are witnessing it every day, it is ingrained in your culture.

The next problem is how Stan sets out to solve to come up with a solution and the over reliance on best practices.  There are a variety of numbers around what percentage of IT projects fail, I have never seen one below 60% and most seem to be in the neighborhood of 70 - 80%.  If best practices are truly best practices, then why do so many projects fail?  If IT were a partner with the business, instead of turning to best practices to solve his problem Stan would have turned to the business.  Then he would have discovered that the process improvements they implemented, while increasing the quality of the applications also increased the average project time from 12 to 18 months.  As a result of this, the business was unable to implement process changes that would allow them to increase their capacity, which resulted in lower revenue.  In this case the process changes actually hurt the real goal – to make money.  So instead of heading off to research to more industry best practices, Stan should have headed to the business unit and discovered what the real problem was.  Then his next focus would be to analyze the IT processes and determine how the efficiency could be increased while preserving a high level of quality.

The Goal

To take a line from “The Goal”, the goal of every company is to make money; everything you do in your job is in support of that goal

It has always amazed me at the number of technology people who lose focus of this simple fact – the goal of almost every company is to make money.  Your job exists to support this goal in one way or another.

I am going to do a series of posts around this simple concept.

Books

As part of my Operations Management class I have just finished reading "The Goal" by Eliyah M. Goldratt.  It is an excellent book - I highly recommend it.  I will be taking some of that and writing about applying it to IT organizations in the next few weeks.

Now I have started reading "The Real Business of IT" by Richard Hunter and George Westerman.  Between this and "The Goal", I should have plenty to write about.

Here we go....

I have finally decided to start a blog based upon my views of IT management (needless to say I disagree with a lot of how I have seen IT groups managed through the years).  I am halfway through getting my MBA from Purdue and will also write about items related to that which pop into my head and I have a passion for.