Category: EPM Software

Home Tools EPM Software

The Challenges of Selecting Enterprise Software

By: Chris Vandersluis
I originally wrote a version of this article for Microsoft’s TechNet site a number of years ago.  The business of purchasing Enterprise Software has unfortunately not changed much in the meantime so the lesson bears repeating in this updated version.

It happens around here all the time. A client sends a “Request for Proposal” (RFP) to the office with instructions to complete a response in a few days or week and send it back to have our enterprise system considered for purchase. RFP’s pretty much all look the same. There’s usually a brief overview, instructions on what you need to do to have your response be considered including how it needs to be formatted and when to send it back etc. Then there’s a long grid of features that are required and a number of additional essay questions to write answers to.

The challenge with RFPs is that they aren’t ideally suited for selecting enterprise software and process that ensues when an RFP process is followed doesn’t guarantee the best decisions for the organization. RFPs were designed by the purchasing community as a way to get the best commodity at the best price and they still do a great job of that. When the offerings are comparable then the decision making process can focus on the best price with only one or two additional variables (such as shipping dates) to contend with. When the possible solutions are in the same general category but not at all comparable (As is the case with Enterprise Software) then the number of variables that must be considered by purchasers is huge and the RFP process doesn’t add value to the selection.

How most companies select enterprise software

Let’s start by looking at the the most typical process that occurs on a regular basis with any software vendor or solutions provider of enterprise software. I’ll be talking about enterprise project management software or enterprise timesheet software as that’s what my firm provides but the paradigm is the same for virtually any enterprise system selection.

In most organizations, the impetus to look for enterprise software comes from some problem. Perhaps the problem is surfaced by the field personnel. Perhaps the problem is identified by someone in senior management. However it happens, the initiative has to get support from someone in senior management. The idea that grass roots selection of a system that will impact the entire enterprise is extremely rare even in the most progressive of organizations. So, most typically, a senior manager decides, “we need to purchase this kind of enterprise system to fix our problem.”

Typical Enterprise Software Selection Process

A project manager for the selection effort is volunteered. He or she does what we all do. They go to the Internet, load up a search engine and type in “EPM Software” (or whatever enterprise system they’re looking for). Immediately a half-million hits are returned. A diligent project manager might investigate the first dozen or so educating themselves on what kind of systems might be available before moving on. A less diligent researcher will look at the top one or two.  Clearly no one has the time to surf through a half-million or more hits to see if the very last one might be the ideal system for the organization so successful search engine optimization by vendors counts a lot in the selection process.

Undaunted, the project manager now assembles a selection committee from among those who will be affected by the implementation of this new enterprise system. Some of those on the committee may be from among field personnel who originally identified the need in the organization in the first place. Others may not. There may be a mix of people on this selection committee who have diverse interests and incentives in what kind of system will be selected.

The hapless project manager now solicits each member of the committee to poll their representative group for what they require in the new enterprise system. How does each committee representative do this? Well, first of all, not everyone puts in the same effort but for those who do their homework, they ask their staff to submit a list of features that they would find important. Then they too hit the Internet and surf some vendor websites. They can copy and paste from features they see in the brochures of these sites as each site gives them new ideas of what kinds of requests they might be able to make of a new system.

Now the committee is re-assembled and the long spreadsheets of each committee member is merged into one massive spreadsheet. The mega-spreadsheet of requirements is categorized but there are challenges. First of all the diverse needs of the committee now becomes more apparent as features are requested from the wide range of perspectives and desires. There may be committee members in different departments but also in different divisions or even different countries. There is almost always at least one request which is at conflict with another request in the same list (e.g. the system should be very easy and not have many prompts and the system should be very flexible with a large number of options for each user).

Finally the combined spreadsheet that the vendors will see is complete. It has hundreds of feature requests and for each one the vendor will be expected to say “Yes”, “No” or “Yes with some effort”. A imageweighting system may be also attached to say whether this feature is a “Must-have”, an “Important-to-have” or a “Nice-to-have”.

The RFP is almost ready to go. There will be a few essay questions usually about the technical architecture of the selection and, depending on how many people were polled about these requirements, the architecture requests can be equally conflicted. (e.g. The system must have all data stored centrally in the SQL database ­and­ the system must allow any data to be stored in a distributed fashion locally on the user’s computer).

Actually, it’s sounding pretty good so far, don’t you think? After all, we’re going to get back a bunch of vendor responses that show who can deliver all the features that we’ll need.

But there’s actually a fundamental problem with what I’ve described thus far. A problem that doesn’t occur when we’re using the RFP process for a commodity rather than an enterprise system.

The problem is this: An enterprise system is a solution to something. But we’ve said nothing so far about the problem. Having now said it out loud, it might seem obvious yet it is almost universally common in RFPs to not explain the original problem that started the initiative in the first place.  This is such a common occurrence that the technology industry has come to accept it as normal and acceptable.

Why selecting enterprise software that way doesn’t work

Purchasers have been using this method for decades and no one questions it, but people in the enterprise software business know there is a fundamental problem with the classic RFP method of selecting enterprise software.

First of all, just because you have an enormously long list of features, it does not necessarily mean that you are any closer to solving a business problem. In fact, if you haven’t even articulated what specific business problems you are trying to solve then you are likely to make things more complex and ultimately worse, not better. The RFP process was designed to purchase commodities. When we’ve got homogeneous products like shoes or potatoes or sugar, then purchasing these items in this way can result in the lowest cost bidder and the best selection from among the possible suppliers. The responses to an RFP for a similar commodity makes comparing possible suppliers very easy. When the variables for each product in the mix are infinite (as they are with enterprise software) then the responses to the RFP have an infinite number of variables also and the process yields results that have little value.

When we use the RFP method of selecting enterprise systems, the RFPs mostly all look the same. This is because they are all created in response to the same stimulus. The project manager requests a list of ‘what you will need in this enterprise system’ and the only vocabulary most middle managers have to respond to that request is a list of features. Consequently, the responses to RFPs all look the same. They’re a checklist of all the features available either as part of the system or as part of the system with some effort.

What is most common for selection teams is that they will receive a number of responses to their RFPs, they’ll wade through the hundreds of pages and, when they’re finished, they won’t feel any closer to a solution than when they started. This is terribly frustrating for purchasers who put in enormous effort in creating what should be a fair request for proposal and in evaluating the answers only to find that the exercise was for naught.

Worse than all of this is that experienced enterprise salespeople know the process will yield frustrating results and are at work from the moment they hear there will be an RFP created. They’re not working on the RFP response. That’s not relevant. Instead, they are working two or three levels higher in the management structure, looking for the original impetus that got the RFP started. They look for the senior executive who articulated some business challenge and set the wheels in motion so that purchasers and other middle-management staff would ultimately create the RFP and send it out to vendors.

When the RFP responses end up without a clear answer to the business problems that are almost never articulated within such a purchasing process, the enterprise salesperson is ready to leap into action, and will attempt to have a senior executive bypass the process altogether and select a system based on their own personal relationship with the senior enterprise salesperson rather than the score on the spreadsheet.

If you think this sounds jaded, you’re wrong. In fact, it is extremely common.

But what about a Proof of Concept or Pilot?

So, we know the classic purchasing process is flawed when we apply it to the purchase of enterprise software. If that’s the case, how should we choose enterprise software such as an enterprise project management system? A popular method is to use the Proof of Concept or Pilot Phase method.

These two terms are often used synonymously so let’s start off by talking about what is a Proof of Concept or a Pilot deployment.

Proof of Concept

In a Proof of Concept the prospective organization deploys the enterprise software in a limited fashion in order to prove that it can accomplish a technical challenge where there is some question as to the solution’s ability to overcome that challenge. An example might be for data volume. “We’re concerned that the product might not be able to handle as many tasks as we have per project. We’d like you to come with the software, take 2 or 3 example projects with 500 tasks each and show us how these can be loaded into to the software and that the software can still perform its basic functions with this volume in it.”

Pilot Phase

A Pilot Phase is an installation of the enterprise software but with a limited scope. A pilot deployment might be for a subset of users; for example only 10 out of 1000 people will use the software fully for a 4 week period. Or, it might be for a subsection of the functionality or a subset of the volume of data; for example only 10 out of 500 projects will be loaded.

How is the Proof of Concept or Pilot Phase used?

The problem that is often encountered is how the Pilot Phase or Proof of Concept is applied. It is quite rare when a prospective organization calls and asks us for a Proof of Concept proposal that they can identify what technical concept needs to be proven. “What technical concept are you hoping to prove and how will we be able to measure that we’ve proven it?” we ask.

What is more common is that someone in middle management has identified a piece of enterprise software that they hope will make their lives easier in their organization.  Senior management is not at all involved and, the middle management staff imagehave not even articulated what business challenges they are trying to overcome. It is their hope that if the solution was just in the building, that the next time someone from management would wander down the corridor, they would see the solution in operation and would instantly give their blessing to an enterprise deployment. To coin a term from the movie Field of Dreams, ”If we build it, they will come.”

Getting management support for a solution in this manner is rarely successful. The problem with enterprise software is that we need senior management’s involvement to make the deployment a success. It is senior management who will be the ‘clients’ of the reports and analysis from this enterprise system. It is senior management who will need to invest personally to allow a range of staff the time required to design, configure and be trained in the enterprise software. It is senior management who will have to accept or even help redesign the business processes that are part of any enterprise system deployment. Without senior management giving not just their blessing but also their implicit support and direct assistance, no proof of concept will help.

This is true also for a pilot phase. If the company has not committed from the highest level to solving some business problem through the use of enterprise software, imagethen the introduction of a pilot phase is not productive.

This is not to say that pilot phases of a deployment have no place. They do carry a critical spot in a successful deployment. That place is immediately after the purchase decision is complete and the design of the enterprise system has been concluded. Now a pilot phase makes a great place to test out our enterprise system design and fine tune it for general deployment.

It is only when a pilot phase is done in the hope that seeing the software in action will result in management selecting it,that we create an ineffective Pilot and get no further ahead in the selection process.

How should organizations select enterprise software?

Enterprise systems are purchased by middle to large sized organizations every day and, while the RFP method may not be the most effective, there are several methods of selecting enterprise software such as Enterprise Project Management or Timesheet software that is very effective. Here are a few tips for creating your own effective enterprise selection process.

1: Articulate the Problem

First and foremost, articulate the problem. This means that senior management must be involved and the problem to articulate is a business problem so it should be articulated in business terms. One good question to ask is, “What business decision can we not make now or can we make only with great difficulty, the making of which could be eased with the deployment of this enterprise system solution?”

There may be a series of business challenges that you wish to solve with the use of this enterprise system.

2: Give Vendors some latitude to create the solution

Once the business problem or problems have been articulated, contact possible vendors in and make sure the access to the senior management who assisted in the process thus are is transparent. “Secret” vendor meetings with senior management become impossible when management is part of the process from the beginning. Let the vendors understand the problem and give them some latitude in answering it. You may find out more about your organization in explaining how these business challenges affect you than you realize and you will certainly see a much wider range of possible solutions to your problem when you don’t try to describe the solution to the potential vendors.

When you talk to possible solution providers, make sure they understand that they must speak to both the technology and the business process challenge. There has never been enterprise system solution that didn’t have some impact on the organization’s process. If the solution provider can’t help with how the process will be impacted, then you’re only looking at part of the solution.

3: Go meet some people

When you get down to a couple of possible solution providers, ask to talk to some of their existing clients. Even better, see if the vendor will let you go visit some of their existing clients. Good solution providers often have clients who have had success in their own deployments and who are generous enough to make time to meet prospective clients.

You’ll learn more from a couple of hours with an experienced client of the possible solution than you would have ever learned from reading RFP responses or looking at vendor sales demonstrations. When you ask the vendor for possible client references and site visits, you might think the ideal company to meet would be one exactly like yours. That’s not always the case. It’s often extremely valuable to meet companies in other industries that are related or somewhat similar to yours. You might also learn lots from organizations who are bigger or smaller than you are. Place more emphasis on how much experience the site visit organization has had with the solution rather than what version they’re using or whether they’re of the exact size or in the exact industry you’re in.

If you are lucky enough to visit an existing client, remember that they’re not the vendor. Be respectful and courteous and thankful. Bringing a small gift, perhaps of company logo promotional material is often well appreciated. While you’re with the organization or while talking to references on the phone, some possible questions might include:

  1. What process did you use to select this solution over others?
  2. What impact has this solution had on your business processes?
  3. What was the most challenging aspect of the deployment?
  4. What was the most valuable return on investment thus far?
  5. How do you see the solution evolving from here?

Don’t expect only happy answers.

A vendor who is completely unable to provide references has to be somewhat more suspect than one who has a number of satisfied clients.

Finally, when you’ve made your selection, deploy in phases. You can find other articles in the blog on how to deploy in a phased vs. big-bang mode. This will mitigate the risks involved in any enterprise system deployment and help fine tune the deployment process as the system evolves.

Remember that any enterprise system deployment is a dynamic process. It’s not a one-time decision with happy results arriving month after month forevermore. The most successful enterprise deployments start from a selection that involves the key personnel who will be a part of the deployment process from the most senior in management to the most tactical in the field and continues through the evolution of the system in phase after phase.

An effective enterprise system selection is only the first phase of the process.

The nature of training on enterprise systems

“How long will it take us to get completely trained?” I was asked recently.

“That would depend completely on your definition of ‘completely’,” I replied.

The challenge with enterprise products like TimeControl is that they can be configured to be so many different things for so many different people.  The strength of TimeControl is its flexibility.  This allows TimeControl to be a multi-purpose timesheet serving the needs of many different perspectives within the organization.  It can be used for time and attendance, time and billing, project management tracking, earned value, government compliance for R&D tax credits or the DCAA.  And all this from the same interface at the same time.

Yet not every organization is created the same.  Not every organization requires the same types of functions or tracking.  Even when two clients have a similar product to like to like SAP or MS Project, those products are not configured identically either.  So each implementation of TimeControl is often unique. Oh there are common elements but there are many elements that are different and not everyone even uses the same functionality.

What we’ve discovered here at HMS when we apply this challenge to training is that training is best done in layers.  The first layer or phase occurs during the original implementation.  If our technical staff assist with the implementation, we train the administration staff as we make decisions together on how to configure the system.  This has a high degree of success but does it mean that these administrators are “completely” trained?

If your definition is, “The administrators should be able to operate TimeControl in accordance with the configuration and existing processes we have defined at the time of implementation.” then the answer is Yes.

But, let the company advance for 6 months or a year even and we find that the level of maturity in the use of TimeControl in the organization is now such that the types of questions the client would ask have evolved.  Now there are questions on functionality that would have never been asked during the original implementation because the questions are now able to be understood or because the organization itself has evolved to have new timesheet requirements.

This isn’t unique to TimeControl.  We’ve seen similar phenomena when we look at project scheduling tools like Primavera, Open Plan or Microsoft Project Server.

Our view is that training should be an ongoing investment.  Do a little less on the first day than you’d expected.  Let that training soak in; be absorbed; be implemented in practice.  Then having a trainer come back or do another remote session for a few hours.  Use that to advance your own knowledge but also to advance the capabilities used of the software.  As new administrators come on board over time, they’ll naturally just take up training that is regularly scheduled.

Doing training in phases or layers ultimately gives the best return on investment.

New article of mine on the front cover of Microsoft’s TechNet

TechnetMicrosoft has published another article on its TechNet site.  This looks at a popular topic in project management circles these days, dashboards.

With the new capabilities of EPM tools like Microsoft’s Project Server or the Oracle BI tools now linked to Primavera, there is a hunger for pretty dashboards that show arrows going up, circles going down and triangles pointing in every direction.  This article talks about what you need to know in creating project management dashboards, some pitfalls that are often overlooked when people create these displays and some of the core principles you’ll need to adopt to make dashboards a useful experience.

Now it’s flattering enough to be on the Project Server 2010 page

You can find the article on the Project Server 2010 page of TechNet but this article was deemed interesting enough that TechNet is highlighting it on the front page of TechNet at That’s quite remarkably flattering and kinda cool to think that the millions of people who go to TechNet every day will see it.

Microsoft’s 2012 Project Conference registration is now open

msproject_conferenceMicrosoft doesn’t do it every year but next year they will once again be holding a conference for Microsoft Project.  This usually signals that Microsoft has a new version to show us and, yes, it’s fairly certain we’ll be hearing all about Project version 15 when the conference rolls around.

The conference is March 19-22, 2012 in Phoenix.

For registration information go to:

Oh, and will I be there?  You bet.

Project Management Insights interviews Chris Vandersluis

PMInsightsIt’s always interesting to talk to others in the project management space.  An article I did for Project Times called the Real Time Project Management Myth prompted a call from the Project Management Insights Blog Lewis Lin over there had some questions for me about Real Time Project Management and.  You can read the interview on Project Management Insights Blog at:6 Questions with Chris Vandersluis, Founder of HMS Software. If you’re not keen to hear more about me, there are lots of other interesting interviews there also!




Service Pack 1 (SP1) for Microsoft Project and Project Server 2010

ANNOUNCING: Announcing The Release Of Service Pack 1 (SP1) for Microsoft Project and Project Server 2010

Microsoft has announced the release of Service Pack 1 for Microsoft Project and Project Server.

You can find details on the enhancement for this service pack at: Announcing Service Pack 1 for Microsoft Project & Project Server 2010.

Microsoft recommends that you read the guidance below and the information on the service pack prior to installing:

Microsoft is also strongly recommending deploying the June 2011 Cumulative update for Project and Project Server when you install the SP1 update.

For more information go to the official Microsoft announcement at:

Enterprise system best practices article

My latest article on best practices for enterprise systems has just been published on Microsoft’s TechNetYou’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.

Doing two things at once can be too much

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

And so it begins.

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

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

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

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

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

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

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

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

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


Project 2007 and 2010 April 2011 Cumulative Update

Microsoft has released the Project 2007 and 2010 Cumulative Updates (CU) dated April

Project and Project Server 2010

This include a number of fixes, so Microsoft strongly recommends that you test this in a test environment based on your production environment before putting this fix live in production.

Server Rollup Package(Recommended):

Description of the SharePoint Server 2010 and Project Server 2010 Cumulative Update Server Hotfix Package (MOSS server-package, Project server-package): April 26, 2011

Individual Project Server Package:

Only required if you do not install the Server Rollup.

Description of the Project Server 2010 hotfix package (pjsrvwfe-x-none.msp): April 26, 2011

Project Client Package:

Description of the Office Project 2010 hotfix package (project-x-none.msp): April 26, 2011

More information on deploying the Cumulative Update:

The article below provides information on how to deploy the Project Server Cumulative Update.

Updates for Project Server 2010

As Project Server 2010 is now based on SharePoint Server 2010 Microsoft strongly recommends that you install the Project Server 2010 Server Rollup Package as there are a large number of individual server packages for SharePoint Server. The Project Server 2010 Server Rollup Package contains all the patches released in this Cumulative Update for SharePoint Foundation Server 2010, SharePoint Server 2010 and Project Server 2010.

For those accustomed to Project Server 2007 Cumulative Updates, you should note that the MOSS Server Rollup Package does not contain the Project Server patches. You will need to make sure that you install the MOSS + Project Server Rollup Package (the link is provided below). As in Project Server 2007, the Server Rollup Packages are much larger but they will greatly simplify your Project Server patch deployment.

Client Installation:

Installation of the client patch is straightforward and is the same as it was in Project 2007. The instructions for installing the client patch are below.

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

  1. Download the hotfix from the link in the KB Article.
  2. Extract the patch package by running the .exe file that you downloaded.
  3. Run the extracted .exe file to apply the patch to your Project Professional/Standard client.

Project and Project Server 2007

This include a number of fixes, so Microsoft strongly recommends that you test this in a test environment based on your production environment before putting this fix live in production.

The article below provides information on how to deploy the Project Server Cumulative Update.

You can read about the fixes included in the April CU from the following articles:

Server Rollup Packages:

Description of the Windows SharePoint Services 3.0 Cumulative Update Server Hotfix Package (WSS server-package): April 26, 2011

Description of the Office SharePoint Server 2007 Cumulative Update server hotfix package (MOSS server-package): April 26, 2011

Individual Product Packages:

Description of the SharePoint Server 2007 hotfix package (sts-x-none.msp): April 26, 2011

Description of the Project Server 2007 hotfix package (pjsrvapp-x-none.msp, pjsrvwfe-x-none.msp):April 26, 2011

Description of the Office Project 2007 hotfix package (project-x-none.msp):April 26, 2011

More information on deploying the Cumulative Update:

The article below provides information on how to deploy the Project Server Cumulative Update.

Deploy cumulative updates (Project Server 2007)

Service Pack 2 for both WSS and Office Servers 2007 are required for this Cumulative Update. The KB articles below provide information on how to download and install SP2 if you have not already done so.

Description of Windows SharePoint Services 3.0 SP2 and of Windows SharePoint Services 3.0 Language Pack SP2

Description of 2007 Microsoft Office servers Service Pack 2 and of 2007 Microsoft Office servers Language Pack Service Pack 2

The Server CU is released in two different versions. The first version is in Individual Packages 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.

The second version is the Server 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 but they will greatly simplify MOSS patch deployment.

Client Installation:

In order to install this hotfix, you will need to have Microsoft Project 2007 SP2 installed on the client.

Description of Office Project 2007 Service Pack 2 (SP2) and of Office Project Language Pack 2007 Service Pack 2 (SP2):

Once we know that SP2 is installed, you will install the hotfix by performing the following steps:

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

  1. Download the hotfix from either the KB Article or by using the information at the end of this email.
  2. Extract the patch package by running the .exe file that you downloaded.
  3. Run the extracted .exe file to apply the patch to your Project Professional/Standard SP1 client.