Wednesday, June 30, 2010

Creating Project Plan/Project Charter

The project plan document contains all the information that you have collected until now. Your project plan can contain the following sections:

1.    Project management approval page
2.    Executive summary
3.    Objectives
4.    Project assumptions &  risks
5.    Project vision, scope & goals
6.    Deliverables
7.    Stakeholders
8.    Resources
9.    Roles & Responsibilities
10.  Communication plan

11.    Training plan
12.    Schedule
13.    Costs
14.    Processes & procedures
15.    Configuration plan
16.    Change management plan
17.    Test plan
18.    Supporting  tools & environments
19.    Risks management plan
20.    Measurement & Metrics plan

Note that some of the information in your project plan was already in the SOW and project charter and by now you have surely updated it given that you have progressed in your project, and gained valuable knowledge that you did not have during the initiating process. Also, depending on the size/complexity of your project you can choose to include or not some of the above sections.

The high level project plan may also be called the Project Charter. The Project Charter is a statement of the scope, objectives and participants in a project. It provides a preliminary delineation of roles and responsibilities, outlines the project objectives, identifies the main stakeholders, and defines the authority of the project manager. It serves as a reference of authority for the future of the project.

Project Plan Approval

imageGet the main stakeholders to review your project plan. Be sure to put into place a document versioning system for your plan as it will be surely updated throughout the project.

The project approval varies from organization to organization. In some, it is a rational process of strategic and technical planning. In others, it is a highly charged political game where project managers keep their backs to the wall to avoid the random dagger from behind. The key to project approval meetings is to be ready with options and alternatives for finishing earlier, spending less money and using alternative resources. Good project managers are eager to change the plan to fit executives’ needs and preference so long as the scope, budget and duration are feasible.

Tip: Before you start the project executing process, use the project management approval page to get signoff from the main stakeholders.

Tuesday, June 29, 2010

Roles & Responsibilities

imageWithin the project environment, a clear definition of the roles and responsibilities that individuals play will be critical to the success of the project. Throughout the course of the project, the role an individual plays, or the “hat” that is worn, may change. In addition, an individual may play more than one role simultaneously. Individuals must understand the roles they play to know what responsibilities they have in making decisions, taking actions, reporting, and reviewing. Role definition benefits the project by:

  • Bringing order to the chaos of a normal project
  • Allowing the team to reach “perform” stage of development faster
  • Keeping people from performing redundant activities
  • Creating a “job description”
  • Predetermining decision-making responsibility
  • Identifying personal responsibility for success at the beginning of the project
  • Reducing confusion about who does what when

Everyone on the project team holds the role, or wears the hat, of a project team member. Each team member is responsible for understanding the other roles and responsibilities. Each project team member should refer to the matrix when assigned a role on the team.

Project Roles

A project role is an assignment on the project team. It’s similar to a job description. A team member can have one or more roles at the same time. A person’s role may be temporary or last for the life of the project. For example, one person may have the role of team lead, artifact owner, and SME. When the artifact is completed, baselined, and the project phase is complete, the person would relinquish those roles and take on the responsibility of the next role assigned.

Some roles, like project sponsor, project manager, project control office, or project track lead, will last over the course of the project track, project, or program. At certain times, the persons wearing these hats may be asked to put on the hat of a different role, like business analyst (BA) or SME. While assuming that role, the responsibilities also change.

To facilitate smooth team interactions and clear lines of authority and responsibility, every person on the team should identify which role he or she is filling when giving direction, making decisions, calling meetings, or reviewing artifacts.

Project Responsibilities

When a team member is assigned a role on the project, he/she is given certain responsibility and the authority to take action or make decisions. On most projects, responsibilities usually fall into process steps:

ProjectResponsibilities

  1. Initiate: Start action on a project track, project phase, artifact, or task. As long as the action taken is within the scope of the project, the person who is given authority to initiate action can do so without being directed by management. Usually, initiating action takes place before a completed plan is in place. The major output of initiating is moving to the planning responsibility. The same person may or may not also be involved with the planning role. For example, the project manager may initiate a project track and turn it over to the project track lead for detailed planning.
  2. Plan: Some roles require planning. The roles associated with planning are project manager, project track lead, and artifact owner. The person doing the planning can use other persons (business process SME, technical SME, project sponsor) to create effective plans. Major outputs of the planning responsibilities are an approved plan, an artifact, or the project.
  3. Implement: Roles that are responsible for implementing a plan are usually those associated with completing tasks on the project plan. Some of these roles are: team lead, artifact owner, author, developer, and tester. The output of implementation is work produced to create an artifact that leads to building the finished product.
  4. Monitor: The monitoring responsibility is assigned to a variety of roles. Monitoring is not to be confused with reporting. A status report may capture some of the results of monitoring. However, monitoring may also involve problem solving and coaching. Monitoring is an active responsibility. For example, a team lead will monitor the progress of the artifact owners and developers working on the tasks of the plan. If the artifact is not being produced to plan, that person has the responsibility of understanding what problems exist that prevent implementing the plan. It may be that the plan needs revision. If that's the case, the problem can be escalated to the role that had the planning responsibility and those who approved the plan. Conversely, the individual who is implementing the plan may not fully understand the specifications, plan, or objectives of the project. In that instance, the monitoring individual can coach the implementer with a review of the specifications, plans, or project objectives. Outputs of the monitoring responsibility are verification that the plan is on track, minor coaching, reporting, and requests for assistance.
  5. Control: The roles that assume responsibility for controlling are those that own a process or artifact. For example, the project track lead, team lead, or artifact owner can take corrective action when the monitoring indicates the project or artifacts are not being created or produced as designed or planned. Controlling is a reactive responsibility. The same person may have the role of monitoring and controlling an artifact. Once monitoring responsibilities are fulfilled, the request for assistance can lead to a decision, counseling, new planning, and resetting scope. One aspect of controlling is the responsibility for preventing the project scope from changing after it has been baselined. This is accomplished through the core processes of change management and risk management. The owners and administrators of these two core processes have the responsibility for administering the processes. The scope change control and responsibility is built into the process and is not assumed by an individual. However, within the process, certain roles are identified that have the responsibility of making scope change decisions.
  6. Close: It is the responsibility to close out anything that was initiated. A project track, project phase, artifact, or task needs closure. It is usually the responsibility of the role of owner to conduct closure. Some tasks associated with closure are archiving drafts and baselined artifacts, contract closure, celebrating, reviewing, lessons learned, knowledge transfers, and hand-offs to the next user of the artifacts.

Roles & Responsibilities Example

Following is a simple Roles & Responsibilities Matrix:

Role Responsibility
Developers Design
Development
Bug Fixing
Quality Team Testing Activities
Requirements Review
Design Review
User Guides Review
Test Reporting
Designer Graphics Design
Team Leader Team Management
Business Validation
Architect Architecture
Technical Standards Definition
Environment & Deployment Planning
Technical Writer User Guide Documentation
Online Help Documentation
Business Analyst Business Analysis
Client Management
Project Manager Project Management
Client Management

Roles & Responsibilities Matrix

The roles and responsibilities for the X project are presented in the chart below. To read the chart, a project team member should determine what role one is playing at any point and what area of responsibility is of concern. See the chart legend for letter designations. They correspond to the responsibilities described in this document. For example, if a person is assigned as an requirements owner and wants to determine his or her responsibilities for the tasks to create the artifact, he or she would read across and find the letters: C, F, G, I. Referring to the chart legend, the requirements owner is responsible for C = initiating the task, F = controlling the task, G = monitoring the task, and I = approving the task.

Roles & Responsibilities Matrix Legend

image

Roles & Responsibilities Matrix

image

Communication Plan

imageHaving a communication plan in place is an essential component for good project management. This document ensures that all stakeholders are equally informed of how, when, and why communication will happen. Communication is often a very effective way to solve problems, deal with risks, and ensure that tasks are completed on time.

Successful communication plans will identify stakeholders, the information to be communicated, and how this information will be communicated. They will leave nothing to chance. The communication plan includes:

  • Listing your communications stakeholders
  • Defining each stakeholders communication needs
  • Identifying the required communications events
  • Determining the method and frequency of each event
  • Allocating resource to communications events
  • Building a communication event schedule

A Communication Plan helps you keep everyone informed so that you can communicate a consistent message to your target audience.

Communications can be internal with your team, or external with your customer and 3rd parties.

Examples of communication types and media are:

External Communications

Type Description /Purpose Audience Media Timing
Report Weekly progress & status Customer, PM E-mail Weekly
Tracking Sheet
E-mails
Conference Call
Open issues list tracking
Team questions
Customer, PM Excel file
E-mail
Ad-hoc
Meeting Demos Customer, PM Meeting Per Milestone
Meeting
Conference Call
Weekly status meeting Customer, PM Meeting Weekly

Internal Communications

Type Description /Purpose Audience Media Timing
Meeting Kickoff Team   Start of project
Meeting Project Closure Team   End of project
Meeting Technical Review Development & Testing   Upon need
Meeting Daily Review Development & Testing   Daily (0.5 hour)
Meeting Weekly Status Team Meeting minutes
Schedule update
Task list update
Weekly (1 hour)
Meeting Ad-hoc meeting Team/part of the team Meeting minutes Upon need
Meeting Knowledge Sharing (problems/suggestions/enhancements) Team/part of the team Knowledgebase update Upon need
E-mails For all agreements, issues… Team   Upon need
Verbal For all agreements, issues… Team Meeting minutes
Task list update
Knowledgebase update
Upon need

It is always helpful to send meeting requests with agendas prior to meetings and to document the minutes of meeting and send them to the attendees after the meeting.

Training Plan

imageIf the project adopts a new technology, or if the business requirements need special type of development while implementing the project, the team should be trained according to the project’s needs. The training plan should include information about the type of training needed, who needs it, and the date of training. The training plan should be considered while planning for the project. A sample training plan may be as following:

Role Name Training Type Start Date End Date
Developers XYZ Build & test automation Sessions 08-Oct-10 13-Oct-10
Testing Team ABC Security testing Self-study 18-Oct-10 22-Oct-10