One of the most common problems that organizations doing a big enterprise project management or enterprise timesheet deployment run into is trying to do more than one enterprise deployment at once. You would think that no one would deliberately put themselves into harm’s way by doing this but it happens often and that’s partly because of how insidious the problem is.

The road to trouble is paved with good intentions
Imagine if you will, being in a conference room in the very earliest days of an enterprise system deployment. The world is full of possibility. You’re working with management to identify key gaps in your organization’s processes. You’re looking at a myriad number of tools that promise to solve all evils. You’re narrowing down how you’ll attack the business challenges with the proposed system.

As you all look together at the processes that will be affected, it occurs to you that one of these processes reaches outside your original mandate. Perhaps you’re looking at creating a resource capacity planning system but it becomes clear as you design that solution that you’ll need to change the current time and attendance system. Or perhaps you’re creating a work management system and you realize that you really need to update the old CRM system. Or, perhaps you’re changing the way you do billing with a new ERP and you realize that you really need to update the document management system.

It’s the easiest thing in the world to let your mandate go beyond its borders and it’s the easiest while you’re in that honeymoon period of designing the new enterprise solution that you started with.

“Let’s just include that 2^nd system while we’re doing the first one,” says one well-wisher and now you’ve got not one but two enterprise systems to deploy.

Being pulled in two directions
Enterprise systems are change management projects. What that means is that they’re less about the particular functionality included and more about how they change business processes. By their very nature, enterprise system deployments reach deep into the operational behaviour of the organization and changes it to something that is hopefully more productive. Virtually any enterprise system can have this effect and the effect can be far reaching. A CRM system doesn’t just touch the sales people. It can also touch production, marketing, engineering, support and, of course, management.

With any enterprise system, we must go to senior management and ask what they wish to accomplish. My standard question for management is, “What business decisions can you not make now or can you make only with great difficulty, the making of which would be improved with this system?” That’s true for enterprise project management systems but it should also be true for virtually every system.

If you aren’t going to improve business decision making or operational efficiency in some manner, then there’s little point in deploying such systems.

But when we try to deploy two such systems simultaneously, we run the risk of pulling management in two directions at once. Even if the end result seems like a rational flow of decisions from Point A to Point B, the deployment of one of these systems will change behaviour and not just of management but of everyone the system touches. When we deploy a second system before the effects of the first stabilizes, not only will the second system be almost impossible to get established, the risk is to destabilize the first system as well.

The most common result is a complete failure of both systems.

Let’s take an easy example to see how this happens. An organization sees the need to improve efficiency in the area of project management. They decide to deploy a new enterprise project management (EPM) system to do so.

At the same time, the organization sees the need to improve resource management and decides that this can be done by deploying a new HR system, affecting all employees.

The two projects seem mutually exclusive and, indeed, for some time, the deployment teams might not even be aware of each other.

As the design of each of the enterprise systems evolves however, the changes driven by the design and deployment of the new systems start to run over each other.

The EPM system designers request a list of all departments, staff approval hierarchy and skills for populating the EPM system. These lists are delivered to EPM.

Over on the HR system deployment, a need has been revealed for better definition of departments staff hierarchical staff management and skill definition. The departments are realigned and redefined.

The HR changes are revealed to the EPM team who have already moved forward on their structure reworks the area that is affected by the changes in HR.

HR is informed by the EPM team that they will be implementing a resource management calendar for EPM and will require all vacation definitions updated weekly. They also send a list of new skills to augment the existing skill set.

HR has already redesigned the skill set for employees and the new definitions by EPM don’t fit. They begin to re-re-design the skills area of the new HR system.

And so it begins.

The most likely outcome is that a certain level of frustration will be reached and the original notion of integrating the EPM and HR data at the points it touches will be abandoned. Each team will go its own way. This might reduce or eliminate a key element of the expected benefits of the new system.

A less common but usually more damaging outcome is that as the frustration of the back and forth changes increases, someone in management figures that this could be resolved by putting both initiatives into one monstrously big initiative and working the projects together. This is rarely successful.

Moving from in parallel to in sequence
For most business initiatives, working multiple tasks in parallel is highly efficient. Deploying multiple enterprise systems is not in that category. When it becomes clear that there are two enterprise system initiatives that can touch each other, the most prudent action is to advance one of them and slow down the other.

Determining which enterprise deployment should go first will not be a popular task. It does, however, offer a great opportunity for benefit because this type of decision can really only be made by senior management.

One of the leading causes of enterprise system deployment failure is the absence of management involvement. Technical and operational personnel are often given deployment projects without direct involvement from senior management to determine what benefits are expected from those systems. When two such projects get underway at once, it’s a good moment to re-involve management in the process to identify what is expected by the organization from each system so that a decision can be made as to which one should be done first.

Some of the decision making criteria for deciding which system should go first might include: expected benefits, costs, return on investment, speed to deploy, severity of impact on existing processes and risk.

Only once the first project is in production and is stable should the second project’s design restart. A stable, in-production system is one where the organization has fully adopted its use, has changed its processes to adapt to the new environment and where the benefits of that system are already being realized.

In the meantime, if your project is the one that has been slowed down, all is not lost. Knowing that you won’t be able to count on a shiny new enterprise system to solve your problems sends you back to the drawing board to think of how to solve your problems without it. We’ve seen countless examples of where an organization realizes other ways to improve their processes while waiting for the new enterprise system deployment to restart.

Whether your enterprise project is going first or going second, it’ll be better than having it go together. Doing two enterprise projects at once is a worst case scenario.

Microsoft has posted my latest article, Creating an EPM Deployment plan up on the Microsoft Project Server TechNet site under the Project Server 2010 area.  The article looks at those elements of a deployment of an Enterprise Project Management system that are much more than the installation and configuration of the tool itself.  When you take into account the management intervention, the change management implications and the overall impact on the enterprise, the project becomes more complex.  It’s a good starting point for those looking at moving to enterprise collaborative tools for project management and, if the organization already had much of this done, perhaps they can move quickly to the automation aspect of the project.

What is it about Enterprise Project Management system deployments that make them seem like an appetizer rather than a big meal?

Just like people who look at the menu when they’re very hungry and order the soup, the salad, the big steak with fries and then throw caution to the wind to pre-order a huge piece of pie, I often encounter senior managers who are struggling with an EPM system deployment that has turned out much bigger than they’d ever expected.

When you boil it down, the chief cause is often embarrassing to who is inevitably the most experienced project management person in the organization; this chief cause if is often a failure to plan.  Those who had coolly scoped the project and determined just how far advanced the organization was towards the perceived solution, they’d have probably backed up to regroup. 

Unfortunately that’s not always so. 

Even project management systems need some project management when they’re deployed.  Measure twice and cut once is advice given to carpenters but it could just as easily apply to project managers starting an EPM systems deployment.

My friend Adrian Balfour who runs PCubed has just done a great article that people like Adrian (and I) have to deal with on a regular basis.  How do you convince management to make the investment in proper project management.  His article “How to Sell Project Management to Senior Executives Who Don’t Want It” is a great read.  Go take a look on the PCubed site.

We spend a lot of energy in project management circles trying to determine how to do a thing. In my travels to various parts of the planet something that’s sadly lacking in many places is good judgement on whether we should do that thing.

I’ve told the story before of an engineering organization that was looking for a new timesheet system. This sounded like good news to me because our own TimeControl timesheet system is a good fit for engineering firms. Yet, I was less happy when I heard the reason why the customer felt that their existing system was no longer able to meet their requirements.

“We’re having to do a whole manual transfer of data from that old system to our Finance ERP,” explained the technology specialist. Because they need 3 rate values and our existing timesheet can send only two we’re having a miserable time with all this manual intervention trying to get a third value stored and sent. Can you that with your TimeControl?”

TimeControl was certainly capable of sending multiple rate values, I assured the specialist but I was at a loss to understand why they needed such an interface in the first place. In the end, after some discussion, the client agreed to pay for a day of system design and I scheduled some time in the offices.

Our meeting together started off just great. They had the CIO in the room and I was suitably impressed that the head of the IT department was sufficiently interested in the problem to attend himself. He and the technology specialist took turns white boarding the problem By our mid-morning coffee break we had a combination of boxes, diamonds, circles and lines in the four basic white board marker colors all over the board.

I took copious notes.

By the break though I had my first intelligent question. “What was the volume of transactions,” I asked, “that was being handled through this manual process?”

No one knew the answer.

“Can we ask the CFO?” I asked.

A quick call was made. Yes, the CFO was keen to talk to me but could only do so over lunch. I was delighted. Senior management intervention at such a rapid pace isn’t that common and indicated to me that management was committed to get this problem handled. Things were looking good.

We worked for another hour on the white board diagram. I headed to lunch with the CFO, the CIO, and the technology specialist that had called me originally with a good understanding of what they wanted and the kind of time it was going to take to create. The CIO and I agreed that changing the timesheet was fundamental to the new solution and that 6-8 weeks of developer time to automate this “archaic manual transfer process” sounded quite reasonable. I was upbeat. Sounded like some business on the way.

Yet, there was something niggling at the back of my mind. The whole premise of the problem came back to a lack of a single field in the old system and its inability to move that column of data to the Finance system. I’d already determined that this data was critical to the corporate effort “Why not just give up on that extra data,” I’d asked. “What would happen if you just didn’t transfer the data?” The CIO had told me he’d already considered just that and that management had made a good case for this data being essential to their ability to bill accurately.

Time for lunch. We went across the street for chicken. (Business lunches always seem to be feather, leather or fish!)

I sat across from the CIO with the CFO to my left. The technology specialist was across from him. We exchanged pleasantries and then ordered and while we waited for our meal, I turned to business.

“I’m here to work on this timesheet system to finance system interface,” I explained. “The CIO here and your technology specialist have been describing the challenge but perhaps you could describe your understanding of it in your own words.”

The CFO to his credit describes exactly what we’d been talking about all morning. This was a good sign. Often when you go back to the client or end user of a system, the understanding of the requested change isn’t at all what IT understands.

“Now could you describe how you handle the interface now,” I ask.

“It’s an archaic manual intervention,” he describes. Again, sounds just like what I’d heard this morning.

“And how many transactions are managed through this archaic manual intervention?” I ask.

“Oh about 5 a month,” he says.

There’s silence at the table.

“Five,” I repeat. I see the CIO’s jaw drop out of the corner of my eye.

“Yes,” says the CFO.

“And how long does it take to do these transactions manually each month?” I ask.

“Oh, it takes one of my staff about 20 minutes,” he says.

“Excellent,” I say, my heart sinking as I changed the subject.

The CIO couldn’t meet my eyes. We finished our meal and headed back to the office as we did so, he walked next to me. “I’m so sorry for wasting your time,” he apologized.

“No need to apologize,” I said. “I’m just happy we figured this out before spending 8 weeks on writing the interface.”

The time to recoup a return on investment from the effort we’d described would have been many years. At 20 minutes a month there was no point in doing the work. In fact, the company had already spent way too much time working on how to do it already.

Could we do the work? Sure. But we shouldn’t.

And sometimes that is the most effective project of all.

I was working with a large Canadian company recently, helping with their enterprise project management processes. As part of my work, I got to watch while a project control officer prepared a report for the Chief Financial Officer.

It was a work of art.

First data was grouped together from multiple projects in the desktop version of a popular project management system. That data was copied and then pasted into a massive Excel spreadsheet as core data for what would become this report.

Now, this person grouped the Excel data and sub-totalled it. Next, a series of macros that were clearly cleverer than I am, created an entirely new Excel workbook with the data now grouped and sub-totalled in a completely different way. The project staffer now reviewed several thousand lines by eye, looking for discrepancies. When they found them, they returned to the first Excel cut-and-paste file and deleted lines, added lines and changed values so that the resulting final spreadsheet would be grouped in the manner they requested. When data really didn’t seem to make sense, it was removed for ‘later analysis’. The über-macro was run several times until finally the results were to this person’s satisfaction and then a second tab in the newly created Excel sheet displayed the data with lovely coloured headings and columns.

I was visibly impressed. But not in a good way.

During a report I made much later, one of the comments I made to the senior PM management was, “This report has a 100% chance of errors each month yet even though everyone knows how it is being produced, it is being interacted with as though it is financial quality data at the same level of quality as your payroll or your financial statements. You are making critical business decisions with this report that you know is flawed.”

The company took steps to improve their reporting process and created checks and balances to make sure the decisions they made were done based on information that they had a higher level of confidence in but the whole experience made me think about a deeper lesson that we can all take home. I wondered if there wasn’t incentive in the organization for this person to become the ‘indispensable project manager’; the person who is absolutely essential because they’re the only ones who can create the organization’s critical project reports.

We all have methods and processes in our project management environments that we’ve created ourselves and that can really only be accomplished by ourselves. If in this company, the person in question had to take a leave of absence, no one else on the planet would have been able to generate the report they did. That’s a risk factor for the PMO and it makes me wonder how many more such risk factors do we all have in our organizations.

The top level of virtually every Project Management Maturity (PMM) Model is to have the process be self-sustaining and self-correcting. Different models use different terms but the idea is the same. The original Capability Maturity Model developed by Carnegie Mellon University used the term “Sustained” for their top level 5 definition. This level of maturity indicates that the project management process can sustain itself and adapt or improve as changes occur. This would include, of course, changes in personnel which is always a risk factor to a process.

If the process was sustainable, then the steps to create a report, a method to test the report for accuracy and a schedule of when and how the report would be created would all be present. Hopefully this would be part of a much more extensive project management process guide that would include not just how to create a report but also the methods by which the data was collected so that we’d know the source information had quality as well. We often make important business decisions based on project data and there is often an assumption that the data is accurate because of how nicely it’s displayed yet it’s common to find project environments where data does not have verification for accuracy and where this is a poorly documented process.

I’ve been a big fan of a phased approach to things for a very long time so it’s a bit of a problem to me to find that the top level of the PMM process is often the last one tackled. I far prefer making an element of the project management process stable and then bringing that element all the way to the sustained level. Document the process, train the staff, repeat the steps required over and over, produce value from this one step and etch a groove for this one part of the process deep enough that it becomes ingrained in the corporate culture. Then build on the same method on the next element.

There’s a plus and minus to my thinking of course. On the plus side, the project elements I work on this way typically last a very long time. On the minus side, organizations rarely get to all the elements they originally envisaged. There comes a point where sufficient value is being produced by the elements of the project process that have been successfully adopted thus far that the incentive for additional investment is reduced.

From my perspective working on organizational project management, the pluses far outweigh the minuses. The bonus from the phased approach is that the process has power rather than an individual personality. There is no hidden, secret knowledge. The whole objective of a publicly known process is that everyone knows how the process works from start to finish. It’s all documented and all on the table.

Virtually anyone can make this kind of difference in their own project organization; small or large. Start by giving knowledge away by documenting how you get things done. If you’re in charge of a PMO, you can encourage team members to share their best practices and make them available to others but you don’t need to be in charge of the PMO in order to do this. It may seem counterintuitive to share your best techniques but don’t worry. Expertise isn’t a depleteable resource. You can generate new expertise tomorrow. Giving your expertise away and working to create your successful project management element as a sustainable part of your organization will have you leave a legacy; some difference that can last long after you’re not longer in that role.

After all, aren’t project managers about having others be more effective? That’s a real indispensable project manager.

“But the timesheet will update the project scheduling system in real-time, right?” says the project manager.

It’s a question I’ve heard many times before. It’s not that unusual for me but then, I have a company that publishes timesheet software for the project industry so perhaps I hear it more than others. The question isn’t at all uncommon for me but it’s also a question I dread hearing because the answer is inevitably much longer than the question and is rarely what the questioner wanted to hear. The notion of “real-time” project management has been around a very long time. Many publishers in the project software industry have used the term to entice clients who dream of “one-button” project management and “instant-feedback”. Before we can even start to answer the question posed to me, we need to look at what Real-time project management is and its implications:

First of all, what is Real-Time project management?

The expectation of some managers is that as individual project resources complete their tasks or report on progress as the day advances, they will be able to see the sum total of all projects progressing. Individual project managers might envisage little red bars turning green as tasks get completed throughout the day.

Is this even possible?

Sure. Modern day systems can move data as fast as you like. It’s not complicated to have a task updated by a user somewhere in the organization flag an update in the summary of the project. In fact, some vendors go out of their way to make this possible. It makes for a lovely demonstration of these “real-time” capabilities which is, after all, what those managers are hoping for.

Sounds good so far – Is there a problem?

The problem comes in terms of the assumptions we make when we look at project data. When we look at a GANTT chart or report of any kind in a project schedule, we have a few basic assumptions. It’s not obvious but think about what you take for granted in the data you’re looking at:

1.  
    
2. You assume that the data is complete

   Particularly when we look at a task’s schedule or at the task’s resource information, we assume that all information that relates to that task has also been updated. In a project schedule, almost everything is related to everything else. Missing even one task’s update information or one project resource’s update information may mean that the schedule you’re looking at is completely inaccurate. So, is the data all here? In particular when we talk about timesheet data (as that question to me was) finding out if we have all the timesheet information is essential. Did everyone submit their timesheet? Were they all approved? Are there any timesheets still outstanding or still stuck in the approval process? It’s no surprise that one of the most popular feature of our TimeControl timesheet system is the “Missing Timesheet Report” and “Missing Timesheet Email notification”. Getting 100% of the data collected can be a big challenge.

3. You assume that the data has been approved

   When a manager looks at project data, they have a natural assumption that the information they’re looking at has been approved by someone. Senior management won’t expect that they need to go to every individual project resource to determine that the schedule information is accurate. They expect that they can go to the project manager and have that project manager stand behind the data. Project system information is, after all, a synthesis of a lot of individual pieces of data that is analyzed and then presented in a particular way. Senior management assumes that the data that they’re looking at in their dashboard or in that management report has gone through some kind of approval process. This is particularly interesting as when we point out to management that they desire instant real-time feedback but also expect that the data has been approved in advance, that the two desires conflict.

4. You assume that inter-related data has been updated as well

   This is an easy one to miss. There are numerous potential elements of related project data but here are a couple of examples. If there are interrelated project schedules where the task of one project can push the schedule of another, we assume that this has been updated too when we look at our schedule. Or, if we’re looking at a related risk management table, we assume that it is up to date when we reference it from the schedule.

All of these assumptions carry implications. It’s certainly possible to create an automated project system that identifies when data is incomplete and show that on a dashboard or on a project report. But, in the excitement of imagining our soon-to-be real-time project system, it’s easy to overlook what we’d need to do in order to make use of the concept.

First, we’d need to be able to ensure that all data was collected hour by hour so that data was complete all the time. This is a herculean job. Anyone who has collected timesheets each week and ensured they’ve all been collected can attest to how much work it can be. Now imagine that you’re going to do that work twice a day to get project updates every 4 hours. It may well be impossible. If you don’t have 100% of the updates, are you prepared to use the resulting project data knowing that it may be incomplete? Perhaps the 20% of task updates you’re missing represent 80% of the schedule delays.

Next we’d need to be able to ensure that data was all reviewed and approved. Again, this can take an extended effort by the project manager or project scheduler each week. To do approvals like this twice a day could easily take longer than a half-day to accomplish for some projects. In environments where project schedule data must be updated shift-by-shift such as in a short-term shut-down/turn-around schedule, such efforts are done full time by a dedicated team of staff. The results are entered in the next shift for viewing a shift later. In almost any other environment, the organization won’t find the effort to update that frequently provides enough return on the investment to make it worthwhile.

When I’m approached by management and asked if I can provide real-time project management dashboards or real-time project management reports or, when I’m asked “But the timesheet will update the project scheduling system in real-time, right?” I ask a couple of questions in return:

“If I give it to you, what will you do with it? Are you ready to do real-time project management?” By that I mean, “Are you ready to take action all throughout the day as data would be presented to you?”

And, “Are you ready to put in all the effort it will require to collect, validate that it’s complete and approve the data before you look at it?”

When most people think about it, they put the idea of real-time project management onto the backburner… for now.

People are always coming to me asking for my help designing a solution they’ve already designed. It’s not their fault of course. Project Management software vendors have become very adept at creating marketing materials that make it look easy to deploy an enterprise project management solution “out-of-the-box” so if you find some solution for a particular problem in the marketing literature, it seems an easy decision to make.

Take an example I had recently. A project manager in an service business called asking if I could help deploy a server-based EPM system. I started to ask the questions I always ask: “What kind of projects are they? How do you manage these projects now? How big are your projects, how many do you have? How many people are resources in the system, how many people would be users?” only to have the person stop me in mid-stream to tell me that the answers to these questions weren’t important. They’d “already chosen the solution,” he told me and just needed someone to make it work.

I explained that I was in the solution business and if I couldn’t understand the problem, I wasn’t the person to deploy the solution. We talked a little longer and the problem the client kept describing was that they had outgrown the scheduling they’ve been doing manually using Outlook calendars and now needed to “upgrade”.

It’s not the first time I’ve been confronted with this exact request. Could we migrate a manually-driven Outlook-calendar resource scheduling system to an “automatic” Microsoft Project Server system? The answer to this is almost always no. This answer shocks and upsets everyone who gets it. “But there’s an Outlook module/connector in Project Server,” they explain to me patiently. Perhaps if I’d only known this I’d see the light and deploy what they want. They seem more upset when they find out that I’m aware of the Outlook connector and other Outlook tools.

The challenge in these situations isn’t the technology involved. This person was quite right. Microsoft has a new Outlook connector as part of Project Server 2010 that links to Microsoft Exchange Server. There have also been Outlook connectors in earlier versions of Project Server. The problem this person has is that he wants to move a relatively small organization which has allocated resources to tasks more or less manually with a single person or a person per large department sliding tasks manually into calendars into an organization where project scheduling, centralized resource capacity planning, resource conflict resolution and an enterprise project management process and associated tools are all automated to the point that the work happens automatically.

That’s a corporate culture and process change, not a technology change. I understand how tempting it seems when the solution for all the organization’s challenges seems only a software purchase away, but software is better considered as the potential for a solution rather than a problem-solved. Getting the software to the point where the problem that was originally encountered goes away may take a lot more thinking as well as resources, time and money. In the end, sometimes going with the large EPM deployment makes perfect sense and other times not.

Let’s take the original problem encountered by the organization who called me. What is the problem exactly? When we dig a little deeper, it seems that the problem is that the challenge with scheduling manually is when work occurs out of sequence or is delayed. When that is the case, then connected tasks such as we’d naturally think of in a logic-driven schedule don’t automatically move. Ok, anyone who’s done a basic course in project management and critical path theory can get that. Then, when we look a little deeper, it turns out that several division leaders are trying to share these Outlook calendars at the same time and doing so means that they can’t determine the priorities of different projects.

Well, if we could centralize scheduling into an actual project schedule, we might do well with having a small project office with one or two co-located schedulers.

But presenting that to the organization immediately generates resistance. What now surfaces is that the client loves how Outlook presents the tasks to the users and how users get these tasks by email even when they’re changed on short notice. This is why they went to looking at the big centralized enterprise project management system in the first place.

If we just take the problem though then there are lots of ways to build a solution: First of all, if we stay in a strictly Microsoft world, Project Professional 2010 can read and write the tasks from a SharePoint list. Outlook users can subscribe to such lists and even get email notifications when the list changes.

Next, if we just look at using a copy or two of MS Project centrally, we can use a tool like Housatonic (www.projectviewercentral.com), EasyTaskSync (www.easytasksync.com) or EasyTaskLink (www.easylinkmail.com) to move data back and forth between Project desktop and Outlook.

Lest we keep the whole conversation Microsoft-based, similar tools exist for Oracle-Primavera. PRMLook (www.primaveratools.com) for example links a Primavera schedule with Outlook.

If we look outside the box some more, TrackerOffice is a project management tool built around Exchange.

I’m not advocating any of these solutions but my point is that there are a lot of paths to get to a solution that may be appropriate and the best selection is going to have more to do with the exact nature of the enterprise and the challenge they’re facing than it is with the brochure of whatever software is being most heavily promoted on a given day.

“Work the problem, not the solution” we tell our consultants. It keeps us focused what ultimately makes a difference.

The CEO of Microsoft, Steve Ballmer got this year’s slogan going with a bang, “We’re all in!” he cried to the crowd early this year. It’s a poker analogy of course. “All-in” refers to betting all of your chips; putting all your money on the next turn of the cards. You’re betting everything that you’ve got the winning hand.

What Microsoft has been betting on is moving many of its products to the “Cloud” where users can consume them online. As I was talking about this new message of Microsoft’s to my wife it prompted the obvious question, “What is the cloud?” I had to think about it a minute. What does the IT industry mean when we talk about Cloud Computing and what are the implications to the project management software industry and to project managers in general?

First of all, like almost anything in the IT world, there are numerous meanings the cloud designation comes from network diagrams which had to depict connections to something out in the Internet.

So the “Cloud” can just refer to the Internet in general as in “somewhere out there”. In recent years though, applications that have been only available via the Internet have sprung up. There are numerous examples. Salesforce is a CRM, Contact Management System that isn’t installed at your local office. You pay a subscription as an organization and then access the application through your Internet Web Browser online. Google Apps is a suite of Applications such as Word Processing, Spreadsheets and Presentations that is available only through your browser. Microsoft’s office.live.com offers Word, Excel and PowerPoint this way also. Almost every knows about Hotmail, Yahoo Mail or Google’s Gmail. These are all Internet-based email systems that you don’t install in your office but rather access through an Internet browser or application of some kind. All of these examples are applications that live “in the cloud”.

One of the big concerns over cloud-based applications has been the security of the information. As many of us have seen in the past, social networking systems like Facebook are having its clients pay for its “free” service with a bit of their privacy. So, a new term sprung up, “private clouds”. This seems like a contradiction in terms but actually it’s referring to something of a mix of terms. A private cloud application is one which is not installed on your premises on your own servers but rather is installed on the servers of a service provider who dedicates that server for your organization’s use. So, the privacy of the information, even though it is being transmitted in some way over the Internet, can be made much more secure.

Ok, so that’s cloud computing, but I’ve yet to mention project management applications. Don’t worry, they’re there. There are a number of project management applications that are made available in both the Internet Cloud and Private Cloud models. Many clients we know are now having their enterprise project management applications such as Oracle’s Primavera or Microsoft’s Project Server hosted by a third party service provider. There are also software vendors who have designed their whole application to be available only through online subscription and your Internet Web browser. Take a peek at Canada’s AceProject (www.aceproject.com) based in Quebec city or Daptiv (www.daptiv.com) based in the US in Seattle. There are many more examples which you can find instantly through an online search.

Your own applications, even though internally developed can also be moved to the cloud. There are many environments to choose from. Take a peek at Amazon’s EC2 Elastic Computing or Microsoft’s Azure environments for examples. You can get your own virtual server at Amazon or a complete computing environment at Microsoft. More and more organizations are finding it attractive to offload their capital costs to such services in favour of regular operational costs as a method of improving cash flow and not tying up working capital in actual equipment. “Shift your CapEx to OpEx” say the salespeople.

With enterprise project management systems becoming more and more complex to support internally, there is some attraction to all of these models. Enterprise systems typically depend on a “stack” of technology. Take Microsoft’s Project Server as an example. We depend on Windows Server, SQL Server, Activity Directory, SharePoint, Internet Explorer and Exchange Server to make all the features in Project Server appear. If we can put responsibility for all of the server-based portions into the hands of a third party who specializes in such things, this can become attractive.

We estimate that more and more enterprise applications will not only become available from a cloud-based service but that more and more organizations will insist on such applications being subscribed to that way so look for more and more of your enterprise level applications to appear in the cloud. That being said, I don’t expect that at any time in the medium term we’ll see a movement completely away from locally installed enterprise systems. Also, regardless of what’s in the cloud, there will always be a market for individual project management tools.

So, what should you do? For the moment, probably not much that’s different but every organization looks at their internal tools every few years and I predict that people who are looking in the 2012 to 2015 range of time will be thinking about whether to install those tools in-house or in the cloud.

There are some clear advantages to installing in the cloud and a few things to be aware of.

On the advantage side, the maintenance effort of keeping the enterprise system available, patched, upgraded, backed up and operational falls to someone else. Suppliers of such solutions also keep staff experienced in the maintenance of the tool so you don’t need to stress over acquiring those skills internally or keeping them current. There’s also a financial consideration. Installation of a new enterprise system is typically quite expensive; requiring hardware, operating systems, databases and a range of other supporting technology. Expertise must often be hired to do the basic installation before you can even think about configuration of the tool for your particular use. These costs can be amortized over time in a cloud-based model and woven into the regular subscription fee. Of course if you evaluate the total cost of ownership, it may appear more costly to pay month-by-month over the long term. You’ll need to check your business case carefully to ensure you’ve allowed for all the costs and cost savings of each option.

On the disadvantage side, you’ve got a few basic things to think about. First, working with an application in the cloud means that every one of your users has to be able to get to the cloud. That means Internet access to the application without the firewall or other restrictions keeping you from it. Security also becomes a concern. If you’ve got a contract in certain industries (like Defense or Healthcare) then you may have legal requirements for security that must be complied with. If your organization is used to doing custom modifications to your applications then that may be a factor also. Some cloud-based applications are not designed to be modified by the end-user. This may be more restrictive than you’re used to. For some applications, bandwidth and performance may be issues. One common question is to find out where the application and its associated data will be physically located. Just because a service has an address that is local to you doesn’t mean they house their data there.

Cloud-based applications are here to stay and you’ll need to include “Should we move it to the cloud?” as one aspect of future enterprise project management and enterprise project portfolio management applications.

I’m a child of the 60s. Born in 1958, I was 8 years old when the original Batman TV series came on the air in 1966 and only 10 when it wound up in 1968. It lasted a 120 episodes but the impression it made lasts to this day.

In the world of Adam West and Burt Ward who played Batman and Robin, there was a ‘bat’ solution to everything. No matter what the problem, Batman would have the solution. The Batmobile, Batboat, Batplane and Batcave all had their place. And, if you were someone who needed help no matter how difficult, how could you reach Batman? Well, with the Batphone of course! Pick up the Batphone and help would be on the way.

I’m nostalgic but reminiscing about a 1960’s series really isn’t my point today. It’s over 40 years since we were introduced to the red Batphone but we’ve got many clients who would dearly love to get their hands on one. I know I get calls on a regular basis from people hoping that I’m the person who could answer the Batphone and deliver them the help they want.

In the world of enterprise project management systems, a Batphone would be a wonderful thing to have. God knows, I wouldn’t mind the number myself from time to time. The problem is, enterprise project management solutions have always sounded easier to deliver than they are. There are a number of reasons for that.

Firstly, enterprise software of all kinds is now dependent on a “stack” of technology. They require a database and a database server, an application and an application server, there must be middleware, security and identification systems, middleware communications, the operating systems, a web server, client browser or other software and operating systems, firewall servers and probably email servers. Each and ever one of these elements should, you’d think, be designed to work with the other, but in fact, all those elements have probably been created with multiple purposes in mind. In fact, getting them all to work together is challenging enough but we also have a myriad combination of hardware and network issues. Oh, and we haven’t mentioned international versions and “localization” complexities.

That’s just the building blocks of the modern enterprise system. There’s a massive second element and that’s configuration. There are resource, rate, task and project tables, system options, report parameters, customizable fields, algorithm options, calendars, and ancillary files such as WBS’s, OBS’s and other categorizing tables to populate. Each of these can have an effect on what your enterprise system can do for you. How should you be organizing the system to generate the effects you desire? For most large epm systems there is a manual of course and then for many there are 3^rd party books and resources that can help with each element of the system.

The third and more significant challenge is to decide what you want to accomplish with your epm system. To determine the functionality to use in your epm system, you’ve got to spend some time thinking about how you’d like to manage your projects and your portfolio of projects. You’ll need to think about how to do preliminary schedules, determine the metrics for valuable vs. non-valuable projects, resource capacity planning, resource allocation, resource conflict management, project tracking, management intervention, costing, estimating, variance reporting and more. To do this you’ll need some knowledge of what your epm system is capable of and a lot of knowledge about how to manage projects.

There’s a workflow challenge to be managed too. Where will the data come from that will power this system? How will the data be gathered in such a way that the benefits of the epm system aren’t outweighed by the work required to feed it with data.

Did I mention training? Not ever project management user is created equal. You’ll need a skills inventory and a plan for ensure the people who need to do certain things with the epm system have the skills to do so.

Oh, what about changes? When any employee changes roles, you’ve got a training challenge and whenever there’s a new version of your epm software (as happens regularly) each of the elements above needs to be thought of again.

Is it any wonder we’d all love a Batphone?

For those of you who remember Batman, you know that he never charged for his services and, no matter how clever or diabolical the villain, Batman was always able to vanquish him within the 30 minutes available to him.

I must get all the calls from people who remember that part of the show. On a regular basis a call comes in for someone who thought that getting their epm system up and running would be a simple affair that the lowliest intern in their office could get underway perhaps with an hour or two of assistance from an internal IT person.

When that fails, there’s usually a second attempt; this time with someone more senior who’s given a couple of weeks to achieve victory.

That too has little hope of success and by week 8 or 26 or 52, often the organization regroups and somewhere in there I’ll often get the call. It’s terribly upsetting to most people when I tell them that their simple upgrade may be several weeks of work or that that simple “reinstallation” they want to do is senseless if they don’t decide first what they want to accomplish with the epm product they’ve already purchased.

On a semi-regular basis, I have someone on the phone who describes to me how long it should take for me to fix their problem. They, of course, don’t have any clue how to fix it or they’d have done it already. But, they also know with a certainty how my personnel should fix it and how long it’ll take (usually an hour or two). We have little choice but to decline such calls.

Another regular call is someone who has a big problem but describes it as a solution. “I need you to come and create a proper report,” they’ll say. “What do you want to have in it?” I’ll ask. They won’t know. I always ask the client to describe the business problem and offer to help describe a solution to that but it’s harder to get people to think that way than you’d think.

It’s no surprise perhaps that there is more and more movement towards hosted epm solutions. I know the IT industry expects that enterprise solutions of all kinds will move this way to avoid at least the technological “stack” challenge and let clients focus their attention on the business and configuration aspects of the system.

People who deploy enterprise project management need to take into account the complexity of the business and technical challenge because there’s no Batphone really.

It’s a shame too cause I’d be using it all the time.