Part of my ongoing preparation for a presentation on EPM Deployment best practices….
A colleague of mine remarked a couple of months ago that the number one indicator of success in a MOPS deployment is identifying the owner of the Server implementation going forward. More often then not, the owner is a PM or PMO member who is dragooned into Server ownership. Alternatively, the owner is a member of IT who has little or no background in project management. In some cases, nobody steps up to take ownership – or the owner changes in mid-deployment. When this happens, the likelihood of long term success in the organization rapidly decreases.
Ownership goes a bit further than just configuring the business processes and reports in the system. There’s a complex web of interactions required to keep a Project Server implementation running smoothly. Borrowing from ITIL guidance, here’s a rough cut of the roles that should be identified to increase the chance of long term success. (Note that one person can probably perform many of these roles.)
First a few definitions of terms (from the ITIL Glossary)…for this post, a Service is defined in ITIL as a means of delivering value to customers by facilitating outcomes customers want to achieve…
In the EPM context, we are defining the service as the EPM collaboration functionality, which consists of multiple elements such as Microsoft Project Professional, Microsoft Project Server, Microsoft SharePoint, etc. Typically, but not universally, the EPM system is owned by the PMO, and provided as a service to the customers of the PMO.
Service Management Roles
The role descriptions can be broken into two main categories: Service Management and Technical Management roles. Service Management refers to the business and operational roles required to manage the EPM implementation. Technical Management refers to the roles required to keep the lights on and support the underpinning components of the service.
The Service Owner is responsible for making any decisions about fundamental changes to service functionality or anything that may impact the service budget (adding new reports, functionality, staffing, training, etc.) The Service Owner is typically the PMO Director or head of Project Execution – whatever that may be called.
The Service Manager is the single person responsible for the overall availability and performance of the service. The Service Manager is responsible for coordinating all of the elements required to deliver the service to the end users. The Service Manager reports to the Service Owner. In my experience, it’s rare that the Service Manager is also the Service Owner. The Service Manager is almost always someone with PM or PMO experience who is responsible for managing many of the key Project Server configuration items such as new users, RBS, custom field configurations, etc. – although these can also be farmed out to specific resources.
Customer Liaison/Business Analyst
The customer liaison is responsible for understanding the project management processes, and working with the Service Manager to tailor the system to meet the organization’s needs – within the budget constraints set by the Service Owner.
The Incident Manager is responsible for ensuring that the Incident Tracking system is operating, and that any unscheduled interruption in service is resolved in a timely fashion. The Incident Manager may be part of the existing Service Desk structure, or may often be the Server Administrator. The challenge with this role is that many of the Incidents in an EPM implementation are more user or process oriented than technical. Therefore an effective mechanism should be created to record all incidents, and to triage them as process, user, or technical issues. It can be quite difficult to integrate a MOPS deployment with routine Service Desk operations. Talk to your Service Desk during the deployment to assess what their recommendations are for providing post-deployment support.
The Problem Manager is responsible for reviewing incidents, and ensuring that infrastructure errors are identified and permanently removed from the system. In most EPM deployments I’ve seen, the Server Administrator plays the role of Problem Manager, but consider this person to be the one who reviews the ULS logs on a regular basis to assess issues that may potentially impact performance but haven’t been reported by end users quite yet.
The Release Manager is responsible for making sure that all key changes are integration tested prior to implementation, and for management of the change collection and release cycle. This function is most critical in terms of testing any custom elements, and in the scheduling of the release cycle around key project dates such as week or month end status date refreshes.
IT Resource Manager
The IT Resource manager is responsible for delegating additional resources to the Service Manager to support the system, or to build or deploy changes as requested by the Service Manager, with the authorization of the Service Owner.
Technical roles can get quite involved and may involve a whole slew of people, from the database administrator to your SAN administrator, server support, client support, etc. This is just an attempt to list several of the key ones. In a true deployment, it would behoove your organization to really identify all of these individuals, their specific roles, and an understanding of how much lead time they would require in normal circumstances to act on a request.
|The client support team is responsible for ensuring that the appropriate software packages and patches are pushed out to the client machines in a timely fashion, and in synchronization with patches deployed to the server. As well, the client support team may be responsible for troubleshooting client issues as delegated by the Incident Management team. An example would be when a client application interferes with Microsoft Project, as has happened with some versions of biometrics software.|
|The security team is typically responsible for managing the AD Groups. If AD synchronization is turned on within Project Server, security participation is required for almost all security changes to the system.|
Custom Development Support
|Ongoing support for any custom elements that have been deployed to the system in excess of what the Application Administrator is qualified to manage. This may include PSI development, custom webparts, Project macros, or any other custom element.|
|Responsible for troubleshooting any database issues encountered, and for maintaining the appropriate level of patches.|
|Responsible for troubleshooting any connectivity issues encountered, both from clients to the server farm, and within the server farm itself.|
|The Application Administrator is often the same person as the Service Manager, but may perform a slightly more technical role as the lead person in ensuring the day to day smooth operations of the server.|
|Ongoing support and patch management for the server hardware and OS patches.|
If that’s not enough, here’s a relevant blog post from Bruce McGraw on a related topic: http://fearnoproject.com/2010/02/06/how-project-managers-should-work-with-support-organizations/
So the question then is, do you have each of those roles identified in your MOPS deployment?