This document discusses the importance of stakeholders in a software project and the role of a project manager in dealing with them. It notes that stakeholders such as customers, suppliers, bosses, and users will determine whether a project is successful. It also discusses how a project manager must clarify the goals and scope of a project after intake to understand what is being asked for without getting blamed for problems. The document stresses the importance of requirements determination and validation to ensure the project is meeting its goals. It also covers giving feedback, managing risks and uncertainties, and introducing a project approach and policies to an organization to make the project manager's job more effective.

1.  By Grosan Radu
 An 4 CTI

2.  Stakeholders are all the people involved in
a project, the customer, the supplier, the
boss, the user, you name it. As a project
manager you have to deal with them, they
will determine if your software project will
be a success or a failure. This will
describe the image a software project
manager should have engraved in his
mind. If you see it, you will surely
recognize it.

3.  Ever got a present where you thought
"what is this?" Ever got something from
your superiors nicely wrapped in a paper
with in neon letters 'project' on it, where
you thought "what?" Problems, ideas or
just plain stupidity are quickly labeled
'project' and handed over to a project
manager. The intake is to clarify what is
meant so the project manager is not
getting the blame.

4.  Whatever you do, what ever you make,you
should know what to do or to make. After
an intake the global contours of the project
are outlined by goals and scope. You
should get more specific though. It's this
getting more specific that requirements
determination is all about.

5.  During the project the requirements stated
at requirements determination should be
validated. This validation goes two ways:
are we meeting the requirements, and are
the requirements still valid. This section
handles the requirements made to the
product part of the project.

6.  Ina project it's all about getting the
approvals to keep on going. This section
handles giving feedback on the
requirements made to the process. Are we
still within time and budget, and are the
project constrains still the same

7. A risk is the possibility of loss of some
kind. It's all about what can be different
from what we believe right now. Not just
what can go wrong, but possibilities can
arise also if the future brings not what you
think it will. "Dealing with uncertainty"
would be a good subtitle for this section of
the guide.

8.  Thissection will cover two aspects of
doing projects in a larger context, your
organization. The aspects are how to
handle policies issued on what systems
you may use, and how it should be
constructed, and how you can introduce a
"project approach" into an organization in
such a way, your own job as a project
manager will be more effective.