Voices on Project Management

> Back to Voices Home

January 2012 Archives

Build Generational Awareness on Your Project Team

| | Comments (1)
There are certain interpersonal skills that project managers must master in order to analyze situations and interact appropriately, as outlined in Appendix G of A Guide to the Project Management Body of Knowledge (PMBOK® Guide)--Fourth Edition.

The skills include political and multicultural awareness. But, since the project team environment has evolved over the last 10 years, I think a new interpersonal skill should be required, not only for project managers but also for team members and stakeholders: multigenerational awareness.

Generations as cultures are based on invisible values, beliefs, attitudes and assumptions created by shared experiences and events. These differ across generations, and each will likely feel or behave differently in the same situation. The lack of cultural awareness may lead to a misunderstanding and misinterpretation of the situation.

As a project manager leading a multigenerational team, you must know how to handle generational differences.

Try to empathize with someone from a different generation and understand where he or she is coming from. Listen to the meaning behind words and interpret non-verbal clues rather than applying generational stereotypes. Focus on making that connection with individuals of different generations to build a meaningful relationship.

When your multigenerational project team disagrees, in my experience, it's often because people are following those generational fundamental values. As the project manager, you need to assume a humble attitude and question rather than assert. Asking people to explain themselves before assuming anything shows respect.

Building awareness around generational differences in your project team can ultimately help avoid any problems. Encourage your team to:

Avoid making quick judgments of values. Try to understand the value and its historical reason. Values evolve as people live their lives in different periods of time.

Define a balancing act. Figure out how to manage different perspectives and different ways to doing things.

What are you doing to build generational awareness in your team?

Read more posts from Conrado Morlan.

Read Dmitri Ivanenko's post on Answering the Loaded Question in Project Management.

Building Blocks of Project Work Planning

| | Comments (3) | TrackBacks (0)

In my previous posts, I laid out the basics, the framework and the key documents for planning a project end-to-end. Now it's time to dive deeper.

One of the most essential project planning stages is to establish the grounds for the project work. Planning and defining the project work starts with defining the "what" of the project.

Before you can begin, you must understand the business needs and identify the project deliverables and its characteristics. You must set the boundaries of the project by establishing what the project will and will not deliver, and break down the project work into smaller and more manageable work units.

The building blocks of project work planning have four main steps:

  1. Collect the project requirements
  2. Facilitate a requirements workshop
  3. Define the project scope
  4. Break down the work in small work units
Collecting requirements is the process of understanding the customer needs, the business use-cases or the required product features and functionality that the project will deliver. It's an elicitation process, a discovery and analysis endeavor, rather than just a gathering effort.

The requirements elicitation process should be facilitated and not done by yourself. Therefore, do this. Get the appropriate project stakeholders together. Organize focused requirements workshops. Interview, brainstorm and job shadow to glean information.

Defining the project scope involves prioritizing the collected requirements, and deciding what's in and out of scope based on such factors as criticality, priority, urgency, constraints, complexity, risks and costs.

The scope covers the project deliverables and all project requirements, along with their detailed descriptions and the related constraints and assumptions. The scope illustrates the entire work that the project will carry out, as well as the project boundaries.

The part of the work planning that generates action is the Work Breakdown Structure (WBS). The WBS enhances the project scope understanding by decomposing the project work and deliverables into smaller and more manageable work units, also called work packages. The WBS defines granularly the "whats" of the project.

Do you agree with these steps? How many steps do you use for project work planning?

Read more posts from Marian Haus.

How to Handle Your Project Management Mistakes

| | Comments (2)
My mother used to have a Charlie Brown pin that said, "I've never made a mistake in my life. I thought I did once, but I was wrong."

I'm not as oblivious to my mistakes. In fact, I have made quite a few, both personally and professionally. In some cases, my gut told me I was making a mistake, but I went ahead anyway. Other times, I forged ahead confidently, only to be jarred by the sudden reality that I'd done something wrong.  

This happened recently at work. I got called into the proverbial "principal, or headmaster's office" and learned something I'd done caused trouble at a sister company. Not intending to make waves, I had started a tsunami.    

If you're a new project manager, it shouldn't be a surprise that you may make some mistakes. What do you do when you are called in to discuss your fallibility on the job?   

I sat and listened to the grievance presented to me -- staying calm is always the best approach. I absorbed everything my organizational leader shared with me. The first thing I said was, "I'm sorry." I briefly explained my side of the story without fanfare or drama. If you can explain yourself with brevity, do. Rambling probably won't work in your favor.

I made it clear that I understood the other side of the story and guaranteed that I would be extra diligent in the future to avoid such mistakes. I wasn't defensive. I wasn't full of ego. I recognized my part in the issue and accepted the blame, as hard as it was.

My organizational leader was professional, but she also expressed her dissatisfaction and disappointment in my behavior. This was the hardest thing to hear. The importance of being able to receive harsh criticism is not touted enough. The ability to hear -- and accept -- when someone else points out that you failed goes a long way in helping you establish a fruitful project management career.

Afterward, my organizational leader followed up by saying she trusted that I had learned my lesson and would make better decisions going forward. She appreciated hearing my side because she now had full context of the incident.  

Before leaving, I asked if there was anything else I could do. In my case, the answer was no, but if there are action items for you, be diligent about accomplishing them in a timely manner. Give feedback to your organizational leader about your progress.   

Making a mistake as a professional is embarrassing, but most times, your career will go on. Deal with the mistake professionally and with integrity for a chance to be even better at what you do.  

Project Management Career Paths in IT Services Organizations

| | Comments (3)
Project management plays a vital role to successfully deliver IT services to customers. Each IT service -- from strategy and consulting to platform migration -- has its own life cycle and project managers must be aware of the different phases, tasks and deliverables. This means IT services organizations must be dedicated to build qualified and competent project managers.

Career paths in project management help build the competencies in project management in an evolutionary manner. Career paths also provide a clear road map for the growth of the employees in the profession.

Those IT organizations that invest on designing the project management career path and relevant skills of the employees deliver excellent business value to customers.

In my opinion, there are nine "levels" of careers in IT services organizations. Titles depend on the organization, but in my experience, these are the levels:

Level 1: Entry-level employees with either a technical education background or a functional background may have titles such as software engineer or functional analyst.

Level 2: Employees at this level participate in requirements or business process analysis, high-level design, and technical specifications.

Level 3: This could be the team leader level. He or she might manage a team of three to four members and deliver part of project deliverables.

Level 4: This could be the project leader. He or she might manage a team of about 10 members and deliver small projects.

Level 5: This would be the project manager. He or she manages a team of 20 to 30 members and delivers multiple, medium-size projects or a large project.

Level 6: This is the senior project manager level. He or she manages a team of about 100 members and delivers multiple large projects.

Level 7: This is usually the program manager level, managing a team of about 200 people. He or she delivers complex program(s) for a single customer.

A delivery manager could also be at this level, managing a delivery unit with a team of 200 members. He or she delivers logically grouped projects based on technologies, customers, verticals or regions. For example, a delivery unit could consist of projects from different customers in the Middle East region.

Level 8: Usually the head of delivery, he or she delivers multiple complex IT programs or manages multiple delivery units.

Level 9: This is the chief delivery officer. He or she takes the responsibility of overall delivery of IT organization.

To move from one level to the next in the project management career path, it requires improving current competencies and learning new competencies.

To move up the career ladder, project managers should focus on the nine knowledge areas from A Guide to the Project Management Body of Knowledge (PMBOK® Guide).

They should also study The Standard for Program Management.

In addition, core competencies should include, but aren't limited to:

•    Project life-cycle management
•    Effort management
•    Software change management
•    Configuration management
•    Organization change management
•    Leadership skills
•    Multi-cultural team management
•    Global delivery model

Do you agree with these career levels? What skills should project managers focus on to move up the IT career ladder?

Editor's notePMI's Pathpro® is an online tool that organizations and practitioners can use to identify the skills and competencies needed to create a successful project management career path. 

Empower Project Team Members

| | Comments (5)
Project teams are built of people with multiple layers of skills and competencies. A few will be selected as project leads to have less responsibility than a project manager, but more than a team member. Project leads ensure smooth task management and reporting flow, but how many of them are allowed or trusted to make decisions? What level of decisions can they make?

The key to empowering a team member lies in the project manager's ability to get to know the person's strengths and weaknesses. Some people, although highly skilled, are weak at managing customers. Some have the ability to influence but aren't necessarily good at managing time.

In one of my earlier posts, I talked about delegating work to team members as a way to help them succeed. To be able to delegate effectively, project managers simply cannot pick one person and assign him or her a task without carefully considering that person's skills.

When empowering team members, the same rules apply. In some cases, you can only see the true colors of a person through action.

First, select someone with a suitable background and competencies. Then test the person with small decisions or tasks. Check if he or she can communicate effectively by having conversations to gauge his or her ability to think and act proactively.

When you empower team members by giving them greater responsibility, you can significantly improve the way a project is managed. Deadlines that require input or quick decisions can be met promptly, for example. Customer satisfaction can be improved because a team member doesn't have to go through layers of approval. And, those empowered team members may get a confidence boost.

What decisions do you trust your team members to make? Have you experienced any negative impacts by empowering team members? Do you think empowering team members improves project delivery?

Persuade Stakeholders for Effective Project Governance

| | Comments (1)
One of the biggest challenges faced by all sectors of the project management profession is persuading senior executives to focus on implementing effective project governance.

Governance is a "top-down" process. Most of the risks and rewards associated with a project or program are determined long before the project manager is appointed.

Effective project management delivers a realistic and achievable outcome efficiently. If the parameters for the project are unrealistic in the first place, the best project management can do is stop the situation from deteriorating further. Failure is guaranteed.

Wishful thinking is not an effective substitute for effective project governance. A Guide to the Project Management Body of Knowledge (PMBOK® Guide) does not have a miracle process that will magically transform an impossible set of objectives into an achievable set of objectives.

The organization's executives need to balance risks, rewards and capabilities to set realistic objectives and then use effective governance systems to oversee the delivery.

The only way to achieve meaningful change is by communicating to affect a change in the understanding of stakeholders. When senior executives require effective project governance, we can better assist them in establishing effective and robust systems.

If you're lucky enough to work in an organization with effective project governance, broadcast the benefits. If you work in an organization that could improve its governance, use your skills to advise upwards. If your organization is on the road toward effective governance, keep helping it along.  

If we are successful in making effective project governance the normal way organizations operate, the rate of project success will increase, as will the standing of our profession.

What can you do to help create the climate for better governance?   

4 Metrics to Help Spot Trouble for Agile Teams

| | Comments (3) | TrackBacks (0)
In coaching several agile teams and sifting through long lists of metrics, I've observed a core set of metrics that can help distinguish successful teams from teams headed for schedule slips:


Many teams have multiple team members who split time between projects. In most cases, it is better to have fewer people full time on a project than more people part time. For example, instead of having eight people working part time, try having four people work full time.

Why? We lose 20 percent efficiency each time we multitask, according to Mike Cohn's book Succeeding with Agile. Count the average percent of time each person is allocated to the project. Averages less than 80 percent should be looked at to see if the team is being pulled in too many directions.

Plan leak

This is the ratio of work planned compared to potential capacity. In theory, people could allocate up to 54 task hours per two-week iteration, but the team only plans an average of 30 hours. Then there is a problem with planning.

Fill your plan until you have 70 to 80 percent of the team's time accounted for. Eighty hours for a two-week sprint is not ideal because other important work is not represented by tasks (such as mandatory training, email, unexpected maintenance work).

In addition, have the team own its total task hours and let them "pull" work when they are ready. Assigning work to individuals may create silos and is based on imprecise estimates.

Execution leak

Compare the number of task hours left at the end of the iteration to the total planned. There should usually not be any hours left, but if the team meets this goal every time, it may not be planning aggressively enough. It's healthy for teams to have a small number of hours, say 5 percent, left over on a small number of their iterations (10 percent or less).


This shows how much unplanned work was added during the iteration.

In my experience, it is okay to add up to 15 percent because planning is based on approximate estimates and technical execution of the project may reveal new subtasks. But if more than 15 percent has been added, it's a sign the team is either not planning enough or they never say no to new requirements. Either way, they lack the ability to plan with enough diligence or to pause new work until future sprints.

What do you think? Have you used these metrics? What metrics do you use to help spot trouble?

Are You Sure Your Project Information is Secure?

| | Comments (2)
Fellow blogger V. Srivinasa Rao recently wrote an interesting post about the Global Distribution Model 2.0 that is launching soon. The model holds a lot of promise and is a great framework for implementing mobile global communications tools.  

Today, the fastest rising communications and computing technology is mobile. And while this development provides exciting possibilities for improved project efficiency, it does not come without risks. I'm focusing specifically on devices with a mobile operating system, such as iOS, Android, Windows Phone 7, Blackberry or Nokia.

The reason for my concern is the speed of adoption for the devices. They now play a role in every project I manage. It may be simple communications such as email between team members, text messaging and calendar functionality, or more sophisticated uses such as remote access to project data, project management software or even video conferencing. Yet 90 percent of the time, I find that no one is really thinking through the implications of using this technology.

Think about it: With this expanded communication comes an increased risk that your project's confidential or critical information could be exposed, intentionally or unintentionally.

This information can be controlled fairly easily by IT departments on laptops, but mobile operating systems don't allow for the same kind of security just yet. You must be wary of how information may be getting communicated over your mobile device.

Information "attacks" can come in several forms. At an event where "free wireless access" is offered, for example, someone who wants to gather data illegally can set up a US$50 wireless router, name it "[Event Name] Wireless" and watch as attendees innocently connect their devices to communicate with the rest of the team. Simply leaving your Bluetooth enabled in public locations can open you up to attacks.

It doesn't even need to be something that devious. All that needs to happen is for one of your team members to lose a device that has regulated data on it. In the United States, you'll have to officially report the incident to the Federal Government.

The key takeaway here is that as our world expands, we are being given exciting new ways to coordinate and communicate with our team members across the planet. We should take full advantage of this. But we should do it with our eyes open.

How do you protect your data on a mobile device?

Beyond Stakeholder Management

| | Comments (6)
My mentor in this field -- Julio Matus Nakamura, a project manager -- once told me, "In any organization, there aren't just processes, projects, strategies or tools. What really matters is people."

That lesson, learned long ago, taught me that no matter a person's position, he or she is a human being first. It's very important to build trust among human beings in order to believe in each other. When I realized that, I vowed to establish that type of relationship with my stakeholders -- to build that trust and try to create a more personal relationship with them.

In my opinion, in some cases it's more important to have a good relationship with the sponsor or customer than the results of the project.

I'm not suggesting you forget about your project's results or even the contract. Just that you should put the same emphasis in building a deeper relationship with your key stakeholders as you put in delivering good results and caring about contract issues.

Here are some simple tips that I have used for a while. I hope it may help you when building a relationship with your stakeholders:

1. Use basic manners: Always say hello, goodbye, thanks, please, well done, good job and I'm sorry. These are powerful little words that can make a big difference.

2. Show respect: Often when we are in a conversation with someone, we are not 100 percent in the conversation. You must be present. No excuses. When talking with someone, pay all of your attention to what the person is saying. Avoid thinking about your response when the other party talks; just listen carefully to what's being said.

3. Learn to read body language: We communicate more with our body than with our words. Learn to "listen" to the body of your counterpart and learn to speak with your body. For example, don't cross your arms during a conversation, as this can seem standoffish. Make eye contact during conversation and always face the person to whom you're talking.

4. Share something personal: Find affinities with your stakeholder wherever possible. This could be the university where you studied, the town where you grew up, vacations you've taken, books you've read, or your favorite team and sport. Make sure to find the appropriate moment to share these commonalities.

5. Break the ice: Read the environment around your stakeholder and discover his or her interests. At the first opportunity, bring those interests into the conversation.

What about you? What tools or techniques do you use to build trust with your stakeholders?

About This Blog

Voices on Project Management offers insights, tips, advice and personal stories from project managers in different regions and industries. The goal is to get you thinking, and spark a discussion. So, if you read something that you agree with — or even disagree with — leave a comment.

All posts represent the opinions of the bloggers.

Follow PMvoices on Twitter

About Bloggers

Keep checking back because the voices for this blog will continue to grow and change to represent a variety of regions, industries and opinions.

Read blogger profiles

Voices Poll