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.

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.

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 had the opportunity to be interviewed on my career and my views of the project management industry recently.  Samir Penkar runs the Future of Project Management site at futureofprojectmanagement.com You’ll find the interview on the site just look for A few Key Decisions to take a look.

It’s great to talk to others in the industry about trends and where things have been, where they are and where they’re headed in the coming years.

Microsoft Technet keeps a column of some of my articles that are on the Project Server 2010 site over there.  The latest article is entitled Centralize or Decentralize.  You’ll find other articles in my “From the Trenches” column on that site.

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

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.

Project Management systems – it’s about deployment. Sure, there are lots of functions to consider and everyone wants to know your “methodology” but if you are committed to having projects fit into a an organizational system, it all comes down to deployment. Can you assemble a system that will actually be accepted and used by the end-users who will have to use it. Deployment includes all of it: developing the concept, buying or writing the system, installing it and configuring it of course and, most importantly, getting acceptance from the end users who must populate it with accurate and appropriate data.

Over the next few issues of PM Times we’ll be looking at how to deploy a project management system. We can’t of course, give you a complete course in the few paragraphs we have here. That would take a book. We can however, raise some of the key issues and give you some food for thought in dealing with whatever your current project management system environment is today. Whether you’ve got a well established project management system or if you’re just getting started, looking at how your system should be deployed is key to its success.

In this issue we’ll look at establishing requirements for a project control system. In the next issue we’ll cover creating the deployment plan. The next issue will cover training and finally we’ll look at integrating your pm system with other elements of your enterprise.

Requirements of a project management system
It used to be hard enough to set the requirements for a pm system for the organization. Internal experts and sometimes external consultants would congregate and, after extensive interviews with staff and management would go to the market to see what might be available. From the myriad dozens of potential products, the selection team would make a short list and vendors would troop in to display their wares. With luck, the selected system would meet most of the “must-have” requirements and would also squeeze into the budget.

The pace of change in today’s world makes one nostalgic for those simpler, kinder days. Imagine that five years ago there were perhaps 4,000 organizations who had ever heard of the World Wide Web. Now, some 4,000 new domain sites are registered every day. Two years ago, Java was something you had with your donut in the morning. Now, it is on the must-have list of every project management systems requirement.

What hope is there of setting appropriate requirements for a project management system your organization when technology upon which those requirements must rest is changing faster than you can even complete your analysis.

Well, it’s not as bad as you might fear. First of all, forget for a moment about technology. Your search should focus instead on who needs access to the system and, once they get it, what they’ll want to do. The great thing about the proliferation of Microsoft Project is that it has given us a good benchmark to use in describing functionality to end-users. A little thought about your own project management process here, at the beginning of your implementation will be the highest leveraged effort of the entire exercise.

Work on some of these questions:

• Who has access to the raw data to create new projects and to update existing ones? Should they have direct access to the project management system? What benefits would they gain from direct access? What benefits would the organization gain?
• What is the project management skill level of the projected users
• Who receives now and who will receive the output of the project management system? What reports will they need? How will having that report or data make them more effective? Is there an actual purpose to the reports they are receiving now?
• What lack of project-oriented information or analysis is hurting the organization? What impact would the availability of this information have?
• Who will champion the project management system? What is their authority? Who at the most senior level of the organization is sponsoring the initiative? What are their expectations? Are they achievable?
• Are there external influences in the implementation of this system (e.g. contract requirements)? What are they?
• What other systems will the pm system need to integrate with? Are these systems open enough to integrate? Will the system need to depend on third-party interfaces?

Once you’ve answered some of these questions you can start looking at some of the key building blocks in creating a project management system which will be acceptable to multiple users across your organization. Concentrate on some of the following factors while looking for potential vendors of expertise and systems:

• Suitability to purpose. Ask the vendor what experience they’ve had with your type of industry. Get references and (don’t forget!) call them!
• Flexibility, flexibility and (did I mention this?) flexibility. An “open-architecture” system will be one which can be easily enhanced and upgraded and modified from one use to another. This is key when technology may change faster than your projections.
• Multiple levels of interface for multiple types of user. Sorry, one size does not fit all. Many enterprise-wide vendors will have flexible interfaces or multiple products.
• Open data architecture. “If you can get at the data, you can do anything.” is a bit of an overstatement but key to interfacing with other systems.
• Keeping your options open is key to success in the deployment of a project management system. Until the next issue when we look at your deployment plan, I’ll leave you with this thought from Napoleon Bonaparte: “A battle plan lasts until contact with the enemy.”