For many years, one of the challenges with technology was to think of software ‘packages’. This pervasive way of thinking inevitably brings us to thinking of software as a collection of features. We even compare one product to another by listing the features on one side with the features on the other.

The idea of having software as a series of interrelated parts that could be made into plug-and-play components of a larger system often meant we would need to do lots and lots of programming of the interrelating software. Our company has focused on solution selling for years, so for us we’re used to asking a client for the problem before we list the solution. But it does make us think around here of software more as a vehicle for creating a solution, rather than a list of features that the client might find attractive.

In the last couple of years, however, there has been sufficient movement in the software business towards more common standards that we can start to think of technology as a “stack” of functionality, and interact with it as the potential for a solution, rather than the fixed list of what can be delivered on the first day.

I recently presented some project management software to a rather large company with a worldwide brand name. This company certainly has extensive project management experience but in the particular division I was interacting with, project management had always been an ad-hoc or project-by-project notion rather than centrally organized. The division’s volume of work has recently increased, however, and the complexity of that work has grown by an order of magnitude. It’s time to make project management a more formal process.

So, I showed them this software, which was rather well received. I showed the software as I often do, after extensive conversations about what the company is attempting to accomplish. Once I’d done the presentation, I turned off the projector and told a story.

“Imagine,” I said, “having to create a new project. You wouldn’t turn on the software we’d just shown you. Instead, you’d click on a link on your corporate intranet portal. The link would present a web-based form for new projects. You’d fill in this form on your terminal. You wouldn’t need specialized project management experience. You might not need to know how to create the schedule and establish the dependencies between tasks, or what a lag is, or that CPM stands for Critical Path Methodology. You’d just fill in this form.

”Depending on who you are, the form might look different. If you were a senior executive for example, certain parts of the form for approvals might not appear. Other parts of the form might only appear depending on other data you’d enter. If the project details you entered had, for example, a place for the cost of the project and that value was, say, more than $100,000 then another part of the form might instantly appear with additional fields of information required to start a project of that value.

“Now, imagine once completing that form that you click on the ‘Submit’ button and depending on who you are, and the data in the form, it is automatically sent to the person in your organization who needs to approve new projects. That person would receive an email in their Inbox. They might see the whole form there or click on a link to the form online in their browser. They would see what you had typed in but they might also see other information. Perhaps they can see right on the form, for example, the value of the project you typed but also the total value of the budget that has been allocated so far for this year. They would see different buttons on the form such as ‘Reject’ or ‘Request more details’ or ‘Approve’ or ‘Forward for approval’. They would click on the ‘Approve’ button and several things would happen. First you would get an email saying that the project is now approved. In your Enterprise Project Management system a new project would instantly appear. It would have the data from the form that you filled out. There might even be a very high level schedule of milestones if those were required in the form for new projects. The stage for the stage-gate methodology would be set to “initialized”. Other key people might be triggered by that event to create certain project documents and so on and so on.

“Now we can do the same thing with change management, budget approval, resource allocation etc.”

There was nothing on the projector. It was a story. But the story was compelling.

“That’s just what we need,” said the representative of the organization.

All of this has become possible and not just with one tool. In fact, if you wanted to make my story into a solution, there are several tools you’d go to look for. They might come from the same vendor or from several vendors.

You’ll need a server-based enterprise project management system of course. That’s a good starting point and there are a number on the market.

You’ll also need server-based workflow engine. Again, there are several on the market that are quite excellent and can be configured without having to be a programmer.

You’ll need a forms-generator for online forms to be able to create intelligent forms that can take actions in the background. Most workflow vendors have such forms-based tools embedded in them or attached to them, but most workflow tools can work with numerous forms tools.

This interoperability is all thanks to the ubiquitous presence of the Internet and the movement from older client-based systems to server-based centralized systems. This has prompted more and more vendors to open their technology. We hear more of the terms “Software as a Service” (SaaS) or “Simple Object Access Protocol” (SOAP). The movement towards Software available as a Service means that whatever functionality is available can be used by different interfaces to create blended functionality. The standard of SOAP and other such protocols means that everyone has a standard syntax and grammar for communicating between products. The end result is the potential to combine the functionality from where you can find it into the solution where you need it, and that’s all possible today.

That’s all the good news.

I know. You were waiting for the bad news weren’t you?

The challenge is what’s implied in my story. The workflow sounded wonderful to my client but, if I want to implement that technology, we need to know what the workflow is. That implies a standardization of process that everyone in the organization agrees to. As I’d mentioned earlier, this particular organization had managed projects in a very casual ad-hoc manner. So getting consensus on what the new project process might be will almost certainly take some work, and consensus is key. Also, we can, in theory, proceduralize almost anything, but the law of diminishing returns takes effect in here somewhere. There will come a point where making a formal automated process of one more procedure rather than leaving it to be managed casually won’t produce any more efficiency. There needs to be someone central to make the decision on what that point is.

Who will make the final decision on what to proceduralize? Who will have the final say on what a particular process will be? What will be the process to change or add to the process? If the processes we’re discussing will touch several departments (such as Finance, or HR) instead of just project management, then who will be the liaison for those departments? Who will be the keeper of the process? What is their authority in the organization?

This is why, when I talk about enterprise project management and what’s possible, I inevitably talk about it as a change management project rather than as a technology project. At its core, we’re asking the organization to change how it works and possibly how some core aspects of how it works. That change is always going to be a bigger challenge than the technology required to deliver the solution.

What’s important to know? That it’s now possible to blend these technologies together and as a result bring the project management process to levels of the organization that will never see or need to understand a GANTT chart or a PERT diagram.

There’s something that I’ve been wondering about for awhile now. We all know how incredibly the ERP market has expanded in recent years. There are a number of ERP competitors who have seen themselves grow a hundredfold since their lean years.

The promise of the ERP solution has always been enticing. After all “Enterprise Resource Planning” holds even in its title the promise of something all encompassing. Many ERP vendors promised to deliver all key corporate computing functionality from a single source. If you look back two to three years at ERP marketing campaigns, you’ll find a leaning toward offering everything from the same vendor. For some organizations and some management people, it was the holy grail of computing environments.

If you’ve worked on an ERP solution implementation team, you already know the drive toward keeping the entire solution inside one box as long as is possible.

Ok. It sounds wonderful. So what have I been wondering about? I’ve been thinking, that if the promise of these ERP vendors was to offer “everything” themselves, why have so many ERP vendors created so many alliance partners?

Stop by any of the majors; SAP, BaaN, PeopleSoft, JD Edwards and Oracle and you’ll find a plethora of add-on products, third party solutions, enhanced functionality and more. Some of the solutions you’ll see are already listed in the functionality of the ERP product.

There’s no mystery why these products exist. With the ERP market so dynamic, many firms (my own included) have placed a high priority on creating ERP add-ons. The mystery is why the ERP vendors agreed to assist these firms with marketing by putting them onto websites and listing them in catalogs.

When you think about it for a moment though, the source of the phenomena is obvious. Actually implementing a complete replacement of a corporate computing environment is a stunningly complex project. No matter how elaborate the project schedule, how extensive the planning and preparation, there is simply no way to turn on such an extensive system on a given day and from then on simply operate on the new system. Even in the simplest of implementations, the system must be installed in phases.

With many ERP systems, it is the core financials which are implemented first. This includes the General Ledger, the Accounts Receivable and Accounts Payable. Sometimes there are other essential ledgers which must be established at the same time. The secondary functions such as inventory, manufacturing, project control and other ancillary systems are scheduled for once the essential financials are stable. Tertiary functions are held off until all else is complete.

I’d be fascinated to see statistics on how many organizations who have purchased complete solutions have only completed the core first phase and have now elected to postpone or even cancel subsequent phases.

It makes some sense to figure that this must occur in some firms. The source of many firms wanting to switch to a completely new financial system is routed in the Y2K problem. With massive costs of upgrading systems that had evolved over time, the incentive to switch to something already written is huge. Add to that the “gravy”; the complete solution that was held out by such vendors in taking over everything else and you’ve got a good case for selling some software. The problem has never been in selling the solution, it is in implementing it.

Such systems can only be sold in a centralized manner. After all, they cover so much of the company that only highly placed executives will have the authority to purchase and start implementation of such a system.

Deployment of the core functionality is restricted to the key financial people who were probably involved with the initial evaluation of the system. Once the initial implementation is complete, however, the deployment of the balance becomes much, much more complicated.

Each additional module will have targeted a particular area of functionality. Some of these areas will be restricted to individual departments, others will be broad band. In both cases, many of the people involved with the deployment of these modules will not have been involved in the initial evaluation. Implementing a solution for such a module will require additional effort. It’s like attacking a village; house to house. Even with unlimited resources (and who has those?), all these secondary and tertiary systems cannot be implemented simultaneously. For one thing, some modules depend on the data from others. Much more importantly though, even trying to implement too fast is just too much culture shock for many firms.

It’s no wonder that the further you go from the centerpoint of the system purchase decision, the more likely it is that some departments will be looking for at worst interim solutions and, possibly permanent solutions for their particular function.

Not too surprisingly, as the ERP vendors themselves have had a lot of opportunity to see their original product implemented over time, some of them have found that there are ways of doing business that simply haven’t been allowed for in their system.

Sometimes third party solutions can be found which enhance existing functionality from the original ERP system. Sometimes, a third party tool simply does something more effectively than the internal tool.

Purists may take issue with inviting the consideration of third party tools but I think it’s inevitable. It’s now a given that a phased-in approach to implementation of such a system is more effective than trying to do it in one big bang. If the solution is being implemented module-by-module anyway, why not look for the “best of breed” for each of these modules as it comes time to implement them.

I have no doubt that this ERP “after-market” is not only growing but that it will continue to grow well after the millennium clock has ticked over. ERP vendors and the suppliers of 3^rd party tools which are linked to ERP systems have tremendous potential for growth as these “core-financial” installations move into their second and third phases.

- – -

ERP deployments seek to be the core business system for all business functions but they virtually always start at the center of the Finance department.  ERP firms, a niche with a tiny home in 1995 became a behemoth of an industry by the end of the 90′s as some firms became desperate to abandon old non-integrated systems in favor of a complete solution that would be not only Y2K compliant but more effective at the same time.

The wave towards major ERP deployments has continued unabate for the last decade.  What those vendors have been doing to continue their growth has been fascinating and in many ways affects the project management world.

Core systems are, of course, defined differently for each firm but generally can be thought of this way: Production systems come first; If we can’t make the plant work, it doesn’t matter what paper work we can’t do. Next, core financial systems; General Ledger, Accounts Receivable (and Billing), Accounts Payable, Payroll. Finally, anything that is absolutely required to make the first 2 categories work.

When we talk about ERP deployments however, we start with a common manta for all vendors: “All systems – one place.”  The idea is that everything will be integrated together and the first systems to be deployed by finance are always the 4 pillars of the financial environment: GL, AP, AR and Payroll.  Production systems are typically left unmolested and unintegrated while these core modules are stabilized.

This leaves a lot of room for systems to not be included. Worse, with the penalties for non-compliance of core systems being the ultimate price, the only sensible course of action is to put a huge degree of testing on those core systems, abandoning much of the work that might otherwise have been placed on secondary systems.

As we all know, compliance of applications alone iss only half the battle. Virtually all hardware, operating systems, communications protocols etc has to be tested and validated as well, all making even more incentive to put aside for the moment the secondary systems not essential to the functionality of the core systems.

Once the core is stabilized, it’s time to extend.  Secondary systems which might be working fine now become the targets for change in order to feed the mantra of everything in one place.

Just like the core systems, upgrades, changes and replacements will have to be prioritized. Systems may have been declared “secondary” yet, once missing can carry enormous impact on primary systems and on operations in general. After all, all of these systems; primary and secondary were presumably performing useful functions before the new ERP was deployed. You will have to look at what systems should be brought on-line before others; which resources you have available to complete the work and whether it might be better for your organization to put some of these secondary systems out of their misery altogether.

While I am sure that that some of these secondary systems have enormous impact on your organization, it is equally certain that some of them no longer fulfill a useful business purpose. It’s obviously silly to spend time, money and resource updating a system that makes no difference just because “we’ve always had it”.  It’s often amazing to me to review systems that have been in place for many years only to find that no one uses the product from those systems.

Systems that we can consider secondary includes different categories for different organizations but inventory, human resources, electronic timesheets, fleet management, analysis, project management, CRM (customer relationship management) are some of those which are often targetted.

All the skills that IT managers and project managers have been able to put to use in effectively updating the core systems now come in handy as the attention turns to the other systems.

The news for IT managers is not, however, all good. The chief problem to be working on immediately is maintaining management support that was so essential in getting the core systems in the first place. Deploying an ERP can be such an exhausting experience for senior management that keeping their enthusiasm alive for the secondary systems may be an issue.  Also, the success of the deployment of the ERP in the core systems may be a factor.  If that project went over budget and schedule, it may be difficult to find the funds required to update secondary systems in a timely fashion. Even where these secondary systems have already been purchased, say as part of a global ERP implementation, the extensive resources required to deploy the secondary functionality may be hard to find money for.

One thing you can’t do is ignore the problem. If the intent was to take a working environment and gradually upgrade it as part of a centralized system then you’ve either got to make sure those secondary systems become part of the central core or that you adopt a ‘best of breed’ approach to building bridges from the central core to those systems.

A curious transformation has come over ERP sales people that I’ve been meeting for the last couple of years. No, I’m not talking about that strange affection for changing their acronym like clockwork every 6 months. The last thing I need to hear in this industry is another TLA (3-letter acronym) No, I’m talking about the newfound affection for 3^rd party tools. Not so long ago enterprise sales people had only one tune to sing and that was “The only way to integrate is to eliminate all software but ours.” Now, some of us thought that was a trifle arrogant but that didn’t seem to bother ERP sales people who new that their way was the right way and were determined to prove it by eliminating all software in their path and having their clients try to work with just their own systems.

All of a sudden, these same salespeople have embraced 3^rd party vendors with the fervour of the born-again crusader. “We can’t be everything to everyone” they now claim, “We are committed to a best of breed solution.”

What, I wonder has brought about this change of heart? Is it perhaps the results of the over-publicized lawsuits of failed enterprise software implementations? Perhaps resistance isn’t futile and 3^rd party vendors efforts to stick with their clients are paying off.

I suspect, the new cry of the enterprise salesperson is the most likely scenario. It has turned out that it really is impossible to be everything to everyone.

As everyone who has ever designed and delivered a piece of software knows, the end result carries with it the bias of the author. The notion of a truly objective perspective in writing software is a myth. We can debate whether one package is more or less generic than another but each system carries its own ideas of how to do business. When you consider the major ERP or CRM vendors, it’s fair to say that they are the result of much feedback from the field in how they should be constructed.

But widespread feedback is not a guarantee of software that works for everyone. In fact, the more people involved in a design decision, the more likely you are to end up with something that is not useful to anyone. Software design through the consensus of a committee is a nightmare that thankfully results in very few software systems. Anyone who doubts this should try assembling a 30 person committee to work on any design issue and see what a few hours in a room delivers (here’s a hint – keep the Tylenol handy). No, the best chance for success in enterprise systems design is more likely to come from widespread feedback to a small, skilled design team who retains full authority to implement design changes as they see fit. All the more reason to believe that the result of such systems design will be a system with the bias’s of the designers in evidence.

Since such systems are being implemented in major sized organizations, the likelihood of it being able to meet the needs of the entire organization seem remote.

Also, remember, that these types of systems had to be sold. The marketing influence for an enterprise system will always be biased to what decision makers desire. Perhaps to no one’s surprise, the senior management and senior finance department personnel who are most often involved in these decisions were attended to first.

Perhaps the only surprise is that it has taken this long for the idea of a “best-of-breed” solution to be popular with such vendors to catch on. I suppose it’s the result of the length of time it takes to implement an enterprise ERP system.

There is a pattern to most of the post-implementation stories I’ve heard. The core Financial functionality implements just fine. The General Ledger, AR, AP and perhaps billing move forward without much trouble. Translating legacy data into the system proves the biggest challenge along with training the staff to work in the new system and designing and implementing new procedures to follow.

The system begins to settle in a routine and now attention turns to the secondary systems. Perhaps this is inventory or project control or time and attendance or manufacturing control. It is in these secondary systems that much more serious implementation challenges arise.

First of all, it is possible that the decision to use this enterprise software was made outside the control of the people who have been running these secondary systems. That generates resistance before the work even starts. It is also possible that the same functionality that made the system attractive for management makes it equally unattractive to end users working on secondary systems. For example, I’ve seen project management cost reports from an ERP system that were popular with management only to find that what appear to be rolled-up summary management reports are in fact the lowest level of detail permitted by the system and the tens of thousands of tasks that must be managed in the project system could never be effectively managed in the enterprise ERP.

There are many examples of such mis-matches in functionality. The old pitch for ERP systems was that everything would be integrated and it was worth trading some level of functionality for the benefit of every element of data being tied together. Out in the field however, it turns out that sometimes the cost of being integrated is by far outweighed by the benefit of using tools designed for their level of use.

It places the enterprise software vendors in a very different position. Suddenly they’re very interested in adopting partners who can integrate with their own systems. This is likely to open up access to the finance system market to mid-range players who have been unable to offer an integrated, across-the-enterprise system but can offer an open architecture finance system which is well suited to interfacing with other best-of-breed tools.

Best of breed? It sounds like a great idea to me.

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.

With both Microsoft and SAP taking a newfound interest in enterprise project management, an all out battle between these software behemoths seems inevitable.

There’s a battle brewing in the project management software arena and we’re just seeing the beginning of it.  Not long ago I spoke in these pages about the movement of Microsoft with Project 2002 into the enterprise project management space.  This had previously been the domain of only a select few project management software vendors who had quaintly become known as “high-end vendors”.  You know who I’m talking about; the Welcom’s, Primavera’s and Artemis’s of the world.  Well, less you were worried that Microsoft will be left an open field, there are other software giants also interested in the booming enterprise project management software market.

SAP, who’s impact on the ERP market in a relatively short time has been remarkable, has also taken aim at winning the hearts and minds of project managers everywhere.

Although the target seems the same, the approaches of these firms are quite different.

First of all, the notion of enterprise project management software is hardly new.  The very first project systems created on mainframes were directly targeted at enterprise work.  It’s true that the projects that would warrant project software in the early 70’s had to be mega projects in order to afford the software, hardware, implementation consulting and training costs required to make one of these systems work yet the analytical results went directly to management.

The increasing affordability of computing power and, in particular, the acceptance of Windows brought project management from a centrally controlled project management office to virtually anyone interested.  Even where no central project management existed, organizations could now enjoy some of the benefits of project management software because it was so easily accessible to end users. 

In the last few years, however, increasing interest in returning project data and analysis from individuals into the corporate pool has resulted in a newfound interest in centrally maintained project management.  Thus the interest in project management software that could bring these project individuals back together.

Microsoft’s latest release is directly targeted at this desire.  It’s only natural of course.  Microsoft has been amazingly successful at capturing the desktop market for project management software.  The ease-of-use in Project has made even scheduling neophytes able to develop professional looking schedules with a minimum of training.  Microsoft has been under increasing pressure for the last several years to make Project better able to deal with issues like multi-project, central resource pools, enterprise reporting and portfolio analysis.  The now almost universal use of the Internet has pushed for more collaborative functionality; all of this designed to bring project managers together. 

SAP however, has been under pressure also.  Their P/S module was designed to provide everything management would desired in project management analysis.  Fine – if you were in management.  The P/S system however, did not start out  with the end-user ease-of-use which Microsoft had so enjoyed.  The advantage of P/S, users were told, was its direct integration into all other aspects of the ERP system.  A project in P/S would typically have a tiny number of tasks – more like cost centers or cost accounts than the tasks one would think of in an end-user’s schedule.  SAP’s deployment of the system was greated with predictable results.  Financial management people seemed to like what they saw.  The system did have the high-end reports they desired.  Project schedulers and PMO’s were less happy.  Many fought to keep their existing scheduling systems.

Like Microsoft, SAP has made advances.  In this case instead of coming up from the desktop end-users towards the enterprise, SAP’s latest P/S module targets more toward the end-user.  Speaking to representatives from both firms can be fascinating.  They could share many of the same PowerPoint slides.  Both groups are directly targeting the enterprise project market and each has the advantages and disadvantages of their legacy systems.

SAP carries the stigma of being management’s system and not the system of the end-user; of the employee.  SAP must convince the end-user project managers that their tool can handle the capacity in an easy-to-user manner and they start from a reputation (whether fair or not) of being user-hostile.

Microsoft carries of stigma of not having been a serious project management tool.  Professional project managers have carried a long-standing opinion of Microsoft Project as a tool for inexperienced or unskilled project planners.  Microsoft must overcome those considerations and convince senior project personnel that they have the capabilities to handle enterprise-level use.  Microsoft must also convince management that Project is now of enterprise-level quality and can be integrated into core financial and production systems.  All of that being said, Microsoft carries the huge advantage of market penetration.  They can honestly say that they have sold more project management software than any other firm ever.  Microsoft clearly controls the desktop market.  It has become a universal axiom that virtually every major firm owns Project.  Microsoft has already won the project management market in numbers, now it will attempt to expand the influence of Project further into its clients.

Less you were worrying about all the other software vendors I’ve not named.  The initiatives of these two firms does not imply that other pm software publishers are out of business.  In fact, many will enjoy the likely spin off effects of huge interest being focused on the project management software industry.  It does mean, however, that you’re likely to see many vendors taking a more focused or niche approach to future development.  The contest of controlling the mainstream or generic project management software market has very little room for more players.

Who will win?  The jury has been barely convened and is certainly not out.  Each of these software giants have allocated tremendous resources at making this category of software key to their expansions. However, with the vast majority of end-users already using its tool, Microsoft has what must be the lesser challenge of expanding existing use rather than SAP’s challenge of expanding Financials into a new category.  

Still, just the efforts being expended in this contest is bound to have good fallout for project managers as more and more resources will focus on bringing project management to the enterprise level.