Each of the phases in the Project Life Cycle is accompanied by a "deliverable", which is just a document or product, program, etc. Deliverables are EXTREMELY important to your project... they're what you're paid for! Never simply give an oral report. Not only do deliverables document your progress, but they demonstrate your organizational skills and your professionalism, and in some cases the deliverable actually doubles as a contract. For instance, the Business System Design promises a system of a specified configuration and capability... add signature lines for you and your client and you have a legal contract which not only obligates you to deliver, but protects you from scope creep (a term which describes the little changes that tend to sneak into a project after the specification and can add up to major cost and time overruns.)
Dealing with Scope Creep:
While we're speaking of scope creep, I can't stress enough that you should take steps to discourage it. Don't actually curtail it, as it can actually be a source of revenue! The best technique is to include a clause in your Business System Design stipulating that any change to the specification, once accepted by the client, will result in a delay of the deliverable date and additional cost to the client. Specify a minimum delay and cost. Each time a change is requested by the client remind them of the agreement, but remember that customer relations are important, too! If a change is small enough and you can reasonably include it without major impact, waive the cost. Record all changes in addenda to the specifications!
The number one complaint I've heard about any methodology is that it's inconvenient. Wel, it is, but only until you're used to it; and even early on the benefits far outweigh the inconvenience. Use it as you would a seatbelt.
This same methodology can be used to manage just about any project you want. My son has even used it to manage his fourth grade science project! Just remember that the methodology does not control you... it's a tool to assist you. Feel free to modify it if a specific project has unique management requirements. As an example of the flexibility of the basic methodology, I'll use the analogy of constructing a house in the links to the various phases. I'll place the examples in shaded boxes at the end of each page.
Just because the phases of the Project Life Cycle are laid out in a certain order, don't think that they have to be performed in exactly that sequence. In fact, that would be wasteful and expensive! Some tasks can and should be done concurrently. For example, the Quality Assurance team can prepare test scripts at the same time that the development team is creating the system. Since both teams are working from the same detailed spec, such an arrangement serves to see how closely the development team followed the specification. A multi-person development team can write different portions of the application simultaneously. If you examine your project you'll find many opportunities for concurrency. Some are listed in the swim lane diagram.
The Importance of Revision Control:
Revision Control Systems (RCS) are not just for software!!! These packages are designed to track revisions of any type, not just source code changes. Take advantage of them to store revisions to the specifications or any of the deliverable documents, contracts, etc. This way, if the specification changes you never lose the original. If you don't effectively manage revisions you are sure to be hit by a contract dispute at some point. There is no excuse for not using an RCS, as many good ones are available... Microsoft Sourcesafe is a great choice if you're using any of Microsoft's Visual programming languages. MKS RCS is more document-oriented, and PVCS is a market leader. In addition, many free or shareware RCS packages exist. The revision control system I use (descriptively enough called "RCS") is available for free for both DOS and Linux platforms. You can find it at Shareware.com. Here's some documentation so you can get a feel for it.
Learn the UML Phase 1. Identify a Need