- Seek out your sponsors. They should be the source to go to when trouble arises. Not only is it likely they will have encountered something similar in the past, but they can also provide additional budget funds, more resources or reinforcement for areas in conflict.
- Consult with your team. Bring everyone together, discuss the problems surrounding the project, and begin to discuss counteraction and next steps. Steer away from blame and trying to determine who is at fault. Beware especially of ganging up on the customer. Team members may want to take the position that it's the customer's problem, not the team's. But be clear that the point of getting together is to determine how to solve a problem project, not pass it off as someone else's fault. Instead, gear questions toward possible solutions and the support needed to achieve them.
- Rely on backup and supporting information. Most likely, you will have monitored risks and issues all along and kept a good repository on your project. If so, you will be able to locate the exact information that helps address your problem. For example, you may be over budget because equipment purchases ate even beyond what your contingency allowed, and now a project sponsor or customer may be questioning the overrun. You should be able to pinpoint the authorization you received to make that purchase.
- Enlist outside resources, if needed. Lessons learned or a fellow project manager could be consulted for knowledge transfer and experience. You could even call in an outside contractor for a specific need.
- Remember that a halt is an option as well. Most times, this is seen as negative, and the project is considered a failure. But that is not necessarily the case. Sometimes, halting the project is the necessary solution, and it doesn't have to have horrific implications. If it isn't halted, the project could accumulate astronomical costs. The trouble could consume the project to the point where it would need to be shut down. A halt can also help you assess if the project is still meeting objectives (which could be the source of the problem). Stopping the project in its tracks could help you to determine if you need to redirect funds and/or resources.
More posts in Best Practices
A project manager's first global project marks a pivotal time in professional development. A project with global scope offers an exciting opportunity to work with people from many different cultures and skill sets.
However, global projects also come with unique challenges. These can include large physical distances between implementation teams, language barriers, country-specific regulations and other considerations that can negatively affect your project.
To get off to a good start, project managers need to manage the differences between global and co-located projects within these essential elements:
1. Requirements: On a co-located project, there is a single set of project requirements. On global projects, it is common to encounter both global (such as quarterly financial reporting) and country (such as provincial tax) requirements. Failure to consider them can cause painful functional gaps upon implementation. Work with your project leadership team to define a prioritization scheme for both types of requirements. For example, prioritize the country requirements by regulatory mandate, business value and desired need. A prioritization scheme helps you achieve overall balance in meeting the project success criteria.
2. Estimation: A global project typically features added complexity and costs not found with a co-located project. This calls for estimation to include additional effort to manage the previously mentioned requirements, as well as cross-geography coordination. The latter can include things such as team member travel time and global communications. In addition, there can be additional costs, such as import duties on equipment, that can add to the overall estimate. To ensure good estimation, identify global and local estimation components to more accurately account for the additional complexity.
3. Scheduling: Scheduling milestones, effort and resources on global projects is one of the greatest challenges for a project manager. The first thing to remember is to include country-specific scheduling considerations, such as regional holidays and vacations. In addition, always leave room in the schedule for project risks that can arise from unstable governments, new regulations and labor disputes. Finally, be prepared for unexpected surprises from nature, such as snowstorms, floods, volcanic eruptions and other disruptions. If such an event happens, meet with your leadership team to discuss whether to reset the project schedule around the unexpected surprise.
While global projects can present some unique problems, they also can be very rewarding when managed properly -- even if a volcano erupts!
What tips do you have for first-time global project managers?
During the summer, for example, temperatures can reach as high as 122 degrees Fahrenheit (50 degrees Celsius).
Project managers working with or in the Muslim world also need to plan for Ramadan, when the majority of the population fasts between sunrise and sunset. Then there's Eid al-Fitr, a national holiday that marks the end of Ramadan. Its importance is similar in scale to Christmas or Yom Kippur.
These combined events mean project managers must plan meticulously to ensure minimum disruption to their project schedules.
During this one month, the expected impact on the construction sector alone is a reduction of productivity by 40 to 60 percent. The main causes are heat and a fasting workforce that is unable to work at full capacity.
Additionally, project managers in construction face government constraints, which forbid laborers to work more than six-hour shifts in the day. They must stop working at noon and wait until it gets cooler to start again.
To keep project schedules moving during the very hot weather and major holiday, the key is to plan, plan -- and plan some more. These planning best practices can help:
- Begin planning for special events about three months prior. The project manger should meet with the customer, contractors and suppliers to agree on expectations, tasks and deadlines.
- Determine activities that can be moved up or delayed to compensate for risks during the special event, such as climate, absent staff and lower productivity.
- Employ more staff to compensate for loss of productivity.
- Keep a sharp eye on daily logs. Doing so will minimize risk -- especially in cases where work hours or the calendar have been altered and extra resources have been employed.
- Communicate with teams on when they expect to complete tasks. Coordinate dates and lines of escalation in the absence of managers.
- Ensure health and safety of employees in the work place. In the case of heat, plan for generators to cool work sites, for example. Provide plenty of water, appropriate clothing and equipment.
PMI's recent 2012 Pulse of the Profession report found that more than 70 percent of respondents always or often use risk management techniques to manage their projects and programs and these practices lead to higher success rates.
Here's an example of how risk management could have saved a project:
A project manager oversees an electrical team that is responsible for installing electrical and audio-visual equipment. The construction and civil engineering teams hand over the completed and decorated site, ready for the final phase of the project. To the project manager's dismay, the projectors do not align with the screens, rendering them not fit for the purpose.
What went wrong?
The civil and construction teams had altered the dimensions of the rooms; the customer failed to communicate the changes to the electrical team. Assuming the project was executed according to plan, the project manger planned and submitted the electrical drawings based on the original dimensions of the room. These plans were made redundant when the room dimensions changed, which upset the equipment's position.
To correct the situation, the project manager drew and submitted new electrical drawings. The site's walls and ceilings had to be reopened to accommodate the changes, which caused delays and increased cost, rework -- and frustration.
Had there been a robust risk identification and implementation plan, they would not be in this situation. Too many assumptions were left unchallenged and risks pertaining to the many external dependencies were overlooked.
As part of this risk management, proactive communication with the customer and other teams should have been planned. For example, the project manager should have considered and asked questions about how the contractors and sites would be monitored and controlled. What would the frequency and type of communication be like with stakeholders?
There should have been an assessment of 'what if' scenarios. What happens if the deliverables are not as expected? What are the risks if there are problems with contractors? What is the impact of not having dedicated resources on the team?
These types of discussions and questioning would have alerted the project manager and team to proactively plan to manage the quality of contractor work and employ the necessary resource on the project team.
Do you practice risk management? How does risk management planning make your projects successful?
To discuss Pulse of the Profession on Twitter, please use #pmipulse.
See more on the Pulse of the Profession.
Many project professionals may consider the project charter as 'more documentation' or a 'mere formality.' But the truth is that if they start to consider creating a charter as a best practice, many problems or issues can be eliminated.
However, I regularly meet project managers that manage their projects without referring to or even knowing the existence of their project's charter.
Here are some reasons a charter is left out, based on my experience:
- Project management immaturity, lack of project approaches or poor project governance by the sponsor or organization. There's a lack of awareness for the need of a charter or formal authorization process.
- At project initiation, there are no clear measurable objectives or reasons for the project. Hence, there is nothing to write.
- The charter may have been written, but is filed away or lost within the organization's documentation system. This could be a symptom of high staff turnover or poor information systems.
- Requirements and other changes to the project deemed the existing project charter obsolete.
- The project has been initiated or is continuing without real executive commitment.
- The project is considered too small or simple to be chartered, so writing a charter is considered a 'waste of time.'
- A charter may exist but contains information that is rigid. Details, budgets and milestones may be unrealistic and unachievable, and therefore not referred to.
- Alternatively, the metrics and information contained in the charter may be too broad and ambiguous and therefore not referred to.
Risk of diminished value and importance of a project, if its purpose and strategic benefit are not documented, agreed and formally recognized.
Delayed decision-making. Getting management and sponsors to sign off on things becomes difficult. There is no one to champion for the project and responsibility for it is passed around.
Difficulty managing expectations. Without a collectively agreed to charter, there may be frequent disruptions and disagreements from stakeholders. They will have differing intentions, opinions and understanding of the project's outcomes.
Risk of failure. When there is no clear, recorded statement of a project's goals, it's more prone to fail. The project charter includes the business case and other additions, which serves as a constant reminder of the project's vision, mission and critical success factors.
Lack of authority. The project manager will be plagued with problems from lack of authority to spend the budget, the ability to acquire and assign resources, and a general power needed to make day-to-day decisions and actions. This will also make it harder for the project manager to attract good suppliers, vendors and resources to work on the project. This can create a culture of dissatisfaction and apathy within the existing project team.
Subject to scrutiny, delay and bureaucracy. The project can expect numerous changes and deviations, which increase the risk of not delivering and reaching the projects goal. It could eventually become a financial burden to the organization.
Do you know of any other reasons why a project charter would not be created? How can the lack of a charter plague a project?
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.
Read more posts on risk.
Read more posts on best practices.
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
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
Read more posts from Saira.
Project-driven organizations must consider customer satisfaction as a critical success factor. Organizations that deliver projects that disregard customer needs create negative experiences and ultimately cause huge problems for the organization.
Typically, project teams that fail to capture what the customer actually needs or wants end up getting the product or service wrong. This can happen because:
- A project manager blindly follows process and doesn't consider human compassion or understanding. Customer engagement seems like a formality or box-ticking exercise to him or her.
- Teams are rewarded on task completion and resolved issues -- not on the number of satisfied customers.
- Projects exist within organizations that don't create opportunities for customers to engage or provide feedback. Therefore, there's no information to improve processes.
- There is lack of support and resources to actively engage and respond to customers. This results in poor employee morale and commitment.
- Collaboration between teams and departments favoring the customer don't exist. Hence there is no sharing of insights and improvements.
- The overall culture and attitude within the organization is not customer centric, so there will be gaps in expectation and delivery.
In my experience, organizations with project management practices that deliver positive experiences are customer-focused and have proactive, sound processes in place. They also have dedicated, responsive teams who are flexible and able to satisfy customer needs.
I believe the following practices can help deliver a positive customer experience:
- Prevent confrontation and problems by balancing your company's customer service expectations with your customers' needs.
- Focus efforts on fulfilling requirements -- but remember to show compassion in the process.
- Bridge gaps between customer requirements and what can actually be delivered through structured communications mechanisms.
- Measure customer satisfaction and gather feedback to continuously improve processes.
- Make "satisfied customers" a measure for success in a project -- in addition to quality, time and budget.
- Report, communicate and ensure project documents are updated and reflect the truth of the project.
- Have processes that inform and include the customers when making changes.
- Capture the "voice of the customer." Make these a part of the organization's project management training.
- Develop and use customer engagement models throughout the project life cycle. This could be in the form of benchmarks and metrics that the customer scores and provides feedback on, for example. Or, contracts could have mutually agreed upon customer satisfaction orientated rewards and penalties.
See more posts from Saira Karim.
See Taralyn R. Frasqueri-Molina's post on The Benefits of a Change Control Board.
Projects act as catalysts that play a vital role in building "a better tomorrow." But without a sophisticated project management platform, it's difficult to be successful.
A project management platform includes policies, procedures, standards, guidelines, integrated project management processes, tools, techniques, templates, project assets library, best practices, learning assets, lessons learned or next practices.
Many micro and small organizations, governments or those in emerging economies frequently don't have the enough money to invest on sophisticated information technology in building and maintaining a project management platform of their own.
This major divide in the profession could be reduced through cloud computing -- providing businesses, governments and individuals with access to a reliable project management platform over internet at an affordable price as per usage (on rental basis). This is called Project Management Cloud (PM Cloud).
Following are a few indicative PM clouds:
• Engineering & Construction PM Cloud
• Information Technology PM Cloud
• Research & Development PM Cloud
• Government PM Cloud
• Education PM Cloud
Those using cloud computing can avoid not only major capital investments, but also the ongoing complexity of managing the technology challenges.
When project management clouds (PM Clouds) are available at an affordable price, as and when needed, they can impact project management in the following ways:
• Provides leapfrog opportunities to emerging economies and small enterprises able to compete globally by leveraging "best-in-class" PM clouds
• Fosters innovation as companies leverage more affordable PM cloud options to experiment
• Minimizes the divide between small and large enterprises. Provides equal opportunities as project management clouds become available at an affordable price
• Allows for global collaboration with project talent around the world
• Facilitates global and interactive learning at an affordable price
We're still in the nascent stage of providing sophisticated integrated project management platforms in the cloud, but eventually, cloud computing will impact the way the project management is done in the future.
How do you think cloud computing is impacting project management?
But project managers often do the work they like and are familiar with, rather than work that needs to be done. Even if it's work that contributes to a project's overall success, I find that many of us focus on tasks that we're familiar with or that we already know we're good at.
Regardless of how great I am with some tasks, I know that I must fill in my own knowledge gaps with team members' expertise. Because in addition to being a good project manager, the real trick to getting things done is surrounding myself with a capable, well-trained project team.
Instead of trying to learn everything and being everything to everyone, I accept that I won't always know it all. I ask for input from the team on a regular basis. This makes the team feel needed and appreciated for their contributions and makes the project execution more efficient.
Do you tackle the tasks you're good at rather than those that need to get done? How do you balance your own expertise with that of your team members?
What interested me the most was a slide detailing three types of networks: operational, personal and strategic.
In the project environment, networking for operational, personal and strategic goals is a core competency for project managers and team members. In all my training sessions, I always repeat the statement "90 percent of a project management job is communication."
In fact, I go as far as to say networking is a skill that can lead to project success. For example, networking comes in handy in the following areas:
On projects we talk to all our internal and external stakeholders on a regular basis. Therefore, we have to network.
We network to acquire and manage resources, vendors and contractors, and also to ascertain and explore risks, strengths and opportunities for the project.
Our personal objectives can be met because well managed, informed and engaged stakeholders equals a happier project manager.
In project communications planning:
Project objectives should be SMART (specific, measurable, achievable, realistic and time bound). Similarly, project-networking activities should be smart too.
Networking activities should:
- Assess the quality of working relationships
- dentify where better relationships are required in order to complete the project
- Develop a wide support network
- Follow up on tasks or commitments
- Build and maintain relationships to get the job done
- Focus and pursue the right networks understand where they fit in and how to communicate with them effectively, know their likes and dislikes and what motivates them.
Project managers must have networking skills to successfully engage, lead and build the team. These skills will enable the project manager to be a mentor and leader of the team.
Project managers should network with their teams to delegate, collaborate, motivate and ensure they work together.
With interpersonal skills:
Networking can help project managers build self-confidence, and devote time and strategy to build and reciprocate through meaningful networks. Plus, meeting others and finding common ground and mutual areas of benefit and collaboration is always helpful to a project manager.
I can confidently assume that since the history of projects, good project managers have been networking out of necessity or risk project failure.
Certainly in my own case, I have been naturally 'networking' without really knowing that I was doing it. The difference now is that I am more aware.
What do you think is a networking best practice? Is project success dependent on a project manager's networking abilities? What benefits has networking brought to your projects? What role has networking played in your projects?
Generally, a Center Of Excellence (COE) is a business unit that has organization-wide authority. It coordinates continuous improvement initiatives, ensures that value is achieved in all areas, and fulfils the role of organizational thought-leader or consultant.
COEs are also created to capture an organization's best practices, standards and industry benchmarks. The COE facilitates the approval, transfer and integration of these best practices across the organization. For example, in a global manufacturing company, the COE may identify a best practice used in its European plant, tweak it, and implement the practice in its Saudi plant, too.
There seems to be confusion between the roles of a Project Management Office (PMO) and a PMCOE. Some argue that the PMO sufficiently leads the organization to project management excellence. So, why would an organization with a well-structured PMO need a PMCOE?
In his book, Advanced Project Management: Best Practices on Implementation, Second Edition, project management expert Dr. Harold Kerzner states:
"The definition of project management excellence must extend well beyond experience and success ... Success is measured by having achieved performance that is in the best interest of the whole company, as well as having completed a specific project."
PMOs and COEs are only successful when they achieve the objectives for which they are created. Leaders in the profession note that the number of projects or years an organization has been delivering projects can't define project management excellence. Neither can the methodology it follows.
Larger, complex organizations may need a PMO and a PMCOE -- but their roles should be clearly defined.
A PMO is an important central hub with a mandate to coordinate and deliver all project activities as determined by the organization's needs.
PMCOE executives would operate as part of the business decision-making process. These individuals would report on the organization's project portfolio as a whole and provide the organization with project consultancy.
The PMCOE also supports the PMO through research, innovation and leadership initiatives and bridges the gap between PMO teams and business units within the organization.
What do you think? Are PMO's and COE's the same? Is a PMCOE just a glorified PMO? Have you come across a PMO and PMCOE in the same organization? Is there clear role differentiation?
It made me wonder how many organizations actually believe that technology applications do the work and produce results -- not humans.
How many organizations and project managers sufficiently analyze their project needs and the compatibility of new technology to their organizations' existing set-up and processes?
Companies often buy expensive project management applications and then force teams to conform and adapt to the application rather than customize the application to the needs of the people and project.
But buying applications because other organizations use them does not by default mean you, too, will become a leader.
Like with best practices, experience has taught me that technology and tools are valuable -- but only if they fill gaps and needs effectively.
Technology is important and can increase efficiency, but in the correct setting and context. Projects are planned and executed by people -- therefore technology must complement and be understood by the humans who use it.
Before investing in new project management applications, you must consider things like training, costs and your team members' willingness to use the tools. Otherwise it could amount to an expensive burden.
What experiences can you share of failing to engage stakeholders before investing in technology?
What factors should be considered before investing in new applications?
Project managers who favor best practices and processes believe it's unnecessary to "reinvent the wheel." They believe using best practices in projects has many advantages:
- Project managers have access to tools, techniques, metrics and templates to use on their projects at any time.
- Best practices provide consistency of expectation, activities and communication for the team.
- They're generally driven by values and results, and can improve customer confidence.
- Construction, infrastructure and power projects have best practices as industry norms to standardize quality, safety and other requirements.
Best practices for projects from 10 to 20 years ago are outdated as technology and real time communications continue to evolve, for instance. More customers are aware of project management, resulting in changed expectations. And definitions of acceptability, constraints and assumptions may differ from the environment where these best practices originated.
I agree that we shouldn't reinvent the wheel. However, I do stress that the wheel should fit properly in order to fulfill its purpose.
Best practices are excellent if there is cooperation and consistency in an organization from top to bottom. Rigidly imposed processes that are unwanted and misunderstood cause problems and restrict new thinking.
Project managers should use best practices but they should build, fine-tune and improve them to fit an organization. Should best practices become better practices or best-fit practices so they become molded, enhanced and understood by the organization and the people who will benefit from them?
How do you enhance best practices for your projects? Do you think best practices are near perfect? Do you agree or disagree that extra effort should be applied to mold best practices?