Project Breathalyzer

The Project Breathalyzer provides questions for the Program Manager to assess of the project is?fit to be on the road. If the Program Manager cannot answer these questions about the current status, or answers in the?negative, then the project is subject to a critical review.

This concept comes from the Software Program Managers Network and the work of Norm Brown in 1997.

The questions came from the Airlie Software Council of experts after the failure of the?Airane?5 launch vehicle failure?attributed to a Software Design Flaw.

1.???Do you have a current, credible activity network supported by a Work Breakdown Structure?

• Have you identified your critical path items?
• What explicit provisions have you made for work that isn’t on your WBS?
• Does the activity network clearly organize, define, and graphically display the work to be accomplished?
• Does the top–level activity network graphically define the project from start to finish, including all the dependencies?
• Does the lowest–level WBS show work packages with measurable tasks and short duration?
• Are project objectives fully supported by the lower–level objectives?
• Does each task on the network have a well–defined deliverable?
• Is each work package under budget control (expressed in labor hours, dollars, other numerical units)?

2.???Do you have a current, credible schedule and budget?

• Is the schedule based on a project/activity network supported with a WBS?
• Is the schedule based on realistic historical, quantitative performance estimates?
• Does the schedule provide time for holidays, vacations, sick days, etc.?
• Does the schedule allow for all the necessary quality assurance activities?
• Does the schedule account for resource overlap?
• Is the schedule for the next three to six months as detailed as possible?
• Is the schedule consistently updated at all levels in the Gantt, PERT, and Critical Path views?
• Is the budget clearly based on the schedule and required resources over time?
• Can you perform to the schedule and budget?

3.???Do you know what software you are responsible for delivering?

• Are the system’s operational requirements clearly specified?
• Are definitions of what the software must do to support the system's operational requirements clearly specified?
• Are system interfaces clearly specified and, if appropriate, prototyped?
• Is the selection of the software architecture and design method traceable to system operational characteristics?
• Are descriptions of the system environment and relationships of software applications to the system architecture clearly specified?
• Are specific development requirements explicitly defined?
• Are specific acceptance and delivery requirements explicitly defined?
• Are user requirements agreed to by joint teams of developers and users?
• Are system requirements traceable through the software design?

4.???Can you list the current top ten project risks?

• Has a Risk Management role been assigned to the project?
• Are risks determined through established processes for risk identification, assessment, and mitigation?
• Is there a database that includes all non–negligible risks in terms of probability, earliest expected visible symptom, estimated and actual schedule, and cost effects?
• Are all project personnel encouraged to become risk identifiers?
• Are correction plans written, followed up, and reported?
• Is the database to the top–ten risk list updated regularly?
• Are transfers of all deliverables controlled?
• Are user requirements reasonably stable?
• Do you know how the risks changing overtime?

5. Do you know your schedule compression percentage?

• Has the schedule been constructed bottom-up from quantitative estimates, not by predetermined dates?
• Has the schedule been modified when major modifications in the software have taken place?
• Have programmers and test personnel received training in the principle domain area, support software, and tools?
• Have detailed unit–level and interface design specifications been created for maximum parallel programmer effort?
• Does the project avoid extreme dependence on specific individuals?
• Are people working abnormal hours?
• Do you know the historical schedule compression percentage on similar projects and the results of those projects?
• Is any part of the schedule compression based on the use of new technologies?
• Has the percentage of software functionality been decreased in proportion to the percentage of schedule compression?

6. What is the estimated size of your software deliverable(s)?

• Has the project scope been clearly established?
• Were measurements from previous projects used as a basis for size estimates?
• Were Source Lines of Code (SLOC) used as a basis for the estimates?
• Were Function Points (FPs) used as a basis for estimates?
• Are the developers who do the estimating experienced in the domain area?
• Were estimates of project size corroborated by an estimate verification tool?
• Are estimates regularly updated to reflect software development realities?

7. Do you know the percentage of external interfaces that are not under your control?

• Has each external interface been identified?
• Have critical dependencies of each external interface been documented?
• Has each external interface been ranked based on potential project impact?
• Have procedures been established to monitor external interfaces until the risk is eliminated or substantially reduced?
• Have agreements with the external interface controlling organizations been reached and documented?

8. Does your staff have sufficient expertise in the project domains?

• Do you know what the user needs, wants, and expects?
• Does the staffing plan include a list of the key expertise areas and estimated number of personnel needed?
• Do most of the project staff have experience with the specific type of system being developed?
• Do most of the project staff have extensive experience in the software language to be used?
• Are the developers able to proceed without undue requests for additional time and cost to help resolve technical problems?
• Do the developers understand their project role and are they committed to its success?
• Are the developers knowledgeable in domain engineering – the process of choosing the best model for the project and using it throughout design, code, and test?
• Is there a domain area expert assigned to each domain?

9. Have you identified adequate staff to allocate to the scheduled tasks at the right time?

• Do you have sufficient staff to support the tasks identified in the activity network?
• Is the staffing plan based on historical data of the level of effort or staff months on similar projects?
• Do you have adequate staffing for the current tasks and all the tasks scheduled to occur in the next two months?
• Have alternative staff buildup approaches been planned?
• Does the staff buildup rate match the rate at which the project leaders identify unsolved problems?
• Is there sufficient range and coverage of skills in the project?
• Is there adequate time allocated for staff vacations, sick leave, training, and education?
• Are staffing plans regularly updated to reflect reality?