My latest article on best practices for enterprise systems has just been published on Microsoft’s TechNet.  You’ll find that column and a number of others on how to get the most out of selecting, planning for and deploying enterprise project management software in the Microsoft Project Server 2010 home page area of TechNet. This article looks at some of the key success/failure criteria to any enterprise system including, of course, EPM Systems.  Those factors include: finding a business owner, knowing what problem the system is supposed to solve, making sure it’s part of your enterprise technical architecture and implementing change management.  Go to Microsoft Technet’s Project Server 2010 page to read the article.

Integrated project management environments are the envy of almost every executive in the country. In virtually every computer publication available there is talk about corporate environments being single source. Yet another TLA (Three-letter-acronym) has crept into our lexicon; ERP. It stands for Enterprise Resource Planning and generally describes large, centralized corporate systems which include not just the traditional financial systems but also production systems including project control. Companies like SAP, Baan and PeopleSoft have been promoting single-stop providers of project control environments. The year-2000 issue has prompted many companies to replace their corporate systems wholesale and this has further fueled interest in a centralized environment.

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.

“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.

One of the big challenges with project management and project management systems has always been the entry of critical information. Project management information is so dependent on the context that getting it wrong is very easy. Think about it for a moment. We ask for a task description. But relatively few people have the skill and experience required to define a task description properly. We ask for a duration but asking several people results in as many different durations as we have people. In the project management industry we’ve always responded to this by saying ‘more training’ and, to be sure, training makes a difference but we’re about to see a focus on project management software that will try to do away with this challenge.

It’s all to do with the term Workflow. Workflow refers to the concept of taking a process and organizing the sequencing of that process including conditional branches. This is very familiar to project management people as the thinking is just like the flow of a project. Workflow software however has become all the rage and it has the potential to make a profound difference in project management systems when linked with databases, lists and, in particular: forms.

Think of this scenario. A new project manager is assigned to create a new project. He goes to the corporate Intranet where he clicks on “Create a new project”. A form appears. He fills in the blanks. Depending on some entries he makes in the form, he might be asked for more information. He completes the form and submits it. Depending on other entries in the form, the approval process might be directed to one person or another.

This is the result of Workflow.

But wait, we’re not done. The workflow engine also sends an email to the person who approves his kind of project. The pending project is put on a list of potential projects in the portfolio management system. A portfolio manager is notified by the Workflow engine that a pending project has been added to their portfolio and asks them to intervene to give it a priority.

The manager approves the project. The portfolio manager sets the priority and as a result, resource scheduling determines the schedule. The Workflow engine wakes up to these responses and sends an email back to our newbie project manager letting him know that his project is approved and telling him when he’ll be getting staff to get it started.

Sound like science fiction? It’s not. The tools for doing this exist right now. Microsoft has been promoting the Windows Workflow Foundation (WWF and yes, I know that’s also the acronym for the World Wrestling Foundation) and how it links to their Infopath forms that are part of Microsoft Office SharePoint Server. Demonstrations that are now viewable of Microsoft Project Server lean heavily on this technology as a method of collecting and organizing data and as a way of communicating with users in an unattended fashion. It doesn’t take a rocket scientist to see that this kind of workflow is a future marquis feature for Microsoft and that it is likely to figure strongly in future versions of Project Server.

Are we stuck with Microsoft though to do this kind of thing? Absolutely not. If you’ve already got SharePoint Server in house, then you’ve bought the technology already so you might not want to look elsewhere but there are numerous workflow solutions in the open-source community. You’ll find a range of possible solutions on SourceForge (www.sourceforge.net) . For information on the WWF, do a search on any search engine of “SharePoint Workflow”.

We’ve not begun to scratch the surface of what’s possible with this kind of approach to collecting data. The beauty of it is the level of intelligence that can now be woven behind the scenes into the forms that are being filled out. Let’s take our new project example.

The form could ask our new project manager to complete a “Risk Assessment” form if the value of his project is over $10,000 or if the duration is more than 26 weeks or if the work is being done for the government. The form could insist that this Risk Assessment for be completed before he even tries to submit his request for project approval.

The form could decide to send the request to a supervisor for approval if it’s value is less than $10,000 and to a senior manager if it’s worth more.

The form could decide to immediately email the portfolio manager if the project is marked as “urgent” or if the executive sponsor is the CEO.

And so on and so on.

Notice anything here? I keep saying the “form could decide” but of course, forms don’t decide anything and therein likes the rub. Any of the workflow we’re discussing here has to be coded or programmed or defined in some way for the workflow engine to understand and that can be a challenge. In many of the project organizations I visit, the manual workflow process is ill defined, not honoured or not defined at all. This kind of solution will demonstrate wonderfully and people will Ooooo and Awwww when they see it but delivering the demo will take a lot more work. A lot more. Just because the technology enables this kind of thing doesn’t mean that organizations are ready to do the homework required to adopt it. I’ve been involved over the years in numerous workflow design meetings. In order to establish just one workflow process successfully you need to bring together everyone who intervenes in that process now as well as those who are clients of the process (meaning they receive the product that comes out of the process) and the suppliers of the process (meaning they provide input that results in the product). You have to look at all the possible permutations. You have to look at where the data will come from, all the possible actions you want to come out of the form(s) and process based on possible answers to questions and then you need to document, train, test and document some more. Yes, the potential efficiency improvements might be huge but you shouldn’t trivialize the work involved in automating the workflow of a process even with great technology at your fingertips.

One of the other hidden pitfalls of workflow automation is the maintenance of this in-the-background-intelligence. What happens when the team that defined the workflow moves on to other things? Who will maintain the rules in the form and make sure they’re adapted to changing business conditions? How were these rules documented? Who maintains that documentation? And, so on.

No matter what, you’re going to hear a lot more about workflow automation in the year or two because it’s just too compelling a technology to ignore and for larger organizations, automating any process that is done many times can result in huge efficiency savings but, like all of these tools, be sure you know not just the benefits but also the total costs before you start your own implementation.

I suppose it shouldn’t surprise me. After all, it’s been 25 years and the request is almost identical each time. Again this week a very senior project manager asked for it again. “It” is a real-time, integrated project management system. The request came in a round-about way while I was demonstrating software for enterprise-wide use in a project environment so I had to double check. “Let me just be sure that I understand what you’re asking for,” I asked. “You’d like an enterprise-wide, web-based project management system that would manage its data in real time. In such a system the CEO for example, could click on a button and see a view of where all project stand at this moment. If they were to return in a few hours, the view would now represent all the changes that had occurred in the intervening time.”

The project manager’s eyes lit up. “You understand completely,” he said.

It fell to me to give him the bad news. “Such a system is demonstrable,” I said, “but could never be implemented.”

He was crushed. Who can blame him frankly? I remember standing in the exhibit hall of the annual Project Management Institute Symposium with the senior executives of two of the largest and long-standing project management software vendors. We were shaking our heads as we looked over the exhibit floor. Every booth it seemed was offering the same thing: “Enterprise-wide web-based project management”.

With all the promises from all these vendors of project management tools that offer this type of solution, surely at least one of them has figured out how to actually deliver it.

The problem is, that it’s not a technical problem. You see, as desirable as such a real-time report seems at first blush, it’s virtually impossible to deliver. The first issue is the context of the data you’re looking at. If I present a report of the status of a project, there are some basic assumptions that people make about the report. You assume, for example, that the data is accurate to the best of my abilities. To be accurate, project management data needs to go through at least some kind of review. You also assume that you’re looking at apples and apples, not a mix of different kinds of data. For example, if I show a report with 10 projects summarized on it, you would reasonably assume that the projects had all been statused on or around the same time. A report showing the status of some reports as of this week and others as of last month would be at best nonsensical and at worst could show a misleading view of our distribution and loads of resources.

This means that to create any such report prior to displaying it to management, I really need to update data on or around the same time and then validate that data through someone responsible for the project. This is the definition of batch processing. It is the very antithesis of real-time.

As soon as I point these kinds of issues out, it becomes obvious that there is going to be no easy solution to this request regardless of what the different booth displays say on the exhibit floor but there is another element of the issue that is almost never asked of the requestor.

Such requests typically originate from someone in the executive suite. A manager or director or senior executive of some kind asks why, with all the products on the market that promise such features, can’t he or she get the real-time analysis they’re asking for.

My first question of such people is “What will you do with it?” It seems trite I suppose but it’s really not. Imagine for a moment, such a system in place. Let’s imagine that through a petition to Harry Potter and his magic wand, we’ve managed to resolve all the issues with collecting, analyzing and validating our project data. Now, it’s 9:00am in the morning and our CEO is checking on the projects. He (or she) pops up the “corporate-wide-real-time-budget-vs-actual project report” Bad news. It shows the actual cost curve slightly higher than the budget curve. Our combined projects are over-budget. But wait! It’s 9:05 and the curve has just changed. Our budget curve has moved up, now the variance is alright. The CEO breaths a sigh of relief. Wait again! The curve has changed. It’s 9:15 and Bob, down in projects has just updated a half-dozen tasks with their new projected finish dates, now the curve is showing us over-budget again and we’re running late besides! But wait! The curve is undulating again. Even if this hapless manager were to take a snapshot and run down to the project department with it to ask how we’re going to get on track, the response is likely to be “Oh, you’re looking at the 10:23am report, you really need to look at 10:45, the picture’s all different.”

It’s obvious that such an environment would be completely unproductive yet the desire for it continues year after year unabated. This brings us back to the now dejected project manager who I met this week who wanted to know what he should do now? My recommendation was to change his question. Instead of searching for the real-time project management system, why not start asking what changes to his project management environment could he implement that would make them more effective. Not surprisingly, when he sets his sights a little lower, there is lots he can do.

It’s perhaps a good question for all of us.

It’s the path of least resistance that is the root of most problems with implementing enterprise project systems. You no doubt have heard the term. It’s commonly used to describe the path water will take if put on an uneven surface. Water will always flow down the path of least resistance, forever taking the easy way to lower altitudes

In the world of project management systems, the term is an easy analogy to adopt if you start to look at enterprise systems. If you’re just looking at a desktop scheduling tool then this whole notion may not play such a key role. In this case, an individual might be willing to tackle a path that is quite difficult including a steep and high learning curve, software which is not simple to install or use and a process which must be defined by the user. An individual might take on such a system in the interests of furthering long term goals of either the company or him/herself.

But what hold true for an individual often does not work for a group. I’ve seen more and more organizations this year striving towards an enterprise project control system. Sometimes the project is underestimated (Ok, almost always) and sometimes the project has many cultural hurdles to overcome (Alright virtually always) but one obstacle that seems to virtually always appear is often not identified as a problem at all and that’s the tendency of people to follow the path of least resistance.

I’ve come across it several times in just the last month. In a huge insurance company based in the US, they have been striving for a common project management system for over a year (at least publicly – They’ve probably been trying to decide on such a system since the company was founded!).

This year I was peripherally involved in the selection process. Fundamental to this process was that a single product would be chosen. Over 300 people were canvassed as part of the due diligence process. “We didn’t want anyone to feel left out,” said one senior committee member. “We need universal buy-in.”

After almost 16 months of sometimes intense internal negotiation, they have now told the 3 product finalists that the “standard” project management tool that will be chosen must be able to integrate fully with Microsoft Project as it will continue to be used by project managers across the company whenever they feel the need is warranted.

Now, I’m on record as saying that I like Microsoft Project just fine but it must be obvious to you that choosing a “multiple-product standard” is an oxymoron.

How can an organization take two products; one a desktop planning tool, the other a high-end enterprise project control tool and make them an integrated project management system for the entire enterprise? Well, they can’t. Oh, you can declare that such a system is now your enterprise project environment but that doesn’t make it integrated.

The problem is that different people have different needs. It might be better in the long term for the organization to work with a complex but extensive project management system but end-users who don’t see a direct benefit to them won’t adopt it. They will follow the path of least resistance; choosing a system which can return them results instantly. Full-time professional project schedulers see their path differently. As an individual who is often asked for reports and analysis, they might find the path of least resistance to be in a high-end system with a lot of flexibility.

So, will this company implement an enterprise project management system? Not this year.

I’ve seen the same phenomenon at the management level. This month, while advising a multi-national pharmaceutical company, I watched a senior executive follow the path of least resistance into a no-win situation.

In this firm, the senior executive in a research group, created a committee to select an enterprise project tool. It started off with a great deal of momentum and lofty ideals. But, as many committees do, over time, the diverse interests of this group started to show through. The selection process should have been complete in a few short months. Instead, some 18 months later, it’s now more mired in controversy than ever.

The senior executive, has had several opportunities to move the process forward at the risk of upsetting some of the committee members but he won’t. He takes instead, the path of least resistance. He has always managed through consensus. His theory, is that everyone just stays in one room long enough, eventually they’ll come to the same conclusion. The underlying assumption of this theory is that there is common ground to be found somewhere. The problem is, there are different kinds of tools appropriate to different kinds of users. Consequently, the longer the committee struggles, the more each diverse interest is attracted to a different kind of tool. Without the intervention of someone senior in the process the committee has no hope of success.

So, is there any defense against the path of least resistance? There is. The two best weapons against the dangers of following the easy road into trouble are commitment and structure.

Commitment is the tougher of the two and is most likely to be seen at the executive level. If you know that you or a committee or group you are sponsoring may be enticed down the garden path of least resistance, you can keep them productive by committing to a goal that goes beyond what is easy. Kennedy did it when he committed to send a man to the moon before the end of the 60′s. When he consulted the project managers they said that the project was impossible in that time frame. But his commitment had inspired the country and many men and women toiled to make the commitment a reality even against tremendous opposition and adversity.

If you’re not the President yet you still want to make an impact in this area, you can do so with the second great weapon; structure. Even the lowliest project system selection committee member can introduce structure into the selection process. Structure can usually be introduced at low stress without offending anyone from any faction.

Once the structure has been agreed to, it becomes a powerful backdrop against which to move the process forward. It may be one of the few elements of the group’s entire history on which everyone was able to agree and thus it can become a focal point for progress together.

Whichever method of combating it you choose, don’t discount the insidious effects of following the path of least resistance. Remember this Chinese proverb – if you don’t change your path, you are liable to end up where you are headed!

I’ve been remiss in not talking about this before now but in October, Oracle announced that they had purchased Primavera.

Primavera has been around since the early 80s and my firm, HMS has been a technology partner since the mid-90′s.  The sale became final late in 2008 and now we’re starting to see some of the effects of the sale.

Oracle has explained that Primavera will form one of the major wings of its strategic systems but I think it’s fair to say that over the next 12 months we’ll see a range of changes that would seem natural when such a big software company swallows a company that is much smaller but highly specialized.  While I don’t have any inside knowledge of Oracle’s plans, some of the changes I’m sure we’ll see include some of the following:

Channel Changes
While Oracle has told the existing channel partners (known as Primavera Authorized Resellers or PARs) that they will be kept on, I’m sure we’ll see a division of labour.  The mega enterprise accounts will no doubt be serviced by Oracle’s account management team themselves with the PARs perhaps in attendance as service providers.  The middle market will be left to the channel is my guess.  That makes for a change in the business model of every PAR on the planet so look for these organizations to be shifting their stance over the coming year or two.

Technology Alignment
It makes no sense to buy something as significant as Primavera without using it for strategic value.  Primavera could serve as a ‘door opener’ for Oracle to get into accounts that they’ve not been able to penetrate thus far.  If the Primavera products work best with the Oracle datbase, the Oracle Financials ERP, the Oracle CRM etc. then these products can follow the thin end of the wedge into these clients so look for the Primavera product line to take even more advantage of Oracle’s technology over the coming year.

An Integrated Story
Primavera’s strength for many years has been as a ‘best of breed’ project and portfolio management tool.  Now, however, look for this position to change.  As a part of Oracle, I’d expect an ‘end-to-end’ integrated story starting from the task level and ending at the centralized ERP level.  I’m not sure if this is a good or bad thing but it’s a change for sure.

3rd Party partners
I’m not expecting huge changes here.  Most of the 3rd party partners have something to add to the Primavera line that adds value.  Not every Primavera client will be ready to climb aboard an all-Oracle product line up so many of these technology partners will still find a place which makes a difference to Oracle-Primavera sales.

If you’re interested in the the Oracle press release, you can find it here: www.oracle.com/us/corporate/press/017594_EN.