Managing people and other things related to projects · Managing people and other things related to...
Transcript of Managing people and other things related to projects · Managing people and other things related to...
Managing people and other things
related to projects. . .
• Goals of the lecture
• Contents of the lecture
• Motivation
References:
• James P. Lewis, Mastering Project Management
1
Manager roles
• Roles related to human relations: (seremony) figurehead,
manager, liaison, and contacts (horizontally,
boundary-crossing).
• Role of a spokesperson: monitoring, information sharing,
speaker (representing the group).
• Role of a decision maker: entrepreneur, disturbance handler,
resource sharer, negotiator.
• Integrated work: one does not work in the above roles
separately, but at the same time, they form a whole (gestalt).
4
Instructions
• PM should find out a systematic way to share information.
• PM should away things that lead to superficiality, but should
concentrate on matter that require concentration, looking at
the whole and by using analytical data.
• PM should manage the his time usage: the mandatory work
can be seen as chances and interesting tasks could be tryed to
get to mandatory ones.
5
More instructions
Designers and implementors (that is, those whole will do the work),
should also take part in planning the project.
• People may not commit themselves to plans made by some
other people. Not because of egos etc but since often the plans
made by some other people are not good enough. Problems can
be found from assessments, schedule, or task ordering, or the
plans made by other people may contain too much or too few
things.
• In addition, the group does not think things that nobody
thinks of (e.g., the PM).
PM should get the group to produce results. But, also the PM
should participate in planning and plan certain things by himself.
6
Power. . .
With what characteristic one gets people to do something?
• expertize
• rewarding capability
• justification
• reference
• force (by forcing)
WIIFM (what is in it for me), should be thought by aligning to the
workers position.
7
A discussion:
Do you have enough authority so that people will do what you ask?
No.
Then how do you get them to do what you want?
They have to want to do it. And my task is to ensure that they
want it.
8
Doing favors.
Bell Labs example.
Engineers who had made friends and who had their networks laid
down obtained answers much faster than some other workers.
9
How to handle disagreements?
• One may ignore (may mean acceptance).
• Or go over (may add resistance).
• Neutralize (“what should I do to convince you”).
• Bypass (e.g., one could go to talk to the manager of the
opponent).
10
Negotiation skills
One should think, how the situation can be seen as a “win-win”
situation (and not as a bad compromise).
“To win a battle, but loose a war” — one should away this.
Negotiation often means to find out a solution to a conflict. (See
also the other slides.)
11
Instructions to negotiations
• Natural surrounding to discuss the problem. Your own office is
not the place.
• Express your sincere wish to get the problem solved, so that
both sides are content with it.
• Don’t suppose that you would know something about the
motives, meanings, thoughts or feelings of other people.
• Handle things, not people.
• If the values have caused the problem, one should handle the
concrete material impacts and not the values by themselves.
Values are not likely to change but one may always request the
other to do certain actions etc.
12
Instructions to negotiations
• Learn active listening. Demonstrate your own understanding by
rephrasing.
• Express your wishes as a request, not as an order. If you
cannot accept a request, do a new suggestion. Try to obtain
win-win-situation.
• It is always a good idea to give a chance to save face for the
opponent.
• Remember that the opponent is not grazy or evel because you
have a disagreement.
13
Instructions to negotiations
• Handle only one thing at a time, if there are several. Start with
those, from which it is easier to obtain concensus.
• Don’t hurry the process.
• When the concensus has been obtainedd, ask from the other
side, is there anything that prevents them from following this
concensus. Ask the same questions from yourself. (“Ecological
check”.)
• Don’t promise what you cannot hold. If you need your
managers permission, it should be brought up and after that,
return to the matter.
• The other side should always be given a chance to save their
faces.
14
Mistakes in the projects. . .
• Not doing something when it should be done.
• Doing something when it should not be done.
• Solving a wrong problem (doing wrongly).
• Seeing a right problem but not applying (using) a solution.
15
Mistakes in the projects. . .
More fault types (another classification):
• Goals not obtained.
• Undesired side effects.
• Designed faults and flaws (sprinkler example ??).
• Unsuitable goals.
16
When the project has succeeded?
If project complies with the tehnical performance
specifications and/or taks, for which it was formed, and if
the key persons in parent organization, key persons in
client organization, key persons in project team, and key
users show up clear satisfaction for results of the project,
one may consider that the project has succeeded somehow.
(This is probably, not necessarely word by word, from Baker,
Murphy, Fisher, Factors affecting success, In Cleland, King (Eds.),
Project Management Handbook.)
17
Succes factors
Jean Couillard, The role of project risk in determining project
management approach, Project Management Journal, dec 1995, pp.
3–15.
• Technical 1, subjective factor on how we succeeded technically
with regards to the original requirement.
• Technical 2, subjective factor on how we succeeded technically
with regards to the other projects in the company.
• Price, subjective factor on how much the budget was being
over or under used.
• Time, subjective factor on how much the time schedule was
being over or under used.
18
• Process, the level of satisfaction towards the process that was
used in the management of the project; a successful project is
one requiring a minimum amount conflict and crises
management.
• Entirety, subjective factor on how well the project succeeded in
its entirety.
19
Success factors
In the impressiveness (importance) order: the most impressive first.
• Coordination and relations.
• The saliency of success criteria and consensus on those.
• Over optimism in the beginning, conceptual difficulties.
• Sufficiency of project structure and control.
• Compentition and budget pressure.
• The uniqueness of porject, importance, publicity.
• Improvement of the talents inside the company.
“The directions do depend on the factor.”
20
Coordination and relation factors
• The unity of project and department (administrative) managers
• Team spirit, sense of mission, commitment to the goal and
capability
• Unity of project manager, public officials (??), client contact
and his manager.
• The human relation and management skill of project manager.
• Realistic progress reports.
• Supporting relations between the team members.
• Authority of project manager (authority, command).
21
• Sufficiency of change operations.
• Safety of the work of team members.
• Team member involvement on decision making and on solving
the main problems.
• Parent enthusism (?)
• Existence of back-up plans.
22
Features that cause the project failures
• Insufficient use of progress and status reports.
• Use of superficial status reports.
• Insufficient managerial, technical or human relation skill of
project manager.
• Insufficient influence and authority of project manager.
• Poor coordination with the client.
• Missing good relations with the client and parent organizations.
• Client carelessness of budget criteria.
• Team not involved in the decision making and problem solving.
• Too much structure in a project team.
23
• Insecurity of the work places of the team members.
• Lack of team spirit, lack of sense of mission.
• Stable parent organization, undynamic, lack of strategic
change.
• Poor coordination with the parent organization.
• A new “kind” of project.
• Project more complex than what the parent organization has
solved before.
• Insufficient funding in the beginning.
• Inability to fix the plans in early phase.
• Inability to stop the functioning (working. . . ).
• Unrealistic project schedule.
• Unsufficient change procedures.
24
Project planning and implementation
• Concept
• Develope a problem expression and idea for the procedure.
• Develope alternative project strategies.
• Develope an implementation plan (for the project, not for the
software).
• Get signatures for the implementation plan.
25
• Implement your implementation plan.
• Is it moving ahead appropriately?
• Complete the final audit on project.
• Finish the project.
In between reviews and other checks which may require one to go
back to previous phases.
SWOT, strenghts, weaknesses, opportunities, and threats (e.g. at
the strategy item).
26
On people
• Interactions can be described as a feedback system.
• That is, the system responses and gives feedback.
• The feedback may be strengthened or weakened.
• “Speed pedal on cars:” some people don’t see that they don’t
keep the same speed with regards to certain things.
• “Feedback”, e.g. a reward or critique.
• Feedback cannot be used continuesly to modify the
performance (somewhere are the upper and lower limits).
27
On people
• Communication: voiceless and spoken, emphasizings, word
choices etc will affect.
• Too strong behaviour may cause counter reactions.
• Symmetric vs. asymmetric relationship. Example about going
to a restaurang.
28
Conflicts
• punctuation (move, countermove, new countermove, etc).
• May means endless game (game theoretic concept).
• It’s not always a good idea to try to find out the starter.
• . . . nor to find out the reasons for the conflict.
• Often, it is more wise to try to break out the counter move (or
counteract) pattern.
• For ex. by asking one side to behave differently, if you are not
involved by yourself, or the by behaving differently by yourself.
29
• If possible, one should prepare beforehand for the problems,
one could try to predict the problems and may to avoid the
problems with suitable inputs.
• Note that often a small deviations in interaction system do not
affect: the system will come back to after some time
(resistance, unconscious or conscious). Either ones needs energy
all the time to do the deviations or the break the patterns.
• Thus, one should try to change the negative feedback “circuit”.
30
Failing corrections. . .
Behind the schedule; then over work; for some time, this is ok;
more mistakes; schedule is behind again.
When a new publication is made; designer has to make corrections
to the old version; schedule behind; new version will have design
and implementation errors; this round again with the next version.
31
Levels of understanding:
• Level of occurrences — reactive. “Let’s make corrections when
errors are observerd.”
• Patterns of occurrences — adaptive. “Recognize patterns,
designers are taught to react quickly to the errors.”
• Systematic patterns — creative. “From where do these patterns
born. We could try to prevent the birth of errors. Maybe a
separate error correction group.”
• Shared vision — generative. “What kind of patterns will be
observed with different procedures? Who will share the
resources.”
32
Benefit of an individual vs. the
community
Expoitative fishing.
An individual fisher don’t think that his actions will affect the
whole and thus he will try to get as much fishes as possbible.
When there are a lot of fishers, the situation changes. . .
In project organization there may be competition for resources,
which may end up in win-lose situations.
(Senge, Peter, The fifth discipline, 1990.)
33