1. PMBOK Chapter 9 Project Human Resource Management And Case Study
Jacob Sandnes
3/30/15

2. Road Map Introduction Plan Human Resource Management
Acquire Project Team
Develop Project Team
Manage Project Team
Case Study
Conclusion

3. Introduction
Project HRM – the processes that organize, manage, and lead the project team.
The project team – those with assigned roles to complete the project.
The project management team – responsible for management and leadership.
Project HRM can also include.
Sponsors, clients, support staff, etc.

4. Introduction Managing and leading involves
Influencing the project team (human factors)
Professional and ethical behavior.
Project HRM processes interact with other areas knowledge areas.
Initial team members create WBS
Additional members may be needed
Their experience levels may increase or decrease project risk
Human factors include:
Team environments
Geographical locations
Communication among stakeholders
Internal and external politics
Cultural issues
Organizational uniqueness
Interactions with other areas.
Initial team members create WBS
Additional members may be needed
Their experience levels may increase or decrease project risk
Additional risk planning may be needed

5. Introduction Process areas are Plan human resources
Acquire project team
Confirm HR availability and obtain team
Develop project team
Improve competencies, interaction, and environment
Manage project team
Tracking performance and managing changes

6. Road Map Plan Human Resource Management Introduction
Acquire Project Team
Develop Project Team
Manage Project Team
Case Study
Conclusion

7. Plan Human Resource Management
Process of:
Identify/document
Roles
Responsibilities
Required skills
Reporting
Relationships

8. Plan Human Resource Management
Key benefits
Establishes
Roles
Responsibilities
Project org. charts
Staffing management plan

9. Plan Human Resource Management
Inputs
Project management plan
Activity resource requirements
Specifically human resources needed.
Enterprise environmental factors
Organizational culture and structure.
Existing human resources.
Organizational process assets
Policies, templets, lessons learned, etc.

10. Plan Human Resource Management
Tools and Techniques
Org. charts and position descriptions
Hierarchical, matrix, and text-oriented
Networking
Organizational theory
Expert judgment
Meetings
Org. charts: Hierarchical, matrix, and text-oriented
Networking: Luncheons, events, seminars, parties. (anything to foster interaction and interpersonal factors.)
Org. theory: Understanding people, team, org. unit behavior. Improves planning efficiency.
Expert judgement: any factors like role definitions or required skills.
Meetings: planning out Human resource management.

11. Plan Human Resource Management
Charts

12. Plan Human Resource Management
Outputs
Human resource management plan
Defines roles and responsibilities
Role, authority, responsibility, and competencies
Project org. charts
Staffing management plan
Staff acquisition
Resource calendars
Staff release plan
Training needs
Recognition and rewards
Compliance and safety

13. Road Map Acquire Project Team Introduction
Plan Human Resource Management
Acquire Project Team
Develop Project Team
Manage Project Team
Case Study
Conclusion

14. Acquire Project Team Process of: Key benefit:
Confirming HR availability
Obtaining the team.
Key benefit:
Outlining & guiding the team selection and responsibility assignment.

15. Acquire Project Team Inputs Human resource management plan
Enterprise environmental factors
Organizational process assets

16. Acquire Project Team Tools and techniques Pre-assignment Negotiation
Selected in advance
Negotiation
Functional mangers, other PM teams, and external org
Acquisition
Virtual teams
Multi-criteria decision analysis
Availability, cost, experience, ability, knowledge, skills, attitude, international factors

17. Acquire Project Team Outputs Project staff assignments
Resource calendars
Project management plan updates

18. Road Map Develop Project Team Introduction
Plan Human Resource Management
Acquire Project Team
Develop Project Team
Manage Project Team
Case Study
Conclusion

19. Develop Project Team Process of: Improving competencies
Team member interaction
Team environment

20. Develop Project Team Key benefits: Improved teamwork
Enhanced people skills
Enhanced competencies
Motivated employees
Reduced staff turnover
Better project performance

21. Develop Project Team Inputs Human resource management plan
Project staff assignments
Resource calendars

22. Develop Project Team Tools and Techniques Interpersonal skills
Emotional intelligence, conflict resolution, negotiation, influence, team building and group facilitation
Training
Classroom, online, on-the-job, etc.
Team-building activities (Tuckman ladder)
Forming, storming, norming, performing, adjourning
Ground rules

23. Develop Project Team Tools and Techniques Colocation
Meeting rooms (war room), poster boards, etc.
Recognition and rewards
Personnel assessment tools
Surveys, structured interviews, ability tests, and focus groups

24. Develop Project Team Outputs Team performance assessments
Enterprise environmental factors updates

25. Road Map Manage Project Team Introduction
Plan Human Resource Management
Acquire Project Team
Develop Project Team
Manage Project Team
Case Study
Conclusion

26. Manage Project Team Process of: Tracking performance
Providing feedback
Resolving issues
Managing changes

27. Manage Project Team Key benefits: Influences behavior
Manages conflicts
Resolves issues
Appraises performance

28. Manage Project Team Inputs Human resource management plan
Project staff assignments
Team performance assessments
Issue log
Work performance reports
Organizational process assets
Newsletters, websites, bonus structures, etc.

29. Manage Project Team Tools and techniques Observation and conversation
Project performance appraisals
Conflict management
Withdraw/avoid
Smooth/accommodate
Compromise/reconcile
Force/direct
Collaborate/problem solve
Interpersonal skills (leadership, influence, decisive)

30. Manage Project Team Outputs PMP updates Project document updates
Issue log
Enterprise environmental factors updates
Organizational process assets updates

31. Road Map Case Study Introduction Plan Human Resource Management
Acquire Project Team
Develop Project Team
Manage Project Team
Case Study
Conclusion

32. Case Study
Title - “Overcoming Barriers to Self-Management in Software Teams”
The team
Basic work unit
A small number of people with complementary skills who are committed to a common purpose, set of performance goals, and approach for which they hold themselves mutually accountable.

33. Case Study
Key question- “How should you organize teamwork for software development”
Two major types
Command and control
Centralized decision authority
Individual decisions
Self-managed
Scrum
Shared decision making

34. Case Study Self-managing teams Benefits Problems
Problems dealt quickly and accurately
Reduce cost, improve quality
Higher employee satisfaction
Higher functional redundancies
Problems
Team performance is complex
Depends on competence in managing and executing
Difficult to implement
Question:

35. Case Study This study examines
5 teams
3 companies
3 years
All introduced agile into their projects

36. Case Study Company A, B, and C
A develops customer specific software on contract. Specifically for planning and work coordination
B manufactures receiving stations for meteorological and earth observation satellite data.
C develops software for maritime, offshore, and process industries.

37. Case Study All five teams received Data gathering methods
One day of general intro to scrum.
One day of tailoring agile practices to their projects.
Data gathering methods
Observation of daily work and meetings (stand-ups, retrospectives, etc.)
Conducted interviews
Inspected documents

38. Case study Key topic emerged Barriers to self-management
Team-level
Organizational-level

39. Case study Team-level barriers Individual Commitment Failure to learn
Individual leadership

40. Case study Individual commitment To much priority to individual goals
Specialization
Developers created
Individual plans, full control over modules
Team members had less interaction
What if someone got sick?
Unrealistic plans
Too much in one sprint
Plans were too broad and too flexible
Self managed teams need to focus on team responsibilities for planning and scheduling their work. Commitment to team plan is needed.
1st point “Let the person that knows most about the task solve it! It will take too many resources if several persons are working on the same module, and there is no time for overlapping work in this project. The tasks are delegated and solved the best possible way today. Maybe we can do more overlapping in the next project.” –scrum master company A
2nd point “In the beginning there were so many dependencies to other projects and subcontractors, so we did not know which tasks we could complete during the sprint. It is also about optimization. You should always have the possibility to work on something else if you are stuck.” – scrum master company A

41. Case study Individual commitment Unclear completion criteria
When is the task done?
Meetings weren’t engaging
Scrum tool was distracting
Scrum master directly addressed developers
In companies A and B some developers fell asleep!
3rd point “The tasks were not tested well enough, and we knew there was still work to be done. These tasks are then not on the list of the next iteration since they officially are done. … Each iteration starts with doing things that we have said were finished, and then you know you will not finish the iteration. … When during an iteration you realized that you would not finish, you do not care if you are 70 percent or 90 percent done.” –Developer company A

42. Case study Failure to learn Low team autonomy
Outside people needs to respect efforts at improvement.
Need to affect managerial decisions to improve.
Symbolic self-management
In company C product owner distracted team
New issue/crisis
Presented new features with uncertainty
Distracted team from iteration plan.
Teams need to be able to change operating norms and rules within the team, as well as in the wider environment.
Why was it so difficult for these teas to improve and change?

43. Case study Failure to learn Impression management Specialization
Made project team look good
Reported unfinished task as finished
Motivated by competing project resources
Company A lost trust in team
Specialization
Problems with developer owned code unreported
1st point “We classified tasks as finished before they were completed, and we knew there was still work to be done. It seems that the scrum-master wants to show progress, and make us look a little better than we really are.” developer from company A
2nd point “When we discover new problems, we feel we own them ourselves, and that we will manage to solve them before the next meeting tomorrow. But this is not the case; it always takes longer time.” developer from company A

44. Case study Individual leadership Decentralized decision making
Failure to understand what others are doing
Company A
Developer spent 3 days implementing features for future products.
Decision hijacking
Many scrum master didn’t change decision habits.
Who should be involved in what decision?
One experienced new hire was left out of decisions.
Shared leadership hard to implement, because of individual and decentralized decision making.
2nd point “We divide tasks among ourselves, and then people are responsible for implementing them. This usually works fine. However, in the last sprint one of the developers spoke with someone in the market about an issue. The developer used a couple of days changing a feature that was already finished, because the developer thought this was very important. We had to redo what the developer had done. “ Scrum Master company C
3rd point ” I probably influence what they do. It is difficult to keep your mouth shut when you feel you have some good recommendations to give. It’s an old habit, difficult to change.” scrum master company A

45. Case study Organizational barriers Shared Resources
Organizational control
Specialist culture

46. Case study Shared resources Projects competed for shared HR
Developers assigned to two projects
Some scrum masters were allowed to prevent developers from other projects
Failure to provide scheduling and cross training
Culture did not allow changes in organization of teams.
No investment in redundancy
1st point “The isolation works how it should, but we [the developers] end up in a dilemma. Like today, it’s crazy in the other project. The customers are starting to use the system this week, and I’m the only one who can fix problems. Then I just need to help if they are having problems. I do not like to decide which project will not meet its deadlines. “

47. Case study Organizational Control Company B Company A
Tool for organizing tasks included information for QA department.
Project team ignored information and characterized it as busy work.
Company A
Management interested in number of hours reported rather than progress.
Scrum masters told developers to report more hours than were actually worked.
To much oversight by the organization. To many rules.

48. Case study Specialist Culture
Generalists needed to be able to fill in.
Company C
Chief architect controlled all decisions
Company B
Developers protected their knowledge
Developers became important and could not be fired
Company A
Developers afraid to take responsibility for code
Developers would be stuck with that product
2nd point : “The chief architect made most of the decisions himself. This was frustrating because we were not involved, and everything was hidden in the architecture.”
4th point: “You get stuck in the quagmire. And for every new project you are on, it gets worse.”

49. Case study Overcoming the barriers Organize cross-training
Increases responsiveness to change and flexibility
Collocate the team
Increases interaction and cooperation
Appreciate generalists
Select team members with potential for redundancy
Build trust and commitment
Teams’ need for learning should motivate not management’s control.
Beware of impression management

50. Case study Overcoming the barriers
Align people to one project at a time
Easier in large organizations
Must be coordinated by management, not team

51. Road Map Conclusion Introduction Plan Human Resource Management
Acquire Project Team
Develop Project Team
Manage Project Team
Case Study
Conclusion

52. Conclusion
Thank you for your time!
Questions?

53. References
Moe, N., Dingsøyr, T., & Dybå, T. (2009). Overcoming Barriers to Self-Management in Software Teams. IEEE Software,
Project Human Resource Management. (2013). In A guide to the Project Management Body of Knowledge (PMBOK guide), fifth edition (5th ed.). Newtown Square, Pa.: Project Management Institute.