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

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

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.

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

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

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

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

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

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.

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.

Plan Human Resource Management Charts

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

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

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

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

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

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

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

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

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

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

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

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

Develop Project Team Outputs Team performance assessments Enterprise environmental factors updates

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

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

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

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.

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)

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

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

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.

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

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:

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

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.

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

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

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

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

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

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?

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

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

Case study Organizational barriers Shared Resources Organizational control Specialist culture

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. “

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.

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.”

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

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

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

Conclusion Thank you for your time! Questions?

References Moe, N., Dingsøyr, T., & Dybå, T. (2009). Overcoming Barriers to Self-Management in Software Teams. IEEE Software, 20-26. 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.