“Sometimes it’s better to look integrated than be integrated.” It’s a saying that goes back a few years now and I can’t even remember who coined the phrase first. I do think about the concept from time to time though. It seems most appropriate in meetings such as the one I had last week where a senior IT executive asked me to comment on a 15 page data flow diagram showing how a legacy timekeeping system would be integrated with the system we had recently supplied.

Fields were mapped representing data in both systems, stored procedures were referred to but not defined. The understanding of how data was to move back and forth between the systems was sketchy at best. What was perhaps most unclear was what benefits were expected to be realized by the organization through this extensive amount of work.

This is not an isolated case. In our work implementing project control environments we’ve had plenty of opportunity to look at extensive ERP implementations where months of effort are allocated for “interfacing” which typically refers to full integration of data between multiple usually non-compatible systems.

What is it that makes this kind of exercise so compelling? Well, it makes for great marketing hype. If you’re in the business of selling man hours for implementing enterprise systems, then this scenario is made in heaven for you. Pretty PowerPoint slides showing lines of data moving between all these systems and suggesting that management will be able to get completely integrated data are enthralling. Not long ago I watched a demonstration showing a financial report on screen which, with a click of a button, dissolved into a pie chart. From there to a histogram and a click on the histogram and the graph broke into a spreadsheet showing multiple suppliers. One more click and this list became another graph and from there down to an individual invoice. To say that this demonstration got the attention of the potential client would be an understatement. These executives were virtually salivating, imagining an ultimate level of control of their own organization’s data.

The truth is not always so easy. In practice, data must often be approved and batched together before analysis. There usually needs to be a defined flow of data from one place to the next and, if as is almost always the case, this data will come from multiple systems which may or may not (probably not) have been designed to integrate their data together.

As I’ve often said in these pages, the most effective analysis of such decisions is one where the Return on Investment is measured. A demonstration which seems delightful is not enough reason to start integrating systems which must be done at an architectural level.

In the 15-page data flow diagram I recently had to confront, data moved from one system to the next, other elements moved back to the first and more elements again moved back to the second. It was difficult even to follow the logic. This might have been worthwhile if there had been some measurable benefit but if there were big gains in efficiency to be found, I certainly couldn’t recognize them. The legacy system was, of course still there but the initial impetus for integrating the two systems seems to have been for the purpose of producing a single report which would show total hours across departments.

Even if such a report had been required it would have taken the tiniest fraction of effort to import the data from the legacy system into the new system in order to produce the report. “Ahh, but that would require intervention every single month,” I was told. “Good point,” is my reply. “However, the 15 minutes it would have taken every month is by far less than the 4 weeks spent writing the integrated design and code and the countless hours spent trying to keep the systems in synch!

Interfaces have another hidden benefit as well. Having to intervene to create the interface is a perfect point of control to manage the data flow. If you’ve got a checklist item in your procedures which says “import the timesheet actuals” then having to physically click an icon or select a menu option and to ensure that it runs is a great place to make sure that item is complete and that all data has move from the source system to the transaction file and from the transaction file to the receiving system as required.

Many finance departments have this in their periscope already. Many systems promote their “open architecture” database as the holy grail of systems integration. There’s no doubt that an open architecture provides more options than a closed architecture but the picture painted is often too close for comfort for finance people. Finance systems are, after all, tough to get stable and once stable, there is a tremendous reluctance to touch them even for upgrades. Every time I’ve suggested that we’d be prepared to intimately integrate the data from a project control system into the accounting system directly, the finance staff have stared at me in horror. No, they say, it would be far preferable to deliver a “transaction file” to finance for importing when they’re darned well good and ready. The idea that an “external” system (for Finance, this mostly means anything outside the GL, AR, AP, PR package) would change cost values in the main accounting system without human intervention is abhorrent to most finance personnel.

While this is true for the systems we’ve been implementing, in many cases it will be equally appropriate for other internal systems to follow the same logic. When an interface can deliver the result at a fraction of the investment of time and effort, then you’ve got to take a careful look at what it’s providing. Far better to interface systems in an organized fashion than to spend the next 6 months trying to determine why the “integrated” system isn’t.

Microsoft has released Service Pack 2 for Microsoft Project and Project Server.  There are a number of components of the upgrade and we’ve put all the links on our Microsoft Project System Updates page.  There are a wide range of improvements from Service Pack 1.  If you’ve been updating each month with the monthly updates we post here, you’ll have a lot of them already but some of the improvements include:

Project Standard and Project Professional

• The scheduling engine, Active Cache, and Gantt charts all have improvements.
• There is additional reliability with earlier versions of the .mpp format.

Project Server

• Better memory management in the queue service.
• Performance to certain database table indexes is improved.
• Resource plans, build team, cost resources, and the server scheduling engine have improved.

 Read more…

Everyone seems to be talking about enterprise project management software.  Chris Vandersluis takes a look at a key element of an implementation plan for enterprise-wide pm software.

I’ve spent the last 24 hours in a project management software exhibition hall here in Toronto, Canada, so you’ll forgive me I hope for harping on what has become a bit of a cliché in our industry.  You know the one I’m talking about – Enterprise Project Management Software.  It must be the hangover from the ERP implementation craze that was the hallmark of the turn of the millennium or something because it seems that every software system available to mankind today is “Enterprise”-something.  Vendors are either selling an enterprise-wide system or they’re selling how to implement it. 

I’ve had literally dozens of attendees ask me questions on what “Enterprise” project management system would be the best.  Almost every product on display has the word Enterprise in its description somewhere but when I’ve asked what about their product made it “Enterprise” enabled, the exhibitors were hard pressed to find a good response.  At the Microsoft booth, a new Microsoft employee asked me if I didn’t think that Microsoft 2000 wasn’t more of an “Enterprise” product.   Even our own firm is touting its’ Enterprise timekeeping system.  Frankly I’m getting a little tired of it.

It’s not that I have anything against Enterprise products.  After all, as I mentioned, we do publish one.  It’s the notion that every project management software tool is an appropriate product to be deployed across the enterprise that has me annoyed.  When I travel to different parts of the world I have the privilege of meeting people who manage some of the largest organizations and some of the largest projects in the world.  For the last 17 years or so that I’ve been in this business, an enterprise-wide-work-for-everyone-universal project management system has been like the Holy Grail.  It’s almost universally desired by management as a panacea for everything you don’t like about the project management business.

“If only we had an enterprise project management system where all the data was centralized, I’d be able to see exactly who is available at any time of the day,” say some.

“Ah, if only we had an enterprise project management system, we’d be able to see our project status in real-time,” say others.

“But if we only had an enterprise project management system, everything would be on-time and on-budget,” think the rest.

What kind of system would it be?
Ok, you may not be that shallow, but think about how great it would be if all project management data from projects done in your organization over the last 10 years was in a centralized database in a format that you could immediately access, that you could see trends and averages in at any time.  Sound attractive?  How about this, imagine that all project managers who are managing projects that have any impact of any kind on either the scope, resources, or schedule of your own projects are using a project management system that automatically ties in with your own and shows the impact as soon as they know about it.

What very few people spend time thinking about is what implications are involved in actually deploying such a system. 

First of all, what kind of system would it have to be.  We’d  need a system that was:

• a) capable of storing data in some centralized format such as a client/server database.
• b) easy enough to use in order to be accepted by the huge numbers of part-time users who would have access to the system
• c) robust enough in its functionality in order to handle the kind of complex analysis that is bound to come from managing large amounts of diverse data.

Next, we’d need to tackle the process.  If you’ve been working on this at all, you’ve no doubt come up against this issue in a big way.  The process by which all the data will be collected, entered, analyzed and distributed through such a system has to be walked through over and over and over again from the perspectives of everyone involved in the process just to make sure data can make it through the system.

Finally, there’s the matter of how it’s deployed at all.  It’s often a case of the shoemaker’s children who go barefoot when it comes to deploying a project management system.  There’s almost never a project management plan for it!

And just what do you mean by an Enterprise Project Management System?
Let’s look at these one at a time.  First with regards to the products themselves.  There’s no point in naming names.  (Please don’t be calling me to ask if I think that “Product A” or “Brand X” is really an enterprise product – the whole point of this is to let you figure out for yourself what’s important.  First of all you’ve got to look at the kind of product you’re looking for.  As I answered to someone today when they asked which was the best enterprise project management product, “What are you thinking of when you ask for an enterprise product?” 

If an enterprise product means simply something that will be used by the enterprise in the widest possible distribution, then looking at an of the easy-to-use desktop products is your best bet.  Make sure you narrow down your search.  Is it scheduling, resource allocation, document management, timekeeping or what that you’re hoping to implement?

If you’re looking more for a system that can be used centrally by a small team of professionals (such as in a project office) to manage all projects in the enterprise, then you’d do best to start your search among the high-end pm systems which were originally designed around mega project environments.

You may rather be looking for a product which will be widely distributed but will maintain all its data in some central repository for reporting purposes.  In this case, your search is not in vain but will take a little more work.  You’ll still need to concentrate on the ease-of-use of the interface such as in a desktop tool but one of your basic requirements will be data storage.  It shouldn’t take long to come up with a short list.

All these three definitions can be deployed with fairly low stress.  It’s the fourth one that causes grief.

If what you mean by enterprise project management software is an environment where the software is widely deployed and where project decisions are taken at different levels of the organization (e.g. resource availability decided centrally, but resource allocation decided locally) and where there are numerous levels of responsibility for data (e.g. the individual project managers manage their own small project but the global impact of all projects is the responsibility of someone at a higher level in the organization and/or if you are talking in terms like multi-project resource leveling, multi-project analysis, hierarchical project groupings and so on…  If you mean something like that, then you’ve got a much tougher challenge.  This kind of product is one which will almost certainly have to come in parts.  There’s got to be some part of the system that is designed to be used by the project office type of project manager.  There’ll need to be a completely distinct interface for end-users who will have only occasional access to the system.  There’s got to be robust reporting, flexible data structures and much, much more.

Getting started
There are a couple of such product combinations on the market today and while theoretically any of them might work, ensuring that the product combination you select can actually be deployed is the next challenge.  You should be able to get your short list figured out very quickly and once you do, here’s the hoop you should be making your project management software vendor jump through:  Have them describe to you (in terms even your management will understand) the process by which data will move through their system.  Be wary of cheap demonstrations.  It’s not difficult to create a demo that gives the simulation of the system working while obscuring key difficulties in making it work. 

A couple of years ago, I watched an organization struggle with a matrix organization problem.  They had divided their project data into individual sub-projects where no sub-project had more than one resource grouping in it or more than one project-phase.  This was so they could group it in one direction for the resource managers and in the other direction for project managers so that each type of manager could manipulate the data within their area of responsibility.  It had taken the organization months to divide up their data this way and they were abjectly miserable.  No surprise.  No one had ever questioned how each type of manager with their own distinct and often conflicting responsibilities would be able to access and manipulate the project data.  No one had used up some inexpensive white board space to map out the flow of data like a process.  The organization’s still struggling with the concept.

Now, I know I’ve said this before, but here it is again:  You’ve got to consider how you’re going to deal with the deployment of your chosen system(s).  If the system you’ve chosen can only deliver its first results once it has been adopted by 100% of the organization, then you’re in for some bad news.  In the majority of cases, project management software implementation projects that are designed as an all-or-nothing approach, deliver nothing.  It can’t be much of a surprise.  The cultural impact of trying to get everyone in an organization to change from anything to anything else at the same time is horrendous.  Look for the small victories.  Make sure that you’re going to be able to get some value out of the product while it’s being deployed.  It’s true that there’s a good chance that you won’t have 100% deployment but the good news is that your system will be delivering some value to the organization even if you don’t.

Finally, work on breaking the trend of not using what you know on your own projects.  The best advice I can give you on how to be successful in implementing an enterprise project management system is to use all the project management techniques while doing so.  Almost everywhere I go, I find virtually no project management being applied to the project on implementing project management software.  Be the first.  Break the trend!

Systems: Microsoft Project Server 2007 updates
Microsoft Project Server 2007 has had a range of updates, service packs and patches.  There’s not a simple list of these updates on the Microsoft web site so we’ve made a cheat sheet list for you to get to them quickly.  Read more…

Here are some recently added compiled help format (CHM) files containing downloadable documentation for SharePoint, Office and Project Server.

·      SharePoint 2007 Technical Library in Help format

·      Windows SharePoint Services 3.0 Technical Library in Help format

·      Office 2007 Resource Kit in Help format

·      Microsoft Project Server 2007 Technical Library in Help format

After downloading the files, you may need to right click the file in Explorer, select Properties, and then Unblock the file in order to view the .CHM file.