Monday, January 29, 2007

January 29, 2007 – Managing the Thing: Project Definition Part 3

Most of the topics that I cover could fill full books and several classes. I barely touch the surface and hopefully point you in the right direction. Even in the brief way in which we are discussing Project Definition it has taken 3 different entries to complete. Today will cover Roles and Responsibilities, Milestones and Budget, and the Management Approach.

Roles and Responsibilities. This section identifies the roles of specific resources involved in the project and outlines their responsibilities. Major miscommunications and unmet expectations can be resolved simply by clearly setting responsibilities here. Build a table with the columns Role, Name and Responsibilities. It is important to identify a specific individual with each role. Also, the Responsibilities column, as with Out of Scope section, offers you the opportunity to state what you expect others to do. The example below is for the Business Team Leads but you should also identify the Sponsor, Overall Project Manager, other Team Leads, external vendors and other key roles.

Role
Business Team Leads

Name
Heather Morgan (Demand Planning)
Jillian Enaile (Supply)

Responsibilities
· Represent their business unit on the project.
· Provide project status to Overall Project Manager and upper management.
· Identify and assign appropriate individuals to participate in JAD sessions.
· Review and approve the Design document, UAT, and Final Approval.
· Coordinate all aspects of UAT for their business unit, including test plan and test scripts creation, execution, and signoffs.
· Etc.

Notice the use of verbs to describe what is expected. Imbedded in the Responsibilities is another clarification on the UAT ownership.

Milestones and Budget. This section, as the name implies, identifies the major milestones and deliverables with planned start and end dates and estimated cost in dollars, hours, or both. This needs to align with the Project Schedule. By developing the schedule and PDD together you can perform checks against each of them to keep them synchronized. If you identify a deliverable in the Approach section, it should correspond with a group of specific tasks in the schedule. Similarly, if you have activities identified in the Project Schedule you need to account for them in the SOW.

Management Approach. Depending on the maturity of your organization the size of the Management Approach section may vary. It outlines how each of the following areas will be handled and sets the expectations up front.
· Communication Management – identifies reports produced and meetings held (ex. Weekly Status Report and Weekly Status Meeting).
· Issue Management – shows expected level of issue documentation and resolution plans, giving a specific path for escalation.
· Risk Management – documents how risk identification and mitigation and how when contingency plans are necessary.
· Change Management – describes what constitutes a change, how to document it and the approval process.
· Acceptance Management – gives direction on how to approve or reject deliverables and timeframes for doing either.

If your organization has any or all of these management approaches defined, do not recreate them here. Reference them and document any deviations that your project will follow.

These six sections (Background, Scope, Approach, Roles and Responsibilities, Milestones and Budget, and Management Approach) form a basic Project Definition Document. Depending on your environment and project needs, the level of detail and legal jargon that is required will differ. The concept remains the same: Define The Thing that is to be delivered. Set the project expectations in writing and then obtain formal approval of it. As we will see in the entries to come, this document forms the basis for both change and approval.

No comments: