So, it’s time to bring it all together. You’ve used your talents thus far to choose the perfect project management software system; to implement it perfectly within your organization and to train your personnel within an inch of their lives. Now, it’s time to fulfill on some of those promises you made to management when they approved the budget in the first place and to integrate the project management system with other systems in the organization.
Here’s the first thing to know. Sometimes, it’s better to look integrated than to be integrated. Ok, that’s a little trite but it’s true. Over the years, I’ve met a remarkable number of otherwise clever people who use Ostrich management practices when thinking about integration. There are a couple of things to remember when talking about integration that can make or break your entire project management software implementation project.
First of all, regardless of what I say in the next few paragraphs, you’ve got to apply a reality check to every aspect of integrating multiple systems together. It is an easy thing to get caught up in the intricacies of a particular link between systems; to become enamored with how elegant the integration between two particular systems will be accomplished. However, if you don’t stop every once in awhile and ask yourself exactly how much effort this link will be saving.
Not long ago, I was consulting a firm who was designing an integration between a project scheduling system and the project invoicing elements of a central ERP accounting system. The person in charge was asked to describe to me how the link would be accomplished. For the next 30 minutes, in an inspired soliloquy, this person went on to enroll me in how completely; how elegantly and in what complex form the programmers would be able to create this automated link. It would take only 6 weeks of effort for a 4 man team to deliver this work of art I was informed.
That’s sounded great to me. After all, the presentation came with slides, flowcharts, ERWIN diagrams and a complete narrative. Clearly, this person had put their heart and soul into this particular aspect of the project. It was the cornerstone of his project management software implementation. I had only one question: How many transactions would his link process each month? That is, how many invoice items were there that had to be transferred from the project management system to the invoicing system? There was a long pause. An average of 12 was the final answer. And how long would this take to transfer manually? About 30 minutes each month, I was told. The 4 person/6 week effort would take over 36 years to pay dividends. I didn’t make this particular person very happy but clearly this particular bit of integration made no sense. This is, unfortunately, not an isolated incident. When you get so caught up in the details of a link between systems, it is easy to lose sight of the overall picture.
Here are a couple of basic elements to consider before embarking on the integration of your pm system with the rest of your organization’s automated infrastructure:
First, make a careful determination of what needs to be integrated. This may take some effort. First of all, you’ll need to determine what people want to be integrated. You’ll have to use your discretion here. Some people will be responsible for a particular system and have some notion that you will be integrating it poste haste. Their ideas of what will make the organization more effective or not may not be based on complete knowledge of what your project management system can do or has been configured to do. Just because someone (often very senior) wants two systems integrated doesn’t mean they can be, should be or need to be in order to make the organization more effective.
Next you’ll need to find out what perhaps should be integrated but that for some reason or another people are reluctant to have integrated. This may not be obvious. For a variety of reasons, there may be people who are responsible for a particular system who feel threatened by the integration of your system with theirs and who will therefore not offer up their system to be integrated. Some finance people for example, will feel that the movement of data into the finance systems from any external system risks compromising their system’s data regardless of the degree of integration. Yet, despite their reluctance, the linking of the project management system with theirs may offer huge potential benefits to the organization so you’ll need to seek such systems out.
Last, you’ll need to determine from the complete list of what can be integrated what should be integrated. Remember to apply a reality check on a regular basis to determine this list. You should constantly be asking yourself, “What is the return on investment of this particular link?” That is, “What is the estimated cost of this link in man hours or dollars and what is the estimated savings in time from doing the work manually?”
Once you’ve chosen the systems to integrate, you’ll probably want to start designing the links right away. This can sometimes be done with just the IT department but be careful. If you do not involve the people responsible for each of the systems affected during the very beginning of the design process you are risking a tremendous backlash.
People who are responsible for particular systems in an organization often treat them like they are their own children. Integrating in even the most non-intrusive, date-out-only fashion can make the feel violated. You must involve these people from the very beginning. Seek them out, ask their opinion about the integration. Find out what would make their lives easier and involve them in the design process. In far too many implementations, I have seen this not done only to find a link that is technically sound but practically unimplementable because no one has checked that organization’s process can support the link in the first place.
Remember, each link you are designing has the potential to invalidate the use of another. It may be possible, for example, to load budget dates from an accounting system or the shop floor manufacturing system. Yet, if you do both, how will you determine what is the source of these dates? You’ve got to look at the overall picture. Use flowcharting to follow data through the process you’ve implemented with your project management system to ensure that multiple elements of your integration plan don’t conflict with each other.
Also, before you start creating your first link between your pm system and the rest of the company, you have got to determine who will be responsible for it after it’s created. Beware. The operational responsibility of such a link may be very contentious. It may be perceived as something that gives someone power over another system. It may be perceived as very desirable or very undesirable and either can cause you problems. If you have involved the people responsible for each of the systems from the beginning, this question can be resolved with a minimum of fuss during the design process. If you haven’t you’re much more likely to end up with an emotional hot potato on your hands. So, make sure you design not only the technical elements of your link but the entire life cycle including maintenance, future growth potential, responsibility for usage of and control over the movement of this data.
Finally, don’t forget to apply simple rules of Return on Investment (ROI). It is the one sensibility check that will stand you in good stead as you create your design plan. The simple formula is to determine how much effort it will take to design, create, operate and maintain the particular link you are making and to subtract the cost of moving the data manually or using any existing structure. Working in person-hours is the most obvious measure but use any denomination for the analysis that works. Remember, sometimes it’s better to look integrated than be integrated.
