Microsoft has released a cumulative update for Project Server.  Such updates typically include components of both Project Server and Microsoft Office SharePointe Server (MOSS).  You’ll find the relative information below.

Webcast on the June Cumulative Update:
Information About Microsoft Project and Project Server Cumulative June Update

How to deploy cumulative updates for Project and Project Server
http://technet.microsoft.com/en-us/library/dd239177.aspx

Rollup Packages:
This is a set of two rollup packages which contains all the fixes for WSS, Project Server and MOSS.  These packages should be used when MOSS is part of the deployment and/or you have language packs installed.  The Server Rollup Packages are much larger (~200MB each) but they will greatly simplify MOSS patch deployment.

• Windows SharePoint Services 3.0 Cumulative Update Server Hotfix Package (WSS server-package): June 29, 2010
  http://support.microsoft.com/kb/983311
• Office SharePoint Server 2007 Cumulative Update server hotfix package (MOSS server-package): June 29, 2010
  http://support.microsoft.com/kb/983310/

Individual Product Packages:
Individual Packages are specific to a particular product like WSS and Project Server.  These are smaller downloads but they do not include language packs or patches for other products so patches for those products would have to be downloaded and installed separately. 

• Description of the SharePoint Server 2007 hotfix package (sts-x-none.msp): June 29, 2010 http://support.microsoft.com/kb/983307
• Description of the Project Server 2007 hotfix package (Pjsrvapp-x-none.msp; Pjsrvwfe-x-none.msp): June 29, 2010 http://support.microsoft.com/kb/983312
• Description of the Office Project 2007 hotfix package (project-x-none.msp): June 29, 2010 http://support.microsoft.com/kb/2028571

Client Installation:

In order to install this hotfix, you will need to have Microsoft Project 2007 SP1 installed on the client: http://support.microsoft.com/kb/937154/en-us

NOTE: Microsoft strongly recommends testing within a NON-Production environment prior to rollout.

Over the last 5 years I’ve spent a fair amount of time working with Microsoft on deployments of its Project Server system. Microsoft refers to its entire solution as the Microsoft EPM (Enterprise Project Management) Solution as it encompasses much more than just Project Server. To consider the total solution we think of a “stack” of technology. There is Microsoft Windows Server 2003 to start with. Part of Windows Server that’s critical to this kind of deployment is Internet Information Services which is the Web Server for delivering all the web content. Along with Windows Server is Windows Sharepoint Services (This is included with Windows Server) which provides us with collaboration and web portal functionality. We often do authentication with Active Directory so that’s part of the solution too. There’s also SQL Server where we’ll house the database. Microsoft Office Project Professional and Project Server and the Project Web Access interface are the more commonly expected pieces of software. Finally, there are some elements of the functionality that might require Microsoft Office, Microsoft Office System, SQL Reporting Services or SQL OLAP Services.

Quite a mouthful, isn’t it?

There’s no doubt that the end result is a powerful one and no doubt that the solution has been well received. Even among Microsoft’s detractors, there is widespread opinion that Microsoft is a force to be reckoned with in the EPM space. The initial targets for this new enterprise functionality was, to no one’s surprise, Microsoft’s enterprise accounts. Microsoft doesn’t publish numbers of how many such accounts exist but it is no secret that these accounts typically number in the thousands of PCs. In these kinds of companies, there are numerous resources that are applied to an EPM deployment. The IT department has network administrators and installers and technical support personnel. There are database Admins and programmers and so on. Well it’s been 5 years now and Microsoft has surely had the chance to present their solution to all of their enterprise accounts by now.

I bring up this whole topic because what Microsoft is about to confront is surely a trend to be considered by everyone who creates systems for enterprise project and portfolio management. Microsoft must, over the coming years start to look beyond just their enterprise accounts and see how they can craft a solution and a sales and deployment message that is as attractive to the mid-market as the one for the enterprise market was.

In our business we get calls almost every day from a mid-market sized firm. “How long will it take us to implement Project Server,” they ask. The question is worded in different ways but it becomes clear quite quickly that an answer that is in the denomination of months isn’t going to find any traction. I can’t tell you how many times we’ve gotten a call on this subject that sounds like, “Can you get the whole job done by Friday?”

With enterprise level clients, there is almost always an understanding that the deployment of such systems must be managed as a change management project. It’s the culture change, not the technology which is the big challenge. This is no surprise in a large firm. We’re talking about managing a major aspect of the business in a different way and this may well have a ripple effect through the organization.

There are aspects of this that are true at the mid-market also but it’s a truism to say that the smaller the organization, the more maneuverable it is. So when we explain how challenging changing behaviour may be, this is often met with more resistance at the mid-market or small-market level.

If you were Microsoft, or another project management software vendor, you’d have to think about how to tackle this market. The same sales model that worked for the enterprise isn’t going to fly here. What will be required is what people always expected from Microsoft: instant results.

This leads to what I believe will be a major trend in project management tools and their manufacturers over the next 5 years: The commoditizing of epm software. Publishers must ask themselves, “How can we provide a solution that enables the correct process, is a minimal drain on management to design and configure and is priced in a way that mid-market companies can afford the total cost of ownership.”

So, how do you go about commoditizing such a product/service offering? I have a few ideas.

First, make the technology all install at once
This is within the technical grasp of the large EPM system publishers. Make a one-click install that works for most mid-market size deployments. When we think of an enterprise deployment, we start talking about multiple servers, web farms, load balancing and other high-end challenges that just don’t exist when the total number of users is 200-300.

Next, pre-configure the software for my use
Sure it’s true that every company is a little different but there are many commonalities between firms. Instead of having the software arrive with nothing in it, the publishers could spend time making sure it’s pre-configured for the most common use with reports, customized fields, lookup values etc. all pre-set. Just add users and you’re there!

Also, make training available to the masses
There are so many great ways to distribute training now that EPM publishers need to take advantage of. Online instructor led or Computer-based courses, Teach yourself books, mixes of online and text-books and so on. The costs of such training would need to drop dramatically and the training would have to be broken into bite-sized pieces so any sized organization could digest them.

Don’t forget to abandon acronyms
Any arcane science has its secret codes. In the project management world we talk about things like CPM, SPI, CPI, EV, BCWS and so on. Even in high-end project management circles, these acronyms and abbreviations are being abandoned in favor of straight descriptive language.

Finally, build the processes into the software

There is a process to being effective with managing projects but the 80/20 rule has always applied here. Twenty percent of the process delivers eighty percent of the value. A basic fundamental process, created, perhaps around the tenets of the PMI could be woven right into the software of most EPM systems so that organizations could adopt it or not as they saw fit.

If you think of the project management systems market as though it was a pyramid, with the most experienced users at the top and the neophytes at the bottom, then the use of project management so far has been focused at the very tip of the pyramid. I hear sometimes someone say that all kinds of complex algorithmic functionality should be added to project management software in order to do better analysis but it’s certain that there’s little return for such an investment. No, the big returns for systems publishers are to make project management systems and project management methodology accessible to the masses. It should be like acquiring any other commodity; a bar of soap or a tube of toothpaste. Project management software as a commodity would be used by millions, upon millions of users and that’s where the big payoffs come for software firms.

That makes commoditizing epm software inevitable.

I’d have missed it frankly because it’s not a massive announcement but I confess I was tickled pink to see HMS Software on page 26 of the July/August issue of Oracle Magazine announcing the naming of HMS Software as a Gold Partner in the Oracle Partner Network.  The magazine is also online and you can see our 15 minutes of fame in the July/August Oracle Partner News segment on the Oracle website.

Want to try Project Server2010 for free? The best way to do that is to get a free hosted trial.  Ah, but where would you find such a fabulous deal?  Right here, that’s where.  HMS Software, Microsoft and Project Hosts have teamed together so you can enjoy a free trial of Project Server 2010.  Just go to the HMS Free Project Server 2010 Trial site to take a look at the latest Project Server!

Everything old it seems is new again. One of the earliest programmatic approaches to project scheduling was invented in the heyday of the Cold War. Propelled by inter service rivalries on one side and by the threat of Soviets in the arms race on the other, PERT was born. The Program Evaluation & Review Technique looked beyond a simple Critical Path Methodology (CPM) analysis to introduce the notion of risk into the project schedule. The method was tremendously successful. It was used on the Polaris missile project in the late 50s and early 60s and was credited with enabling the first test launch only 18 months after the start of the project.

The PERT method asks the scheduler to provide three data points for each activity rather than one. Each activity has a best-guess duration but also an optimistic and pessimistic duration as well. The idea is to start by doing the schedule based on only the optimistic, then only the best guess and then finally only the pessimistic durations. As the project progresses and actuals replace the optimistic, best guess and pessimistic durations, the range of risk at project completion decreases.

Why should this matter? Well, if you’re looking at the schedule for any significant-sized project and the result of that schedule says something like “We’ll be done with this project in 2 years, 3 months 6 days and 4 hours, everyone knows that’s a lie. The more likely scenario is that you will be able to estimate within a couple of months yet that’s not how we talk about the schedule. It we had followed the PERT method, we’d have gotten the easiest schedule range from just adding up the optimistic, pessimistic and best guess durations to be able to add “Our most optimistic projection is 2 years and 12 days and our most pessimistic projection is 3 years, 6 months and 4 days”

A range like that may not be what management wants to hear. We know what the reaction from management is likely to be: “You will finish the schedule then based on the most optimistic projection!” But, if you introduce this kind of analysis into every schedule, then you reveal several things straight away. First of all, is the scheduler an optimist (like the one above) or a pessimist? This isn’t trivial. It’s a terribly important thing to know. Also important is the increased credibility of giving a range of dates. It says to the reader that you’ve considered things that could happen to this project (both good and bad) and have given your best possible answer.

For those who spend time in such an analysis, it is also interesting to keep track of the progression of the range. Think about it like this. The day before the last day of the project, the range of possible finish dates is probably very narrow. “We’ll finish tomorrow or maybe the next day,” you might say. On the first day of the project, you would expect the widest range because we have the most number of tasks, which still have optimistic and pessimistic numbers that we’re considering. It’s logical then to expect that the two endpoints (the optimistic and pessimistic) will migrate towards each other as the project progresses. That indicates a healthy advance.

If the endpoints start to move apart during the project, this indicates that we’ve introduced an element of risk into the project that wasn’t there when we started. The endpoints can only move apart when we either add tasks or re-assess the optimistic and pessimistic durations of the remaining work. That’s an easy-to-watch-for warning sign for management that should spark some kind of project review.

We seem to have come a long way since the Polaris missile project but, while PERT did find its fans, it never took off the way that we talk about CPM analysis. Only those esoteric schedulers in the Risk Analysis industry seemed to take any notice and they were working on other things. If you’re interested in schedule and budget risk then you’re probably talking more about statistics that come out of a Monte Carlo analysis, or something much more involved. (“What’s Monte Carlo analysis?” you ask. That’s a subject for another day but suffice to say that the result of such analyses are S-Curves, Bell Curves and probability statistics.)

We still see PERT analysis available in a wide range of project scheduling tools. Some vendors probably wonder why they’re still supporting something that hasn’t got a huge following.

PERT suffered in its popularity not because it was a bad technique (I think it’s a great technique) but because it takes more work. Remember, we’re talking about adding additional elements of data for every single task during the planning process. In some organizations it’s hard enough to get a single data point, never mind three. So given there was more work and no incentive for most project managers to implement the technique, it gradually fell from favour.

So? It’s ancient history right?

Wrong.

While enjoying a quick four-day visit to Sydney, Australia (I’m kidding of course, while I do love Australia, it’s impossible to fly the 26 hours there and the 26 hours back and enjoy only four days in between), I got to meet with and listen to some of the top project managers in the Defence Industry. I took great interest in the sessions on Risk Management, as it’s something I know something about and it’s not often talked about in those terms.

In Australia, defence projects (and other major capital projects) must comply with the AS4360 standard. This standard was first introduced down under in 1995 and thanks in part, I think, to a red-hot economy and a government committed to expanding its defence spending, the AS4360 standard took hold in a big way and has become a staple of large projects there. That might have been the end of this story except that the standard has done so well that there  has been a resurgence of interest in project risk management in the US for major capital projects. Those in the know say that the AS4360 promotes a “risk analysis lite” culture that is quite acceptable to the Defence, Aerospace and Energy projects that should be implementing such techniques.

In particular, one of the components of this newfound interest in risk management is the notion of three-point estimates for schedules, and that is PERT.

If you’ve never done PERT analysis before, it’s almost certainly available to you.  Try it with any copy of Microsoft Project up until version 2007. (The functionality is unfortunately no longer available in Project as of 2010)  Right click on your menu bar to reveal the PERT toolbar. It will show you how to enter your optimistic and pessimistic analyses and show you a view with the result of your three-point analysis. It’s a worthwhile exercise if you’ve not tried it before and, if you do, you’ll be ahead of the pack and have a taste of project management life from Down-Under.

G’day mate!

One of the first things I need to do whenever I go into a company to talk about Enterprise Project Management (EPM) is to get some kind of a consensus of what it means.

I can hear some of you laughing.

“Surely after all this time,” you’re saying, “we have a common understanding of such a basic term in the project management industry.”

No, I’m afraid not. It’s perhaps remarkable in an age when we talk often about Project Management Maturity Models but a common understanding of EPM is not only not that common but there is a huge range of possible interpretations.

EPM for some means everyone storing their data on projects into a common repository. For others, it means grouping projects together which share some common element, perhaps a resource pool or inter-project dependencies. For some, EPM means working on projects at a portfolio level. Still others might mean tracking actuals in a single timesheet. There are people who say that it’s not really enterprise project management unless you’re doing resource capacity planning and there are people who say it’s not “enterprise” unless it’s integrated directly to the Enterprise Resource Planning (ERP) system.

That’s already a lot of possible directions to go and yet there’s more. The sheer size of what someone might mean by “the enterprise” is also critical. In the last month, I’ve been in organizations which thought of an enterprise as being a division of 50 people, a complete company of 400 people, a division of more than 1000 people and a department of about 10 people.

So, all of that to say that there are a lot of definitions of what Enterprise is and what Project Management is and what Enterprise Project Management is.

So, let’s transpose our definition conundrum to selecting tools. There are many vendors in the project management industry who promote their “enterprise project management systems”. This can present a challenge to those trying to find a tool to help their project organization to become more effective.

Microsoft is an excellent case in point. With the release of Office 2007, we see of course, the release of the new version of Microsoft Project. There are now 6 products to purchase from the Project department of Microsoft. Project Standard, the trusty veteran has been with us now since the early 90s. Project Professional 2007 is the big brother of Standard designed to link to Project Server. Project Server of course is now in its third iteration and its associated Project Web Access. There is also Project Portfolio Server 2006 for Project Portfolio Management and the associated Project Portfolio Client Access License. I’ve seen organizations which use Project Standard as a solution for their enterprise requirements so, while it is designed as an individual efficiency tool, it’s certainly possible to work with it either alone or in concert with other tools to make an entire organization more effective. Project Server of course, is what we’ve heard most of from Microsoft in the last 4 years for organizational solution needs.

Yet, there are a couple of elements that Microsoft has also released recently that are fascinating possible solutions.

Inside of the new version of Microsoft Office SharePoint, a product which is provided at no additional cost as part of Windows, Microsoft has included “Lightweight Projects”. This template allows an organization to create simple GANTT charts complete with dependencies, resources, Critical Path analysis, and a bar chart view. The module was actually created by the Microsoft Project development team for the SharePoint group. Lightweight projects can be promoted to Project Server 2007 at any time should you need to put them into a more complete structure with more depth and options but for some groups, this will be an interesting feature to look into.

Of course there are already organizations which have used SharePoint’s other features to track project documents, issues, risks, to-do lists and more. For them, this may be enterprise project management. Here at HMS we’ve assisted organizations with creating enterprise management systems for tracking key project data using only SharePoint.

The most popular project management system in the world (yes, I’m talking about Excel) has also been enhanced with Office 2007. In particular a server component for Excel which is part of the Office System 2007 is something that project management Excel aficionados should look into. The server component allows the massive Excel farms that have been so problematic to support to become centralized enterprise-like components. Where once we would have thought of Excel only as an individual productivity tool, that thinking is due for some revision with this new version.

Microsoft also has tools for project management that are part of its Dynamics line if you think of project management as an accounting or cost-based conversation. And, if you’re in an IT environment doing development, then the new Visual Studio Team Services system is a centralized enterprise-level system which includes scheduling and resource allocation.

But, by far my favourite of the new products in the Microsoft camp is Groove. Groove was one of Microsoft’s acquisitions this year. Whether you’re talking about Groove Server or the Groove client, the Groove Project Space is a fascinating way to collaborate with a team. Documents, lists, assignments and more can be assembled in the Groove space which can interact with SharePoint, with the Groove Server or even peer to peer.

I’ve talked only about Microsoft so far but there are offerings from numerous other vendors for systems that are worth consideration including Primavera, eProject and others. So, which of these various tools are the best? Just as I’ve often said in these pages, there’s no way to answer the question. If you’re looking for a solution, you’ve got to first identify the problem. For any organization which identifies business challenges at the enterprise level that require an enterprise project management solution, the first step is to identify exactly what that business challenge is.

When we consult a client on EPM, we go through a simple yet powerful process with the management of the organization early on in the deployment. We start by having senior management identify key business decisions that they either can’t make now or can make only with great difficulty that they believe would be made easier through the deployment of an EPM system. The exercise is virtually always fascinating. Once we’ve identified as many possible such business challenges we trace what would be required to deliver information to management in order to make that business decision easier. Then we sort the requirements based on those which are possible to deliver based on data that is already available to us and those which will deliver the biggest impact on the organization.

There are a couple of instant benefits to this process. First participants in the meetings are almost always surprised to find out that the perspectives of others in the meeting don’t match their own. Just finding out that others in the organization are not looking at the same metrics or trying to manage the same business challenges is usually eye-opening for everyone in the process. Second, we are able to focus on what aspects of an EPM system should be deployed in order to deliver the fastest return on investment. I have never done this exercise where I have not been surprised by at least some aspect of what was revealed.

There is a plethora of enterprise project management tools on the market and if you’re thinking that implementing one of them will result in making your organization more effective, then start your search in house. Start with identifying what aspects of your business will benefit from what type of system and the selection of which category of EPM tool to search for will become infinitely easier.

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

In our last issue I talked about determining your requirements for a corporate project management system. This month we’ll talk about creating your plan for the deployment of your project management system.

What?! You don’t have a plan? Well, there’s good news and bad news. The good news is, you’re not alone, many project managers have attempted to deploy their project management system without a plan. The bad news? You’re not alone, many project managers attempt to deploy a project management system without a plan! I think it’s the ‘shoemaker whose children are barefoot’ syndrome. We tend to apply our skills last to our own projects.

The first step in making for a successful deployment of your project management system is in looking at the exercise as a project with everything that entails. Does this project have a sponsor? Who is the client? What is the schedule? What are the conditions for success? Here are a few elements you should be looking at when you are planning out the deployment of your new project management system:

Management Support
First of all, does this plan have management support. Problems with deploying project management software suffer most often from a lack of a product champion in the executive suite. Sometimes, decisions about implementing pm software come from management as a reaction to some problem (either real or perceived) about a particular project or projects in general. This might look like executive support but the support is very short term. Does management understand the scope and duration of the plan or are they hoping for an overnight fix? (You know what I mean – “As soon as that new software’s here, all our projects will be back on schedule”)

Look for management support that will last long term – It may be a year or two before the final effects of this implementation are felt. Is your project champion ready for the usual backlash that comes with a change in culture?

Also, what about funding. In this day of $300 project management software it’s easy to overlook the overall costs of implementing a change in a corporate system. Will you have the funding required for training? How about consultants to help tie your pm system to other legacy systems in the company? Has the I/T department set aside funds for technical support or people to help with the implementation?

Getting a product champion identified at the highest levels can be the most significant factor in overcoming the problem with all projects: Murphy’s Law.

Degree of deployment
While you’re assembling your plan, one of the most significant elements will be its scope. Implementation of a project management system if often thought of in one of only two camps: 1) Let every project manager do what they want or; 2) Choose a corporate-wide system and implement it everywhere. The problem of course with either plan is that few organizations benefit from them. The most common structure is one where some projects warrant a high-end project scheduling system, other projects warrant some kind of desktop planning system and yet other projects are so simple they warrant no project scheduling system at all. While you’re deciding who will and won’t be using your newfound package, think about what the payback will be for project managers at different levels. It is sometimes easier to leave small, low-risk projects out of the plan altogether. They’re numerous, they’re often very unique, very different from each other and the payback of having them in the central system is often very low.

Deciding on your level of penetration in the organization will be critical element of success. Pick your battles. If the small-project project managers want to do their own thing, it may be worth your while to get them off your list by letting them.

PM Process
Have you thought of where you’re going to gather the data for this new and improved software? Is the company ready to provide it or are you looking at cultural changes in the way they operate. One of our clients recently was working on implementing the corporate timekeeping system we publish. Management committed the company to move to a weekly time collection from the bi-monthly payroll-oriented collection they used to use in order to properly implement activity-based-costing. “No problem,” said management. Well, it has taken an enormous effort to get that message out to the rank and file who were so used to doing the work on the 1^st and the 15^th. Some resist doing the timesheet weekly despite the obvious advantages for the company. You need to look at what your new system requires and plan for it in advance.

Implementing a new package is also a perfect time for implementing process changes that may have been long-delayed. People will be changing anyway. You might as well take advantage to have them change to more productive ways of working.

Training
Can I say this enough: training, training, training. Not just in product functionality. Make sure you put aside enough funding and time to get people trained in the new way they’ll need to do business in order to support your new system. Make sure people know long in advance how much time will be required for users to come up to speed and make both an incentive to get trained and a penalty for avoiding it. It doesn’t matter if you spend $300, $30,000 or $3,000,000 on your new system; either get your people trained or plan to use the new CD for a coffee coaster.

Legacy Data
It’s a category that too many people forget. Unless you’re a start-up, you’ve got projects in progress. What will you do with all the legacy data from you existing system? That system may have been automated, may have been database-based, it may have been manual. You’ve still got to consider the value of the data in that system (or systems) and arrange the resources required to get it translated into the new system. Data conversions are often a tricky business. Get your new software supplier to check on the data and give a firm-price bid on converting it. You may need to pay them a day or two of investigative time but the back-end savings will make it well worth it.

Legacy Systems
Finally, don’t be too quick to throw those legacy systems in the trash bin. If you’ve got projects in progress, it may be less disruptive for everyone to let some projects wind down with the software that is being used on it. Make sure you’re going to give the project manager some benefit by switching his in-progress project data from one system to another before you mandate the change. If you’re keeping those legacy systems for awhile (and many do) then make sure there’s a firm plan to retire them once they’ve fulfilled their function and make allowances for moving their data and training the personnel working on them at a later date.

Conclusion
All in all, deploying a project management system can be an exciting time as the new features and functions start to impact the way you do business. It’s an opportunity for an organization to become much more effective but it’s also not risk-free. Make sure you take the time to plan before you leap.

In our next issue, I’ll be looking at how to weave your way through the myriad categories of project-oriented software in order to choose the one that’s right for you.