During the project initiation phase, a project charter can help facilitate the initialization process.
In the past, we have been asked to write such document and schedule the review with the stakeholders, before we kick off a project.
It describes what a project looks like and what resources needed, and how big the project will be. It identifies the interim or final deliverables expected from the project.
I feel that this process is still important. It is kind of like writing a contract. People need to agree with the term and conditions before start working on the project.
For the internal software development projects, the quantified dollar values and the costs may not need to be tracked, but it is still helpful to write down the resource requirements and the business values the project may produce so people know why we do a project.
The system we are using for tracking the software projects can be used for tracking the project initiation as well.
Here are the information we need to enter:
Project Name
Brief Description
Assigned to - This is default to the person who creates the project
Path - this describes a hierarchical structure that can organize the projects
Lifecycle - Here are the possible values:
Product Line - This is unique for software development for prepackage applications
Release - This is also unique for software development
This is very useful as release management uses this field as the main filter for tracking the projects
Release Priority - This should be useful for planning but we do not really use it.
Team - This may be a good filter for organizing the projects. So far I do not see any use
Wiki Page Link - It is a good idea to track project also in the wiki site
Search tag - This is also useful to accept the free form text to track additional information.
For example, we use this to track who are the main consumers and what is the sub product component categories that cannot be tracked under the Product Line field
Stakeholders - We can add the users who may receive the notifications when any of the project information changes.
Activities
The system assumes that each software development project follows the same processes and have the same high level lifecycle activities:
I like that the concept of listing the review as a separate activity. It helps formalize the review process.
Activity Owner - Each activity is assigned to a owner, who will be automatically assigned as a stakeholder.
Activity Target Date - Enter an estimate date
Activity Status - This is really only used in the project tracking. It is beyond the initialization phase.
Other information should be provided as part of project charter:
Justifications -
We should describe why we need to do this project and what may happen if we do not do it.
Resource Requirements and their responsibility
Resources should not need to be assigned to the above lifecycle activities. Those are milestones for project tracking. During project initiation phase, a named person or the roles are required. The participation level (percentage of time, start/end date) may help
Deliverables - Deliverables may be different activities.
Limitations - What are out of the scope. This is for clarifying the scope
Assumptions - What are given and if they are not true, the content cannot be committed.
In the past, we have been asked to write such document and schedule the review with the stakeholders, before we kick off a project.
It describes what a project looks like and what resources needed, and how big the project will be. It identifies the interim or final deliverables expected from the project.
I feel that this process is still important. It is kind of like writing a contract. People need to agree with the term and conditions before start working on the project.
For the internal software development projects, the quantified dollar values and the costs may not need to be tracked, but it is still helpful to write down the resource requirements and the business values the project may produce so people know why we do a project.
The system we are using for tracking the software projects can be used for tracking the project initiation as well.
Here are the information we need to enter:
Project Name
Brief Description
Assigned to - This is default to the person who creates the project
Path - this describes a hierarchical structure that can organize the projects
Lifecycle - Here are the possible values:
- Unknown
- Candidate
- Duplicate Requirement
- Will Not Do (Rejected)
- Deferred
- Implemented
Product Line - This is unique for software development for prepackage applications
Release - This is also unique for software development
This is very useful as release management uses this field as the main filter for tracking the projects
Release Priority - This should be useful for planning but we do not really use it.
Team - This may be a good filter for organizing the projects. So far I do not see any use
Wiki Page Link - It is a good idea to track project also in the wiki site
Search tag - This is also useful to accept the free form text to track additional information.
For example, we use this to track who are the main consumers and what is the sub product component categories that cannot be tracked under the Product Line field
Stakeholders - We can add the users who may receive the notifications when any of the project information changes.
Activities
The system assumes that each software development project follows the same processes and have the same high level lifecycle activities:
- Requirement Definition
- Functional/Technical Specification
- QA Review of the specification
- Development / Programming
- Sign Off
- DHQA
- Testing Specification Development
- Development Review of Testing Spec
- QA Test Execution
- Documentation Specification/Plan
- Documentation (Writing)
I like that the concept of listing the review as a separate activity. It helps formalize the review process.
Activity Owner - Each activity is assigned to a owner, who will be automatically assigned as a stakeholder.
Activity Target Date - Enter an estimate date
Activity Status - This is really only used in the project tracking. It is beyond the initialization phase.
- N/A
- Will Not Do
- Required
- Approved
- Rejected
- In Progress
- Complete
Other information should be provided as part of project charter:
Justifications -
We should describe why we need to do this project and what may happen if we do not do it.
Resource Requirements and their responsibility
Resources should not need to be assigned to the above lifecycle activities. Those are milestones for project tracking. During project initiation phase, a named person or the roles are required. The participation level (percentage of time, start/end date) may help
Deliverables - Deliverables may be different activities.
Limitations - What are out of the scope. This is for clarifying the scope
Assumptions - What are given and if they are not true, the content cannot be committed.
No comments:
Post a Comment