Tips, hints, links, and helpful information related to the discipline of Project Management.
Search This Blog
Wednesday, September 08, 2004
Team Communications
Accountability - What are the team members accountable for? Which tasks and/or deliverables is each team member responsible for delivering?
Approvals - What decisions are the team members authorized to make? What type of communication needs to be sent by the project manager to the team when project approvals have been made?
Synchronizing - Timely and accurate information needs to be provided to the team members regarding the project's tasks and milestones. Special attention must be paid to how the work is coordinated so all team members are working on the right things at the right times. Include the team when making decisions about synchronizing the work.
Progress Tracking - The project manager is responsible for tracking project status and the team must participate in the status reporting process and be kept informed. Ensure that the team is aware of the project's issues and allow them the authority to take remedial action to avert a crisis.
Thursday, September 02, 2004
What is not in writing has not been said
The following text was taken from Chapter Twenty in the “Field Guide to Project Management”. The authors Francis M Webster, Jr. and Stephen D. Owens state, "the written document provides instructions, restates previous instructions, conveys importance to the message, and helps the project manager to cover their tracks".
The authors also make the point that that "e-mail isn't always enough and can get you in trouble faster and with more people". As we all know from experience, e-mail usually isn't given enough thought before it is sent which can lead to messages being misinterpreted and having unintended consequences.
A project manager that is doing his or her job will formally document all items that are important and relevant to supporting a project's triple constraints (Time, Cost, Quality).
Friday, August 27, 2004
Project Objectives and the Work Breakdown Structure
I talked earlier about a Work Breakdown Structure (WBS), but this is such an important subject it is valuable to revisit.
The WBS should accomplish several things:
It is the mechanism that takes the project's requirements and turns them into manageable project tasks
It is used to communicate project objectives to the project team and other stakeholders
Its output is used to build your first plan and schedule
In David I. Cleland's Book "Project Management: Strategic Design and Implementation. Second Edition" he states that:
In general the development of the WBS provides the means for:
Summarizing all the deliverables , resources, and activities of a project
Relating work elements to each other and to the total project
Building the matrix organization for the project by cross referencing the work elements to the organizational resources responsible for their completion
Addressing all contracted resources required for the project.
Estimating costs, simulating project scenarios, and conducting risk analysis
Providing information to define, budget, schedule, perform, and control work packages
Definition: "Work Package" - A deliverable at the lowest level of the Work Breakdown Structure.
Keep in mind a complex WBS isn't' required for most small and medium sized projects. Many times a simple deliverable-oriented tree of activities that graphically displays the work to be done will suffice. By that I mean a structure similar to an organization chart with the project name on the top row and the second row consisting of some elements of your project methodology.
For example, for an IT project the second row headings might be:
Analysis
Requirements
Design/Procurement
Coding/Installation
Test/Acceptance
Close-out.
The best way to get started with creating a WBS is to gather the team (always done with the team) and write down the project tasks on Post-It Notes. Then, use an available wall to post the tasks in the appropriate places under the headings of your WBS's second row.