Deliverables:
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!
Convenience:
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.
Applicability:
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.
Concurrency:
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