Best Practices for Software Projects - Design Signoffs
 
  May 2004 - Pragmatic Software Newsletters 
 
 
Best Practices for Software Projects - Design Signoffs
This year's newsletters will focus on best practices for Software Development Projects.  Each month will cover a different best practice technique.  This month focuses on improving project management with the use of design signoffs.

 

Newsletter Sponsored by Software Planner

http://www.SoftwarePlanner.com
Sign up for a free 2 week trial and you are entered to win a
FREE HP Pocket PC

Software Planner (http://www.SoftwarePlanner.com) helps improve the quality of software releases and decrease software maintenance costs by providing you with tools for managing all phases of the software lifecycle. Software Planner tracks customer requirements, test cases, defects, support tickets, appointments and to-do lists, and allows you to share documents and hold threaded discussions.  Fully web-based and integrated with email.
 

Best Practices for Software Projects - Design Signoffs

Ever worked on a project where the requirements were scribbled on a napkin and you were asked how quickly you could get the project done?  First time project managers sometimes fall into this trap, and it is a recipe for disaster. 

To consistently deliver software solutions on-time and on-budget, you must follow a disciplined approach to managing the project.  The only way to adequately determine the project timeline is to fully understand all deliverables of a project, to manage risk with risk mitigation, and to obtain signoffs along the way so that you have documented accountability.

Here is a simplified overview of how a software project should be run to ensure on-time and on-budget delivery.  Notice that each phase requires sign-off from various project members to ensure a quality release.

  1. Planning Phase - This is where you collect requirements from the client and agree to the requirements.  Upon completion of this phase, your client should physically sign the Functional Specifications document agreeing to the requirements of the project.   Also at the end of this phase, it is wise to perform risk assessment to budget time for risks that may arise in the upcoming software lifecycle phases.
  2. Design Phase - Once you have a signed Functional Specifications document, your technical team should provide a design for each requirement.  Designs should be done for coding, testing, customer support, and documentation.  The designs should be reviewed with team members to ensure that the design fully meets the objectives of the requirements document and each functional specification should be matched to the design to ensure all items have been covered.  Upon completion of the Design Phase, your project manager and technical team should sign off on the detailed design, your project manager and test team should sign off on the master test plan, and your project manager and support team should signoff on the design for support procedures and documentation.  Once this is done, the project manager can create a timeline based on the estimates from the design process.  The project manager can divide requirements into "iterations" as to allow the team to more quickly deliver the project in stages and to lessen the risk of the overall project.
  3. Iterative Code/Test Phase - Once coding and quality assurance testing is complete, the testing team should develop documents that describe the User Acceptance testing phase.  This document should be reviewed with the users and signed off by both the users and the testing team.  This sets the rules and procedures for User Acceptance testing and outlines the requirements for a successful User Acceptance testing phase and the criteria for moving the software to production.
  4. Production Phase - Before moving the code to production, the Project Manager, Quality Assurance and User Acceptance team should sign off on the release, allowing it to be moved to production.  That indicates that the release is production ready.
  5. Post Mortem Phase - After a month of production, post mortem meetings should be held to highlight the things that were done well and the things that went wrong in the project.  Upon completion of this phase, the Project Manager, Development Lead, Test Lead and User Acceptance Lead should sign off the Post Mortem documentation.  This documentation aids future teams, allowing them to learn from the things done well and learn to avoid common mistakes.

The easiest way to begin delivering software on-time and on-budget is to follow a disciplined approach to project management.  Below are some helpful templates to aid you in this, notice that each document has a section for signoffs, providing accountability every step of the way.

About the Author
Steve Miller is the President of Pragmatic Software (http://www.PragmaticSW.com).  With over 20 years of experience, Steve has extensive knowledge in project management, software architecture and test design. Steve publishes a monthly newsletter for companies that design and develop software.  You can read other newsletters at http://www.PragmaticSW.com/Newsletters.htm.  Steve's email is
steve.miller@PragmaticSW.com.


 

Pragmatic Software Co., Inc.
383 Inverness Parkway
Suite 280
Englewood, CO 80112

 

Phone: 303.768.7480
Fax: 303.768.7481
Web site:
http://www.PragmaticSW.com
E-mail:
info@PragmaticSW.com