Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations IamaSherpa on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Is Project Server 2007 worth our while? 1

Status
Not open for further replies.

Elijah82

IS-IT--Management
Mar 28, 2007
7
IT
Hi all,

We work in a small office of about 8 peolpe and we currently use Project Standard 2003 to keep track of our tasks.
We are wondering wether using Project Server 2007 to collaborate to our projects would be worth the expense. In fact, we do have a shared hard drive, where we could store the .mpp files. Since we're few, and we're all eingineers, in my opinion we wouldn't harm each other too much if we simply established a set of rules to update the projects and worked on the shared drive.
Is there any reason why we should afford the expense and move to Project Server 2007, apart from the OLAP cube and the multi-level undo it supports?
Thanks in advance!
 
Project Server 2007 cannot be accessed by Project Standard 2003 (in fact, it can't even be accessed by Project Professional 2003).

So you'll need to examine the costs of P2003Std -> P2007Pro; P2007 Server; a CAL (~$150 for each resource entering time or manager accessing reports); costs of SQL Server; etc.

Then there's the implementation effort (note, not "installation" which is simply putting a CD in a drive and clicking on a few buttons and typing a few answers) including all the planning around the codes you will use throughout, training PM staff, training project resources, training management to use the reports and views, training resource owners to respond appropriately to resource requests, etc.

The look at the benefits of the cubes. After that, it's your call.

I think your manual approach will work just fine in your environment.
 
Thanks for your quick reply. I am aware of the compatibility issue and that we'd need all those licenses. The MS site says Project Server 2007 is available via Volume Licensing only; can you make a guess of how much that would cost in our environment?

Instead I didn't know about the implementation issues. Why can't we get the clients to work with the server right out-of-the-box? Supposing that we only wanted to add basic collaboration (say, allow team members to update their tasks' completion) to the features the standalone Project offers, what kind of implementation would we have to deal with? Do you have you a rough idea of which skills and efforts would be required?

Thanks!
 
These questions are pushing the boundary of my knowledge.

Cost of Project Server ... ~US$4,000-5,000 (never actually purchased a licence).

Implementation ... well, technically, yes: once installed, you can get the pieces to work together without much effort. But enterprise project management is a journey, not a goal. The objective -- as much as the word is overused -- is a synergy between the projects and between the projects and the organization.

As a simple example: generic resources. Instead of creating a project with tasks and assigning Bob and Mary to the tasks, you'll be creating the project and assigning a Programmer and a Systems Analyst to the tasks. When the project has received approval to proceed, you'll request a Programmer from the Resource owner (of the programmers) and get one assigned to your project.

Here's another: what will you do when a resource identifies an additional task/deliverable that needs to be performed?

I don't know how true this is, but I was once told that the hurdle question for moving from Project to Project Server is your answer to this question: are you accurately tracking earned value right now on all your projects? The rationale was that you need a certain maturity of project management processes before you will get sufficient benefits out of Project Server to make the switch.

Two further thoughts and then you've pretty much exhausted my knowledge of Project Server.

First, a number of companies offer a "service bureau" approach to Project Server. They have Prj Server installed on their own servers, you install Prj Pro on your machines and then use their servers. The advantage: you get their experience in setting up the codes, doing the training, migrating the processes, etc., while dodging many of the intial headaches in getting everything aligned.

Second, go to Amazon.com and look for books with Gary Chafetz as the author. You should some from good (but dry <grin>) reading there.
 
I see. Well, probably the objective you pointed out lies a tad beyond our reality. First of all, we use Project on our own initiative, just for our own office's planning and tracking purposes. There is no synergy between our projects and the entire organization, since we work mostly independently and address IT support rather than core business. Usually we don't share resources with other offices, and none of these uses Project anyway.

As we're few, we have some Bob, Mary, Ed, and so on rather than Programmers, System Analysts, and so on. Most of us have a few specific jobs and can't be exchanged.

Finally, as a support office in a non-profit organization, we don't generated any earned value directly. We use Project to schedule of our projects (for example we are planning to deploy an enterprise collaboration management suite) and to extimate the resources workload in order to know who is busy and who isn't.

Maybe I should have written all these considerations earlier and saved you some typing, but I'm sorry I had no idea of how Project suits the needs of a big and synergic organization. Anyway, your posts were helpful to me, since it seems that Project Server may be a bit overdimensioned in our context.

Thanks!
 
A couple of "add on" thoughts.

Earned Value isn't actually related to the line of business but, rather, is a measure of how accurately the project is actually performing when compared to the baseline schedule. It generates a variety of numbers with (to me, anyway) the two most important being the Schedule Performance Index and the Cost Performance Index. These are two data points which are tracked and trended during the life of the project (in other words, the two numbers today mean relatively little; it's the trend of each of those two numbers that really means something).

There's a useful write up here:

Finally, you needn't fret about how the dialog went. That's the whole point here: one starts somewhere; one asks questions; one learns something and moves to a different point on the path (or even to a different path) which has different questions.
 
Thanks for the input. There's a whole world behind that "Earned Value"! I guess mastering these concepts is a must for a successful project management, and definitely more important than the very software used for the purpose. At first glance I agree with you that SPI and CPI are the most important indicators.

I think I'm going to spend quite a while on hyperthot.com!
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top