PMBOK: Human Resource Management – Building a Team Culture

September 30, 2010 — Bruce McGraw

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.

Posted in Best Practice, General Project Management, management, staff. Tags: , , , , , , . 3 Comments »

Status Reports: PM Anachronism or Necessity

September 24, 2010 — Bruce McGraw

 

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.

Posted in Best Practice, Communication, General Project Management, pm, Project Management. Tags: , , , . Leave a Comment »

Finding the Best Staff – Tips for Project Managers

September 16, 2010 — Bruce McGraw

I know that project managers working for large companies with human resource departments and Project Management Offices, usually get the staff needed for their project without the need to recruit or hire from outside. However, in small companies, the project manager may be tasked with finding new employees or outside consultants to work on his or her project from outside the organization.

I sympathize with PMs who must add the “find-hire-acquire-staff” to their to-do list. It is not easy to find the right people and the negative consequences of failure can be long-term. Therefore, I have given some thought to effective staffing/recruiting strategies—along with borrowing insight from others.

Obvious Ways to Recruit New Employees
Of course, you can place an ad in local newspapers and check out popular generalist and industry specific websites that post jobs for those seeking them. Popular sites for job seekers include  monster.com, hotjobs.com and craigslist.org. Professionals seeking jobs in the technology sector also register with Dice and techiegold. (Joel on Software offers insight and disheartening numbers on using these sites for recruiting developers in his post, “Finding Great Developers”)

Ask your current work contacts for suggestions or referrals or represent your company at local job fairs talking with perspective employees and collecting resumes. Some companies use staffing firms to get resumes and outside contractors – but be warned that this industry has become over taxed with too many players and too few good resumes.  Use social networking sites that focus on work related information sharing such as LinkedIn or Plaxo. Also, another warning, “Posting on these social sites may yield varying results”.

In the past, some organizations dismissed searching though active job seekers for their employees preferring instead to use recruiters to tickle the fancy of people already employed and not actively looking—this becomes very expensive very quickly. In today’s economy, many talented, hardworking developers and project staff are unemployed or under-employed and looking.  

Any or all of these activities bring resumes of viable candidates for your consideration –frequently buried with hundreds of others that are not viable. Be prepared to sort through a lot of chaff to get to the wheat.

Before you make any decision about recruiting versus staff augmentation, you also need to look hard at your real needs and constraints for a project:

  • Do you need a junior or senior person?
  • How long will you need the skill set?
  • How long do you have to get the person on-board and trained?
  • If you need multiple people, how many do you hire versus bring in as consultants?

Recruiting Outside the Box
The first question I would ask you to consider, “Is there someone in your organization who– with training–could do the job you are trying to fill?” The advantage of hiring from within is that the individual already has a stake in the company and a record of accomplishment you can check. Of course, some training takes more time than you have available, but at least think about the possibility of offering training in exchange for the opportunity to work on your project.

Check through filed resumes and applicants from past employee searches. Someone that almost made the cut for a previous position may still be interested in your opportunity and a potential candidate for you.

Attend trade shows, professional conferences or training events with the purpose of scoping out talented individuals. When you find someone with potential, give them your card and let them know that your company is looking for people with their skills.

A Techrepublic article offers this out-of-the-box recruiting strategy—host a training event or game night. Depending on the type of developer you seek, you may find that they share interests with others in your organization for advanced training workshops or video game competition. Check with your compadres to identify a topic or event that is relevant or fun and will attract the types of people you might want to hire.

IF your timeframe is long enough, think about hiring an intern. Of course, their skills are nascent, but some future superstars are in the ranks of graduate students who would appreciate a chance at real world experience. And, who knows they may remain after their stardom is established.

Once you successfully get a group of potential candidate resumes (for either hiring or contracting), get ourself prepared to ask good questions and be a good interviewer.  If you decide to hire be sure you look for soft skills in addition to the hard technical skills.  I have developed a few  key competencies I look for in staff over the years – you may want to read my thoughts in, “Staffing Projects for Success: Back to The Basics” by Cognitive Technologies – (free registration required).

Please share your out-of-the-box and traditional staffing/recruiting techniques with fellow project managers.

Posted in General Project Management, management, pm. Tags: , , , , , . 1 Comment »

Keep Users in Mind in Your Design

September 12, 2010 — Bruce McGraw

General Electric Company used to say in their advertising, “Progress is our most important product.” In terms of project management, satisfied users are often our most important product. Users may not be our direct clients, but they are the ones that eventually decide if our efforts to develop a software system helped or hindered getting their job done.

In previous posts — Business Analysts and Helping the Business Analyst Helps Your Project – I talked about the role of the Business Analyst in collecting user requirements and evaluating performance from a user’s perspective. Integral to our support of the user’s experience at Cognitive Technologies is Performance-Centered Design and Development addressed in detail in this white paper by Dr. Karen McGraw. In today’s post, I want to summarize the key points in Karen’s paper and tell you about an interesting site I found that adds another perspective to designing for users.

Performance-Centered Design
Cognitive Technologies works with users from the beginning of a project through final testing and support. We seek to capture and document work processes and information needs as well as user characteristics. We recommend rapid prototyping to develop a proof of concept or visual prototype to test early understandings and determine/refine requirements. Our user-centric activities include:

  • Identifying the information needs, including required input and output, sources and destinations for data, and information manipulation
  • Defining responsibilities or assignments, including understanding the job functions and goals, work processes, and critical success factors for the user community
  • Documenting standards and criteria for the user’s job performance that may be impacted by the new system
  • Capturing decision making factors and heuristics (i.e., rules of thumb) users apply in performing job functions affected by the system
  • Capturing problem solving patterns and preferences within the user community
  • Documenting difficulties and problem areas (in the way the job is performed today) that technology will or can improve

Design with Intent
Dan Lockton’s background in Industrial Design Engineering followed by a Master’s in Technology Policy from the University of Cambridge and his doctorate work at Brunel University in England focused on the impact of design on user behavior. Lockton and colleagues from Brunel developed a group of design concepts they call: Design with Intent, which are available for review and download.

Lockton uses the term Design with Intent to mean “design that’s intended to influence or result in certain user behaviour — it’s an attempt to describe lots of types of systems (products, services, interfaces, environments) that have been strategically designed with the intent to influence how people use them.” Although Lockton does not limit his thinking to software, many of his ideas are provocative in terms of their implications for software design. I picked 10 of over one hundred such suggestions to list here:

  1. Can you recognize the ‘desire paths’ of some of your users, and then codify them into your system, so others follow too?
  2. Can you edit the choices presented to users so only the ones you want them to have are available?
  3. Can you make the default setting the behavior you prefer users to perform?
  4. Can you detect and suggest a better option to users when it looks like they’re making an error (i.e. Google search correcting typo errors)?
  5. Can you let users know their progress towards achieving a goal or let users know how what they’re doing is affecting the system?
  6. Can you give users a preview or simulation of the results of different actions or choices?
  7. Could your system adapt what it offers to match individual users’ needs and abilities?
  8. Can you give people a ‘map’ of the routes or choices they can use to achieve different goals?
  9. Can you give users different choices or access to functions depending on the capabilities they can demonstrate?
  10. Can you make elements look similar so users perceive them to share characteristics, or that they should be used together?

What does this mean to project managers?
First, consider if the ideas about structuring user interaction suggested in Design with Intent make sense for your product and customer. If so, prepare a brown bag training topic about Design with Intent – or ask someone on your staff to do it. After your business analyst develops an overview of the users, their requirements and operating environment, brainstorm with the design team how some of the Design with Intent suggestions could be implemented. For those individual guidelines that you support, make sure that product testing includes an evaluation of those items.

Posted in General Project Management. Tags: , , , , . Leave a Comment »
« Older posts
Follow

Get every new post delivered to your Inbox.

Join 354 other followers