Voices on Project Management

> Back to Voices Home

March 2012 Archives

Best Practices to Engage with Cross-Cultural Teams

| | Comments (15)
The increase of international projects has made working and communicating with people of different cultures and languages more common. Preparing and understanding another person's culture, mind set, sensitivities and communication styles can maximize the chances for successful outcomes.

Some of the most common problems of cross-cultural working arise from three main misconceptions:

1. Assuming your way is the correct way
In my experience working in the West, it's generally considered a positive trait to be able to communicate assertively, directly and voice an opinion.

But for Far East and Arab cultures, communicating in this manner is largely considered rude and aggressive. Emphasis is placed more on honor, pride, politeness and relationship building as a means for successful collaboration.

2. Assuming everybody understands your language
When I began working in the Middle East, I wrongly assumed that my strong British accent and articulation of the English language was clear for everyone. But just because I spoke clearly did not automatically mean that everyone understood me.

In fact, politeness prevented people from telling me truthfully that they didn't understand what I was saying. Though English is spoken around the world, it is still a second or third language for others. Allow time for others to process what is being said.

Additionally, the word "no" does not exist in some cultures. These cultures breed an optimistic disposition, and the answer to everything is a nod of the head, whether it's impossible deadlines or difficult requirements. If left unchecked, the end results will lead to frustration, misunderstandings and differences in quality expectations.

3. Selecting organizations or individuals on language abilities
When selecting suppliers, implementation teams or project staff, it seems more reassuring to recruit based on English language skills. The assumption is that communications will be easier and mitigate risks associated with translation.

This can actually backfire as the ability to communicate in English does not necessarily mean a person or organization is suitable for the job.

Based on personal experiences and lessons learned, here are my suggestions for good practices for project managers who work across cultures on projects:

  • Begin conversations with a warm and engaging welcome. If you can learn the greeting in the local language, this immediately breaks the ice and leaves a good impression.
  • When speaking English, speak slowly and use simple words.
  • Limit professional jargon and unfamiliar terms until you are sure they are understood.
  • Ask questions and politely request the other party to share their understanding.
  • Never show frustration at having to explain something more than once.
  • Insist on an opinion or clarification if one is required.
  • Listen to everyone's opinion. It may be the person who is not speaking or is not the most articulate has the most valuable input.
  • Be patient and tolerant in accommodating others' styles of making a point.
  • Be astute as to what is being said and why.
  • Follow up meetings with appropriate written communications to confirm times, dates, costs, and any other agreements or actions. Insist on a reply confirmation.
  • Ask, request and check for constant feedback
  • Smiling, relaxing and showing personality helps build relationships faster.
  • Deliver on your commitments. This builds trust and respect. It sets a standard and makes it easier to hold others accountable.
  • Employ multilingual people who can advise on cultural norms.
  • Spend time building communication networks.
  • Consider cultural training, guidebooks or manuals for all team members working on cross-cultural projects.
What advice or experiences of interacting with other cultures can you share?

Read more posts on risk.
Read more posts on best practices.

Coach Your Project Teams by Example

| | Comments (0)
Have you ever thought that as a project or program manager, you indirectly set a precedent on managerial style, behavior, competencies and professionalism. Unconsciously, we are showing our team members how to manage crises, deal with stakeholders and so on.
 
There are many ways that we can unknowingly coach our team members. When dealing with stakeholders, for example, project managers have the authority to set limits and control the discussion to stay on the subject. To be able to do this, we need to know the business process at both a high level and in terms of the customer's business goals.

In dealing with stakeholders, we indirectly coach our project team members to do the following things:

  1. Exercise a project manager's authority when the situation calls for it
  2. Understand the strategic direction the customer is embarking on
  3. Display at least a little business acumen and subject knowledge
  4. Communicate direction effectively with the objective of getting good results
  5. Control meetings and discussion; ensure objectives are met within the allocated time
As project or program managers, we need to tackle our day-to-day tasks strategically in order to be an effective coach and leader. Our team members observe every communication we make and actions we take.

How have you indirectly coached your team members in your projects? What examples do you set for your team members to follow?

Read more posts on coaching teams.

Technology Helps with Project Lessons Learned


| | Comments (6)
Conducting lessons learned and project reviews has been a practice that many organizations have used over the years to help their next projects be successful.
 
It's a continuous cycle of retrieving and assessing your project information.

As the project manager, you should call a meeting and discuss any issues or tasks that went wrong and what could have been done to improve the project. The improvements should be incorporated into the processes of the next project, which typically have a better outcome. Then that project will have its own challenges that will also need to be addressed. And so it goes.

If you aren't doing some type of project review or lessons learned, you will most likely repeat actions that have caused the project failures, budget overruns, scope creep, inadequate stakeholder involvement, technology mishaps and other problems that plague your projects.
 
Yet some project managers find excuses not to host these valuable meetings. One such excuse is a geographically dispersed team. There's no need for a dinosaur mentality to achieve a project review. Use today's advanced technology to your advantage when conducting a lessons learned meeting:

  • Conduct a lessons learned session in the same way as you would hold a virtual team meeting. Emphasize the goal of targeting improvements. Use a virtual whiteboard to list pre-determined questions or to show a timeline of how the project progressed. Allow the team members to post their version of the events that could be improved upon in the next project. 

  • Consider posting a social media page to capture comments. This venue would allow you to reach stakeholders in their habitat, possibly presenting more candid comments.
  • Send out a survey. Then collect and analyze the results. Gathering the data this way could lead to more impartial responses and a scientific alignment of the priorities that should be addressed.     
Traditional methods for conducting lessons learned will always prove beneficial as well. Bring in an outside group or consultant to assess projects and provide recommendations. As the lead and manager of an important project delivery, designate time to look back so that history does not repeat itself.

Do you use technology or traditional methods in your lessons learned?

Project Management Adds Value to Operational IT Departments

| | Comments (2)
The structured approach of project management can add value to operational IT departments. What makes this work is the approach that the project management office (PMO) or the project management team defines in its project management methodology for release of the systems into production environments.

Operational departments should execute with a process often referred to as "steady state transfer." This process gives the project team the opportunity to validate all the key production processes such as the support, maintenance cycle, systems restore and sanity testing, which is the basic testing of the system functionality.

Project teams launch the steady state transfer after successful tests show the systems are ready to be released into the production environment.

This validation step -- to ensure that the system processes are well mapped between various support departments -- adds value to the operations teams. The validation step is done during project execution using the steady state transfer process -- and without generating special projects.

This validation step in the project management practice guarantees process interface manuals are updated with any changes to the processes and the test results.

The operational departments work with the project team to complete this task and thus make a smooth transition into the "steady state" of operation.

What processes does your organization use to achieve the same results?

See more posts on IT.
Read more from Dmitri.



Project Change Challenges

| | Comments (10)
Who should lead the change challenge: organization management or project management?

The project team probably has a better idea of the technical aspects of the changes required. But, the organization's management initiates the project and has overall responsibility for achieving the intended benefits after the project is complete.

In my opinion, change management is an organizational responsibility. The role of project management is to focus on creating the deliverable effectively and supporting the organizational change effort.  

In short, the project management team works for the organizational change management team. However, I have seen many situations where managing the change is treated as a project responsibility.  

For those project teams undertaking change management, the change challenge is getting the necessary buy-in from organizational stakeholders who have to make effective use of the project's deliverables to get the expected value from the project.  

There is no point in the project team being happy with its work if no one uses it. The way the organization works has to change if the deliverable is going to be used effectively to create value for the organization and generate a ROI on the investment in the project.

Effective communication with the affected stakeholders is a must when addressing the change challenge. These communications follow a fairly standard pattern:

  • Explain the reason for the change needs so they are understood.
  • Define, communicate and support the actual changes to work practices and behaviors though training or other skills development activities.
  • Provide ongoing support to embed the new practices into the operating culture of the organization.
Do you think change management is an organizational or project responsibility? Which option do you think is best for effectively engaging with the affected stakeholders? Which option best facilitates the overall change in behaviors needed to generate a successful project outcome?

See more posts from Lynda.
See more on stakeholder management.

Use a Framework to Plan Project Requirements

| | Comments (3)
Project requirements are rarely collected and made available in a final form to a project team. Instead, requirements are often collected through an elicitation process, which involves a discovery, analysis, understanding and validation endeavor.

Usually, a business or requirements analyst carries out the requirements elicitation process. The project manager is typically responsible for planning and setting up the requirements elicitation and management framework.

Well-planned and well-managed project requirements are common characteristics of successful projects.

This simplified framework can be a guiding requirements checklist for project managers:

Organizational assets: Identify the available organizational process assets for planning and managing project requirements. The organization or project management office might already have standards, guidelines and templates that can or should be used as a starting point.

Stakeholders: Use the stakeholder register to identify the stakeholders who will help provide, collect, analyze and document the project requirements.  

Categories: Identify and categorize the requirements types that are to be elicited, such as:
 
  • Project requirements: Business requirements, end-user requirements, functional and non-functional requirements, etc.
  • Product requirements: Technical requirements, product features, functional requirements, etc. 
  • Indirect requirements: Overhead imposed by organizational or enterprise environment and standards related to security, regulations, infrastructure and industry, etc.
Channels: Identify the channels through which requirements will come in, such as business-use cases, focus groups, requirements workshops, surveys, product introspection, reverse engineering or  imposed by the organization.

Documentation: Identify how requirements will be documented, whether it's textual form, graphically or using a formal requirements language. Identify the way requirements will be tracked -- through requirement tools, Word documents or spreadsheets.  

Maturity Index: Establish the criteria by which requirements are validated and qualified. Is it clear? Does it make sense? Is the criteria aligned to the project vision and goals?  

Prioritization: Identify the criteria on how requirements will be prioritized and scoped. For instance, list the must-haves first. Then come the "quick wins," requirements based on the owner prioritization, complexity and costs, the project phase, etc.

Risks: One of the main inputs for the project risk management plan are the scoped requirements. Identify the requirements posing a risk to the project. Develop risk mitigation, response and tracking plans.

Change management: Establish the criteria for detecting scope creep and basic rules for handling requirements changes for applying the change management process.  

How are you planning and managing your project requirements?

See more posts from Marian.

See more on project planning.

The Optimistic Team for Project Management Success

| | Comments (3)
"A pessimist sees the difficulty in every opportunity; an optimist sees the opportunity in every difficulty." -- Winston Churchill

About 100 years ago, Ernest Shackleton was looking for a crew for a challenging project: to produce a map of the South Pole. It is said that he published an ad in the local newspaper looking for team members with creativity, a good sense of humor and technical skills.

Fast forward to the present day. Dr. Martin Seligman, director of the Positive Psychology Center at the University of Pennsylvania in the United States, is the founder of positive psychology, which focuses on the study of such things as positive emotions, strengths-based character and healthy institutions.

Dr. Seligman theorizes that in order to choose people for success in a challenging job, you need to search for aptitude, motivation and optimism.

This "explanatory style" theory, which indicates how people explain to themselves why they experience a particular event, can be applied to teams, too, according to Dr. Seligman. He based his hypothesis in three basic predictions:

If everything else remains unchanged, the individual with a more optimistic explanatory style will succeed. This happens because he or she will try harder, particularly under bad circumstances.

The same thing should hold true for teams. If a team can be classified by its level of optimism, the more optimistic team should achieve its goals, and this will be more evident under pressure.

If you can change the style of the team members from pessimistic to optimistic, they will achieve more, particularly under pressure.

The next time you need to pick a project team member, consider their optimism in addition to his or her technical competencies.

How do you choose your team members? What characteristics do you take into account when integrating members to your team?

Read more from Jorge.
Read more about teams.

Help Celebrate Project Management Achievements

| | Comments (0)
There are some stunning stories of success out there  -- too many of which go unheralded. Here's your chance to change that with the 2012 PMI Professional Awards.


You've got plenty of options -- from project and individual awards to research and literature awards.

Consider that peer you've seen contributing to the advancement of the project management profession or PMI. Now's the time to acknowledge all that hard work by nominating him or her for the PMI Distinguished Contribution Award. Nominee(s) don't have to be a PMI member and may work in any field.

Doing well should give project professionals more than just that "warm and fuzzy" feeling. Shine the spotlight on projects that improve the wellbeing of a community, or achievements that apply project management principles to the pro bono delivery of goods and services. The PMI Community Advancement Through Project Management Award is offered in Individual, Organizational and PMI Chapter categories.

Nominations for both awards must be submitted by 1 April 2012.


All awards are presented among your peers at the PMI Awards Ceremony, which is held in conjunction with PMI® Global Congress 2012 -- North America (20-23 October in Vancouver, British Columbia, Canada).

No one knows excellence in project management like you and your peers. So nominate a deserving colleague today.

Learn more, download applications, and watch videos of past award winners and nominees. 

Read more about PMI awards.

Resolve Communication Issues in Projects

| | Comments (8)
After a recent project progress meeting with my team, one of the senior members and I discussed the face-to-face communication challenges we have with other members.

We concurred that when the person receiving information has a low retention, it results in false assumptions and misunderstanding the topic of discussion.

Why is this happening? Why, if the person receiving information confirms that everything is clear, do we still we face communication issues in projects? Usually, it's because taking notes in a meeting is going away, as many team members wait for a meeting recap that notes their action items.

In face-to-face communication, we spend most of the time listening -- and apparently, we're not good at it. We filter what we want to hear and that may result in a broken message.

The senior member of my team referenced earlier is part of the silent generation. He mastered his listening skills in an environment without all of the ways to "replay" conversations that we use today.
 
In addition, he mentioned that the communication environment was "less polluted" than today, where we are bombarded with things that affect our ability to pay attention.

I asked the senior team member what are the key elements of good listening skills, based on his experience. He recommended:

  • Pay attention to the dialogue and receive the message.
  • Acknowledge the message using positive expressions, such as "OK" or "I see."
  • Confirm the message was received by summarizing what was discussed.
  • Ask questions to the person giving information during and after the discussion.
What are the face-to-face communication challenges you have experienced with your team? Do your team members pay attention when you speak?

Plan an Effective Project Meeting

| | Comments (5)
On a project management forum I frequent, someone asked whether or not it was rude to use digital devices during meetings.

Some responses were flat out rejections of using digital devices. Other responses were accepting of using technology while others are speaking.   
 


Personally, if you are not being disruptive, I don't think it's rude to use your digital devices in a meeting. I think what's more important to note is why people are using their digital devices during the meeting.

As a new project manager, you will probably be hosting many meetings for a project.  It's up to you to stay focused even if the participants aren't captivated the entire time.

As project managers in general, we should really take a good look at why we call meetings at all.
 

You may think you've called everyone together to get their input. But how many people did you invite? What often happens is that a few  people talk at once, and several people are left out and unable to contribute.They will inevitably find a more useful way to spend their time.  
 


You may think you've called a meeting at a good time because everyone was available on the calendar at the same time -- finally. But realistically, almost everyone has something going on before and after your meeting. Your meeting isn't the only thing occupying their attention. An empty space on a calendar really isn't an empty space.
 


As project managers, we need to ask ourselves what kind of meetings we are calling, what's the purpose, who must be invited and why to determine if a meeting is the absolute best way for you to impart or gather a particular type of information. The reason for calling a meeting should not be because it's the easiest way to give information or to get input.   

If you do find that you must meet, consider having several smaller meetings in small spaces that engage your core audience. Invite three to five people instead of a huge group. You can even adopt the agile practice of having 15-minute stand-up meetings to encourage groups to focus and get through agenda items quickly.  



Sitting in a room waiting to be engaged is bound to lose anyone's attention. If you keep your attendee list short, even if the meeting is long, there is more audience engagement and less individual downtime. Most importantly, there is less opportunity for someone to tune out because they feel no one is paying attention to them.

How do you engage team members during meetings, and do you care if they use digital devices?    

Read more posts from Taralyn.

Read more about project planning.


How Project Managers Can Execute Force Majeure Clauses

| | Comments (3)
The revolutions and demonstrations last year in the Middle East and North Africa, dubbed the Arab Spring of 2011, was a trying time for project managers in the region. As we near the first year anniversary of these historic events, we face more uncertainty.

We have witnessed the evacuation of expatriate staff, the relocation of operations, and an unmotivated local workforce. Project managers still see strikes, riots, civil disobedience and tension.  

Some projects have been derailed, failed to meet their objectives or are late. Customers have faced contractors, suppliers and developers absolving themselves of their contractual responsibilities by pleading "force majeure."

"Force majeure" is a common contractual clause that frees parties, bound by a contract, from liability or obligation if an "act of god" happens. Unless these acts are clearly defined, they are assumed to be extraordinary events with an extremely low likelihood of occurring.  

If used, force majeure clauses shift risk allocation from project contractors to their customers or other contractual stakeholders.

Organizations with projects in regions where force majeure events have taken place should prepare for ongoing conditions. To reduce the potential for conflict and ambiguity, organizations should add more contractual detail and definition to force majeure provisions in existing and new contracts. It eases tension and increases the prospect of sharing the responsibilities of cost and impact from these events.

Project managers can follow these good practices to add detail and definition to force majeure clauses in the following way:

Define what circumstances and events constitute a force majeure.

What constitutes force majeure in my region seems to be open to interpretation. My advice to project professionals is to provide as much clarity to this clause as feasibly possible by listing examples and inclusions.

Depending on the project's nature and location, the list might highlight political unrest, riot, war, invasion, terrorism, civil war, rebellion, revolution or insurrection. Other events could be radiation leaks, nuclear accidents, toxic explosions and natural disasters.

Define what constitutes the end of a force majeure.

A demonstration or strike would have a start and end time, for example. However, this event may have ongoing implications that could disrupt project work. This may include changed work conditions, reduced resource and productivity, or loss of utilities, materials and equipment.

The force majeure clause should detail whether these impacts are the reasons for non-performance and non-liability for damages.

Agree on a formal process in the event of a force majeure.

There should be additions to the clause on:

  • Formal notice time
  • Method of notification of a force majeure event
  • Process for executing mitigation responses
  • Agreement on a neutral country where arbitration can be held
Identify risk planning and mitigation responsibilities.

Project managers should identify risks and responses associated with continuing the project work such as:

  • Renegotiation of contracts reflecting any changes or cost increases in the market
  • Force majeure insurances, associated guarantees and contingency funds
  • Clarity on when to reasonably employ mitigation responsibilities, the costs and time period of mitigation efforts, and whether these efforts should be shared or incurred and for how long
  • Revision of schedules or extensions for projects with fixed completion dates
  • Recovery of agreed costs  
  • Eventual termination of the contract
What advice can you give project managers in force majeure situations?

Read more posts from Saira.

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