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.