Know Thy Operational Integration Model

Sooner or later, every IT department implementation faces the issue of how to integrate their EPM tool with their operational service desk management tool.  This is not only an issue for IT, as I have seen the same challenges in pipeline and oilfield maintenance, but it’s an issue that seems to arise more in IT than in other domains. 

I was thinking about this a couple of weeks ago when I was working on a PMI presentation including items to consider when deploying an EPM tool.  During my preparation, I identified two potential models for Project-Operations integration that I think are helpful to take into consideration when developing a road map for an EPM tool deployment.

If you’re implementing an EPM tool right now, and you plan to integrate project and operational work management, it would behoove you to spend a couple minutes thinking about the following models – and how or when they may be implemented within your organization.

Model #1: Segregated Project & Break-Fix Work Force


This is the model most strongly espoused in all of the IT Service Management literature, i.e. that all of the people on staff doing break fix work are kept separate from the people building new applications.

In the ITIL vision then, each of the costs of the operational work items (read: “trouble tickets”) and the projects can be rolled up and mapped to a specific application to determine the total cost of ownership for that specific application.

What are the ramifications of this from a deployment perspective?  When developing the custom fields for slicing and dicing your project portfolio, ensure that projects are coded such that they may be rolled up to the model the TCO for your application portfolio (or to use non-IT terms, your asset portfolio), i.e. ensure your Project and Ops coding are compatible and may be combined.

Model #2: Integrated Project & Break-Fix Work Force


This is the model that I see more often in my deployments, specifically in low-maturity organizations where resources are often split between building new assets and keeping the existing ones working.  This, of course, is the configuration that makes Agile and TOC practitioners cringe.

In this environment, the resources are shared, and thus to develop an accurate profile of the work demand, a comprehensive picture of both operational and project work is required.  This sort of implementation is significantly more complicated than the first model, as it requires both the integration of the costs as well as the work demand profile – i.e. I need some way of modeling the resource commitment to breakfix work in addition to the project pipeline of proposed projects.

This kind of model also gets more complicated as actual costs are booked to both operational and project work – usually meaning either double booking resource time, using two different timesheet interfaces, or implementing a third party solution to provide a shared interface between operational and project tracking tools.

Moral of the Story

If you’re implementing an EPM tool, take the time up front during envisioning and certainly during the development of your road map to identify which operational integration model you will most likely be implementing – and to build into the deployment the specific features that will be required to support it.

Know Thy Operational Integration Model

One thought on “Know Thy Operational Integration Model

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s