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.

So, it’s time to bring it all together. You’ve used your talents thus far to choose the perfect project management software system; to implement it perfectly within your organization and to train your personnel within an inch of their lives. Now, it’s time to fulfill on some of those promises you made to management when they approved the budget in the first place and to integrate the project management system with other systems in the organization.

Here’s the first thing to know. Sometimes, it’s better to look integrated than to be integrated. Ok, that’s a little trite but it’s true. Over the years, I’ve met a remarkable number of otherwise clever people who use Ostrich management practices when thinking about integration. There are a couple of things to remember when talking about integration that can make or break your entire project management software implementation project.

First of all, regardless of what I say in the next few paragraphs, you’ve got to apply a reality check to every aspect of integrating multiple systems together. It is an easy thing to get caught up in the intricacies of a particular link between systems; to become enamored with how elegant the integration between two particular systems will be accomplished. However, if you don’t stop every once in awhile and ask yourself exactly how much effort this link will be saving.

Not long ago, I was consulting a firm who was designing an integration between a project scheduling system and the project invoicing elements of a central ERP accounting system. The person in charge was asked to describe to me how the link would be accomplished. For the next 30 minutes, in an inspired soliloquy, this person went on to enroll me in how completely; how elegantly and in what complex form the programmers would be able to create this automated link. It would take only 6 weeks of effort for a 4 man team to deliver this work of art I was informed.

That’s sounded great to me. After all, the presentation came with slides, flowcharts, ERWIN diagrams and a complete narrative. Clearly, this person had put their heart and soul into this particular aspect of the project. It was the cornerstone of his project management software implementation. I had only one question: How many transactions would his link process each month? That is, how many invoice items were there that had to be transferred from the project management system to the invoicing system? There was a long pause. An average of 12 was the final answer. And how long would this take to transfer manually? About 30 minutes each month, I was told. The 4 person/6 week effort would take over 36 years to pay dividends. I didn’t make this particular person very happy but clearly this particular bit of integration made no sense. This is, unfortunately, not an isolated incident. When you get so caught up in the details of a link between systems, it is easy to lose sight of the overall picture.

Here are a couple of basic elements to consider before embarking on the integration of your pm system with the rest of your organization’s automated infrastructure:

First, make a careful determination of what needs to be integrated. This may take some effort. First of all, you’ll need to determine what people want to be integrated. You’ll have to use your discretion here. Some people will be responsible for a particular system and have some notion that you will be integrating it poste haste. Their ideas of what will make the organization more effective or not may not be based on complete knowledge of what your project management system can do or has been configured to do. Just because someone (often very senior) wants two systems integrated doesn’t mean they can be, should be or need to be in order to make the organization more effective.

Next you’ll need to find out what perhaps should be integrated but that for some reason or another people are reluctant to have integrated. This may not be obvious. For a variety of reasons, there may be people who are responsible for a particular system who feel threatened by the integration of your system with theirs and who will therefore not offer up their system to be integrated. Some finance people for example, will feel that the movement of data into the finance systems from any external system risks compromising their system’s data regardless of the degree of integration. Yet, despite their reluctance, the linking of the project management system with theirs may offer huge potential benefits to the organization so you’ll need to seek such systems out.

Last, you’ll need to determine from the complete list of what can be integrated what should be integrated. Remember to apply a reality check on a regular basis to determine this list. You should constantly be asking yourself, “What is the return on investment of this particular link?” That is, “What is the estimated cost of this link in man hours or dollars and what is the estimated savings in time from doing the work manually?”

Once you’ve chosen the systems to integrate, you’ll probably want to start designing the links right away. This can sometimes be done with just the IT department but be careful. If you do not involve the people responsible for each of the systems affected during the very beginning of the design process you are risking a tremendous backlash.

People who are responsible for particular systems in an organization often treat them like they are their own children. Integrating in even the most non-intrusive, date-out-only fashion can make the feel violated. You must involve these people from the very beginning. Seek them out, ask their opinion about the integration. Find out what would make their lives easier and involve them in the design process. In far too many implementations, I have seen this not done only to find a link that is technically sound but practically unimplementable because no one has checked that organization’s process can support the link in the first place.

Remember, each link you are designing has the potential to invalidate the use of another. It may be possible, for example, to load budget dates from an accounting system or the shop floor manufacturing system. Yet, if you do both, how will you determine what is the source of these dates? You’ve got to look at the overall picture. Use flowcharting to follow data through the process you’ve implemented with your project management system to ensure that multiple elements of your integration plan don’t conflict with each other.

Also, before you start creating your first link between your pm system and the rest of the company, you have got to determine who will be responsible for it after it’s created. Beware. The operational responsibility of such a link may be very contentious. It may be perceived as something that gives someone power over another system. It may be perceived as very desirable or very undesirable and either can cause you problems. If you have involved the people responsible for each of the systems from the beginning, this question can be resolved with a minimum of fuss during the design process. If you haven’t you’re much more likely to end up with an emotional hot potato on your hands. So, make sure you design not only the technical elements of your link but the entire life cycle including maintenance, future growth potential, responsibility for usage of and control over the movement of this data.

Finally, don’t forget to apply simple rules of Return on Investment (ROI). It is the one sensibility check that will stand you in good stead as you create your design plan. The simple formula is to determine how much effort it will take to design, create, operate and maintain the particular link you are making and to subtract the cost of moving the data manually or using any existing structure. Working in person-hours is the most obvious measure but use any denomination for the analysis that works. Remember, sometimes it’s better to look integrated than be integrated.

Heather O’Cull from the Microsoft Project Development team has a great blog post explaining how Project deals with the rate to consume a resource on a task through the Assignment Units field.  You’ll see there’s some debate from commenters on whether the change in this functionality is the right move but whether you agree or not, this is a key element of Project’s Calculation engine that it’s important to know about just so you know how it works behind the scenes.  For those who do resource calculations in Microsoft Project, I encourage you to take a look.   You can find the post at the Project Dev Team Blog.

Well, we told you it was coming and now the release of Microsoft Project and Project Server is just about upon us. On May 1st, Microsoft’s Enterprise clients and its partners will be able to access the official release of Microsoft Project 2010 and Microsoft Project Server 2010. While the official name of the products has dropped the word “Office” (It was quite a mouthful), both products continue to be part of the Microsoft Office family of products and will be released at the same time.

That’s not an accident.

Microsoft has made it quite clear that its strategy is to leverage client’s interest in one product line by tying it to another. The Office group has done this very successfully. You don’t think anymore of just buying Word or just buying Excel. No, you buy one of the bundles of Office and those products are contained within it.

Project and Project Server will continue to have their own licneces and aren’t available as part of any of the Office bubdles for now but there a bunch of other things that have changed.

Say bye-bye to Office Project Portfolio Server
One big change is how Microsoft has rolled some of the most popular Portfolio Selection functionality from Portfolio Server 2007 into Project Server 2010. There will not be a Portfolio Server 2010 product and, while existing users of Portfolio Server 2007 will see updates of that stand-alone product for some time, any new development on Portfolio management will focus on Project Server.

Did you say 32bit? Bite your tongue!
It’s all 64 all the time for server installations now. Installing Project Server will no longer be possible on a 32bit version of Windows Server. The new 64bit architecture makes a lot more memory available to Project Server but may cause some companies to take pause as the consider the costs of hardware.

Project Standard and Project Professional will still work on both 64bit and 32 bit versions of Windows Vista and Windows7.

Gotta love SharePoint
Previous versions of Project Server could be installed with either the free Windows SharePoint Services (WSS) of the licensed Microsoft Office SharePoint Server (MOSS). (Don’t you love how many acronyms we use in this industry?) Project Server will require users to have a MOSS license. The system will now longer support just the free WSS. This may be a license cost issue for some users.

So that’s the bad news. What’s the good news?
There’s good news in this release in a couple of areas. First of all, the underlying architecture of Project Server and Project Desktop hasn’t changed since 2007 and that will almost certainly mean the stability of the product at release time will be better than 2007 was.

Rather than rewriting the system’s architecture, there are new features that should be popular including Project Data Pages that allow Project data questionaires to be gathered online and then woven into a workflow, some improvements in the timesheet that will be great for those tring to do a full timesheet week and then update the project progress, some easier dashboarding tools that should allow people with intermediate skills to create great graphical representations of their data and, of course, the aforementioned Portfolio Selection functionality.

On the Desktop look for a distinction between Project Standard and Project Professional that will no doubt result in some kind of push to have people upgrade to the more powerful version.

Project Professional will have a new Timeline View and a new Team Management view which I think will go over well.
The scheduling tool will not default to automatic scheduling and you’ll be able to enter a description rather than a duration iin the duraton column as a sort of placeholder for the data to be entered later. Purists may howl at this. It’s another sign of how Microsoft Project has become so ubiquitous and how the product must now cater much more to non professional project managers.

Expect the Microsoft marketing beast to crank up to a fever pitch in the coming weeks. It’s already been moving forward at a pedestrian speed for months but as the product hits the market, Microsoft will do what it does best as it announces everything new in the Office 2010 family of products.

Over 90% of our new clients already own project control software. It’s a tough statistic to come to terms with generally and it implies a particular environment in which, in our firm, we live most of the time. If you’ve been involved with the implementation of project control systems in the past, you know that it is often the case that you are replacing a system rather than installing and implementing into an unsullied environment. The nature of the project management software industry is that it changes quickly and, unlike many systems, there is often huge returns on investment for getting the latest, fastest algorithm to calculate critically required project resources.

Dealing with the culture shock of a new system is bad enough but, as is the case with project control systems, that environment is “mission-critical” to the organization, the pressures of the entrenched culture can be fatal to the implementation.

Culture shock is inevitable in any major change of a system. It refers to the general upset that occurs when familiar systems are replaced with unfamiliar ones. Generally these systems are the oldest, most entrenched systems in the organization. Often, paradoxically, these systems are not even well liked and are complained about by the very people who will be most upset at them being removed. It is a testament to how much we crave the familiar to see what we will put up with rather than change. However, the phenomena can be a huge upset to personnel who are attempting to update systems and to make the organization more effective. If a successful implementation is essential to the success of the organization or the project, then this situation must be allowed for and dealt with.

Actions by those experiencing culture shock can be varied. Some users, faced with a new system will resist actively, stating their objections and demanding satisfaction. These are the easiest to deal with as the dialog to resolve their concerns has already been started by them. Other users will simply not use the new system, sticking with the old system if it is still available or not using anything at all and not speaking out about it. Perhaps the difficult type of reaction are the “covert resisters”. These people will pay lip service to the success of the implementation, declaring themselves to support it yet, their every action will do the opposite. In particular, the longest standing staff members are most susceptible to this shock reaction and are most likely to have close contacts in upper management where a few well-placed words can wreak havoc on the implementation plan.

The effects of this culture shock can be significant. Users of the new system may experience a long period of confusion with the new system, insisting in vain that it work like the “old system” even if the old system was flawed and inaccurate. This confusion can rapidly lead to general ineffectiveness across the organization.

Recently we were involved in an organization-wide implementation of a new project control system on a significant project. As anyone who is working on large projects knows, the pressure on the project team, indeed on the whole organization is intense. In this case, the project management group had determined that the cost of staying with an outdated project control system outweighed the disruption of replacing a system which was used across the enterprise.

With time being of the essence, training, consulting, data-conversion and system configuration were all on the “fast-track” with many tasks working in parallel to get them up to speed in the minimum time possible. However, with the core project management team focused and working overtime to get the system up and ready, they were less available for the human element, spending time with the remote office users or working on focus groups and sitting in on training sessions. The result? Not surprisingly, the initial “go-live” week wasn’t as successful as we’d hoped. The system was rolled out, worked with little technical difficulties for about four days. However, the reaction from almost every corner is that the system “doesn’t work the same way as the old system”. So may users reported that they couldn’t deliver key project data in a timely fashion that after the first four days, the project management team relented and instructed users to return temporarily to the old familiar system for several days while these “issues” were resolved. An intense retraining and internal marketing campaign restating the returns that the end user could expect along with some key support from upper management at just the right time made a second run at the implementation much more successful about 2 weeks later.

This implementation was successful but over the years, I’ve seen many that are not. The culture shock reaction from the end users is so unexpected and, so intense, that the implementation dies on the starting blocks and never recovers.

So what should you do to avoid this scenario in your own implementations?

First of all, expect it to happen. The most vulnerable implementations are those where the implementors naively assume that the new system will be welcomed with open arms by all involved.

One of the most significant elements that should be part of any enterprise-wide implementation is upper management support. Find a champion for the implementation who won’t shy away at the first grumblings and make sure that someone has enough authority in the organization to make sure the implementation will not be abandoned. Also, (do I need to say this?) make sure that person is apprised of the potential for culture shock and prepares for it.

Next, plan on a significant effort communicating with and informing as widespread a range of users as possible. Run focus groups, or information seminars, or just get a newsletter going. Make sure there is some mechanism for feedback by the end users. Nothing ticks people off more than not being able to be heard.

Three words: Training, Training and Training. Can I say this enough? Spend more time training than you’ve already planned. Planned a lot of training? Put some more into the plan. Even if the training sessions become more of a user-group meeting or bull-session, all the better. The more users are able to get out of the new system, the more likely they’ll be to support it.

If it’s possible, a phased approach will often help in this kind of implementation. Start with the group most likely to succeed, not the group making the loudest noise about what’s not working.

Finally, keep selling this solution. Many groups will do a selling job for the new system one time early on in the plan then not return to it again until the software is actually installed. You’ve got to keep selling the new solution until it becomes the new culture.

It’s called “The Stack” over at Microsoft.  It refers to the layers of technology that are required to get the Microsoft EPM functional.  For those who only have experience with Project Desktop this will sound unfamiliar.  After all, what’s to know?  You put the DVD in the box, you hear a whirring sound.  When it’s over the DVD pops out and you start entering tasks in Project. 

 If only Project Server were that simple. 

Microsoft made the decision years ago to leverage the  different technologies that Microsoft produces for its server products.  When we’re asked to deploy the Microsoft EPM “Solution” for Project 2007, here are the Microsoft Products we need to think about:

Windows Server
Internet Information Services (IIS)
Active Directory
SQL Server
SQL OLAP Services
SQL Reporting Services
Microsoft Office
SharePoint Services (WSS) or Microsoft Office SharePoint Server (MOSS)
Project Professional
Project Server
Project Web Access (PWA CALs)
Portfolio Server
Portfolio CALs

That’s pretty much been the list since Project Server was first introduced and later when Portfolio Server was introduced.  With Project 2010, we know the list will change a little:

Windows Server
Internet Information Services (IIS)
Active Directory
Exchange Server
SQL Server
SQL OLAP Services
SQL Reporting Services
Microsoft Office
Microsoft Office SharePoint Server (MOSS) 2010 is now required
Project Professional
Project Server
Project Web Access (PWA CALs)

At first glance the list doesn’t seem that different.  The Portfolio Server license is now woven into Project Server and a new option for Exchange Server is added.  But, let’s take a peek below the hood.

In Project 2010 you will need MOSS.  The Project team is leveraging technology available only in MOSS so it’s not an option and the option to use Windows SharePoint Services is discontinued.  Ok, that may have an impact on your licenses or perhaps not but lets think about the impllications.

SharePoint is the fastest growing server product in Microsoft’s history.  A large number of organizations have adopted the platform in its 2007 incarnation.  Let’s imagine that you’ve *just* finished deploying SharePoint 2007 and now Microsoft comes along to explain how great Project Server 2010 will be.  But, in order to take advantage of Project Server 2010, you had to adopt “the Stack”.  That means you’ll need to upgrade your SharePoint from 2007 to 2010.  That may be quite a challenge.  You might have extensive customizaiton in SharePoint 2007 that would have to be migrated.  You might have applications that only work with SharePoint 2007 and not yet with SharePoint 2010 or that might have to be upgraded themselves to work with the new SharePoint. 

Only a version ago, Project Server was viewed as the vanguard; the product that would “pull-through” technologies like SharePoint into the organization.  Now, however, that same link may have organizations think twice about going to the new technology because of the platform they’ve adopted.

Interestlingly I had a conversation about this just last week with my friends at Occam who have been doing Project Server hosting for years.   Hosting the new technology might be an attractive solution for many project offices who are keen for the new technology.  It has been attractive for a minority of users thus far, but if going to a hosted model eliminates the challenge of confronting “the Stack” then it may well be attractive when Project Server 2010 hits the streets next year.

It’s happened three separate times this month. In hindsight it’s obvious but it amazes me that large organizations whose staff should really know better continue to bite off larger enterprise-wide implementations than they’re capable of delivering. The problem is, to be sure, insidious. After all with “enterprise-ready” software hype available in every publication, you might be lulled into thinking that just choosing the right software means that everyone in your organization will instantly become an integrated machine with all parts harmoniously moving in the same direction. The problem is, implementing enterprise-wide software of any category is much, much more than the purchase of the package itself.

I’m sure no implementation starts out this way but, for the three companies who I spoke to about it this month, they certainly ended there. I’ll not name these firms but, you’d recognize each of them instantly. One, an insurance company, the second a financial organization and the third a telecommunications company. In each, the issues were similar yet distinct. Each of these firms has an interest in making themselves more efficient by implementing project-oriented software. Sounds simple enough but even in this sentence the mischief starts. “Has an interest”. Well, firms don’t really have an interest, people do and if a firm is large enough, it is represented by many, many, many people. Part of the problem with implementing any kind of solution that will affect everyone in the enterprise is finding out first, how the enterprise will determine its wants and needs. Should it use the democratic method? Everyone puts in a vote and the solution with the highest number wins? Should it manage by consensus? Dissenting voices are managed one by one until there is some kind of movement in a single direction? Should the decision be made hierarchically? The executive at the top of the food chain decides and everyone else follows the lead? The answer to all of these may be yes… or no. Each firm’s management, for each situation must determine what degree of seriousness to allocate to an enterprise-wide plan.

I/S managers who might have spent years cajoling, teasing, arguing, forcing, enrolling and trading with their fellow managers in an attempt to generate enough consensus to move an enterprise-wide solution forward are often given the full authority of management to implement such solutions. In the past year I’ve seen Boards of Directors actually make operational decisions on software and on implementation schedules, something that in the 5 years previous would have been unheard of. With that kind of authority, anything can be implemented.

Yet, not every solution carries that much weight behind it. How do other enterprise-wide solutions get chosen and implemented?

In the case of the insurance firm, a committee has been struck with a mandate from the highest levels of management. Yet the mandate wasn’t clear in how it should be accomplished. In this firm, a couple of mainframe-based applications run high-level project tracking for the finance group. The goal is to eliminate these cumbersome systems and replace them with more modern reporting systems. The first idea was to look for a commercial system which closely matched the existing functionality. Surprise, surprise, no one has exactly the functionality required in a single system. While the requirement specification was being created to even evaluate systems however, the project increased in scope. Why look for obsolete functionality, the argument went, when we could create a state-of-the-art enterprise-wide project control environment? It sounded wonderful and the team was inspired. Now the search was on for multi-project, enterprise-wide systems which could integrate the work of thousands of employees and hundreds of supervisors, project schedulers and managers.

It sounds wonderful, but there was a small fly in the ointment. The majority of end-users are already using desktop project scheduling software from a funny little company based in Redmond, WA. While very popular among end users, this software was deemed insufficient for managing the centralized, cross-enterprise needs of the firm. “Did the committee,” I asked, “have the mandate to replace this software across the board?” “Well… no.” was the answer. But, some committee members thought it was such a good idea that they were determined to lobby for the notion. It sounded like fighting the good fight but without the backing of the highest levels of management, this committee was destined for failure. Trying to replace the desktop product would ultimately be so contentious, raise so many issues and concerns, step on so many toes that the committee would be handcuffed in implementing anything.

At the telecommunications firm, the news was similar. Here, one division has successfully implemented a project management system across their entire group and have come to the conclusion that if only the other 30,000 employees of this firm would see things they way the 1,000 of them do, everyone’s life would be easier. Nice plan, tough execution. This firm, like most high-tech telecommunications firms these days is enjoying explosive growth and changing directions and goals faster than can be imagined. The only way these firms survive is to compartmentalize their operations, leaving each group somewhat autonomous with significant discretionary power. The individual groups agree on virtually nothing. It is, in some ways a problem but it comes with the territory. Implementing an enterprise system that could only be used successfully if everyone agreed on how it would be used, how data would be analyzed, what quality of data would be included and last, but not least that all … every bit of data would be entered into this particular system is going to be very difficult. The original idea was valiant but in this case, even if the CEO himself thinks it’s a good idea, deploying such a system is going to be tremendously difficult if it’s even possible. This presumes of course that the product(s) that are selected and that they attempt to implement can even carry the load across such a large number of users with so many diverse interests.

In the case of the financial company, reason has somehow prevailed. Here, the original notions of an enterprise-wide planning system have been toned down. Technicolor plans of real-time resource management with instant management oversight have resolved to a more modest first phase approach. This firm has elected to implement only one of a wide range of elements that may one day make up the final solution. In this case, the first element is an activity-based timekeeping system which will, of course, touch every employee in the firm, yet is already somewhat culturally accepted. This first phase, will deliver some of the results management has been looking for with an ability to closely approximate some others without having to deploy tools or collect data from every user.

The lessons seem to stay the same. If you are contemplating implementing an enterprise-wide solution consider some of the following elements:

Ø Do you have the authority to do so? Has someone high enough up in management; someone with the authority to impose this solution if need be, requested that this solution be selected and implemented and; do they understand what kind of commitment will be required of them if the plan moves forward?

Ø Is there a need? If end-users are already satisfied with whatever solution they may be using at the moment, how will you convince them to switch? What benefits will this solution provide to each level of the enterprise?

Ø Finally, consider a phased-in approach. After all, if it’s all or nothing, then you’ll need to wait until the entire system is selected, installed, configured, loaded with existing data, tested, people trained etc until the first byte of useful return will come out. This may take months years or… forever. A phased-in approach lets you get small victories with benefits along the way. It’s true that the final dream system may stay forever outside your grasp this way but… was it ever really within your reach anyway?

I was talking last week about the announcement of Project Server 2010.  It’s part of a much larger communication of course.  The whole release that’s due in the first part of next year will be Office 2010 and that includes a whole pile of products.  It’s worthwhile keeping note of that because the new information available in Microsoft Project may well get lost in the noise of what is to come when the Office Marketing machine gets cranked up to full speed as it always does for a big launch.

One of the biggest elements of the Information Worker Division at Microsoft (that’s the part that releases business products like Office) is the next release of SharePoint.  SharePoint has become the go-to platform for Microsoft and almost every other part of Microsoft is working on leveraging it. 

What does this mean in practical terms?  It means that Microsoft Dynamics accounting software will have an interface based in SharePoint.  It means that the Browser-based interface of Visual Studio Team Services is based on SharePoint.  And, like the last 2 versions, it means that Project Server’s Web Access (PWA) Interface is based on SharePoint.  The interface of Project Portfolio Server has now been woven into the PWA interface also and therefore it too now is based on SharePoint.

Project Server is not the most algorithmic product.  It’s strength is not based on the incredible resource levelling calculation or it’s the flexibility of its critical path methodology calculations.  Project Server’s power is in being a collaborative project management tool.  For an organization that says “We’re not interested in collaboration.  We just want a heavy project scheduling calculation engine then working with a desktop product may be more appropriate.  There are many to choose from.  Primavera, Deltek and Planview all have desktop versions that are very powerful.  Even Microsoft Project Standard might be more palatable for that kind of requirement.

Project Server, however, is squarely targeting those interested in collaborative project management and SharePoint becomes a big part of that.  In fact, when you take the requirements apart, the ability of SharePoint to collaborate may make the addition of Project Server more of an afterthought and don’t think that Microsoft hasn’t thought of that already. 

Already when we go to clients who ask “Should we upgrade from Project Server 2003 to Project Server 2007 now or should we wait for Project Server 2010 next year?” the answer has little to do with the relative functionality in each version.

“What are your plans for SharePoint?” we ask.  If the company has already adopted SharePoint 2007 and has no intent to upgrade straight away next year, then we recommend Project Server 2007.  If the company is already committed to SharePoint 2010 or isn’t committed at all to a collaboration platform then we can consider waiting until the new version.  There’s plenty to do in the meantime if the plan is to go with 2010.  Architectural plans, pilot groups, training and system design can all be worked on now with an intent to roll out at the middle of next year.  The key is SharePoint.

Can we be that far away from Microsoft saying “Project Server is just another blade of a SharePoint Server?”

I suppose it shouldn’t surprise me. After all, it’s been 25 years and the request is almost identical each time. Again this week a very senior project manager asked for it again. “It” is a real-time, integrated project management system. The request came in a round-about way while I was demonstrating software for enterprise-wide use in a project environment so I had to double check. “Let me just be sure that I understand what you’re asking for,” I asked. “You’d like an enterprise-wide, web-based project management system that would manage its data in real time. In such a system the CEO for example, could click on a button and see a view of where all project stand at this moment. If they were to return in a few hours, the view would now represent all the changes that had occurred in the intervening time.”

The project manager’s eyes lit up. “You understand completely,” he said.

It fell to me to give him the bad news. “Such a system is demonstrable,” I said, “but could never be implemented.”

He was crushed. Who can blame him frankly? I remember standing in the exhibit hall of the annual Project Management Institute Symposium with the senior executives of two of the largest and long-standing project management software vendors. We were shaking our heads as we looked over the exhibit floor. Every booth it seemed was offering the same thing: “Enterprise-wide web-based project management”.

With all the promises from all these vendors of project management tools that offer this type of solution, surely at least one of them has figured out how to actually deliver it.

The problem is, that it’s not a technical problem. You see, as desirable as such a real-time report seems at first blush, it’s virtually impossible to deliver. The first issue is the context of the data you’re looking at. If I present a report of the status of a project, there are some basic assumptions that people make about the report. You assume, for example, that the data is accurate to the best of my abilities. To be accurate, project management data needs to go through at least some kind of review. You also assume that you’re looking at apples and apples, not a mix of different kinds of data. For example, if I show a report with 10 projects summarized on it, you would reasonably assume that the projects had all been statused on or around the same time. A report showing the status of some reports as of this week and others as of last month would be at best nonsensical and at worst could show a misleading view of our distribution and loads of resources.

This means that to create any such report prior to displaying it to management, I really need to update data on or around the same time and then validate that data through someone responsible for the project. This is the definition of batch processing. It is the very antithesis of real-time.

As soon as I point these kinds of issues out, it becomes obvious that there is going to be no easy solution to this request regardless of what the different booth displays say on the exhibit floor but there is another element of the issue that is almost never asked of the requestor.

Such requests typically originate from someone in the executive suite. A manager or director or senior executive of some kind asks why, with all the products on the market that promise such features, can’t he or she get the real-time analysis they’re asking for.

My first question of such people is “What will you do with it?” It seems trite I suppose but it’s really not. Imagine for a moment, such a system in place. Let’s imagine that through a petition to Harry Potter and his magic wand, we’ve managed to resolve all the issues with collecting, analyzing and validating our project data. Now, it’s 9:00am in the morning and our CEO is checking on the projects. He (or she) pops up the “corporate-wide-real-time-budget-vs-actual project report” Bad news. It shows the actual cost curve slightly higher than the budget curve. Our combined projects are over-budget. But wait! It’s 9:05 and the curve has just changed. Our budget curve has moved up, now the variance is alright. The CEO breaths a sigh of relief. Wait again! The curve has changed. It’s 9:15 and Bob, down in projects has just updated a half-dozen tasks with their new projected finish dates, now the curve is showing us over-budget again and we’re running late besides! But wait! The curve is undulating again. Even if this hapless manager were to take a snapshot and run down to the project department with it to ask how we’re going to get on track, the response is likely to be “Oh, you’re looking at the 10:23am report, you really need to look at 10:45, the picture’s all different.”

It’s obvious that such an environment would be completely unproductive yet the desire for it continues year after year unabated. This brings us back to the now dejected project manager who I met this week who wanted to know what he should do now? My recommendation was to change his question. Instead of searching for the real-time project management system, why not start asking what changes to his project management environment could he implement that would make them more effective. Not surprisingly, when he sets his sights a little lower, there is lots he can do.

It’s perhaps a good question for all of us.

Often when I’m speaking in the blog people assume that when I say EPM System, that I mean one large integrated EPM package.  It’s an easy assumption to make.  But enterprise systems can be made up of a myriad collection of tools and if those systems are accompanied by a strong enterprise process, then they can be very effective.  With the new announcements this week on Project Desktop 2010 it has me thinking.

I teach Advanced Project Management at McGill from time to time and one of the things that I always challenge my students on is to challenge assumptions. And a challenge I love to throw at them is to prove to me that an enterprise system is better than individual systems.  I mean, if you’re an organization, it must be better to be integrated into a single enterprise system, mustn’t it? 

Well, that’s a good question and before we’re done I often have the students make a case for having project management integrated into an enterprise system or leaving individual project managers with their own tools.

This debate comes in handy when I’m consulting organizations who are certain they want to implement an enterprise system. 

“Why?” I’ll ask. 

This often takes them aback.  Aren’t I the salesperson who should be trying to push an enterprise system on them?

“What specific business benefits do you expect to realize,” I ask.  Sometimes the answers are obvious.  By far the most popular request is that the enterprise system help with resource capacity management and forward capacity planning. 

But there are a lot of paths to getting to your goals. 

With the incredible penetration of Project Desktop it’s interesting to think about how effective project managers might be if they continued to manage some of their workload as individuals and collaborated on other elements.

How about this for an idea:

Use Project Desktop as a desktop tool.  Let individual project managers manage their individual projects on their own.

Use SharePoint for the team communication and collaboration that has become so important in today’s fast-paced project management world.  Document management, work flow with forms and list management could all live there.  Even milestone management to track deliverables could be in SharePoint.

Use Excel Services to do resource aggregation at the highest skill level.  It won’t do resource levelling of course but that might not be the biggest challenge.  A graphical representation of resource overloads at the skill level might be enough to overcome the biggest demands of resource capacity planning; determining if there *is* a problem.

With the ability of Project Professional 2010 to now import a list of tasks from SharePoint 2010 and keep that task list synchronized and the new Team View there may be more and more organizations interested in making a Sharepoint/Project Desktop organizational environment.