Software Project Survival Guide

1: Welcome to Software Project Survival Training
  • The project team’s survival needs are being met.
  • The customer and the project team agree to respect each other’s software project rights.
    • The agreement in principle is not followed in practice.
     
2: Software Project Survival Test
  • The project scores at least 60 on the Survival Test.
  • The project scores less than 60, but corrective actions are planned to improve its score.
    • The project team doesn’t follow through on the planned corrective actions.
     
3: Survival Concepts
  • Project leadership understands the critical role of well-defined processes and supports them.
  • The project’s processes are generally oriented toward detecting as many problems upstream as possible.
  • Project leadership recognizes that estimates made during the first half of the project are inherently imprecise and will need to be refined as the project progresses.
4: Survival Skills
  • The project team creates a detailed written plan designed to eliminate potentially costly problems early in the project.
  • The project emphasizes the importance of upstream work by holding Planning Checkpoint Review and making a go/no go decision when the project is about 10 percent complete.
  • The project practices active risk management.
  • Project plans emphasize visibility and control.
  • The project plan involves real users early and throughout the project.
  • The project is conducted in a productive environment, or the project plans assume lower productivity.
  • Project plans call for a simple-to-complex approach rather than the reverse.
5: The Successful Project at a Glance
  • The project uses a staged delivery approach.
  • Upper management, the customer, or both track progress by following the code growth curve.
  • Upper management, the customer, or both track progress by keeping tabs on major milestones and deliverables.
6: Hitting a Moving Target
  • The project has a change board.
    • The change board’s decisions can be reversed by management, marketing, or the customer.
     
  • The project has a written, approved Change Control Plan.
    • Project team members aren’t given enough time to carry out the plan.
    • Work products aren’t actually put under change control.
     
  • Change Proposals are evaluated by all the project’s concerned parties before they are resolved.
  • The change board notifies the project’s concerned parties of how each Change Proposal is resolved.
  • The change board has the project team evaluate changes in batches so that the team is not distracted by a constant barrage of change requests.
7: Preliminary Planning
  • Project has a clear vision.
    • Vision doesn’t provide guidance in deciding what to leave out of the software.
     
  • Project has identified an executive sponsor or committee with final authority over project-wide decisions.
  • The project plans and progress according to plan are readily available to all project team members and upper management.
  • Project has appointed a risk officer.
    • Risk officer is the project manager.
     
  • Project has a Top 10 Risks List.
    • The Top 10 Risks List is not kept up to date.
     
  • Project develops risk management plans for each risk on the top 10 list.
  • Project hires well-qualified people, waiting if necessary, rather than just hiring whoever is available first.
  • Project time accounting is begun before requirements development begins.
  • All of the above considerations are formalized in a Software Development Plan.
    • The Software Development Plan isn’t placed under change control.
    • The plan described in the Software Development Plan isn’t actually followed by the development team.
     
8: Requirements Development
  • The project team identifies a set of key end users who can be trusted to shape the software.
  • The developers create several versions of a basic prototype until they find one that the users are excited about.
    • Prototyping stops while users are still only lukewarm about the prototype.
     
  • The developers extend the user interface prototype to elicit detailed requirements from users.
    • The prototype is not kept broad and shallow, and time is wasted providing deep functionality that will be rewritten for the final software.
     
  • The project team develops a User Manual/Spec to use as the detailed requirements specification.
  • The fully developed prototype is baselined and placed under change control.
    • The project team attempts to use the prototype code in the real software.
     
  • A separate, non user interface requirements document is created, reviewed, and placed under change control.
9: Quality Assurance
  • Project has a written, approved Quality Assurance Plan.
    • Project isn’t following the written plan.
     
  • Quality assurance is initiated in parallel with requirements work.
  • Defect tracking software is placed online at requirements development time, and defects are tracked from the beginning of the project.
  • Developers review all designs and code before they are considered to be "done."
    • No designs or code have failed their reviews, suggesting that reviews are superficial.
    • Developers don’t source trace and unit test their own source code prior to submitting it for review, which gives rise to an unwieldy number of defects that have to be tracked from reviews onward.
     
  • The Quality Assurance Plan calls for an independent quality assurance group.
    • No funding is available for an independent quality assurance group.
     
  • The Quality Assurance Plan contains measurable criteria to be used to determine whether the software is ready to be released.
10: Architecture
  • The architecture team creates a Software Architecture document.
    • The Software Architecture document has not been placed under change control.
    • The Software Architecture document has not been updated to reflect changes arising during design and construction and no longer accurately describes the program.
    • Developers don’t observe the project’s architecture.
     
  • The architecture emphasizes simplicity over cleverness.
  • The architecture supports the Staged Delivery Plan.
  • The architecture addresses all the project’s requirements, and requirements coverage is documented with a completed requirements traceability matrix.
11: Final Preparations
  • The project team creates its first estimate after preliminary requirements development is complete.
    • Estimates do not account for normal activities such as holidays, weekends, and vacations.
    • Developers don’t believe the estimates are realistic.
     
  • Estimates are updated after detailed requirements development and again after architectural design.
  • The project has a Staged Delivery Plan that organizes the stages into theme releases.
    • The stages are not defined in detail.
     
  • The project’s vision, risk management, decision making, and personnel plans are up to date.
  • The project’s Software Development Plan is up to date and being followed.
12: Beginning-of-Stage Planning
  • Planning is conducted at the beginning of each stage for that stage’s activities.
  • Stage planning includes requirements review, detailed design, coding and code reviews, test case creation, user documentation updates, in-stage defect correction, technical coordination, integration and release, risk management, project tracking, and other important activities.
  • The project team creates a set of miniature milestones to aid in tracking progress throughout the stage.
    • The list of miniature milestones does not include all activities.
    • The project is not actually tracked against the list of miniature milestones
     
  • The project manager adopts a hands-on approach to the project itself.
13: Detailed Design
  • The project team creates Detailed Design Documents for each subsystem, which drive the architectural considerations down to a detailed level, and puts them under change control.
    • The detailed designs aren’t reviewed or are reviewed superficially.
    • The Detailed Design Documents don’t address requirements traceability.
     
  • The degree of formality of the detailed design work seems well-suited to the size of the project and expertise of the developers.
    • Degree of formality in detailed design work errs on the side of too little formality rather than too much.
     
  • Detailed design reviews focus on finding functional defects, requirements mismatches, and ways in which the project’s objectives can be satisfied better.
  • Detailed design during the first stage of the project explores potential problems with the architecture.
14: Construction
  • The project has a Coding Standard.
  • The coding standard is enforced through technical reviews of all code.
  • The project has a Software Integration Procedure.
    • Developers aren’t following the procedure.
     
  • The project team builds a skeleton of the system during Stage 1.
    • The project team gets bogged down building the complete infrastructure of the system before building any visible functionality.
     
  • The project uses daily builds and smoke tests.
    • The daily build is broken more often than not.
    • The smoke test hasn’t kept up with the daily build and doesn’t test the software’s full functionality.
     
  • The project manager tracks relevant progress indicators weekly, including miniature milestones, defects, change reports, time-accounting data, and Top 10 Risks list.
  • Project status data is readily available to all project members.
    • Status isn’t reported regularly to customers or upper management.
     
  • Changes are controlled through continuing use of the change control board.
    • The change control board wasn’t set up until construction began, limiting its perceived authority.
     
15: System Testing
  • System testing is ready to go at the same time as construction.
  • Testers smoke test the daily build and return the build to development if it fails.
    • The build often fails the smoke test because developers are not unit testing their own code adequately.
    • Developers don’t fix defects quickly after they are reported.
     
  • Testing identifies "error prone routines" for developers to review and redesign or reimplement.
16: Software Release
  • The project team treats the end-of-stage release phase as its top priority.
  • Statistical techniques are used to aid the release decision.
    • Only one statistical technique is used.
     
  • The project team uses a release checklist to prevent oversights during software release.
  • The project team uses a release sign-off form to ensure that all project stakeholders agree the software is ready to release.
17: End-of-Stage Wrap-Up
  • The project team defers feature change requests until the end of each stage.
    • Project also defers defect corrections until end of stage.
     
  • The project team reestimates effort, schedule, and cost at the end of each stage.
    • Reestimation assumes the estimation error will be added to end of schedule rather than multiplied across the entire schedule.
    • Reestimation is perceived as a "slip" instead of an "estimate" because stakeholders weren’t educated about reestimation at the beginning of the project.
     
  • The project manager records project status in the Software Project Log at the end of each stage.
18: Project History
  • Project creates a written Software Project History that contains both objective and subjective summary information about the project.
    • The Software Project History isn’t created within 15-30 days of project completion.
     
  • The completed Software Project History is distributed to all project members.
  • Project History results are packaged into a project planning checklist and an initial risks list for use on the next project.