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

Goals

After these lectures, the student should know about:

•

2

Contents

Things said in the goal slide, and

•

3

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