JOSEPH SABOExecutive Consultant| CGIColumbus, Oh, United States
I am conducting a PM analysis for a large state government agency. Historically, large-scale IT projects (particularly software development projects) have been managed jointly between the agency's Office of MIS and Program Areas (peer Offices to MIS who deal with the business side of this State Agency). The CIO of the Office of MIS is now tasked with the justification of why IT Project Management belongs in his Office of MIS and not the Program Areas. Makes sense...right? But there will be pressure from the Program Areas to retain some PM control, despite a lack of PM training. Are there any articles out there that justify why a Project Support Office belongs in its IT department, and not split among program/business areas? The more justification we have, the better. Saving Changes...
Sort By:
Frank WintersPhotographer and ConservationistSandwich, Ma, United States
Joseph, I think I understand your dilemma. I've dealt with the problem you describe and had some success. The key is in separation of the PMO (designed to deal with business issues) and the PSO (designed to support day to day project work). If the PMO is in a business area, its a very good idea to have the PSO reside in IT. This provides a way for the business and IT to interact.
See the attached ppt slide. This model was adopted by a client of mine -- they told me the identification of the PSO, PMO and Architecture groups as separate functional groups was a key to getting agreement in their organization (a large insurance company).
A very interesing question. Frank has given you sound advice. One of the core issues is differentiating the strategic business function of the PMO from the operational function of a PSO. I agree with Frank that there is a strong case for the PSO to reside in the PMO, otherwise project strategy and project functionality take separate directions.
A lot of organisations struggle with the basic question of where the PMO sits. Simple answer: It must be positioned strategically, close to the business decision makers it supports. For example if the PMO supports all projects in an organisation (not just IT projects) then it should reside at the organisational program level. It would be a mistake to place the PMO with any single technical arm (of which IT is one choice), because this 'type-casts' the PMO function as focussed singularly on a specific project type. It also robs the PMO of critical resources and communications.
Further food for thought. Consider classifying the roles of the PSO/PMO mix on a heirarchy of roles, each successively more strategic. They could be: (1) controlling project information flow; (2) supporting the project function (methodology, training, systems, people), and (3) managing the selection and direction of projects. These roles are not mutually exclusive,in other words they can exist simultaneously in an organisation. It may even be appropriate to start low and reach high later so that the PSO/PMO function grows with the maturity of the organisation. I suspect though, that is not the case in the example you cite, where the organisation already has a mature project approach and is seeking a broad range of operational PSO and strategic PMO function.
Regards, David Hudson, Australia Saving Changes...
JOSEPH SABOExecutive Consultant| CGIColumbus, Oh, United States
David and Frank - I appreciate your feedback! Our client has a unique situation here that I didn't clarify too well in my initial post. Their PSO will actually function as (what you and I think of as) a PMO. Many (though not all) Project Managers will report to the PSO, but the term "PSO" was chosen to downplay the rigid "management" aspect of the Office and emphasize the helpful "support" aspect of the Office. Robert Wysocki's "Effective Project Management" book sold us on this concept.
But you have identified the real rub of this: the business strategy is defined by individual Program Areas (each focused on a particular social service), not the Office of MIS (the IT organization). the Office of MIS is responsible for building their computer systems and providing IT support and for setting the strategic direction for all computer systems (i.e. standardized development tools, change management processes, computing platforms, etc). We are currently going down a path where the PSO (and Project Managers) will reside in the Office of MIS, but for each project, there will be a near-peer representative from the respective Program Area called the Project Owner. The PM will still be the single point of accountability for the project's success, and the Project Owner will advise the PM on a day-to-day basis and provide oversight of project staff who come from the Program Area. The trick here is telling the Program Areas that "even though you set the business strategy for this Agency, you are not the Project Manager." We're mitigating this by demonstrating measuremements/controls where the success of a project is judged by how well it aligns with business requirements. We want the Program Areas to be comfortable referring to themselves as "The Customer," perhaps finding solace in the adage that "The Customer is always right"...even when they're not in charge! Does this notion ruffle any feathers out there? Saving Changes...
Rather than ruffle any feathers,,,, quite the opposite. Your additional detail gives valuable insight into the rationale for structuring and PMO/PSO naming the way you have..
If the core of PM excellence is in the Office of MIS, and the project focus is IT, then those factors can be strong drivers for having the PMO/PSO there. The PMO could migrate elswhere in the future, but that would dependent on a range of organisational factors and drivers..
I think your governance overview is quite reasonable. Separating projects delivery from customer is perfectly workable with the right set of roles and responsibilities, business rules, and communication protocols. And obviously your project management methodology would reflect this governance structure..
Good luck with this model. One obvious risk is that the customer still feels that he/she has reasonable ownership of the initiative, and the project owner will be accountable for post-project lifecycle ownership of the deliverable. But again, the examples of your governance strategy indicate you have considered this vital issue..
Am sure you agree, the eventual success of your governance strategy is as much in the human and cultural domain as it is in the methodology and technology domain. What I call "Factor X". It is a real trick for the Project Manager to act in a way that ensures the project is run in accordance with the Office of MIS requirements but still retains full custome by in. A lot rests with effective relationships and clear communications ... would you not agree?
Regards
David Hudson, Australia Saving Changes...
JOSEPH SABOExecutive Consultant| CGIColumbus, Oh, United States
I'm glad to hear that you find this approach to be reasonable. After we make our recommendations for the PSO implementation, our client manager will have the job of selling it to the customer/Program Areas, so we need to try and predict risks and issues such as the ones that you mentioned. The Office of MIS also provides Production Support for systems, so there will be an going partnership between MIS and the customer. The greater risk to the success of this approach is the "Factor X" risk that you mentioned: the change in culture. I'm optimistic that an enthusiastic response by our client might rub off on other parts of the organization, but we're talking about a very large state government entity here. I'm afraid some (though not all) of the stereotypes about rigidity and reluctance to change are true! Thanks so much for your comments. I'll be happy to inform the client that our recommendation has the full support of the Australian PM contingency! Cheers...Joe. Saving Changes...
I would be intrigued to hear how you went with this initiative. Give me a direct email on [email protected] I stress that my interest is purely professional and not the quasi-consulting pitch that tends to show up in the threads regretably to often.
Regards
David Saving Changes...
Mark Price PerryBusiness Driven PMO Evangelist| BOT InternationalOrlando, Fl, United States
Dear Joseph, very interesting post and discussion threads. The comments and advice offered by David Hudson are quite excellent, in particular the X factor. And Robert Wysocki's book, "Effective Project Management" is a very good read..! From the prespective of a vendor that has worked with over 30 government organizations to set up PMOs of varying sizes, I would only add that the issues you address (project owner, project manager, measurement/controls, and inter-organizational/Program Area comfortability) have been very much in view and a key consideration for them - and quite a bit more so than what we have seen in commercial sector PMO setup. And due to the concern of the not so hidden resistance to change as well as other more difficult attitudes, virtually all of these government organizations proactively and quite successfully addressed this issue head on using two techniques.
First, a shift away from rigid methodology-oriented thinking to a more flexible process-oriented thinking, ie. flexibility within structure, not bureacracy; controls and measurements, not resource ownership; institutionalization of skills, not hero reliance and worship.
Second, an introduction of continuous improvement as a key cultural enabler and feedback mechanism for the organization (PSO, Program Area, MIS, etc). The end result is not only cross functional buy-in, but real teamwork and participation in getting it right. As Deming put it, "Fix the process and you fix the problem."
Also, we were surpised to learn from our government sector experiences that they take CMM quite seriously and even have a special extension to the CMM Model that provides for three additional levels of maturity and process adoption or more accurately put, lack thereof:
CMM -3, "The Saboteur"
CMM -2, "The Misfit"
CMM -1, "The Conscientious Objector"
Half jokingly, but with a serious undertone, assuming an organization (any organization, not just governmental ones) starts at CMM Level 1 might be an inaccurate and overly optimistic starting point. Rather than pretending to be at or on the road to CMM Level 5, these government organizations, almost all of them, were very realistic about the true state of things. Hence, the need to plan for and address organizational culture and thinking up front and to ensure (not assume) the achievement of the desired state: buy-in, real participation, and longevity of commitment and teamwork. Project manager skill helps greatly, especially when the leadership team of the organization sets the tone.
As you mentioned there might be some resistance to change, etc, just out of curiousity, do you plan to address this head on (and if so, how?) or do you more or less hope for the best..? I do hope you are able to share your progress as organizations of all types and sizes can learn quite a bit from each other..! Cheers and good luck..!
