I’ve been in a lot of corporate meetings lately discussing various aspects of delivering an “integrated” project management environment. Don’t get me wrong, a corporate-wide integrated system is a wonderful thing to desire. There’s no doubt that the idea of pushing a button on a screen and finding that every element of data across the company is tied to every other element in just such a way that the answers I desire are immediately available in every detail seems fabulous.
The delivery of such wonders, however, usually requires a little more thinking. As you might imagine in the project management world, it is often a combination of tools that deliver the total functionality desired. I know, I know. Many ERP vendors have done a fine job not only in selling the idea that one tool delivers all solutions but in advancing their solutions to have their software actually do so. The problem comes when deployment starts and in the field we discover a need for other tools to become a part of the “integrated” solution. Often a scheduling tool such as Microsoft Project or Primavera will be part of the conversation; sometimes it’s a specialized tool for managing costs or risk or issue tracking.
In every one of the cases I’ve come across in the past few months, all the vendors involved have been quick to point out how their tools are linked to whatever ERP or Finance system is in question. Unfortunately it’s not always so easy. Everyone is telling the truth of course. The links being described or even demonstrated do work. The issue is that they work in the demonstrations based on a range of assumptions that are not always made clear.
It’s a truism that systems can only integrate at the lowest common denominator, but for some reason, that is not obvious to everyone who works on integration projects. Recently, for example, I was asked to describe how the data from a high-level costing module of an ERP would move its data to the more detailed database of the scheduling tool. The tools had been selected long ago and there was no problem with either. During the deployment, the Finance group had worked on the configuration and deployment of the ERP system and the Project group had worked on their scheduling tool. The decisions of each group on the configuration of the data were valid and justified. The problem was, they weren’t coordinated.
For the desired system to work, the company would have had to managed data in the ERP at the same level that scheduling was doing. This involved tens of thousands of tasks and hundreds of projects. In theory, Finances system had the capacity. In practice, it was unwilling to manage at that level of detail. The result? Data could be consolidated and rolled up from the project system but could not be “de-constructed” and moved down from Finance.
For any integrated implementation it’s crucial to look at how systems and their data must be configured in order to integrate at a later date. There are often trade-offs and compromises to make that are easier to do the earlier you make them. Remember, just knowing that a link between systems exists makes systems integrateable. It doesn’t mean yours are going to integrate unless you follow all the unspoken assumptions.
