Skip to main content

Author: Chris Vandersluis

Not How Do You Do It… Should You Do It?

Written by Chris Vandersluis on . Posted in Articles. 6 Comments on Not How Do You Do It… Should You Do It?

FEATUREMar28thWe spend a lot of energy in project management circles trying to determine how to do one thing or another. 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. However, I was less happy when I heard the reason why the customer felt 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 three 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 do 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 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 whiteboarding the problem By our mid-morning coffee break we had a combination of boxes, diamonds, circles and lines in the four basic whiteboard 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 it indicated to me that management was committed to get this problem handled. Things were looking good.

We worked for another hour on the whiteboard diagram. I headed to lunch with the CFO, the CIO, and the technology specialist who had called me originally with a good understanding of what they wanted and the kind of time it was going to take. 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.

However, 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 that and 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 and your technology specialist have been describing the challenge but perhaps you could describe your understanding of it in your own words.”

To his credit, the CFO described 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 currently handle the interface?” I asked.

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

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

“Oh, about five a month,” he responded.

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

Don’t forget to leave your comments below.

Chris Vandersluis is the founder and president of HMS Software based in Montreal, Canada. He has an economics degree from Montreal’s McGill University and over 22 years experience in the automation of project control systems. He is a long-standing member of both the Project Management Institute (PMI) and the American Association of Cost Engineers (AACE) and is the founder of the Montreal Chapter of the Microsoft Project Association. Mr. Vandersluis has been published in numerous publications including Fortune Magazine, Heavy Construction News, the Ivey Business Journal, PMI’s PMNetwork and Computing Canada. Mr. Vandersluis has been part of the Microsoft Enterprise Project Management Partner Advisory Council since 2003. He teaches Advanced Project Management at McGill University’s Executive Institute.

The Indispensable Project Manager

Written by Chris Vandersluis on . Posted in Articles. 2 Comments on The Indispensable Project Manager

superPMI 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 deplete able 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.

Don’t forget to leave your comments below

Chris Vandersluis is the founder and president of HMS Software based in Montreal, Canada. He has an economics degree from Montreal’s McGill University and over 22 years experience in the automation of project control systems. He is a long-standing member of both the Project Management Institute (PMI) and the American Association of Cost Engineers (AACE) and is the founder of the Montreal Chapter of the Microsoft Project Association. Mr. Vandersluis has been published in numerous publications including Fortune Magazine, Heavy Construction News, the Ivey Business Journal, PMI’s PMNetwork and Computing Canada. Mr. Vandersluis has been part of the Microsoft Enterprise Project Management Partner Advisory Council since 2003. He teaches Advanced Project Management at McGill University’s Executive Institute. He can be reached at [email protected].

Solving Challenged Enterprise Project Environments

Written by Chris Vandersluis on . Posted in Articles. 4 Comments on Solving Challenged Enterprise Project Environments

PTimes_Nov3_Feature_cropped“So, what were you trying to accomplish here?”

It’s a common question that I’ve had to ask of many project management office managers.  Because of my background in enterprise project management systems, this mostly happens in response to some request to review a problem with a project management system implementation.  Over the years I’ve been called upon to try to fix, repair, re-establish or just replace a failed or problematic project management system and my approach is always the same:

Tell me what’s going on?

It’s a good start and it gets the problems and the client’s frustrations up on the table right away.  The story typically comes out in a jumble.  (Think Pulp Fiction where the story starts in the middle and then jumps to the beginning, back to the middle, to the end and then finishes back somewhere in the middle.)

Distinguish the parts

I’m never presented with a single problem.  Inevitably before the problem has been fully described, it’s more than one problem and it’s critical to distinguish each of the moving parts.  I’ve had lots of experience debugging system’s problems and anyone who has ever been in that role will tell you that it’s important to try to isolate the problems and then isolate the causes.

“So, what are you trying to accomplish here?”

Now that I have a fuller understanding of what is upsetting the client, it’s essential to know what they want to accomplish and therein lies the expectations of the client. 

Design the solution(s)

The solution is often not obvious and determining the expectations often changes where to look for satisfaction.

Let’s take a Look at Each of these Four Steps in a Bit More Detail

What’s going on?

When people describe a project management problem from a systems perspective the most typical description sounds like this: “It’s just broken”, “It just doesn’t work”, “It’s got a bug” or “The data is corrupt”.  None of these of course are helpful.  So we start by asking for specifics.  “What did you see that makes it look like it’s broken? , “Can you re-create the steps that make it look like it’s broken again?” “Can you show me a report or a screen-shot that made you think it was broken?”

This sometimes slows the process down.  Remember that the ‘What’s going on?’ process often arrives in a jumble and we may be looking at multiple problems.  When the client can finally show me the report, field, screen or result that they believe to be a problem, the next obvious step is to ask, “What do you believe the result should be?”  During this part of the analysis I’m often fascinated as to how people produce results. I’ve seen people take information from a project management system, extract it to Access or Excel, manipulate it with macros, formulas and then extract it again, merge it with data from other systems and then point me to the end result and say “See?  It’s wrong!” 

Think that’s unusual?  It’s not.  Excel remains the most popular project management tool by far and project managers often have more experience in it than in whatever project scheduling tool they’re using.

Distinguish the Parts

When we get the offending result identified and I can determine that it is, in fact, not the result the client was expecting, it’s key to ask “What other results are not appearing as you expect?”  Often there is one part of the data or the process that is the most problematic for today but there are other results that are only a minor irritant yet may have bear a significant impact on the problem.  For example, I had a client who was unhappy with the resource levelling results of a project management tool.  “Is there annnnyyyyyttttthhhiinnnnngggggg else?” I asked.  Well, there was.  There had been a minor irritation with how individual resource calendars were updated when vacations were taken.  That opened up the door to how resource availability was defined and before you know it, we’ve got a fundamental break in the resource definition process as the main culprit.  We standardized that process and how an individual resource’s availability was defined and presto – the scheduling results were all perfect.

So, What are We Trying to Accomplish Here?

The answers to this question often amaze me and you’d think I couldn’t be so surprised after almost 30 years in the industry.  The most likely easy answer is “We just want enterprise project management”.  Of course I then have to ask what they mean by that.  On many occasions lately what I hear is “We just really needed a timesheet”.  The client has purchased an entire resource management, schedule management, portfolio management analysis system and then finds that the timesheet aspect of what they purchased just doesn’t give the results they were expecting. 

It’s also common to find that the education of working on an enterprise project management system deployment has changed the perspective of what they really need.  Perhaps they were enthralled by the sales demonstration before they got started.  Perhaps they didn’t really understand what questions they should be asking.  Perhaps more knowledgeable people were hired only after the deployment started.  Either way, the notion of what’s now required evolves and by the time the client calls me to help get their project management environment back on track, the expectations of the original system are quite different from what they were before we started. 

It’s also very common for the client to have gotten so caught up in the minutiae of system issues that they’ve lost track of what the original goals were. 

This often brings us to a challenging aspect of the repair project.  What if the new goals of the enterprise project management environment would be better served by not continuing to deploy the system they’ve already got a lot of investment in?  We’ve had a couple of cases where the client was trying to deploy an entire enterprise project management system but in the end just wanted a timesheet.  Do we keep banging the square peg in the round hole?  Or, can we put that enterprise system aside for now and just deploy a more appropriate timesheet?  Now, that’s a situation of going from a more complex system to one that’s less complex but I’ve seen the reverse as well.  Someone takes a simple internal timesheet system and then tries to modify it with every enterprise project management feature they’ve envisaged.  At some point it makes sense to pause that work and rethink the whole tool selection.

Build the Solution(s)

I’ve been talking a lot about tools but often a solution can be found in the process.  It’s common to find that some process that evolved over time or that is engrained in the corporate culture is the root cause of data analysis that makes no sense.  Once we know what the client needs are, we can go back to the source and start with a solid process for collecting and analyzing the data.  What the client originally thought of as a tool “bug” or “corrupt data” is often resolved with a change in how data is collected, in how it’s interpreted, with training or just by saying “don’t do that anymore” (I can’t tell you how many times I’ve had to say that).

It’s also possible that we can produce a result in a manner that the client hadn’t thought of.  Once we know what the client is trying to accomplish, there are often a number of ways to get there that the client simply hadn’t thought of.  From time to time, for example, I’ve had to say, “Why bother automating that?  We can do it manually in 10 minutes per month with a lot less stress.”

If you take a methodical approach to solving issues that are a challenge to your enterprise project management environment, you’ll find that most of them are solvable very quickly.  When it turns out to be expanding into a more and more complex problem it’s often good to take a big step back and look from a higher perspective.  Figure out what you’re trying to accomplish, what benefit that will bring you and then how you’ve been trying to get there.  When you break the problem down to its component parts and you can see clearly where you need to get to, building a path there is easier. 

Don’t forget to leave your comments below

Chris Vandersluis is the founder and president of HMS Software based in Montreal, Canada. He has an economics degree from Montreal’s McGill University and over 22 years experience in the automation of project control systems. He is a long-standing member of both the Project Management Institute (PMI) and the American Association of Cost Engineers (AACE) and is the founder of the Montreal Chapter of the Microsoft Project Association. Mr. Vandersluis has been published in numerous publications including Fortune Magazine, Heavy Construction News, the Ivey Business Journal, PMI’s PMNetwork and Computing Canada. Mr. Vandersluis has been part of the Microsoft Enterprise Project Management Partner Advisory Council since 2003. He teaches Advanced Project Management at McGill University’s Executive Institute. He can be reached at [email protected]

The Real-Time Project Management Myth

Written by Chris Vandersluis on . Posted in Articles.

Oct_6_New_cropped“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. 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 features 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.
  2. You assume that the data has been approved
    When a manager looks at project data, they make 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.
  3. 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 four 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 back burner… for now

Don’t forget to leave your comments below

Chris Vandersluis is the founder and president of HMS Software based in Montreal, Canada. He has an economics degree from Montreal‘s McGill University and over 22 years experience in the automation of project control systems. He is a long-standing member of both the Project Management Institute (PMI) and the American Association of Cost Engineers (AACE) and is the founder of the Montreal Chapter of the Microsoft Project Association. Mr. Vandersluis has been published in numerous publications including Fortune Magazine, Heavy Construction News, the Ivey Business Journal, PMI’s PMNetwork and Computing Canada. Mr. Vandersluis has been part of the Microsoft Enterprise Project Management Partner Advisory Council since 2003. He teaches Advanced Project Management at McGill University‘s Executive Institute. He can be reached at [email protected]

Work the Problem, Not the Solution

Written by Chris Vandersluis on . Posted in Articles. 8 Comments on Work the Problem, Not the Solution

Work-the-problemPeople 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 a 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 in 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 that 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, EasyTaskSync or EasyTaskLink 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 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.

Don’t forget to leave your comments below

Chris Vandersluis is the founder and president of HMS Software based in Montreal, Canada. He has an economics degree from Montreal‘s McGill University and over 22 years experience in the automation of project control systems. He is a long-standing member of both the Project Management Institute (PMI) and the American Association of Cost Engineers (AACE) and is the founder of the Montreal Chapter of the Microsoft Project Association. Mr. Vandersluis has been published in numerous publications including Fortune Magazine, Heavy Construction News, the Ivey Business Journal, PMI’s PMNetwork and Computing Canada. Mr. Vandersluis has been part of the Microsoft Enterprise Project Management Partner Advisory Council since 2003. He teaches Advanced Project Management at McGill University‘s Executive Institute. He can be reached at [email protected].