Author: Kevin Aguanno

I was teaching a project management course last week and presented a module on stakeholder management.  In this module, I presented some techniques for identifying  project stakeholders, some criteria for evaluating them to see which ones have an important influence over the project, and strategies for dealing with stakeholders who may have some moderate influence over the project but who are not involved in the day-to-day decisions in the project.  In all, I thought it was pretty standard material.

What surprised me, however, was a comment from one of the students in the class.  He said that he was taught (elsewhere) that the role of the project manager stopped at interfacing with the sponsor – dealing with secondary and tertiary stakeholders was the responsibility of the sponsor, not the project manager.  At the time, I thought that this was preposterous – of course a project manager needs to deal with stakeholders other than the sponsor. Later, however, I began to think more deeply about this and I came upon a new understanding of the issue.

For argument’s sake, let’s say there are two kinds of project managers: transactional project managers, and strategic project managers.  Transactional project managers are focused solely on driving the team to achieve the project scope within project constraints (budget, timelines, etc.).  Strategic project managers, on the other hand, focus on finding the optimum path to achieving business value during the project.  This second type of manager is still concerned about completing the project scope within constraints, but has a different approach that tries to determine what other – hidden – factors may be considered to drive optimum project results.

Transactional project managers are performing standard, basic project management activities.  I am not suggesting anything out of the ordinary here.

For strategic project managers, however, I am adding a layer of soft skills and business acumen on top of the basic project management skills to create a more sophisticated, nuanced approach.  The International Project Management Association (IPMA) has been setting international standards for project management competency assessments for decades.  The organization publishes the International Competence Baseline (ICB) which breaks down the knowledge and experience required by a competent project manager into three areas:  PM technical skills (like scheduling, quality management, resource management, etc.), behaviours and traits (like negotiation skills, a results-oriented attitude, creative problem solving, etc.), and general business knowledge (such as program management, organizational structures, health and safety regulations, etc.).  I believe that the strategic project managers have deeper competence in the general business knowledge and display the required behaviours and traits at a deeper level of sophistication.  In essence, the strategic project managers are more senior – more competent – than the transactional project managers.

Transactional project managers are given a project scope and some constraints within which to deliver that scope.  They would then focus inwards on the core project team to ensure that the team is following a plan that will achieve those objectives.  Strategic project managers are different:  they focus outwards from the project team and look to the opportunities and threats that exist in the project’s business environment that may impact project results.  The strategic project manager would meet with the sponsor and try to find out the details of the business case that led to the project, asking if there were any personal objectives of the sponsor or key stakeholders that the PM could consider when planning the project.  After all, there are many paths to achieving project objectives, and some may help the sponsor to achieve other (perhaps covert) objectives along the way. This is where office politics comes in to play.

The project sponsor may have other initiatives that this project could support – perhaps without extra cost – through the way in which it structures its work or deliverables.  And while the sponsor has his or her own personal agenda, so do the other project stakeholders.  The strategic project manager tries to understand the influence of these stakeholders over the project and the relative importance of keeping these stakeholders happy.  Sometimes, the PM will find out that some stakeholders can be safely ignored, or should only be paid lip service to, while others need to be carefully considered and approached with a strategy in mind. 

Office politics sometimes can derail a project faster than anything else – by considering the external stakeholders, their power, their (sometimes) hidden agendas, and their level alignment with the project’s objectives, the strategic project manager can structure the project to more likely meet its transactional goals, and to do so while helping other further their own agendas.  If he or she can pull this off, the strategic project manager will be seen as a person of influence and a strategic partner for various interests and factions within the business. And that, over time, leads to an even greater involvement in organizational politics.  Let the games begin…

Over the years that I’ve been attending project management events, I’ve heard project managers from various backgrounds comparing their projects in an effort to see whose project was harder to manage.  Typically, these PMs are men – perhaps it is part of the genetic makeup of men that many feel the need to compete with each other to establish some type of social hierarchy.

What I’ve noticed is that there are two typical results of these comparisons:  either both projects are in similar industries and are therefore somewhat comparable, establishing one as clearly larger or more complex than the other; or the two projects are of a completely different nature, with little that can be directly compared.  I most commonly see this latter occurrence when one is an engineering or construction project, while the other is an IT project.

When two projects are of a similar nature, we often use budget or team size as a means of comparison.  This falls apart when comparing projects of different types; for example, a $10 million software development project is a rather large, complex project of its type but a $10 million expansion to a chemical plant would be a fairly small engineering/construction project.  So when an IT project manager brags that he’s managing a $10 million project, the engineering/construction project manager chuckles thinking that the IT project manager must just be a beginner to brag about a project of such a small size. We look at team size in a similar way: an IT project with 70 people on the team and four vendors would likely be a fairly-complex project; however, even fairly straight forward construction projects could easily have hundreds of people working on them with dozens of vendors.

This does not mean that construction projects are generally harder to manage than IT projects.  We need to look at other factors, since budget and team size seem to be calibrated differently in the two project types.  If we look at what is really driving the project management complexity in the different project types, we find that the complexity in managing IT projects comes from the lack of clarity in requirements/scope, while engineering/construction projects are challenged by large numbers of vendors, each with their own unique contract to establish and manage, and the complexities of coordinating the work of so many independent project participants, each worried about meeting the terms of their own contract, not necessarily the needs of the project as a whole.

Requirements and scope in engineering/construction projects tend to be simpler elements to manage.  Building codes and other government regulations largely reduce the misinterpretation of requirements by restricting the range of possible options allowed.  Also, scope completion is easy to verify (e.g. “Is the foundation done, or not?”).  On IT projects, however, scope is typically more challenging to define.  The output of a software development project is intangible and many people have a hard time describing the vision of what they want, leading to requirements misunderstandings.  Construction projects resolve this issue by using modeling techniques such as sketching elevations (“artists’ concepts”) and creating 3-D models in a CAD package for simulated virtual walk-throughs of the design prior to construction. The modeling techniques used by IT projects tend to create complex diagrams that require special training in UML to be able to understand.  Certainly, some of the common IT models will work for you but many of them will just confuse the uninitiated.  As a result, an IT project manager will spend a large portion of their management time explaining the project scope to various team members and stakeholders

Vendor and contract management are critical on engineering/construction projects.  Even when running a project to design/build a single family home, the project manager will have many, many separate contractors to manage.  Continuing our single family home example, the foundation could involve over many contractors: one to survey the site, one to dig the foundation, another to haul away the dirt, a carpenter to frame up the forms for the footings, another to bring in ready-mix concrete to pour into the footings, a company to set up and later strip the forms, another to pour the foundation wall concrete, a building inspection, probably a progress inspection/assessment for the construction finance company.  Each of these contractors would have their own unique contract with a scope of work, terms and conditions, and a schedule that would need to be coordinated.  One of the main roles of a construction PM is the coordination of these schedules and the coordination of the scope statements to ensure that nothing gets missed or “falls between the cracks.”  IT project managers may have vendors on their projects, but typically it is one or two firms even for fairly large, complex projects, so the contract management aspect on IT projects is much diminished.

So, the real underlying argument that should be made to compare two projects of different types should be the comparison of the level of scope clarity with stakeholders versus the number of vendor contracts to manage. This is a more difficult comparison – it is like comparing apples and oranges – and usually leads to a stalemate. While I usually see no winner in these debates, it does lead to some very interesting discussions.

I think we each have a lot to learn from project managers from other industries who face very different challenges from what we typically find on our own projects.  Few project managers have experience across project types and the ones who do are usually highly valued by their employers. 

Talk to your peers from other industries and learn from them what you can about what makes their own projects complex.  I am sure that by doing so you’ll mature in your understanding of project management and perhaps you can take away a few tips to try on your own projects.

A few days ago, I attended a seminar on managing cross-cultural projects – these are projects where there are people from diverse backgrounds on the project team, perhaps spread out in countries across the world.  The course was excellent, focusing on the need for managers to understand better the cultural differences that exist between people and perhaps to leverage these differences to improve project performance.  Many illustrative examples were given that showed clashes between cultural norms and how they could impact communications.

I attended another such seminar many years ago, but have not seen too many offered at conferences since then.  This was once a rather specialized topic, of concern to those senior project managers lucky enough to manage large, international projects.   Over the past few years, however, we’ve seen a shift in our team demographics that makes the need for cultural training all the more valuable to today’s project managers.  Two main factors are contributing to this shift:

• Changing Patterns of Immigration.  The population demographics of immigrants to the U.S.A. and Canada changes over time.  In the early years of the 20^th century, immigrants were mainly from the United Kingdom, with early waves of immigrants from China and Italy. After World War II, immigrants primarily came from devastated European countries.  Later, there was a wave of people fleeing Hungary in the wake of Soviet aggression, and another as people left Korea to seek a better life in the wake of the Korean War.  During the later years of the century, immigration patterns shifted to Hong Kong as people fled the country before it returned to Chinese control and Africa, as people fled drought, starvation, and political corruption.  Also, immigration levels increased from India and Pakistan.  Recently, we’ve seen higher numbers of immigrants from other areas of the Middle East and southeast Asia.  The point of this is to show that our population of available project team members keeps shifting as different groups change the makeup of our organizations.  Astute project managers need to be able to relate to people from these cultures, knowing their cultural biases and norms in order to work together effectively.
• Increasing Numbers of Multi-National Projects.  At one time, multi-national projects were uncommon and were led by only the most senior project managers.  With the increase in using offshore service providers on all kinds of projects, however, such projects are becoming quite commonplace.  Whether outsourcing their call centres to the Philippines, their software development to China, or their engineering design services to India, companies are seeking competitive advantage by using the lowest-cost resources available globally.  Increased literacy and higher-education rates in these countries, has contributed to the commoditization of skilled labour.  Project managers need to focus on the unique challenges of working across cultures and time zones in order to keep their projects successful.

Most project managers these days have felt the impact of these factors on their own projects.  Our communities and our organizations are evolving into a diverse mix of people from many cultures and we are finding co-located teams less common as organizations spread their resources across cities and countries.  “Cultural sensitivity training” may be quite useful, but it is not enough. We need to take advantage of communication tools (like instant messaging, teleconferencing, and video conferencing) to help us work with remote team members.  Tasks as simple as scheduling a meeting become increasingly complex as we need to consider time zones, local holidays in remote countries, and cultural norms about who needs to attend various meetings.

But all of these things are teachable.  Given appropriate training, most project managers can learn the factors to consider and how to make the most out of the teams they have been given.  What seems to be missing in some managers I’ve encountered, however, is a heartfelt appreciation for the value that multi-cultural diversity can bring to a project team.  Bigotry is still an unfortunate reality that we must deal with.  Some people have trouble adapting to the rapid demographic changes in our cities, and others adhere to deep-rooted biases that they bring from other countries.  In the western nations, we have traditionally welcomed all comers to our shores but it sometimes takes generations until these newcomers feel like they are truly a part of our society. 

We need to confront racism whenever we find it and make sure that it does not exert a negative impact over our projects.  We can learn much from each other and it is only through a healthy appreciation for our diverse cultural backgrounds that we can truly bond as high-performance teams, leveraging our individual strengths for the good of the whole project.

Kevin Aguanno, PMP, IPMA-B, MAPM is the vice president of the Project Management Association of Canada, and Executive Project Manager with a large international consulting company, and a well-known author and speaker on project management-related topics.  He also comes from a mixed cultural background including Italian, Welsh, Irish, English, and Native American Indian.  Find out more about him at www.AgilePM.com.