|
Projects are the way
that most new work
gets delivered. All
projects have
certain
characteristics in
common. They all
have a beginning and
an end. In other
words, they do not
continue on forever.
Projects result in
the creation of one
or more deliverables.
Projects also have
assigned resources -
either full time,
part time or both.
There are other
characteristics as
well. All
organizations can
have projects.
Projects can include
building a house or
office building,
planning and
executing a
marketing campaign,
upgrading desktop
operating systems,
installing a new
phone system,
developing an IT
business application,
etc. |
Click here to
download the
LifecycleStep
Executive Summary. |
Projects can be managed
using a common set of
project management
processes. In fact, a
similar set of project
management processes can be
utilized regardless of the
type of project. All
projects should be defined
and planned and all projects
should manage scope, risk,
quality, status, etc.
Project management, however,
defines the overall
management and control
processes for the project.
Project management does not
actually result in the
project execution. At some
point, you still need to
define the actual activities
necessary to build the house,
execute the marketing
campaign, develop the IT
business application and
upgrade the desktop
operating systems. These
activities are referred to
as the project lifecycle and
the project lifecycle is the
focus of LifecycleStep.
The typical waterfall
lifecycle model is described
first in detail. The steps
are as follows:
|
 |
Analysis
Design
Construct
Test
Implement
|
Analysis
The Analysis Phase is where
the project lifecycle
begins. The only exception
is a situation where you
have broken a large project
down into smaller
components. In that case,
you may have an entire
project that is only focused
on the Analysis Phase, while
the next project may start
at the Design Phase. The
Analysis Phase is where you
break down the high-level
Project Definition into the
more detailed business
requirements. The Analysis
Phase is also the part of
the project where you
identify the overall
direction that the project
will take through the
creation of the project
strategy documents.
Gathering requirements is
the main attraction of the
Analysis Phase. The process
of gathering requirements is
usually more than simply
asking the users what they
need and writing their
answers down. Depending on
the complexity of the
application, the process for
gathering requirements has a
clearly defined process of
its own. This process
consists of a group of
repeatable processes that
utilize certain techniques
to capture, document,
communicate, and manage
requirements. This formal
process, which will be
developed in more detail,
consists of four basic
steps.
Design
The project team should have
a nice set of requirements
to work from, a set of
direction-setting strategies
and a Conceptual Systems
Design. There might be some
on the project team that
would say that this is
enough to start the
Construct Phase. However, it
is not. The design process
comes next. Even if the
project was small and the
requirements were simple,
there is still a mental
design process that occurs
in between understanding the
requirements and starting to
construct. Design becomes
more and more important as
the project becomes larger,
more complex and impacts
more and more people. Once
you complete the
requirements, you will
typically see a myriad of
alternatives for
construction. These
alternatives include the
tools and technology you
will you utilize, the
scalability of the solution,
and the structure of the
components you will build.
In essence, the Design Phase
is where you look at the
many potential solutions and
narrow down the choices to
determine the most effective
and efficient way to
construct the solution. The
Design Phase answers the
questions about "how" you
will build the best solution
for your organization and
your environment.
At the end of the Design
Phase, you will have a
logical solution defined.
The solution is "logical"
because it exists on paper
or in a design tool. This
logical solution is then
passed to the Construct
Phase, where the logical
solution is turned into a
physical solution. However,
the people that specialize
in constructing the solution
will not have to worry about
the myriad of possibilities.
That guidance will be
provided to them through the
work in the Design Phase.
The people working to
construct the solution can
use their talents to build
the solution based on the
deliverables produced during
the Design Phase.
Construct
Depending on your point of
view, the Construct Phase is
where the "rubber meets the
road". This is the point in
the project when we actually
start to construct the
solution. In an IT
development project this is
the time to start writing
program code. If you
followed the LifecycleStep
process so far, your
construct team has a lot of
guidance. They have a
complete set of design
specifications showing how
the application should be
structured and organized.
They have design
specifications for all
screens, reports and
programs. At this point,
then, the project manager
should be able to start
handing out the various
design specifications and
the construct team can start
to build the solution.
The Construct Phase is also
where we will create support
documentation such as a
Disaster Recovery Manual and
User's Manual. In essence
these documents are also
being "constructed" and so
the logical place to create
them is the Construction
Phase. Depending on the type
of document, the support
material can also be tested
in the Test Phase and then
executed or implemented in
the Implementation Phase.
Test
We test our
work for
two main
reasons. First, we want to
ensure that the solution
meets the business
requirements. For instance,
if a specific business
transaction follows a
logical path from A -> B ->
C -> D, we want our testing
to prove that this, in fact,
happens. Second, we test to
catch errors and defects.
These may be programming
errors, or errors that were
introduced earlier in the
development lifecycle. In
other words, we need to
prove that our solution is
correct, while at the same
time proving that there are
no errors or defects. You
may not catch many errors,
but you still need to prove
that the solution meets the
business requirements.
|
 |
Regardless of the
type of project you
are on, you want to
catch as many errors
as early in the
lifecycle as
possible. There are
projects that
purposely blast
through the analysis,
design and coding
phases with a
philosophy that they
will fix all the
problems in testing.
This is usually
disastrous. It’s not
so bad to correct
programming errors
that you discover in
your testing. It is
much more difficult
when you realize
that a design error
resulted in
information missing
from your database.
It is even harder if
you discover that
your analysis missed
an entire business
process. At the same
time, you cannot
ensure that your
software is perfect. |
Even with the best tools, it
is impossible to test every
logic path of every program.
Therefore, you cannot ever
be sure that your code is
bug-free. There are times
when software that has been
stable for ten years
suddenly breaks through an
unlikely combination of
circumstances that never
occurred before. (These are
“subtle” bugs.)
Implement
Implementation refers to the
final process of moving the
solution from development
status to production status.
Depending on your project,
this process is often called
deployment, go-live, rollout
and installation. For the
purpose of LifecycleStep,
all of these terms are
synonymous with "implementation".
There is no single way to
implement an application. It
depends on the
characteristics of your
project and the solution.
Some implementations are as
easy as saying “we are now
live.” This type of
implementation can work when
the solution is brand new
and you are developing and
testing in what will become
the production environment.
In these cases,
implementation is just a
state of mind. One day the
solution is in development
and the next day it is in
production. What could be
easier?
When we think about
implementation, we should
always start by
understanding the level of
complexity involved. If the
implementation is relatively
straightforward, then there
is no reason for elaborate
implementation processes.
However, most projects have
a number of implementation
events to plan for and
execute successfully.
Other Lifecycle Models
In addition to the classic
waterfall model described
above, LifecycleStep also
describes other popular
lifecycle models, including
Rapid Application
Development, enhancements,
Agile and Research and
Development. Although the
waterfall model can be used
on all projects, other
models may be more effective
given the nature of the
project and your
organizational environment.
