Project Management Office
The following references document templates developed and used by Torix Corporation over the past 25 years for use in its Information Technology projects. They are based on an older set of IEEE software engineering standards. Torix prefers these templates over newer standards for several reasons:
- Standards have been changing so rapidly in recent years that they have become a growth industry in themselves. How can a standard that changes every 2 or 3 years remain "standard"? How can such a mercurial "standard" be applied uniformly across an industry?
- Project documentation has become increasingly complex and automated, requiring increased personnel specialization and elevating project resource costs.
- Automated tools require an investment in software, servers and training, in addition to personnel, which limits software development to well-capitalized companies and excludes market competition by small and midsize businesses.
- There is a tendency in current IT practice to create work products as "shelfware" for the sole purpose of meeting project audit requirements, rather than using these documents as effective management tools for the successful execution and conclusion of software projects.
These factors detract from holistic and responsive project management practice that must create quality software systems and products in short periods of time. So, these templates allow software project managers to get up to speed quickly, but also force them to grapple with real issues and decisions that should prevent expensive rework. Torix Corporation uses these tools in its software projects.
Consulting services involving the following areas are provided on time and materials basis at the quoted rate plus actual expenses. A mutual nondisclosure agreement is executed preliminary to any consulting engagement. Torix Nondisclosure Agreement
The project charter is the first document in any new project. It identifies what the project is, who commissioned it, who will pay for it, and the expected result. It should also set schedule and cost limits. It should be only one page in length, but otherwise has no set form. Save the finished document in a safe place, because it will be referenced later. For more information refer to: Project Charter Template
This is an "infinitely" more detailed version of the project charter. That is, this document should specify the expected results of the project, and the inputs on which those results should be based. Requirements are often couched in terms of "the product must do ____", or the service needs to ____". The best requirement statement is written as a simple sentence that expresses one specific function that needs to be performed by the software, based on a given input set. Sometimes the requirements definition process can be subdivided into Business Requirements and Technical Requirements, although the technical requirements are usually irrelevant from the business perspective. When statutory law is encoded to software, however, they are exactly the same.The requirements document(s) are the basis for project scope definition and control. For more information please refer to: Project Requirements Template
Project Management Plan
Stating a plan for managing your project is a simple and effective way to ensure that measures are taken and documented to keep the project participants "on task". All project stakeholders should have a copy. For more information refer to: Project Management Plan Template
Quality Assurance Plan
A Quality Assurance Plan is a part of the Project Management Plan. It specifies the goals, in general (but binding) terms, of outcomes expected for quality of both the project's end product and the quality controls over the processes that result in that end product. For more information you may refer to: Quality Assurance Plan Template
Software Configuration Management Plan
A Software Configuration Management (SCM) Plan is also a part of the Project Management Plan, although in many projects it may make more sense to place it within the Quality Assurance Plan because SCM is necessary for producing tested software releases. Automation is essential because there usually are many configuration items to track. However, I prefer to use simple, public-domain tools such as cvs backed up by a solid change management methodology. For more information you may refer to: Software Configuration Management Plan Template
Test Planning and Management
Testing is absolutely essential before putting any software into production. In my opinion, however, the focus on automated software testing is overblown, and testing phases can easily consume over 60% of software project costs. A far better approach seems to be to concentrate on a few good tests designed around function point analysis. Under this "black box" approach, components that pass high level functional and load tests at high need not be tested further. Regression testing is reserved for failing components when they are fixed. This iconoclastic view doesn't win me many software testing contracts, but software produced by Torix Corporation meets high functional quality standards.
A Test Plan is part of the Quality Assurance Plan, and may also be linked directly to the SCM Plan. There are several interrelated documents that are needed to prepare a complete test plan. Because there are so many, they might benefit from some simple automation. It is more important to understand how these documents are interrelated by a coherent and integrated testing process cycle. Commercial products I've used do not adhere to the IEEE Std 829-1983 standard employed by these templates, however. For more information you may refer to: Test Plan Template
The Test Design integrates the Test Procedure and Test Case documents. For more information you may refer to: Test Design Template
Test procedures are specified for each test that must be performed. The procedure specifies automated test scripts that are created to exercise the test cases. For more information you may refer to: Test Procedure Specification Template
A test case is specified for each variation of the test procedure. If possible, I prefer to write only one test specification document for each test procedure, specifying all the inputs and corresponding outputs for a successful test. For more information you may refer to: Test Case Specification Template
A test log is kept for each test procedure, indicating the results of the procedure run for each test case. Test logs should be automated to capture the results of automated test scripts. For more information you may refer to: Test Log Template
A test incident report is prepared for each failure noted in the test log. For more information you may refer to: Test Incident Report Template