Microsoft Project Server 2003 - Architecture and Business Logic

"How tightly integrated is Project Server and Visual Studio Team Server?" ... A Question from My Recent Webcast

Mark Schneider — Wed, 03 May 2006 13:12:00 GMT

Your question: "How tightly integrated is Project Server and Visual Studio Team Server?"

My answer: "Not very integrated, yet."

Visual Studio 2005 Team Foundation Server provides many of the same functions for coordination and collaboration that Project Server 2003 does. Each uses a WSS site as the basis for collaboration and coordination of documents, tasks, issues, etc. It would be pretty logical if both could be built on top of the same WSS sites, but that is not the case.

So, why not just get by with Visual Studio 2005 Team Foundation Server? Because it is a tool of the techies, for the techies, and by the techies. It is a great tool to manage the Software Development Lifecycle, but that is only a subset of project management. The Project Server tool was created because a proper project team needs to include a cross-functional team of people for whom Visual Studio 2005 Team Foundation Server would be all but impenetrable. Sponsors, business analysis, subject matter experts, deployment and support professionals, will all have a much easier time dealing with Project Server 2003.

So, my recommendation is to use Visual Studio 2005 Team Foundation Server for the development team but use Project Server for the overall project team. Again, to me, the integration is more one of workflow than technology. The handoff to the development team would be a milestone in Project Server, and concrete deliverables would be the product of the handoff. There are some clever workarounds that you could pursue, but clever is rarely a good idea in these matters.

Project Initiation: Project Server
Project Planning: Project Server
Project Execution: Visual Studio 2005 Team Foundation Server
Test and Validation: Visual Studio 2005 Team Foundation Server
Deployment: Project Server
Productionalization: Project Server

We can certainly imagine that 2007 will bring new opportunities for cooperation between these two important tools.

P.S. Yes, I know that "Productionalization" isn't really a word but I'm uncomfortable with "Institutionalization"... it sounds like it's off to the funny farm.

My Project Stats are "All Shook Up"

Mark Schneider — Tue, 28 Feb 2006 12:48:00 GMT

FACT: According to Mental Floss (www.mentalfloss.com), Elvis Presley made his first professional recording in 1954.

FACT: By 2004, there were at least 35,000 Elvis impersonators in the world.

FACT: By my own calculations, this rate of growth means that one person in four will be an Elvis impersonator by the year 2054.

FACT: Project Managers can take the facts of a project and spin them to say just about anything they please.

FACT: The only way to avoid having your project information spin out of control is to use “Net Present Value” calculations to keep track of time and money for complex projects.

FACT: It is really hard to calculate NPV unless you can track projects and resources at an ‘enterprise level.’

FACT: Microsoft Project Server helps you keep your project statistics from turning into Elvis sightings.

For a brief moment I stood among giants

Mark Schneider — Tue, 21 Feb 2006 08:28:00 GMT

One of my customers, Mindsharp, has a contract to train Special Operations Command (SOCOM) personnel in the use of Microsoft software. Because of the size of the project, Mindsharp hired me to be their project manager for the effort. As a result, I was with the Mindsharp team at SOCOM HQ last week. Our project focused on relatively boring office software, and none of us have security clearance, so we didn’t see or hear any important information. We did have the honor of rubbing elbows with giants for a few brief hours.

If you aren’t familiar with SOCOM, they are the super-stars who go after the global bad guys to keep us all safe. They are the combined command for the various elite soldiers in the U.S. military. These men and women are the toughest of the tough, and I was a little apprehensive about how they would treat a computer geek like me. I needn’t have worried, they were unfailingly:

Polite
Patient
Soft-spoken
Helpful
Generous
Honest

I guess that you don’t have to act tough when you really are tough. Before the meeting I attended began, I had a chance to mingle with the various high-ranking men and women present in the briefing room. I had a chance to tell them that my kids think I’m 6” taller just standing next to SOCOM personnel, and that they are heroes in my household.

In short, I had the rare opportunity to say “thanks” on behalf of my friends and family. They all smiled.

They also gave me all kinds of stickers and things for my kids. Don't tell anyone but I kept a couple of the SOCOM stickers for myself.

My Dog Champ has Scope Management Problems

Mark Schneider — Mon, 20 Feb 2006 16:39:00 GMT

My greyhound ‘Champ’ lives by a simple motto,

“Go ahead and eat it; if it turns out that it isn’t food,

you can always barf it up in the living room.”

A lot of project teams live by the same motto when it comes to scope management. When they define their project objectives, they don’t place them under change control. As they begin to plan out the project, they see opportunities to tack on other tasks and objectives “as long as they are in the neighborhood.” The problem is that each little opportunistic change can have a profound impact on the budget and schedule, particularly if the project is already under way. More often than not, these extra requirements are indigestible and the project team eventually drives the project off schedule and budget. This, more than anything, is why most IT projects fail.

Project Server 2003 helps you address this by having the project team collaborate on scope, schedule, and requirements documents, and then place them under change control. If the requirements absolutely have to change, then there is a process to review the change and estimate its impact to the project schedule and budget. The schedule and budget are then modified in keeping with the scope change, and the project remains under control.

Keep in mind though that Project Server 2003 doesn’t manage your scope for you, it gives you the tools to use to effectively manage scope. You still have to have more discernment than Champ when it comes to decided what’s in, and what’s out of scope.

Microsoft Project Server 2003 can get you where you want to go, but don't understimate the difficulty of the trip.

Mark Schneider — Mon, 06 Feb 2006 14:19:00 GMT

Microsoft Project Server 2003 can get you where you want to go, but don't understimate the difficulty of the trip.

I had a Mini Cooper back when I was going to college in Minnesota (State Motto: “We’re no worse than some people we could mention.”) This wasn’t one of the modern Mini Coopers that actually goes places, but one of the original Mini Coopers from the 1960s that needed significant engine repair every six or seven blocks. Every aspect of maintenance required parts that were mythical and the manual appeared to have been unsuccessfully translated from Japanese. It had the obligatory Union Jack flag on the roof and was the coolest car I have ever owned. I wish I still owned it, warts and all. When a car is that cool, actually getting it to go places seems relatively unimportant.

What possessed me one summer evening to attempt to drive my Mini from Winona State University to Kellogg, along the scenic Mississippi river, I will never know. I was even “dressed up,” which back in college was quite bizarre. Perhaps I had had some kind of mental breakdown during finals. At any rate, the Mini did inevitably have a breakdown on a particularly desolate stretch of Highway 61, leaving me marooned. After listening to the crickets in the darkness for an hour, I heard a solitary engine sputtering and struggling in the distance. In a moment, two headlights crested a nearby hill and a shabby old pickup truck came weaving along the road in a cloud of blue exhaust. As it approached, I could see two very drunk rednecks in the cab. One drank from a large bottle while the other downshifted with a hay hook. They were laughing and having a good old time as they rolled to a stop. Meanwhile I tried desperately to remember if the movie ‘Deliverance’ was based on a true story.

Since neither was holding a banjo, I accepted their gracious offer of a lift to nearby Kellogg, and climbed into the back of the truck. As my shoes slowly sank into a mound of chicken manure, I held on to the cab for dear life. The truck made a swaying U-turn and sputtered northbound up the southbound side of the highway, gaining speed on the downhill slope. Of course, now that I was traveling the wrong way in a pickup truck full of chicken refuse, Highway 61 suddenly sprang to life with hundreds of oncoming cars. The good old boys in the cab laughed as we slalomed in between oncoming cars, and listened to the panicked horns dwindle in the summer night behind us. Here is the moral of the story. I could have criticized those boys all day long, but we were going to Kellogg. It wasn’t safe. It wasn’t sanitary. It wasn’t the route I had imagined, but we were going where I needed to go. Deploying and configuring Microsoft Project Server 2003 feels a lot like my trip to Kellogg.

Please don’t misunderstand me. I am a proponent of Project Server 2003 and am writing a training curriculum to support it. However, getting it deployed is much harder and more confusing than you might imagine. It is a very ambitious and complex product. The confusion arises because other Microsoft products are relatively simple to understand and straightforward to deploy. This last statement probably makes you want to hunt me down and do me bodily harm, but it is quite true. Microsoft has, in fact, spoiled us with the relative ease of implementation for most of their products. As I’ve hopefully made clear, Project Server 2003 is a competent product that is clearly heading in the right direction with its Enterprise Project Management systems, but make no mistake—it is going to be a tricky ride. Project Server 2003 is Microsoft’s first significant effort to integrate its software into a vertical solution that scales across the entire enterprise. This means that it is far more complex than we are used to when dealing with Microsoft products. It is no more complex than other vertically integrated enterprise suites, but we don’t usually think of Microsoft in that context.

Deploying a small version of it for testing is not that big a deal, but building it out across an enterprise is. With its level of integration and collaboration, it is more like an ERP system than a traditional project management tool. I think this is an appropriate analogy, but please remember that ERP systems aren’t designed, deployed, and placed into production in a single day. You can start small with Microsoft Project Server 2003 and probably should. But always keep in mind that deploying it successfully across the enterprise is a major project which will require major time and resources. It is, in other words, no different than any other true enterprise solution. We’re just not used to that level of integration and complexity from Microsoft.

My dream in writing my curriculum was to take senior System Administrators and make them self-sufficient masters of Microsoft Project Server 2003, in a single week of training. It is not to be, and if I said otherwise I’d be pulling your leg. Instead, the students will walk away with a thorough understanding of how to organize, manage, and drive a deployment and configuration project. They will also walk a way with a Project Server 2003 deployment imaged in a virtual environment that they can use for evaluation. They will have what they need to evaluate and test Project Server 2003, but they will not be able to quickly plop it into production. You will regret any shortcut you attempt to take. It is still worth the effort to pursue MS Project Server 2003, and I think it will become the marketplace ‘front runner’ in the near future. Just don’t underestimate the effort and training required.

So, to sum it up… you wouldn’t expect to master SAP or PeopleSoft after a 40 hour course. You should measure Project Server 2003 with the same yardstick. A project to successfully deploy and configure MS Project Server 2003 will involve a senior team of technical professionals, and will take some time to complete. You will need expertise in

Physical infrastructure,
Storage technology,
Microsoft Windows Server 2003,
Email systems,
IIS,
SQL Server 2000,
WSS,
Project Professional, and
Project Management Methodologies.

My course can make you the leader of the team that deploys Microsoft Project Server 2003, able to scope, organize, and manage an implementation project. In all honesty, it won’t give you the ability to install it without a team of competent professionals supporting you. I don’t think any class will, and I don’t think any competent and scalable Enterprise Project Management solution will be any easier or faster to deploy. You will, however, get to your own personal Kellogg.

If you’d like to know more, please contact sales@mindsharp.com

A Primer on Project Risk (or “My Dog is Afraid of Butterflies”)

Mark Schneider — Tue, 17 Jan 2006 10:47:00 GMT

What is Risk Management?

Microsoft Project Professional and Microsoft Project Server both provide ‘risk management’ capabilities. How in the world can a project manager objectively and empirically manage ‘risk?’ Does it mean that Microsoft’s Enterprise Project Management tools encourage you to “lay low” during your project? Does it include a library of books with titles like “Why Bad Things Happen to Good People?” Is it some kind of karma management device? Does it help you root out un-confessed sin?

No.

Risk management is a set of project management best practices that can be used to estimate:

Bad things that can happen to your project.
How bad the bad thing would be, if the bad thing happened.
How likely it is that the bad thing will happen at all.
What to do about the bad thing if, Heaven forbid, the bad thing does in fact happen (contingency planning).

Microsoft Project Professional and Microsoft Project Server 2003 have tools that help itemize and manage potential bad things that might happen, without getting too paranoid.

Risk Assessment Example 1 – My Dog Champ

My dog is a very large and muscular greyhound capable of speeds up to 45 miles per hour. Apparently an animal’s speed is inversely proportional to its mental capacity, and Champ is a case in point. I love Champ dearly, but on the intellectual front we are not exactly saving up for his college education (if you catch my drift.)

Champ is deathly afraid of the butterflies that frequent our back yard. He is loathe to go outside if they can be seen flitting gently from flower to flower. I have tried my best to explain to him the principles of risk management in this regard:

Risk = (The PRESENCE of an object or event) and the (POTENTIAL it has to cause harm)

Using this best practice to assess the risk of butterflies to my dog Champ, it becomes apparent that

The butterflies are indeed present.
However their potential for causing harm to an 80 pound dog is very small, even if they all ganged up on him at once.

Champ has never been one for mathematically calculating probabilities, so he remains unmoved by my logic. Even using Microsoft tools to organize and present this information has failed to move his opinion.

Risk Assessment Example 2 – A Project to Buy Milk

My friend’s father has grown extremely forgetful with age. During a recent get-together, we ran short of milk and this kindly old gentleman took it upon himself to get more. Due to his relatively short attention span coupled with a very optimistic outlook on life, the trip to the store took about four hours rather than the customary fifteen minutes. Though this was six months ago, he would presumably still be strolling happily North had the good officers of the local constabulary not found him, as a result of our missing persons report. Not to worry, he had an extremely pleasant afternoon and met some very nice officers. As I said, he is a very optimistic and friendly person.

In fact, the whole thing ended quite happily except for one tense moment. The police ‘all points bulletin’ instructed the officers to be on the look out for a “confused looking man” in mismatched clothing, and to place him in protective custody immediately. Upon hearing this particular turn of phrase, I quickly hid in my friend’s basement lest the good officers scoop me up in the same net, based on this physical description. I am, after all, a computer professional.

But I digress.

So, if we had a project team that included my friend’s father and the project required him to get milk, the risk would be:

(High probability that he would get lost) and (that the event would delay the project from 15 minutes to at least four hours AND require the addition of resources with guns in squad cars, AND the use of a basement).

So, measuring risk is simply an accepted means to determine how likely an event is to happen and what the impact is going to be if it does. This is then used to adjust schedules and resources (move milk delivery out four hours, add 14 squad cars and hide in the basement), so that the project schedule is not impacted.

Risk Assessment Example 3 – Smelling Like a Rodent at the Worst Possible Moment

Risk management also helps you to avoid over-reacting to things that seem scary but really aren’t. If you spend a lot of time fretting about being bitten by a cobra, and you live in Minneapolis, you should probably seek professional help and/or medication, unless you happen to be the curator of the Reptile House at the Minnesota State Zoo, and you smell like a rodent; now that, ladies and gentlemen, was a sentence. My point in this paragraph, as nearly as I can remember, is that a risk management methodology also helps to prevent the project manager from over-planning for bad events that are very unlikely to happen.

If a cat has kittens in an oven, it doesn’t make them biscuits.

Here is another truth we can take away from this post. Just because you happen to own and use Microsoft Project doesn’t mean you are a qualified project manager. If a cat has kittens in an oven, it doesn’t mean the kittens are biscuits.

So, it is important to understand the logic of risk management in general, before learning to use it in a tool like Microsoft Project Professional. Project management tools do not turn people into project managers.

Q: Why does MS Project Server include SharePoint Services?

Mark Schneider — Mon, 16 Jan 2006 09:11:00 GMT

A: Projects are ruled by collaborative documents which most team members have never read. The project is governed by the ‘project documents,’ which are created by the project team, approved by the Steering Committee or Sponsor and placed under change control. The Project Documents go by various names, but they usually include:

· A Scope Document. This spells out exactly what the project will do and not do, the project team roster, how the project will be funded, who the Sponsor is, and when the big deadline is intended to be. This document comes first, and no other action should take place until the scope document has been approved by all the impacted parties, especially the Sponsor.

· A Project Contract. This is sometimes combined with the scope document. A project represents a contract between several people to accomplish a given task, under a certain budget, and by a specified deadline. It spells out which role each person is to play in accomplishing this project, and what the mechanisms are for making decisions once the project gets started.

· A Requirements Document. Failure usually begins here. The problem is that the project team doesn’t know that they have failed until the end of the project. There needs to be a simple and straightforward document that lists everything the Sponsor expects the project team do accomplish. This needs to be very clear and measurable with no room for ambiguity. A requested customer requirement might be“to make the screen a green color.”

· A Testing and Validation Document. It is important to build the test strategies and plans right after the requirements are approved. This helps make sure that the testing will ultimately validate that the requirements have been met. It will also help find holes in the requirements by forcing the Project Team to walk through them and determine how each requested feature will be measured and proven.

· A Specification Document. This document takes the requirements listed above and refines them to a measurable and objective solution strategy. So, the ‘green color’ requested above would be refined to say something like “a green color emitted at a wavelength of 5270 Angstroms at standard temperature and pressure.” This may sound dumb, but it will save the Project Team’s hide

· A Design Document. Once the Sponsor has approved of the Specification Document, the Project Team creates a Design Document. The Design Document spells out exactly how the Project Team will meet specifications and requirements.

· A Deployment Plan. This is the plan that governs the deployment of the solution produced by the Project Team.

· A Task Summary or Work Breakdown Structure (WBS). Once the solution has been determined, documented, and approved, the Project Team then develops a list of tasks to accomplish each step in completing creating and deploying the project solution they are about to create and implement.

· A Project Schedule. This is what Microsoft Project Professional does so very well! The tasks are placed in a tool like Microsoft Project Professional and organized in chronological order. Any tasks that require other tasks to be completed first (dependent tasks), are linked to their predecessor tasks. This way, if a task changes its individual schedule, it is possible to see what the impact is to the overall project schedule.

· A Staffing Plan. Based on the WBS and Project Schedule, the Project Team can determine what skills needed to be added to the Project Team and when. This plan then needs to be negotiated with the ‘Resource Managers’ who manage those people on a day-to-day basis. Microsoft Project Professional does an excellent job managing resources that are committed to the Project Team. However, most Project Team members are only assigned to project tasks intermittently on a part-time basis. They are needed when they are needed, but not needed the rest of the time. When they are not actively engaged in a project, they may be assigned to a different project temporarily.

· A Resource Plan. This lists how many tools, computers, materials, offices, trips, and other costs will be incurred by the project.

· A Project Budget. Based on the above information, the Project Manager can create a Project Budget. If the Project Budget is higher than the Project Sponsor had intended, the Project Manager and the Sponsor have to decide on one or more of the following:

a. Get more money and resources. (Increase the budget)

b. Complete the project more slowly. (Change the schedule)

c. Settle for fewer features. (Narrow the Scope)

Note that all project management decisions boil down to a trade-off between scope (what), schedule (when), and budget (how much).

· A Communication Plan. This is a plan that spells out how often reports will be published, what will be in them, and who will the audience be. It also includes a list of expected meetings, their frequency, the level of participation required, and the content of the meetings.

Most projects fail due to inadequate communication and collaboration. Documents, if they existed at all, were written in Word and Excel and emailed to the various participants. Sometimes team members didn’t receive the emails, sometimes they were overlooked in the volume of email received, and sometimes the team members were working with conflicting versions of documents at the same time.

Even if the documents were properly created, approved, and placed under change control, most project teams have no idea where the authoritative copies of those documents are! Most team members have never read the project documents and have no idea what the real intent of the project is!

The addition of SharePoint Services to MS Project Server 2003 provides a great method for empowering collaboration among team members, making sure that the correct versions are used, and providing a means for tracking approvals and releases.

It is important to understand project management if you are going to understand an Enterprise Project Management solution like Microsoft Project Server 2003.

Mark Schneider — Thu, 12 Jan 2006 15:33:00 GMT

You wouldn’t expect a technical team with absolutely no understanding of finance and accounting to successfully select, purchase, build, configure, and deploy an accounting package. There would be no way to understand which modules were necessary and which were not. “Well, the manual said that Accounts Payable was optional, so we didn’t put it into the deployment.”

The same is also true for special purpose packages like Microsoft Project Server 2003. Most of the technical questions I’ve heard are something like “Does Microsoft Project Server 2003 absolutely require ‘xyz,’ or can I get around it?” Questions like this make me cringe. It is like asking “Is it possible to write a term paper without using any of my keyboard’s vowel-keys?” I can show you how to do it, but I’d be a better friend if I asked you why you wanted to do this in the first place. It is possible you are making things more difficult than they need to be.

Here, by the way, is how to write a term paper without using vowel-keys. Write your paper substituting the ‘~’ for ‘a’, the ‘{’ for e, the ‘} ‘for I, the ‘[’ for ‘o’, and the ‘]‘ for ‘u.’ When you are done with the paper, open another document or web page and copy an ‘a’. Then use global replace to replace all the ‘~’ characters with ‘a’. Continue for each vowel. Like so much in the computer industry, it is a clever but useless solution.

If you understand the ‘big picture’ when working with Microsoft Project Server 2003, you can avoid many technical solutions that are clever but ultimately useless.

Coming up next… an explanation of why Microsoft Project Server 2003 uses SharePoint Services.

Microsoft Project Server 2003 is one of the most under-marketed and least understood products available today.

Mark Schneider — Wed, 11 Jan 2006 13:53:00 GMT

Microsoft Project Server 2003 is one of the most under-marketed and least understood products available today.

Microsoft Project Server 2003 is a competent tool that should be considered when selecting an Enterprise Project Management solution, but usually isn’t. Why not? Here is some of the buzz about MSPS 2003:

· “Oh sure, we own a copy. I think it’s on that shelf right over there. No, it’s never been opened.”

· “It is OK, but frankly it is an unfinished product.”

· “We really love Microsoft Project Professional, but I’m having my brother-in-law Rudy build the back-end integration from scratch. He’s an unemployed plumber, but how hard could it be?” (I made this one up, but it fits a pattern)

Here, sadly, is the decision process when a company selects an Enterprise Project Management suite or tool.

Many Stand-Alone Copies of MS Project Professional are in use. Someone in IT finance realizes that there are “many” copies of Microsoft Project Professional installed “out there.” Enough money is at stake that somebody decides to see if Microsoft Project Professional is necessary. Often this task is given to a junior accountant that nobody likes.

Project Managers are not coordinating their efforts with each other, resulting in cost overruns. The finance audit of Microsoft Project Professional determines that a large number of self-proclaimed project managers work throughout the company. For these folks, Microsoft Project Professional is as necessary and fundamental as Microsoft Excel is to an accountant.

MS Project Professional alone is not designed for collaboration. It becomes apparent that Microsoft Project Professional is a very critical and time-honored tool for project managers. At the same time, it is not designed to provide services to the entire project team. It is a single-user, stand-alone tool. Effective project management involves collaboration that is driven by the information provided by MS Project Professional.

Project collaboration tools are evaluated as a means to improve coordination of the efforts of individual project managers. Someone in management reads a journal article about Enterprise Project Management tools and suites. These tools promise to make the above problems go away. An IT person uses the list of Enterprise Project Management tools in the journal article to create a spreadsheet listing pros and cons for each listed vendor. Microsoft Project Server 2003 isn’t represented on the list because it doesn’t read well and has no snazzy screenshots to put in the article.

A strategic decision is made to use a third-party collaboration tool. An executive decides to buy a random project management software package sold by a salesperson who bought lunch during a tradeshow. The IT person wisely skews the evaluation to favor the software company that bought lunch for the executive.

The tool is deployed. The package is purchased and installed.

Moving to a third-party enterprise solution can cause a costly and time-consuming effort to retire existing tools. Only after installation does it become apparent that the new project management tool does not in fact work with Microsoft Project Professional as the salesperson said it would. All project managers are forced to migrate from MS Project (which they like) to the new project manager interface.

Older tools are used in parallel with the new tool. All project managers secretly continue to use Microsoft Project Professional. They also enter just enough information into the new tool to keep management off their backs, but the new tool is irrelevant. In fact, it is now a hindrance as it takes up lots of time and adds no value.

(Of course, this is the buying pattern for most software packages used in the corporate world. That’s why so many sales people are trained to “sell up,” which usually means “buy lunch at a trade show.” The truly odd thing is that the “buy lunch at a tradeshow” model is the engine that drives the world’s economy, and it does so successfully. But I digress.)

Is Microsoft Project Server 2003 the Right Product for Your Project Collaboration Needs?

OK, so cut away all of the lunches, meaningless four-color brochures, and journal articles that favor who ever buys the most advertising space, and what is the “right” answer for Enterprise Project Management tooling? Is Microsoft Project Server 2003 the Enterprise Project Management suite you should use in your corporation? I have no idea. I can, however, help you to understand the product and put together a test image that can be quickly installed and used in your own environment. Why not just put it in place and see?

Top ten reasons to give Microsoft Project Server 2003 a fair evaluation:

You probably own it and have it on your shelf somewhere.
It is easy to use, once you understand it.
Microsoft Project Professional integrates with it.
It is easy to learn because it has the same general UI as other Microsoft tools.
It is low risk. It can start very small.
It can grow in functionality to be a very sophisticated tool. It is designed to integrate well with SQL Server, Outlook, and Microsoft SharePoint. With this integration, a number of collaboration, reporting, and tracking features can be added.
It scales well.
A test image can be built and deployed in a few days, with a little help.
Competing tools will be using MS Project Server “under the covers” to do the work anyway.
Most of the ‘gee whiz’ features of other products are really not necessary to effective project management. These eye-catching features generally are little more than “bells and whistles” to generate excitement. Few, if any, will be of practical use to project managers on a day-to-day basis.

Coming up next… understanding what an Enterprise Project Management suite does.

(Understanding the ‘big picture’ makes it a lot simpler to plan, build, and deploy a Microsoft Project Server 2003 image.)