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.
