Fisher Information Technology Center
News Feature
IT Program Management Offices: a Report from the Trenches
Most large firms recognize the need for a Program Management Office (PMO), whether as a formal organizational unit, or as a small group of individuals charged with responsibility for coordination and success of projects involving information technology throughout the organization. In early April, 2006, several CIOs from the San Francisco Bay Area met to discuss what they are doing in this area, what’s working and not working for them, what is missing and what they have planned. This is a report from that private and confidential two-hour meeting, with corporate and personal names omitted.
The meeting opened with brief statements of what is happening regarding PMOs in several organizations.
A software firm recently bought another similar firm, and has put all managers through special training both to develop a common culture and to learn to use tools related to Program Management. A third firm created a governance structure to get the CIO out of the ‘hotseat’. The business leaders see estimates, and they pitch their peers regarding the process. The business leaders do post-mortems as a group, and reviewed the project results (for fairly big projects – estimated to be above $250,000, including labor). The group ranked upcoming projects, using ITM (The ITM Software* Business Suite - *ITM SOFTWARE ® is a registered trademark owned by ITM Software Corporation, Mountain View, CA. – see http://www.itm-software.com) to quantify the projects for the group heads. Another firm now uses the same approach to manage the initial 450 projects in IT. They categorized all work by business owner and found that many projects did not have a business owner. These were dropped. ITM does have a necessary overhead in such an exercise. A semiconductor company has a weekly staff review and include all projects of all sizes. They built their own Domino-based system for tracking projects. The cost of the project must be shown to break even in the user’s budget. The CFO follows up to ensure that these savings were indeed realized.
A second semiconductor firm is just rolling out an ERP system and will implement ITM or something like it in the next year. Their project office is chaired by IT. They are implementing SAP, which involves completely re-inventing the company. They list the processes needed to run their business, then divided them into four categories – (1) Identity, (2) Priority, (3) Operational, and (4) Mandatory. They asked themselves which four or five processes would take to company to the next level of success. For example, when Dell asked themselves this
question, they came up with just one – Supply Chain. In this semiconductor company’s case, the answer looks like it is going to be Customer Support. The balance is toward the information needs of the new world business – what process and technology supports that.
To have an effective Program Management Office you must also have an effective governance structure. For example, at one hardware firm the governance group met monthly. They documented each project in a project book, and used the ‘red, yellow, green’ coding to denote criticality. Another hardware firm had cost estimates, and an IS Steering committee that met quarterly. This was the directly reporting managers to the very top executives of the company, who would ‘horse-trade’ to get the resources to the right projects. The CIO gave advice on technical issues (such as project technical pre-requisites that might not be obvious to others, etc.). A big commercial bank prioritized projects into A, B, and C, with projects having no user representative present not remaining on the list. So, different companies use different approaches to Program Management.
How many firms have separately organized PMO groups? The second semiconductor company mentioned above does PMO within IT, not as a separate office. A hardware vendor’s CIO reported that it has PMO reporting into the Business Process Transformation management area. A software company has a 1,000 person IT shop, and the PMO function is three people. At a specialty software firm, the IT group owned all the projects at first, but they have now been transferred to the business owners. Now IT does not give updates on projects, the business owners do that. IT will give the status on projects that are exclusively IT, or on the IT components of other projects. This firm’s IT does own the infrastructure, however, and must sell projects related to that area just as the business area heads do for theirs. The semiconductor company’s IT area also does not own the projects, the business groups do.
What is the role of Service Oriented Architecture (SOA) in Program Management? The relevance is that a blueprinting operation is needed to let you experiment with ideas. Companies have custom systems now that are not service oriented, so the problem is how exactly to move to an SOA environment. The key is to know how to embed the legacy systems. A wrapper is needed for such systems, so that they need not be taken out or replaced, but can still be used.
Assuming that the legacy issue is somehow solved (admittedly a big assumption!) or that a wrapper process is found, what does the continuing operation of the business need? Can the total cost of ownership of SOA be justified?
Any such SOA must be standardized but the “giant database companies” of the world will not do this standardizing. Even companies with high margins, who can throw money at problems, sometimes find that does not solve them.
At a large commercial bank, there was a system which was essentially a boat anchor / spaghetti code. They simply froze the customer base on that old system, and then built a new system for new customers, leaving the old system to gradually die.
The value comes from the process. Can a PMO improve the quality of the delivered products? The second semiconductor firm is service-driven, built around ITIL and tied strongly to customer satisfaction. Their budget is divided into three areas: (1) Sustaining, (2) Enhancing, and (3) Transforming. They slot all projects into one of these three areas each year. The goal is to move 5% of the sustaining projects up each year. Sustaining is efficiency, where enhancing and transforming are effectiveness – thus, they want efficiency to improve 5% each year.
A bio-tech firm uses the same budget management process as does the software company. A desirable goal is to get the ratio in the three areas to 60-20-20. The bio-tech firm prepares a stack by “least” to “most” degree of control on budget components / projects. They look for transparency – showing every person, every dollar. At the second semiconductor firm the business people determine how much money IT gets, and there is no cap on it. Rather than hire two more sales people, they may decide to do a project that would make their entire existing sales force more efficient. They want to put pressure on the ‘transforming’ projects, and this requires that people take risks.
In general, all agree that we should have Program Management Offices or a Program Management function. Big organizations tend to have a group for this, and those with fewer than, say, 1,000 people in IT tend to have designated ‘people’ but not an office. The function is what is important.
What processes do people include under the Program Management Office umbrella? A beginning list would include project management, tracking of projects, project methodology, resource management, project templates, and training. Some firms also do a list of ‘consequences’ for when a project goes right or when it goes wrong. For example, one tactic was to use a rubber chicken to take note of a person who violated a process. A program management associate would actually hang the rubber chicken around the neck of the offender – to much laughter, but the underlying message was very serious.
Regarding Enterprise Business Processes and how to address the legacy system issue, one attendee drew an array of small boxes on the board, labeling them with ‘legacy’ names – CICS, Batch, SOX, IDMS, “plug”, etc. To the left he drew a set of boxes, labeling them as ‘ERP’, which may have multiple iterations. Below that, he drew a dark box and labeled it SAP, with an arrow from the array of legacy boxes to the SAP box. He said that it makes sense to put in a ‘vanilla’ SAP system and let people join into it. He said that to differentiate competitively, you go towards a service-oriented architecture, and drew a big box to the right side of the array with an arrow to it, labeling it “SOA”. Then he drew a dotted line around the whole ‘legacy’ environment, and said that you could then put a message queue around all of it. You can then use the functional elements almost biologically --- throw a message into the queue, and each system listens for one affecting them. Finding one, they may pick it up and generate three or four more into the message queue.
This allows for a quick solution for the business processes, while allowing for a slower approach to moving into SAP. When things become standardized, more can move into SAP. The curtain becomes the SOA, while the ‘behind the stage’ is all the systems. You can do the wrapper with TIBCO software (copyright 2000-2006 TIBCO Software, Inc. – see http://www.tibco.com).
You need to do a data dictionary to make this all work -- to enable the bridging between systems. As you mouse over a field, a window will pop open that tells all the various definitions. You need to be able to integrate new systems into the data dictionary. The nature of such a change is mostly ‘adds’, with very little revision. But you must do a lot of analysis to agree on definitions. Over time, people will start to use the common wrapper system data names.
In conclusion, with PMOs, the idea is that somebody must drive projects through. The goal is for senior managers to think like they are managing the whole company. The culture at some firms would not look well on the idea of ‘one owner / one driver’ – they feel that projects need to have an overall view. Some of this issue of ownership may also be traceable to the nature of the firm – e.g., hardware versus biotech – or the nature of the industry. Regardless, the overall goal is quick decisions and accountability.
