Control Mechanisms

1. Control Mechanisms

2. Agenda The project control process group Software reviews Software Metrics Earned Value Analysis

3. Project control The Fourth Process Group is activated from the beginning of the project. Continuous monitoring and control is required to ensure that all the planning is done properly, and nothing is left out. Checks and balances, metrics, standards, and benchmarks are required to be set and measured to ensure that only the promised work is performed, and delivered as per the customer�s specifications

4. Project Control Measure according to Project Management plans Measure according to performance baselines set during Planning processes. Determine variances from the plans Scope Verification � which means getting the customer to sign-off the individual items..

5. Project Control Configuration Management to check against the technical specifications Recommend changes, defect, preventative and corrective actions as required. Integrated Change Control process revisited Approve Changes, defect, preventative and corrective actions through the Change Control Board (CCB), and get them implemented

6. Project control Risk audits to ensure that every new and crucial risk is identified, planned and a risk mitigation strategy is created, with ownership. Manage Reserves � both management reserve and contingency reserves need to be managed. Issue Logs to track changes, problems, bugs, issues etc. are documented, and acted upon. Facilitate Conflict Resolution among the team members, stakeholders, and take continuous action to ensure any small issue does not become big unnecessarily.

7. Project Control Measure Performance against plans and take action. Report on Performance using performance reports, using various communication channels Forecasts for budget, timeline, scope, based on the current progress, and the rate of progress. Administer Contracts with Third Party vendors, contractors, and sub-contractors as desired and required.

8. Software reviews Inspections Walkthroughs Desk checks Code Reviews

9. Inspections An inspection is one of the most common sorts of review found in software projects. The goal of the inspection is for all of the inspectors to reach consensus on a work product and approve it for use in the project. Commonly inspected work products include software requirements specifications and test plans .. In an inspection, a defect is any part of the work product that will keep an inspector from approving it. For example, if the team is inspecting a software requirements specification, each defect will be text in the document which an inspector disagrees with.

10. Inspections In an inspection, a work product is selected for review and a team is gathered for an inspection meeting to review the work product. A moderator is chosen to moderate the meeting. Each inspector prepares for the meeting by reading the work product and noting each defect

11. Inspections Commonly inspected work products include software requirements specifications and test plans . In an inspection, a defect is any part of the work product that will keep an inspector from approving it. For example, if the team is inspecting a software requirements specification, each defect will be text in the document which an inspector disagrees with.

12. Walkthroughs A walkthrough is an informal way of presenting a technical document in a meeting. Unlike other kinds of reviews, the author runs the walkthrough: calling the meeting, inviting the reviewers, soliciting comments and ensuring that everyone present understands the work product. It typically does not follow a rigid procedure; rather, the author presents the work product to the audience in a manner that makes sense..

13. Walkthroughs Many walkthroughs present the document using a slide presentation, where each section of a work product is shown using a set of slides. Work products that are commonly reviewed using a walkthrough include design specifications and use cases Walkthroughs are used when the author of a work product needs to take into account the perspective of someone who does not have the technical expertise to review the document

14. Deskchecks �A deskcheck is a simple review in which the author of a work product distributes it to one or more reviewers. In a deskcheck, the author sends a copy of the work product to selected project team members. The team members read it, and then write up defects and comments to send back to the author.

15. Deskchecks Unlike an inspection, a deskcheck does not produce written logs which can be archived with the document for later reference. There is no follow-up meeting or approval process. It is simply a way for one team member to check another�s work.

16. Deskchecks Deskchecks are not formal reviews (where �formal� simply means that it generates a written work product which meets a certain standard and is archived with the rest of the project documentation); there is no standard for the results of the deskcheck. The reviewers simply review the work product and return the results. There is no moderator, and there is not necessarily any consensus generated

17. Deskcheck sample comments