PMBOK: Human Resource Management – Building a Team Culture

From time to time on this blog forum, I have talked about PMBOK (Project Management Book of Knowledge) as an industry standard on areas of PM responsibility and best practices. To continue my journey through the book, I would like to talk about an area that is often overlooked but critical to project success:  Building a Team.

A collaborative team functioning effectively provides an essential ingredient in successfully executing a project. I know senior project managers who believe a team is more effective and productive than even a group of superstar players in getting the job of a project done well. However, turning a loosely affiliated group of people into a team requires skill and intervention by the project manager.

A bit later in this post, I will talk about the wisdom gained from PMBOK on human resources and building a team. Before that, let me stray for a minute into a world where building a team is quintessential to success and survival – coaching. Whether you are coaching peewee football or a professional sports team, the coach (read project manager) creates an environment, a set of rewards and punishments, and acts as a role model that makes being a team possible. Successful coaches also say inspiring things like:

“Individual commitment to a group effort – that is what makes a team work, a company work, a society work, a civilization work. Vince Lombardi

"Good teams become great ones when the members trust each other enough to surrender the Me for the We." Phil Jackson

“When you’re part of a team, you stand up for your teammates. Your loyalty is to them. You protect them through good and bad, because they’d do the same for you.” Yogi Berra. Of course, Berra also said, “Baseball is ninety percent mental and the other half is physical.” (So, he probably would not have been hired on any IT projects!!).

My first thought for a new project manager or a project manager with a new team is, BE PATIENT. It takes time for a team to gel. A project manager should act as a facilitator and coach to get things going in the right direction.

Building a software development or project team from scratch begins with breaking down natural barriers to camaraderie that come from a lack of knowledge.  This is especially true when you use staff from many organizations including external companies.  So, begin building the team by providing an overview of the project goals, the execution time frame and the roles of the players. In the beginning, you will be more directive – then later in the process you will switch to a facilitative role, when the team-based momentum can carry the ball.

Another characteristic of teams is that they have fun when things are not serious. Having fun together builds relationships that support working effectively together (read my post on projects and fun). To the extent possible, add some fun to a regular project meeting and keep a relaxed and open communication style. It is not necessary to go off together to a resort to build a team. However, taking lunch together occasionally or having a treat brought into a meeting helps.

The project manager and coach should reinforce team-like behavior through praise and reward.

  • Do not reinforce behavior that works against the team by picking favorites or reinforcing negative behaviors through your attention.
  • Demonstrate trust by trusting.
  • Celebrate successes, even small ones.
  • Resolve conflicts fairly with a constant eye on the desired result – meeting objectives on time and within budget.

The last thing I will say about building a team culture is that it is easier when you have face-to-face contact on a frequent basis. As the project manager, you will have to be more creative and work harder to build a sense of team when players work remotely.  There are several posts on managing remote and virtual teams as well as tools in this blog if you need to do some reading on the subject.

Guidance on Team Building and Human Resources from PMBOK
The Project Management Book of Knowledge in chapter 9 “Project Human Resource Management” makes it clear that the project manager is responsible for the team, not a team member. It is your job to develop team competencies, facilitate team interaction and create an overall team environment to enhance project performance.

You are responsible for developing training plans for project members to gain competencies needed to execute the project. By the way, attending training together helps build a team. You can schedule team building activities that include informal communication and trust building activities during the first five minutes of regular status meetings.

Remember: You must handle project problems as team issues.

You should reward appropriate behaviors that help the team reach its objectives. Decisions on recognition and rewards should be part of the Human Resources Plan developed before work begins on the project. The PMBOK cautions you to take into consideration both individual preferences and cultural differences in creating a project reward system. Rewards include not only monetary compensation, but (more importantly) also recognition and opportunities to grow and apply skills to meet new challenges. Remember that rewards given during the project are more useful in shaping behavior on the project than rewards given at the project’s end.

If you have had any training in small groups then you understand the formation of teams – the PMBOK describes the process of building a team as:

  • Forming – team meetings to learn project objectives and meet each other
  • Storming – begin project work, develop detailed plans and make technical decisions. With strong personalities and individual competencies in an environment of under-developed trust in one another’s skills this can be a contentious time
  • Norming – work habits and behaviors have adjusted to support the team
  • Performing – the team is well organized and working through issues smoothly and effectively
  • Adjourning – work is completed

So bottom line is that you should think about the human component of a project team when you are the PM and not just leave it up to the organization or HR staff.  If you have had successful in building teams, please share some tips.

Status Reports: PM Anachronism or Necessity


I would not be completely honest if I did not admit that there have been times when I have complained – quietly to myself, of course – about having to write a project status report. So, I laughed out loud (LoL) at Cornelius Fichtner’s tongue-in-cheek post, Status Reports are no Fun which concludes that there is no good excuse for not doing an expected status report if you want to stay employed.

Which then reminded me of a classic Dilbert cartoon featuring the pointy-haired manager, Alice and a new guy – Pointy Hair tells Alice to show the new guy how to do status reports. She waits until he Pointy-hair leaves to answer the new guy’s unspoken question and then says, “He doesn’t read them anyway, so we all use a random phrase generator. I’ll e-mail it to you.”

Putting humor aside, I have received and submitted hundreds of status reports and I sincerely believe that they have an important place in organizational communication and project management.

What should be in a status report?
Project managers are accountable for ensuring compliance with the project’s schedule and budget. Therefore, status of those two items should form the basis of the report. Depending on the size of your organization – meaning how far removed from the project are the individuals that will read the report or a summary of it – it sometimes help to provide a one sentence summary of the long term goal of the project.

Use the schedule as a framework to identify major accomplishments during the reporting period and potential risks. If your project uses predictive scheduling techniques that type of data is especially helpful in writing meaningful status reports. (Here’s a link to a post and paper about predictive scheduling techniques.) Budget information is usually reported as actual versus planned expenses.  A real key is to focus on outcomes and measurable things like dates and progress – don’t just status activities like “we held a meeting”.

If your project received positive feedback from a stakeholder about the project, add that information to the report. This real-world good news may serve to make your manager look good to his boss, which is good for you also.

The other cornerstone of a simple status report is risks. Risks are events that have occurred or are likely to occur that will negatively affect the first two items – schedule and budget. Alerting your manager to project risks gives him an opportunity to help (sometimes a mixed blessing, I realize) and a heads-up he can give to his management.

Do not report risks lightly. Part of your job as a project manager is to plan for and handle risks. It is best to present risks or issues within a framework of how you are protecting the project’s schedule and budget from risk-based damage. However, if an unanticipated risk shows up at your door, remember the cardinal rule of management relations – no surprises. Tell your manager that XYZ Company is more than 30 days late in delivering their code AND what you have done to hold their feet to the contract fire.

If possible, add graphical information to show project schedule, expenses and budget compliance. Color coding for on-track, at risk, or in-trouble – typically stoplight charts — make it quick and easy for your stakeholders and executives to see how your project is performing against expectations and shows management that you are on top of the project details. Most status reports include a section on plans or action items for the next reporting period.

Here are some other housekeeping thoughts on writing status reports:

  • If your organization has an approved status report form – use it.
  • Do not use technical jargon, especially if your report is to be combined with other project reports and forwarded up the chain of command.
  • Focus on “outcomes” not just activity.
  • Use spelling and grammar checkers.
  • If the content is proprietary, mark it.
  • Add project name, your name, date and reporting period. Number the pages only if more than two. If your status report covers a month of activity or less, one page should be enough.
  • Be honest.
  • Keep a copy.

If you just need to a simple status then here is a simple list of topics I utilize:

  1. Accomplishments (from prior period)
  2. Plans (for the current period)
  3. Significant milestones / deliverables (with dates and progress information)
  4. Major risks or Events (to be aware of)

Do you have a simple way to do status reports?  Would love to hear from you.

The Lazy Project Manager's Blog

The Home of Productive Laziness Thoughts

Thoughts, experience, tips and tricks on issues affecting managers and project management

A Girl's Guide to Project Management

Project Management musings for one and all

LeadingAnswers: Leadership and Agile Project Management Blog

Thoughts, experience, tips and tricks on issues affecting managers and project management

Project Management Hut

Thoughts, experience, tips and tricks on issues affecting managers and project management

Herding Cats

Thoughts, experience, tips and tricks on issues affecting managers and project management


Pushing the Edges Out ...


Just another site