Voices on Project Management

> Back to Voices Home

January 2013 Archives

How to Build Ethics into Your Team Culture

| | Comments (0)
Ethical behavior is just as crucial as effective leadership in persuading stakeholders to cooperate and support the work of the project manager — and therefore contributes to successful project outcomes.

Ethical behavior has been a hallmark of PMI's drive to establish the profession of project management, supported by the PMI Code of Ethics and Professional Conduct.

What is less well understood is the crucial role leaders play in establishing the ethical culture of their organizations. 

One key direction ethical leadership takes is indirectly — across the hierarchy, to peers of the leader. There is also a cascading effect, with the ethics of a senior leader influencing a subordinate leader's behaviors. In turn, ethical conduct trickles down to the subordinate leader's team culture, and so on down the hierarchy.

As with any cascade, figuratively speaking, the flow is always downhill. An October 2012 study among more than 2,500 serving military personnel published in the Academy of Management journal supports two key findings from various business studies, including one published in the Harvard Business Review and one by Boston University professor Tamar Frankel:

  1. The ethical culture of a team is unlikely to be any stronger than the standard set by the team leader, and is usually slightly less ethical.
  2. The ethical culture of a less senior leader is unlikely to be any stronger than the standard set by the senior leader, and is usually slightly less ethical.

In short, the ethical framework of an organization is set at the top and standards can be expected to be similar or deteriorate as you move down the hierarchy and out into the teams.

Note that these studies were not looking at extreme ethical behaviors, such as dishonesty or discrimination — breaching these standards would offend most people. The research above focused on subtle but important aspects of ethics, similar to those found in the "aspirational" sections of PMI's Code of Ethics. These types of behaviors encourage individuals to develop as professionals, create a great place to work and urge external stakeholders to support the team.

The practical implications of these findings are that leaders need to "walk the talk" by engaging in ethical behavior. They need to create a strong ethical culture in their teams by providing the tools needed to help team members behave ethically, on a reinforced basis. 

Some tools to inject ethics into the team culture include: 

  1. Positive reinforcement, such as praising people for notifying you of a mistake they have made. 
  2. Encouragement of open reporting of "bad news" in any form.
  3. Establishment of systems that strongly encourage ethical behaviors, such as refusing to allow derogatory remarks in any form (jokes included). This would require backing by formal systems, such as clearly defined and protected "whistle blower" procedures.

Once created, an ethical culture in your team can be expected to have a strong effect sideways and downward within the organization — and outward to the wider stakeholder community. 

How do you encourage ethical behavior among your peers and teams?

Video Series: Women in Project Management, Part One

| | Comments (2)
Voices on Project Management presents a six-part interview with Beth Partleton, PMP, PMI Board of Directors, on "Women in Project Management."

Beth's background spans three decades of project, portfolio and risk management, particularly in the area of capital projects. She headed Miller Brewing Company's PMO and served as senior project manager and functional project manager of architecture and civil engineering. She has been a certified Project Management Professional (PMP)® since 1991.

Beth is a strong advocate for the value of the project management profession not only for organizations but also for practitioners. "Women in Project Management" provides her perspective on how women are closing the gap in traditionally male-dominated fields.  

In part one, Beth shares her road to project management; her thoughts on the misconception that project management is a male-dominated profession; and the strides organizations have made in including women on project management teams as well as some candid observations on what still needs to be done.

Fostering Cultural Awareness — Right from the Start

| | Comments (1)
Establishing a connection early on among team members is essential, but it can get complicated when they're from different parts of the world.



One of the elements I consider is what anthropologist Edward T. Hall describes as a person's cultural context level. Higher context cultures -- such as Italian, Latin American, Chinese and Indian -- place great value on interpersonal relationships. Lower context cultures -- such as U.S., British or German -- emphasize directness and logic. For example, non-verbal communication is more important in higher context cultures. In higher context cultures, the contract is a starting point for negotiation. In lower context cultures, the contract is the contract.

By understanding an individual's personal, national and organizational cultures, you can better align the team and gain greater influence.



I didn't just read up on this theory. I lived it. While leading a project in Brazil in 2001, some U.S. team members told me they were uncomfortable with how Latin American team members greeted them with hearty handshakes and kisses on the cheek.  



I knew I had to address the issue early on to set the tone for the rest of the project. So during our next meeting, I eased into the topic by showing clips of people greeting each other in movies or sitcoms, making sure none were from the United States or Latin America. Afterward, I asked team members how they would react if they were in a similar situation. This was a revealing moment as the team became aware of their cultural differences by "seeing" themselves in the video clips. This broke the ice and opened the floor for candid discussions. 



Since then, I've included cultural differences on the agenda for every first team meeting. I use that time as an open forum for us to share and record cultural experiences. I also create a repository with documents and video clips that can be later used to induct new team members.



I've shared this experience with peers, who agree that cultural awareness is a skill that should be developed and mastered. Incorporating a cultural differences exercise establishes respect and empathy for diverse values and behaviors, which in turn creates an open and accepting team environment.


How do you handle cultural differences of your team members at the start of each project? What are you doing to build cultural awareness?

Decomposing Requirements for Tangible Project Outcomes

| | Comments (1)
Delivering scope or fulfilling needs on a project is not always equivalent with adding value. In my opinion, a project adds value to an organization if its deliverables add value. 

Many project managers approach the project in a delivery-oriented fashion. They plan for, work against, and monitor and control the project's work through deliverables. Delivery-oriented project managers make the scope's outcome tangible in order to fulfill the project's goals. 

The first step to incorporating this project planning technique is to understand what a "deliverable" is. "Deliverables" are concrete and discrete artifacts of a project's outcome, such as products, functionalities, features, documents and plans. They can be obtained by "decomposing," or breaking down, the project's requirements in smaller, more manageable components. 

As you decompose requirements, keep in mind that you can structure and manage the project deliverables in various ways. Some of the most common approaches for different types of organizations include:

  • Spreading deliverables across project phases. This is typical for projects conducted in a waterfall fashion and for schedule-oriented projects.
  • Spreading deliverables across knowledge areas. Project teams  organized by areas of expertise (such as operations, legal or  finance) usually use this technique in their projects.  
  • Spreading deliverable across processes. This is typical for process-oriented projects.
  • Spreading deliverables across sub-projects. This is most effective in big projects with added complexity, where deliverables are specific for parts of the project but not for the project as a whole. 
  • Organizing deliverables hierarchically, from major deliverables to sub-deliverables. This is best for product-oriented projects.
As a side note, in agile projects, where teams are action-oriented, the work decomposition is done slightly different. The focus then is on epics, user stories and on the functionality to be delivered.

To decompose requirements effectively, I recommend following these tips:

  1. Break down the work in deliverables and sub-deliverables by focusing on "what" to deliver. Remember that decomposing requirements happens during the early stages of the project. Don't ask "when" in the project phase it will be delivered or "who" is going to take care of it. Save these questions for later, when sequencing the project work and building the project schedule.
  2. Organize the deliverables based on their relation to each other. Use a graphical form, such as a hierarchical tree (i.e., work breakdown structure, or WBS), a relationship diagram or a mind map diagram.
  3. Avoid over-decomposition — that is, excessively breaking down or over-detailing work. This leads to micromanagement or inefficient work management. A good general rule is to decompose requirements to the point where you can estimate deliverables, costs and time, and verify and measure results. 
  4. Since you are dealing with deliverables and not activities, use nouns to describe each deliverable. Don't use verbs, adverbs or other action-driven labels.
  5. Verify the accuracy of the decomposition at the end of each level. Each sub-deliverable should add up to 100 percent of the deliverable above it. 
Focusing mainly and steadily on the "what" is a pragmatic and efficient planning approach as you set up the project.

How do you decompose requirements?

Learn about the basics of project work planning, including the four main steps of planning.

What's the Story Behind Your PMP Certification?

| | Comments (4)
Long-time Voices on Project Management blogger Conrado Morlan, PMP, PgMP shares how attaining a PMP certification helped his career.

Project management practitioners like me, with more than 20 years of experience, learned about PMI and the PMP® certification in ways much different from today. 

My first exposure to PMI, A Guide to the Project Management Body of Knowledge (PMBOK® Guide) and PMP certification was in the late 1990s. It was during a training program to attain PMP certification -- and in Spanish, no less -- at the company I worked for in Puebla, Mexico. 

My colleagues and I questioned the benefits of this certification, which at the time was not well known in Mexico. In addition, the written exam was in English. That did not make the PMP more attractive. 

I left the company before taking the exam. Yet in my new job, I discovered that the knowledge I acquired in the training program was very helpful. Without prompting, I used some of the best practices in the PMBOK® Guide, especially those related to risk and project integration.

As I progressed professionally, I moved to the United States and learned more about PMI chapters and global congresses. I became a member and a regular at chapter meetings. 

By this point -- even with eight years of practical experience in project management and applying best practices in my work -- I realized I needed to take it to the next level: earning PMP certification. Sure, professional experience and on-the-job-training are important -- but I was only recognized for that at my company. Attaining the PMP meant that the world's largest association for the profession would validate my professional experience. 

In the lead-up to my exam, I was traveling intensively for my job, and the PMBOK® Guide became my travel companion. While abroad, I visited local PMI chapters and learned about running projects in different settings. The interaction with members of PMI chapters in other countries helped me tweak my project plan. The combination of studying and exchanging ideas with practitioners internationally were fundamental for my PMP exam preparation.

In December 2005, I attained my PMP -- and I have never regretted it. Achieving the certification brought me immediate benefits. After I notified my manager, he awarded me an incentive bonus. A week later, I was selected to lead one of the most challenging projects of the portfolio. 

Over the years, I also became more involved in my community, volunteering at events such as PMI item-writing sessions. In 2011, I was honored with the 2011 PMI Distinguished Contribution Award. I'm not saying that getting my PMP awarded me recognition and experience overnight, but I needed it to get to the next stage in my career.

I still find project professionals who think the same as my colleagues and I did in the late 1990s. The most frequent questions I hear are: Why should I earn a certification or a credential, if I am a senior project manager with many years of experience? How does a certification or credential make me different? 

To these, I respond with a question (Why not step out of your comfort zone?) and a thought (What made you successful in the past will not make you successful today).

The truth is that, just like doctors, project professionals need to update their knowledge to face the challenges in today's project world. PMP certification and PMI membership give you access to share and acquire project management knowledge, stay up to speed on new trends, and join a group of global volunteers contributing toward the advancement of the profession. Most importantly, certification helps you reach the next step in your professional life. At least that is what it has done for me.

How did getting a PMP help your career? Are you still considering getting one, and why?

6 Communication Tips for Distributed Agile Teams

| | Comments (1)
Distributed agile teams have to overcome distance and time to achieve what Alistair Cockburn describes as "osmotic communication" -- tacit knowledge and spontaneous discussion. Speakers at an October 2012 summit on distributed agile teams offered six tips for improving high-bandwidth communication:

1. Make a Time Zone Table. You may know this already, but this tool is a must for finding times for meetings required by your agile process, including daily Scrum meetings, estimating, planning, demos and retrospectives. To create one, use a spreadsheet to list rows of times for potential meetings and corresponding time zones for all members. For example:

PMI Voices Bill Krebs Time Zone Table.pngMind the International Date Line and daylight savings time. Then apply your matrix to a range of dates, before or after daylight savings time changes. For example, a December call between New York and India would be at 7:00 a.m. EST/5:30 p.m. India time -- but in June, it is 4:30 p.m. India time. Online date and time tools are useful when putting together this matrix.

Be aware of each location's typical work hours, and make a separate table or calendar of holidays. 

2. Break language barriers. Even when remote team members speak the same language, don't assume smooth communications. For example, some people have heavier accents than others. Language barriers can particularly impact the efficiency of agile teams, which include daily standup meetings. One solution is to assign a spokesperson with better language skills in the team's common language (English, for example). Also, be mindful of cultural metaphors and idioms that may not make sense in other countries. 

3. Increase visibility. Because agile teams use task boards to show stories and associated work, communications can become complicated for distributed teams. To show the many visual elements used in agile -- from notecards on a wall to task boards -- teams need to think beyond web cameras. Try using online tools, which can range from free task boards to full-service applications with analytics and portfolio management. Or opt for spatial collaboration environments such as Terf©. Terf shows cards for each task on the wall in the context of other charts and team members. Online virtual rooms deliver contextual information and a sense of co-presence, where distributed agile teams experience the collaboration they are accustomed to in a face-to-face environment.

4. Improve sound. Agile teams rely on high-bandwidth communication. And clear audio is essential in the frequent meetings necessary in the agile process. So if you are using voiceover IP, avoid wireless for a more stable connection. Little things go a long way in improving sound quality, too. Use a USB headset or ear buds to avoid feedback and echoes from built-in speakers. Consider investing in a better microphone. Some have digital signal processing to reduce noise, some are excellent for large rooms and some have different patterns to accept or reject sound. Finally, provide text chat for backup communication and questions during a long discussion. 

5. Go on the record. Recording audio from conference calls and screens from slide presentations keep team members informed if they cannot attend in real time. This is especially helpful for informing offshore team members in crucial content meetings, such as agile planning. Just beware that without the interactivity, it is harder for people to remain engaged. So with recordings, try to keep it short.

6. Organize by component, not role. Some teams may be tempted to assign people in one location one role. Yet team members on agile teams are encouraged to share roles. So what's the solution? Cross-functional teams by location, working on a subset of your project. This improves communication between locals, reducing overhead.

What communication challenges and solutions have you experienced for your distributed teams?

Go beyond communication tips -- find out how to apply measures and metrics of agile techniques into your projects. PMI members can dig deeper into the topic, with expert tips on the many facets of agile.

Want a Career Edge in 2013? Carpe Diem

| | Comments (4)
In my last post, I promised some pointers for what to do after you've identified your career goals.

My suggestion is to toss them aside. It may seem to defy career logic, but here's why it works: While our definition of success evolves slowly, the specific steps and goals that get us there can and should change with the circumstances. And circumstances are changing ever more rapidly.

For example, a meaningful goal can quickly turn into a waste of time with a corresponding opportunity cost.

I remember sitting down for my first career-planning session when I got into line management at IBM in the late 1980s. My manager and I carefully mapped out a plan that included various entry-level positions, followed by roles in middle management and then executive management. It all looked pretty good. Then along came the great upheavals of the late '80s and early '90s that stripped away entire layers of middle management.

I found myself with a plan that led to a place that no longer existed. I was trapped in career limbo, until finally I was forced into a role as a system architect. Frankly, that didn't work out very well. But in that role, I attended a conference on software development and learned about project management as a profession. It intrigued me, so I sought out more information about it. 

You see, the system architects on my team were brilliant technologists. But they weren't good at planning their own work. Opportunity! I suggested that perhaps I could add more value in the role of project manager. The rest, is history.

Had I relentlessly pursued the goals outlined in my career plan, I probably wouldn't have survived past 1992. But when serendipity and opportunity intersected, I seized the moment. As a result, I've had a rewarding career, one in which I see myself as successful. (In this regard, my perspective is the only one that counts.)

The moral of the story? Where you will end up in your career 25 years from now may have nothing to do with your grand visions of today.

Here are a few other suggestions to keep you on course but flexible:

  • Keep a short horizon. The further out you plan, the less your actual future will look like your vision of it.
  • Seize the moment. Anticipate serendipity. Plan for it. 
  • Stay aware of what's going on around you and inside of you. Revise your goals accordingly.

Systematically pursuing relevant goals and adopting new ones as others become irrelevant is a delicate balance. But the resulting career agility is well worth the effort.

The Scoop on Requirements Scoping

| | Comments (1)
We've all been there. When a project's scope isn't properly managed, it can lead to schedule delays, budget overruns or not meeting project goals.

Requirements scoping can help keep projects under control by establishing what criteria — such as prioritization — will drive decisions. The process also clearly details what the project will deliver, and perhaps just as importantly, what it won't.

Depending on a project's complexity, goals and project management approaches, there are various ways to manage requirements scoping. Here are three of the most common.

1. Early scoping assumes all scoping is done as part of the project charter or during the scope definition. The approach relies on precise estimations of required resources, budget and time. It discourages scope creep and requirements changes.

The advantage of early scoping is that it facilitates starting project work ahead of time. On the other hand, poorly estimated efforts can translate into budget or schedule overruns, resources bottlenecks or missed project goals. 

Early scoping is recommended for projects where the main focus is on the scope, and on ones with no, or minimal, budget and schedule constraints. For example, early scoping works well on consolidation or integration projects, where the constraints on the scope (budget limitations, for instance) impact objectives.

2. Late scoping is performed after collecting, analyzing and even designing the requirements. At such late stages, efforts estimates are much easier to assess and generally more accurate.

Although late scoping can keep a project within budget and schedule boundaries, this approach has a considerable downside: Efforts spent for out-of-scope requirements are wasted or deferred. Consequently, this leaves less time, budget and resources for addressing in-scope requirements — the ones that matter.

Late scoping is recommended for projects addressing requirements that have similar (and not critical) relevance for the project's outcome — for example, regular maintenance projects.

3. Iterative scoping is a balanced, incremental approach. The entire scope is broken down and prioritized by items that have the highest relevance. These will be addressed in the first scoping round. The rest of the requirements, as well as potential changes or rework, are subject to scoping in subsequent iterations. 

The requirements scoping and the project work advance in a rolling wave approach. Iterative scoping is especially useful for IT and agile projects.

How do you manage requirements scoping on your projects?

Project Adjournment for Virtual Teams

| | Comments (2) | TrackBacks (0)
While project managers often talk about building a virtual team, they rarely discuss disbanding one. I recently adjourned the virtual team I'd led for the past four years. As a dispersed team, we initially experienced some issues around cultural differences. But we came together eventually and produced the expected results for the organization. When the time came to close the project and disassemble the team, a different kind of challenge arose. 

The first issue I encountered was that some team members didn't want to leave the team. Over the life span of the project, we'd built a strong bond. And there was another layer of complexity as team members' cultural traditions and values informed how they expressed their disappointment.

As I helped the team to reach closure, I discovered the more "face-to-face" time, the better. I tried to reduce the distance that separated us with video conferences. During these meetings, I would explain that team adjournment wasn't a loss, but rather an opportunity to meet new people and take on new tasks. With some team members, an impromptu call before the adjournment meeting worked fine. With others, I scheduled a conference before and after the meeting to ensure they would be okay. 

The second challenge was preparing team members for their next project assignment. During the transition process, it was important to see their reactions, so video conferences were helpful here as well. I also tried to keep the focus on how team members could leverage their experiences in our project for their next assignment. Finally, I introduced some team members to project managers in need of skilled resources. Two of my former team members joined projects this way.

In the end, the team members understood that our strong bond wouldn't end just because the project did. We're always just an e-mail or a phone call away.

As a virtual project manager or team member, what challenges do you face during team adjournment?

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