Projects of different sizes
have different ways and
requirements on how the
people are organized. In a
small project, little
organization structure is
needed. There might be a
primary sponsor, project
manager and a project team.
However, for large projects,
there are more and more
people involved, and it is
important that people
understand what they are
expected to do, and what
role people are expected to
fill. This section
identifies some of the
common (and not so common)
project roles that may need
to be required for your
project.
Analyst.
The
analyst is responsible for
ensuring that the
requirements of the business
clients are captured and
documented correctly before
a solution is developed and
implemented. In some
companies, this person might
be called a Business Analyst,
Business Systems Analyst,
Systems Analyst or a
Requirements Analyst. For
more information on this
role see
407.2
The Role of an Analyst..
Change Control Board.
The Change Control Board is
usually made up as a group
of decision makers
authorized to accept changes
to the projects
requirements, budget, and
timelines. This organization
would be helpful if the
project directly impacted a
number of functional areas
and the sponsor wanted to
share the scope change
authority with this broader
group. The details of the
Change Control Board and the
processes they follow are
defined in the project
management processes.
Client.
This is the people (or
groups) that are the direct
beneficiaries of a project
or service. They are the
people for whom the project
is being undertaken.
(Indirect beneficiaries are
probably stakeholders.)
These might also be called
"customers", but if they are
internal to the company
LifecycleStep refers to them
generically as clients. If
they are outside your
company, they would be
referred to as "customers".
Client
Project Manager.
If the project is large
enough, the client may have
a primary contact that is
designated as a comparable
project manager. As an
example, if this were an IT
project, the IT project
manager would have overall
responsibility for the IT
solution. However, there may
also be projects on the
client side that are also
needed to support the
initiative, and the client
project manager would be
responsible for those. The
IT project manager and the
client project manager would
be peers who work together
to build and implement the
complete solution.
Designer.
The Designer is responsible
for understanding the
business requirements and
designing a solution that
will meet the business
needs. There are many
potential solutions that
will meet the client's
needs. The designer
determines the best
approach. A designer
typically needs to
understand how technology
can be used to create this
optimum solution for the
client. The designer
determines the overall model
and framework for the
solution, down to the level
of designing screens,
reports, programs and other
components. They also
determine the data needs.
The work of the designer is
then handed off to the
programmers and other people
who will construct the
solution based on the design
specifications.
Project Manager.
This is the person with
authority to manage a
project. This includes
leading the planning and the
development of all project
deliverables. The project
manager is responsible for
managing the budget and
workplan and all project
management procedures (scope
management, issues
management, risk management,
etc.). For more information
on this role see
407.1 The Role of a Project
Manager.
Project
Team.
The project team consists of
the full-time and part-time
resources assigned to work
on the deliverables of the
project. This includes the
analysts, designers,
programmers, etc. They are
responsible for.
-
Understanding the work
to be completed
-
Planning out the
assigned activities in
more detail if needed
-
Completing assigned work
within the budget,
timeline and quality
expectations
-
Informing the project
manager of issues, scope
changes, risk and
quality concerns
-
Proactively
communicating status and
managing expectations
The project team can consist
of human resources within
one functional organization,
or it can consist of members
from many different
functional organizations. A
cross-functional team has
members from multiple
organizations. Having a
cross-functional team is
usually a sign of your
organization utilizing
matrix management.
Sponsor
(Executive Sponsor and
Project Sponsor). This is
the person who has ultimate
authority over the project.
The Executive Sponsor
provides project funding,
resolves issues and scope
changes, approves major
deliverables and provides
high-level direction. They
also champion the project
within their organization.
Depending on the project,
and the organizational level
of the Executive Sponsor,
they may delegate day-to-day
tactical management to a
Project Sponsor. If
assigned, the Project
Sponsor represents the
Executive Sponsor on a
day-to-day basis, and makes
most of the decisions
requiring sponsor approval.
If the decision is large
enough, the Project Sponsor
will take it to the
Executive Sponsor for
resolution.
Stakeholder.
These are the specific
people or groups who have a
stake, or an interest, in
the outcome of the project.
Normally stakeholders are
from within the company, and
could include internal
clients, management,
employees, administrators,
etc. A project may also have
external stakeholders,
including suppliers,
investors, community groups
and government organization.
|
Steering Committee.
A Steering Committee
is a group of
high-level
stakeholders who are
responsible for
providing guidance
on overall strategic
direction. They do
not take the place
of a Sponsor, but
help to spread the
strategic input and
buy-in to a larger
portion of the
organization. The
Steering Committee
is usually made up
of organizational
peers, and is a
combination of
direct clients and
indirect
stakeholders. The
members on the
Steering Committee
may also sit on the
Change Control
Board, although in
many cases the
Change Board is made
up of
representatives of
the Steering
Committee.
|
 |
Suppliers
/ Vendors.
Although some companies may
have internal suppliers, in
the LifecycleStep Process,
these terms will always
refer to third party
companies, or specific
people that work for third
parties. They may be
subcontractors who are
working under your direction,
or they may be supplying
material, equipment,
hardware, software or
supplies to your project.
Depending on their role,
they may need to be
identified on your
organization chart. For
instance, if you are
partnering with a supplier
to develop your requirements,
you probably want them on
your organization chart. On
the other hand, if they are
a vendor supplying a common
piece of hardware, you
probably would not consider
them a part of the team.
Users.
These are the people who
will actually use the
deliverables of the project.
These people are also
involved heavily in the
project in activities such
as defining business
requirements. In other
cases, they may not get
involved until the testing
process. Sometimes you want
to specifically identify the
user organization or the
specific users of the
solution and assign a formal
set of responsibilities to
them, like developing use
cases or user scenarios
based on the needs of the
business requirements.
Responsibility Matrix
In a
large project, there may be
many people who have some
role in the creation and
approval of project
deliverables. Sometimes this
is pretty straightforward,
such as one person writing a
document and one person
approving it. In other
cases, there may be many
people who have a hand in
the creation, and others
that need to have varying
levels of approval.
The Responsibility Matrix is
a technique used to define
the general responsibilities
for each role on a project.
The matrix can then be used
to communicate the roles to
the appropriate people
associated with the team.
This
helps set expectations, and
ensures people know what is
expected from them.
On the matrix, the different
people, or roles, appear as
columns, with the specific
deliverables in question
listed as rows. Then, use
the intersecting points to
describe each person's
responsibility for each
deliverable. A simple
example matrix follows:
|
|
Project Sponsor |
Project Manager |
Project Team |
Client Managers |
Analysts |
|
Requirements
Management Plan |
A |
C |
R |
A |
R |
|
Requirements Report |
I, A |
R |
R |
I, A |
C |
|
Process Model |
R |
R |
R |
I, A |
C |
|
Data Model |
R |
R |
R |
I, A |
C |
|
Requirements
Traceability Matrix |
R |
R |
R |
R |
C |
-
A - Approves the
deliverable
-
R - Reviews the
deliverable (and
provides feedback).
-
C - Creates the
deliverable (could be C
(1) for primary, C (2)
for backup). Usually
there is only one person
who is responsible for
creating a deliverable,
although many people may
provide input.
-
I - Provides input
-
N – Is notified when a
deliverable is complete
-
M - Manages the
deliverables (such as a
librarian, or person
responsible for the
document repository)
In the table above, the
Requirements Management Plan
is created by the project
manager, approved by the
sponsor and client managers,
and reviewed by the project
team and analysts.
The purpose of the matrix is
to gain clarity and
agreement on who does what,
so you can define the
columns with as much detail
as makes sense. For instance,
in the above example, the
'Project Team' could have
been broken into specific
people or the person
responsible for creating the
Data Model could have been
broken out into a separate
column. After the matrix is
completed, it should be
circulated for approval. If
it is done in the project
definition process, it can
be an addendum to the
Project Definition. If it is
created as a part of the
initial Analysis Phase, it
should be circulated as a
separate document.
Examples of responsibility
codes are as follows. Your
project may define different
codes, as long as you
explain what they mean so
that people know what the
expectations are for them.
