2.3 Project Framework Rules Document | Managing Software Deliverables: A Software Development Management Methodology

< Day Day Up >

A Project Framework Rules Document (PFRD) defines agreements made by the project team as to how the team will operate. It should clarify the expectations of the project participants and ensure that important decisions are made early in the process and documented. The Core Team should participate in drafting and finalizing the PFRD. The decisions made in this meeting do not need to be unanimous; however, when gridlock occurs, the Project Manager casts the deciding vote. Some of the questions for each major area of consideration that should be answered in the PFRD are listed in the following sections.

2.3.1 Planning Decisions to Be Made and Documented

Development

Who is responsible for developing the project plan?
If more than one person is responsible, who should be involved?
What are the specific roles and responsibilities of each participant?
What does the plan include?
Does it meet customers'/management's needs?
What product or service life cycle will it follow?
Will meetings be needed to define the project plan?
When and where should they be held?
Who will attend?
Who needs to be informed of decisions made? How will they be kept informed?
Will a list of terms be distributed for better comprehension?
Is there a plan to improve management of the project?
Is there past experience on similar projects? How can we use it?

Planning Output

What are the outputs from the planning process?
In what format will they be presented?
How detailed should they be?
Who needs to receive them?
Who is responsible for them?
How will we know that each output is completed?
Who will assess the quality of each output?
Who needs to approve and sign off at the completion of each output?
How will we know that each output has been signed off on?

Project Tools

What project management tool(s) are we going to use?
What equipment is required to support the tool(s)?
Will all subprojects use the same tool?
Who will operate the chosen tool?
Who will enter planning and tracking information?
Who will need training to operate the tool?
Who will provide technical support for the users of the tool?
What additional software do we need in order to support the project management tool?
If additional software is needed, is it for financially related issues or for action items, follow-up, documentation, and so on?

2.3.2 Tracking Decisions to Be Made and Documented

Tracking

How will we assess progress?
How will we get data from the project team to others about the progress of each activity?
How often will we get this data?
At what level of detail will we track the project?
Who will assess the impact of each variance?

Progress Review Meetings

What types of meetings will we hold (e.g., general, top-level, activityspecific)?
Where will they be held?
How often will they be held?
What is the process for calling an emergency meeting?
Who will define the strategy and method for managing meetings effectively?
Who will run these meetings?
Who will produce an agenda to be distributed before each meeting?
How will the meetings be run?
Who should be included in each type of meeting?
In what format should the meeting information be presented?
Who will keep minutes of the meetings?
Who will produce them?
To whom should they be distributed?

Reporting

What project reports will be generated?
Who will generate, analyze, and distribute them?
To whom should they be distributed?
What content is appropriate for each audience?
How detailed should status reports be for each audience?
What formats (tabular, narrative, graphic) communicate best to each audience?
What criteria will we use to define an exception for exception reporting (e.g., deviation, spotlight, urgent action)?
Who initiates these reports?
Who will receive and analyze exception reports?

2.3.3 Best Practices Decisions to Be Tracked and Documented

The Project File

What should the project file contain?
How will all project information be kept?
Who will create the project file?
Who will update and maintain it?
Will changes to the file be allowed? If so, by whom?
Has a filing system been set up for all documents?
Where will the file be located (e.g., online, paper copy, library)?
Who will have access to the file (e.g., to update, change for information only)?
For how long will the file be kept after project completion?
Who will keep it after project completion?
How will it be used?
Where will it be stored?

Managing Change

When will the plan baseline be frozen?
Who will make the decision to freeze the plan?
What will the decision to freeze it be based on?
What criteria define change (e.g., design, baseline, or schedule changes)?
Who will define the change management process we will use?
Who will maintain the change log?
Who will have change approval authority?
What documents will be presented for change approval?
How will we document approved plan changes?
How will we assess the impact of changes?
Who will set adaptive actions?
How will we track the effectiveness of these adaptive actions?
How will we decide whether to update the baseline plan?
How much deviation from the plan are we willing to accept before doing a total reschedule?
How will we link revision to the change management process?

Continuous Improvement/Project Assessment

Will a project assessment meeting be held?
Who will attend?
What subjects will be addressed?
How often during the project life will an assessment be done?
How will we document project assessment so others can learn from our experience?
What information should be kept to provide a historical basis for continuous improvement?
What is the release plan process for this project?
Is the product release part of this project?
Who owns the release plan?
When should the plan be fully defined?
Who has the authority to approve it?

2.3.4 Relationship Decisions to Be Tracked and Documented

Ownership

What departments will we need to interact with during the life of the project?
What are the roles and responsibilities of each organization (e.g., reviewer, approver, creator)?

Communication

How do we communicate among ourselves? With others outside the team?
How frequently do we need to communicate?
How will we keep people informed of deliverables, dates, changes, problem areas, and so on?
Are there specific communication milestones, dates, or intervals?
What information will or will not be exchanged?

Escalation

What process will we use to resolve disagreements?
What is the conflict resolution process?
What is the standard decision-making process?
What escalation process will we use for making decisions?
Who has final decision-making authority?
Who decides when to escalate a problem?

As you can see, this decision-making process is not a quick and easy task. The team must be encouraged to find solutions to these questions by relying on the resources of the SPMO. Many of the previously listed questions are answered by using processes that are defined within the SEP framework; however, it is very important for project success to have the Core Team take the necessary time to review all of these questions and decide among themselves how to handle each and every issue. In doing so, the team will begin to appreciate the sheer magnitude of the task, and its members will better understand the overall scope of the project to which they have been assigned. They will begin to understand that doing the job correctly it will take considerable time and effort. They should also understand that the SPMO is their first, best, and most reliable resource in going forward with a project.

2.3.5 Target Completion Notice (TCN)

The TCN is sent by the Project Manager to the Sponsor. This letter notifies the Sponsor of when the User Requirements Document (URD) is due to be completed by the Core Team and presented to the Sponsor. The selection of a target completion date, of course, should be a mutual exercise between the Project Manager and all of the Core Team members. A sample memorandum as follows displays exactly what the TCN should look like for the sample project with the code name Marvel.

 Memorandum of Record   March 29, 2003  From: Click here and type Project Manager's name To: <Click here and type all recipients by name> Subject: Marvel User Requirements Document Target Completion Notice   The User Requirements Document (URD) will be completely finished and delivered for sponsor sign-off on [Mar 29, 2003]. <Click here and type Project Manager's name> will serve as Project Manager of the project codenamed Marvel and will be responsible for ensuring that the URD is completed on time.   Sincerely,   ________________________________________________   Marvel Project Sponsor   CC: <Click here and type all involved department heads, listed by name>

< Day Day Up >