In the project-management industry the word “Integration” has been used so much as to become an oxymoron. Adjectives of varying degrees from “Totally” to “Seamless” to my all-time favourite “Watertight” describe systems which supposedly form different aspects of a complete solution for managing projects. In our company we’ve talked about the “Integrated Solution” so much it’s embarrassing.
But is it always productive to shoot for the “total” solution? There are several factors to consider. First of all, is the solution that looks so “integrated” in the brochures in fact as integrated as it promises? There are a number of vendors who have taken systems from different development teams or even acquired companies with products which were missing from their notion of an all-round solution and glued them together. Sometimes the most integrated thing about this combination of products will be the brochures themselves. It’s important to understand exactly what is meant by integrated different systems together even systems which seem similar in interface.
The acid test for integration used to be a proof-of-concept test where files from one system are readable by another but in practice this is not nearly enough. Data can never be considered in isolation. One of the more impressive examples of pre-sales testing I’ve seen by a firm recently has us doing our homework at the office. This firm has spent the last 90 days or so not looking at product features but rather generating data and scripts for testing. When they get to completing their tests between the 3 products they’re looking at later this month they will be looking at the data in as close to real terms as possible and they will be looking at the flow of data through the entire project control process. Seem like a lot of work? It is but the hidden bonus here is that when the system is implemented, there is already a very good system description of the control environment.
The second factor to deal with is understanding for yourself exactly what you require in terms of integration. We were asked recently for example if our TimeControl timesheet system would update the project scheduling system in real-time. It was this executive’s notion of the ultimate in integrated systems. As people completed tasks in the middle of the day, the project budget vs. actual would instantly adjust showing the advance of the project details. Sounds great but isn’t implementable. Aside from the problem of doing validation of the actual time and never knowing if all of the data has been collected (Ever had to find missing timesheets on a Monday morning?), the data would never be stable enough to be used for comparison against a budget. The issue here is that the data had never been considered as part of a process. For each organization, the requirements must be considered.
Finally, the benefits of being integrated inevitably trade-off against a higher degree of overhead for the total system. It doesn’t take long to see this. Imagine two systems, say a timesheet system integrating with a scheduling system. We’ve decided to tie these two systems together so that we can see budgeted costs vs actual costs. Sounds great but by integrating these two systems we’ve got to take on a couple of additional tasks. First, tasks in the scheduling system will have to be made available to the timekeeping system. Regardless of how “seamless” this process is, some degree of communication or coordination must be made between the keeper of the timekeeping system and the keeper of the scheduling system. Coding of the two systems must be coordinated. A process must be established for the movement of actual labour hours from the timesheet system to the scheduling system. A system of checks and balances must be established to ensure there is no data missing in the process. Another system of corrections must be established for inconsistencies between the two systems. Even in the most “integrated” environment, there is no escaping this establishment of proper process. Sound intimidating? It’s not really but it’s not trivial either. One of the most significant causes of failed integrated environment implementations is a misunderstanding of management of the process. Is it worth it?
So what are the options? Well, it’s worth considering at least having different categories of data to work separately. Look at the individual applications that you’re considering as part of your project control system. What benefits are available from each implementable aspect of the system when it is not integrated into the whole. If you can’t find any, you should be reconsidering why you’re implementing that feature in the first place. Examine how you could implement each aspect of the system distinctly and see if the benefit outweighs the payoff. If you are looking at products from a single vendor ask them to outline the benefits/costs of implementing systems separately. If you’re considering products from multiple vendors ask them each how they would make you more productive when these products are working in tandem and how they’d make you more productive if the products were implemented stand-alone.
Finally, don’t start anything without at least a rough implementation plan. Make sure all the players know when the system should be firing up and when the first benefits can be expected from different aspects of the system. You can always adjust a plan that wasn’t ideal but starting without a plan will ultimately cost you more than the purchases of the systems you’re considering.