|
|
402.0 Assumptions |
|
This page describes some
assumptions that were made
that will put the
LifecycleStep process into
better perspective.
-
The methodology is
written with the project
manager and project team
as the intended audience.
In many cases, the names
'project manager', 'analyst',
'designer', etc are
specifically mentioned.
In other cases, the
content may say 'you' or
'your'. The assumption
is that 'you' (the
reader) are the project
manager or a team member.
-
A set of generics roles
is defined in
LifecycleStep including
"project manager", "analyst",
"designer", etc. However,
the exact title and
roles in your company
may well be different.
-
LifecycleStep refers to
specialist roles in many
section of the process.
For instance, different
sections refer to the
role of "analyst",
"designer",
"programmer", "test
team", etc. However,
these roles do not imply
that different people
are necessarily
involved. On many
projects, for instance,
the roles of analyst and
designer are performed
by the same people. In
fact, the same group of
core people may well be
involved throughout the
lifecycle, each of whom
is performing all of the
project roles as the
project progresses.
-
LifecycleStep
refers to the
deliverables of
the project with
the generic name
of "solution."
That is, all
projects exist
to create a
solution.
Depending on the
project, the
actual
deliverables
could be
hardware,
software, a
bridge,
marketing
campaign, etc.
However,
LifecycleStep
refers to all of
these with the
generic name of
"solution".
|
 |
-
LifecycleStep refers to
the people that request
the project as "clients".
In some companies, these
people have different
names such as "customers"
or "the public". However,
LifecycleStep
generically refers to
this role as a client.
When LifecycleStep does
refer to "customers" the
context is external
customers in the
marketplace, not
internal "clients"
within your own company.
-
LifecycleStep refers to
"business requirements"
and "requirements"
depending on the term
that seems to make most
sense. For all practical
purposes the two terms
are synonymous. While
not all requirements are
"business" focused, all
projects are typically
done to provide value to
the business and
therefore the
requirements are all
business related. Some
methodologies also refer
to technical
requirements, but in
LifecycleStep the
technical requirements
would all be a part of
the design and
architecture of the
solution.
-
LifecycleStep was
written to be able to
support large projects
and needs to be
comprehensive to ensure
that large projects can
be successful. However,
this means that smaller
projects may not need
all of the steps
associated with
LifecycleStep. Each
project team must use
the content of
LifecycleStep as a
starting point and
customize the activities
as needed. This includes
adding important
activities that are
needed by your project
and deleting activities
in LifecycleStep that
are not needed for your
project.
-
There are many models in
the marketplace for
defining the project
lifecycle. The models
within LifecycleStep
reflect the experience
and best practices of
the author.
-
There are two main
components on every
project - the project
management process and
the actual project
lifecycle. The
LifecycleStep Process
goes hand-in-hand with
the
TenStep Project
Management Process®.
For example, gathering
business requirements is
considered a part of the
project management
process in some
methodologies. However,
it is not considered a
part of the TenStep
process and it is
considered a party of
the LifecycleStep
process. Likewise, some
lifecycle methodologies
have activities for
quality control and risk
management. These are
important concepts, but
they are considered a
project management
function and are
therefore a part of the
TenStep Project
Management Process.
Therefore, they are no
considered a part of
LifecycleStep.
-
LifecycleStep is
designed to be
comprehensive, yet not
overly burdensome for
any project. The process
is flexible and scalable.
LifecycleStep defines
the overall framework
for larger projects.
Smaller projects may not
need to execute all of
the steps that are
defined. For instance,
section
414.0 Defining
Project Strategies would
not be needed for small
to medium sized projects.
Likewise, all of the
activities associated
with training can be
bypassed if the project
will not require any
training element.
|
