Project Management Workbook is a generic tool for a project manager in order to reflect the project status quantitatively at any point of time in the SDLC in terms of:
Identification of Configuration Controller: Configuration Controller (CC) can be identified for the project by PM during the Kick off meeting or while requesting for the resource allocation. CC along with PM / PL shall be responsible for maintaining the Process Database according to the library structure defined by SQA, Process Database Management Process for the Library Structure creation. The library structure created by CC shall be documented in the Project Library Structure and Access Control. CC of the project will update the Process Database after the approval of the work product.
Below is a sample checklist for Release Readiness Review and Pre Delivery Audit. It is useful both for Project Managers and Software Quality Analysts.
The purpose of the WBS, as a project management tool, is to organize the scope of a project. WBS definition for programs and portfolios can use similar techniques to organize scope. There are many project management tools that use the WBS or its components as input:
Project Charter: The WBS takes the project charter as its starting point. The highest level element in the WBS should represent the project’s overall end-point product(s), service(s), or outcomes as described in the project charter. If the project’s major products cannot be described during the creation of the WBS, then the project management team should examine the charter to determine if it has been sufficiently defined.
Metrics collection is an excellent way track the project, measure the performance. Software metrics provides objective information to help the project managers to do:
Project risk control and risk monitoring is where you keep track of about how your risk responses are performing against the plan as well as the place where new risks to the project are managed.
You must remember that risks can have negative and positive impacts. Positive risk is a risk taken by the project because its potential benefits outweigh the traditional approach and a negative risk is one that could negatively influence the cost of the project or its schedule.
Different Software Development models have different features and properties. Selection of the software development model depends on the nature of project and client. Here, I will try to give a comparison of various software development models with three parameters:
1. Contribution to Quality
2. Risks Associated
3. Context of adoption
Model Name: Waterfall Model
Contribution to Quality: Phase End Checks
Risks Associated: Expects a task to be well done in the first go
Context of adoption: When the requirements are structured and competence is high
Below is a sample configuration audit checklist (for FCA and PCA). The Project Managers can use the following checklist as a reference for the readiness of the audit or even for doing the audit.
Qualitative Risk Analysis is a measure of risk or asset value based on a ranking or separation into descriptive categories such as low, medium, high; not important, important, very important etc. or on a scale from 1 to 5.
Qualitative Risk Analysis includes methods for prioritizing the identified risks for further action, such as Quantitative Risk Analysis or Risk Response Planning. Organizations can improve the project’s performance effectively by focusing on high-priority risks. Qualitative Risk Analysis assesses the priority of identified risks using their probability of occurring, the corresponding impact on project objectives if the risks do occur, as well as other factors such as the time frame and risk tolerance of the project constraints of cost, schedule, scope, and quality.
Risk Identification is the process of determining which risks might affect the project and documents their characteristics. Participants of risk identification activities: project manager, project team members, risk management team (if identified), subject matter experts from outside the project team, customers, end users, other project managers, stakeholders, and risk management experts. While these personnel are often key participants for risk identification, all project personnel should be encouraged to identify risks.