Managing International Projects – Part 2

February 6, 2017

This is the second in a series of nine blogs that provide insight and tips on managing international projects.  In this blog, we’ll discuss issues and solutions associated with project scope definition.

Tips for International Projects

  • Test project outcome “facts” as if they were assumptions
  • Surface assumptions early and often
  • Look for constraints around cultural and regulatory issues
  • Document success criteria and share them with the customer
  • Seek “middle ground” resolution of multicultural issues

The information and recommendations in this blog reflect the Four Key International Variables as documented by O’Hara and Johansen in their book GlobalWork.

 Cultural diversity, distances and other variables greatly increase the potential for misunderstanding within international projects.  For that reason, the team must ensure that all stakeholders in an international project, including Customers, suppliers and project team members, clearly understand and support project outcomes and their accompanying success criteria, constraints and assumptions.

Information on events leading up to the start of a project could provide valuable information for addressing measures of success, identifying constraints or examining assumptions within one or more unfamiliar cultures.  Clarity on the need, opportunity or issue addressed by a project could provide useful cultural insights.  And, of course, clear identification of the project Customer is essential regardless of the cultural setting.

Particular attention should be paid to the following four Critical Planning Questions.  These should be tested frequently against the Four Key International Variables of Context, Power/Status, Time and Information Paths.

What criteria will be used to measure success or failure?

Supplemental International Testing Questions:

  • What cultural issues may influence project success/failure criteria?
  • Do specific individuals have unusually strong influence over the success/failure criteria?  Who are they?  Why are they important?  What multicultural patterns do they represent?
  • What cultural issues might influence successful adherence to deadlines?
  • How might multicultural information flow issues influence project success/failure?

What constraints will affect how this project is implemented?

Supplemental International Testing Questions:

  • Who around the world must be kept informed of project progress and outcomes?
  • What global resources, ideas, approaches and other conditions are usable or off-limits?
  • How should information be delivered to specific multinational individuals or groups regarding project progress or outcomes?
  • Are any of the constraints negotiable and if so, who should be consulted?
  • What international legal, customs, transit and other issues must be considered?
  • How concrete are project time constraints and how might they be influenced by multicultural perspectives?
  • Who might change the deadlines and why?

What assumptions are currently being made regarding this project?

Supplemental International Testing Questions:

  • What do members of different cultures on the team believe to be true about this project?
  • What is our plan to resolve differences about these beliefs?
  • What would be the likely cross-cultural impact if these assumptions prove true?  False?
  • How likely is our Customer to have multi-cultural assumptions about this project?  How will we test for these assumptions?  What impact might they have on team members’ multi-cultural views?
  • What is our strategy to manage these multi-cultural assumptions if they prove true?  False?

How will this project affect other people, groups or projects?

Supplemental International Testing Questions:

  • Whose work around the world might be impacted by this project?
  • What multicultural influences should be considered?
  • How do I know this?

Example:  Your project team, part of a North American company, has members from Mexico,Brazil,Korea,Switzerland,Germany and Canada.  Your Customer for an electrical engineering product development project is a Chinese company.  The Customer expects Phase I of the project to be finished in 30 days.

Deliverables include detailed production specifications.  The Customer insists that you add a nuclear physicist from his organization as an ex-officio advisor.  You test your team for assumptions and learn that:

  • The member from Switzerland doesn’t think the physicist is really necessary.
  • The member from Mexico wants to check with the leadership from his home organization committing to the 30-day deadline.
  • The member from Brazil doesn’t think the Customer is deeply committed to the 30-day deadline.
  • The member from Germany thinks a detailed background report should accompany the production specifications.
  • The member from Canada thinks a second physicist should be added from the Customer organization.

You hold a meeting to address these and other assumptions.  You post the assumptions on the walls and discuss each one fully, being sensitive to the different cultural perspectives.  You then put the team to work finding compromise resolutions to issues raised by these assumptions.  A criteria for these compromises is determination of Customer needs.  You then bring these concerns, and their recommended resolutions, to an informal meeting with a Customer representative whose multicultural views you have come to value.  He provides valuable insights that you later share with the team.

Advertisements

Managing International Projects – Part 1

January 6, 2017

This is the first in a series of nine blogs that provide insight and tips on managing international projects.  In this blog, we’ll discuss issues and solutions associated with general international project implications.

Tips for International Projects

  • Test everything – appearances can be deceiving
  • Seek the “middle ground” in resolving multi-cultural differences
  • Listen to the people who have “been there”
  • Research cultures relevant to your project
  • Ask the Supplemental International Testing Questions/Create your own testing questions

The Challenges

International projects increase the need for a systems approach to project management.  Members of international project teams must overcome the usual project management challenges, along with additional risks posed by such factors as:

Cultural diversity:  Representatives of two or more differing cultural systems must work together on a project team.  In addition, Customers or suppliers may be members of cultures different from those of team members.

Distance:  Team members must respond effectively to each other’s needs, or Customer/supplier needs, across continents or oceans.

Language:  Speakers of a variety of languages must find effective ways to understand each other.

Diverse laws, trade conditions and business operating requirements:   In planning and implementing their project, team members must consider such issues as multiple import or tax regulations, differing currency values, and a variety of multi-national operating procedures.

Logistics:  Team members must consider differing transportation systems, terrain or climate conditions.

Supplemental International Testing Questions

These supplemental international testing questions are fashioned around four Key Variables of International Projects.  The variables, based on the findings of Mary O’Hara-Devereaux and Robert Johansen in their book GlobalWork, David Victor, in his book International Business Communication, and other recent global-business scholarship, are discussed here in broad terms to provide a sense of prevailing cultural conditions.  Variations can be expected within specific cultural groups.

The Four Key Variables of International Projects are:

Context:  Context represents the filters by which members of a cultural system give meaning to events and information around them.  Members of high-context cultures, often representing Asian or Latin countries, may tend to view as important, the conditions surrounding events or communication experiences and the status or position of individuals involved in these events or activities.  In a high-context environment, the conditions surrounding such experiences may have more meaning than their actual content.  Members of low-context cultures, often representing North American or Northern European countries, may attach more meaning to the facts of an event or communication activity than to the surrounding people or conditions.  The value of an event or communication will be determined more by what occurred or was said than by who was involved.

Example:  A project team must request resources needed to achieve a desired Customer outcome.  In a high-context culture, considerable time would be spent determining whom the most appropriate person would be to convey and receive the request and how its submission should be coordinated with other events, in and outside of the organization.  Issues such as status, formal and informal power relationships, gender and longevity with the organization would be carefully assessed.  The actual wording of the request itself might be relatively vague.  In a low-context culture, planning for acquisition of resources would likely emphasize a well-reasoned, effectively worded case for a favorable decision.  The request itself might be delivered rather informally through office e-mail or through a presentation by a junior team member.

Power/Status:  Asian and Latin cultures tend to have more rigid power structures, often influenced by family connections, longevity, wealth or other factors beyond actual job performance.  Decision making and other organizational events may be hierarchical.  In North American and Northern European cultures, power may be assigned more on the basis of earned position, professional credentials or distinguished performance.  In these regions, organizations are likely to be flatter, with more decision-making at the daily operating levels.

Example:  A project team needs someone with electrical engineering expertise.  In a culture where deference is made to rigid, hierarchical power structures, final selection of such a new team member may take extra time as compromises are worked out among a variety of individuals and power centers.  In a culture valuing flatter, less hierarchical decision-making, the team may determine who it needs, request services directly from the appropriate individual and inform various supervisors after the fact.

Time:  Members of Asian and Latin cultures tend to view time as a long-term continuum extending from the distant past through the present and into the distant future.  The nature of relationships within this sweep of time are often more important that the precise unfolding of events according to a rigid schedule.  A number of activities may be scheduled simultaneously in such culture groups, with completion deadlines often weighted against such context considerations as power, long-term benefits to the individual or the perceived value of a relationship with a key project stakeholder.  Members of North American and Northern European culture groups may put more emphasis on completing a single task before beginning a new one.  Focus may be on successful meeting of a specific deadline or commitment for the sake of the deadline.

Example:  A project team has scheduled a meeting for 1 p.m. Tuesday.  Members from more schedule-focused cultures can be expected to arrive early or apologize profusely if they are a few minutes late.  Members from less time-focused cultures may arrive half an hour or more after the designated start time and make no effort to justify their tardiness.  They assume the others appreciate their need to conduct several hallway discussions with long-time colleagues on the way to the meeting room.

Information Paths:  O’Hara-Devereaux and Johansen describe information flow in cultures as “both the path and the speed of communication…How fast does a message travel from one part of the organization to another.”  In many high-context cultures with their heavy emphasis on relationships, information is likely to travel via complex, time-consuming routes, with connections made to many individuals with little or no evident involvement in the project.  By contrast, information in lower-context cultures may be delivered with emphasis on efficiency and involvement of the least number of people to get the job done effectively.

Example:  A change in a project plan activity has been agreed upon with the Customer.  In a more relationship-driven culture, information about the change would be widely communicated.  Depending on power considerations, the change might also have to be approved by several people along this information path.  In a lower-context, more event-oriented culture, information about the change is likely to be sent only to those directly involved in its successful completion.  Others might be informed on an FYI basis at best.

Stakeholder Analysis – Part 1

December 6, 2016

The rule rather than the exception is that some stakeholders will love the solution you have defined while others will find it unacceptable, unworkable, or simply ludicrous.  Many projects have been scrubbed because a high influence stakeholder did not have a relationship with a project leader and felt they weren’t given adequate opportunity for input in the planning process.

To find some balance or common ground, use the Stakeholder Analysis, which consists of two parts:

  1. Stakeholder Solution Assessment (SSA): designed to identify what stakeholders do/do not like about the proposed solution.
  2. Stakeholder Issue Resolution (SIR): designed to manage concerns about the solution voiced by stakeholders.

A good idea that never gets implemented is no better than a bad idea.  When good ideas are implemented, the team wins, the organization wins, and the customer wins.

Good ideas emerge from open discussion and debate between suppliers and clients in  stable, productive relationships.  The SSA and SIR will facilitate this process.

These steps will lead you through a successful Stakeholder Analysis:

  • Identify all key stakeholders
  • Conduct a Stakeholder Solution Assessment to surface concerns
  • Address concerns through Stakeholder Issue Resolution
  • Present to key stakeholders, seeking:
    • Acceptance, then
    • Support, and finally
    • Approval

The objective of the Stakeholder Analysis is to promote a high level of acceptance of the team’s solution.  By doing so, the probability of successful implementation is taken to a new level.

Identifying Key Stakeholders

To implement a solution, it must be supported by the right people.  You must develop strong and functional relationships with everyone who will approve, implement, be affected by, or simply support the solution.

The people whose support is needed are:

  • Those who must formally approve the solution
  • Those who must implement the solution
  • Those who must live with the solution
  • Those who must informally support the solution

Those who must formally approve the solution.  This might be one person or a small group.  Typically it is the person who has the final say. Budget and other resources may be involved.  It then may be the person(s) with expenditure authority.  Without formal approval, everything comes to a halt.

Those who must implement the solution.  The people who must implement the solution must support it.  Some of these people may be members of the team.  It depends on the nature of the idea being proposed.  There may be a number of people involved.  For example, the team may have representatives from production, maintenance, engineering, or scheduling.  Their solution may include changing the documentation for reporting on production output or machine up-time.  The solution may involve others from these departments.  It may also involve accounting, purchasing and shipping.

It may not be practical to get the support of everyone included.  However, identifying key stakeholders is critical.  Key stakeholders are formal or informal leaders in groups or departments responsible for implementation of the solution.

Without support of key stakeholders, problems will arise.  The end result may be failed implementation.  Also, there may be a perception that the team came up with a bad idea.

Those who must live with the solution.  The people directly affected by the solution are often those who implement it.  However, they may be a different group altogether.  For example, a team proposes a new office layout.  The team will also be involved with implementation.  Programmers, engineers, and others who work in the office will live with the new layout.  They will not be actively involved in implementing change.  Their support is important, however.  Without it, failure is likely.

Those who must informally support the solution.  This group fits none of the previous categories.  However, they are still important to success.  They are often referred to as “champions” or “advocates”.  They command respect within the organization.  Therefore, their support is extremely valuable.

This group may include top managers with little or no involvement with the implementation.  Or, they may be very much part of the solution.  In either case, they have clear influence with people in the previous categories.  In particular, they have influence with those whose approval is needed.

For differing reasons, these people must support the solution.  Their support is necessary for successful implementation.  Identifying them is crucial to identifying key stakeholders.

The Role of Influence

Projects do not run in a vacuum.  In addition to the impact the project has on the people who are responsible for conducting it, every project affects other individuals, groups, and even other projects.  This means that a lot of people in the organization will take an interest in your project, for a wide variety of reasons.  And where there is interest, there is also influence.

Webster defines influence very simply: “the power to affect others.”  Your challenge is to identify the source of the power, and the intent of the change, in order to secure the success of your project.  The best, and perhaps only, way to do this is to develop good working relationships with all project stakeholders.

First let’s consider where influencers get their power.  These four categories are not exhaustive, but cover the most common situations.

  1. Position: Department Heads, Plant Managers, Account Representatives, etc., can wield significant influence through the power vested in their position.  Influential moves by these people will most likely come “through channels” (i.e., visible and documented efforts to change the project).
  2. Competence: Every project has its complement of subject matter experts.  These people exert influence through advice and/or criticism.  Their efforts can be upfront and formal (e.g., reports at project review meetings) or subtle (side conversations to influence team members).
  3. Affiliation: Every organization has its share of unofficial groups and cliques.  Individuals who have participated on previous high-profile projects, been successful in winning large accounts, or are on the “fast track” may have the right affiliation to impact change in your project.  They are most effective influencing other people who would like to join their club.
  4. Politics: You can name at least a half-dozen people (managers as well as individual contributors) who are “connected”.  These people have the ear of key decision makers and can exercise significant influence without ever speaking to you.

You cannot change the source of anyone’s ability to influence or their intent to exercise that influence.  What you can do is influence the influence.  You do this by learning their interests and needs surrounding your project, surfacing any dislikes or concerns, and using the four dimensions of relationship management to dissipate any negative consequences their influence may create.

One last point – influence is not always negative or destructive.  Developing close relationships with stakeholders will also reveal your supporters and advocates.  The better you are at positioning your project for meeting the needs of these important people, the more you will enjoy their benevolent influence.

Relationship Planning

October 4, 2016

This is the tenth in a series of 12 blogs that provide insight and tips on managing client relationships.  In this blog, we’ll discuss issues and solutions associated with relationship planning.

Now What?

“The problem with Heaven is what you have to do to get there.”   – Unknown

This is not about project planning.  It’s about making project planning successful.

You may also have heard the phrase “It is much easier to do than it is to plan to do.”  Our jobs and lives are so full that we feel compelled to keep accomplishing and just can’t find the time to think ahead and get organized.  We get caught reacting to fires rather than proactively installing the sprinklers.  In projects, it isn’t just important to create a solid plan, it is imperative.

By now you have:

  • Diagnosed the current situation
  • Defined the best solution for your client
  • Received approval from key stakeholders

Now it’s time to turn your attention to designing a workable, attainable implementation plan.  A little forethought and planning will go a long way to avoid the pitfalls that accompany a “ready-fire-aim” approach to implementation.

The actual planning process is really quite straightforward.  It simply describes the following considerations:

  • What actions need to occur?
  • When will each action be started/completed?
  • Who will be responsible for each action:
  • How much will it all cost?

Everyone On-Board

The real challenge in defining and holding to a plan is “keeping all the bayonets pointed outside the fort” during the process.  Since most project teams are cross-functional in their membership make-up, there may be as many planning models in the team as there are members.  For instance, Information technology people may be familiar with a planning model driven by a sophisticated software program, whereas marketing people are more comfortable with hard copy calendars and spreadsheet forecasts.

The nature of an interdisciplinary team of people with diverse skills and interests presents you with a unique challenge as a relationship manager.  this is the “formation stage” of team performance, and you must be prepared to hear all the input, involve all the players, and facilitate agreement on a planning process.

Pursue these steps with your team and the client:

  • Agree that planning is key to project success
  • Commit to a single planning model that everyone can use
  • Apply the model consistently throughout the project life cycle

Below are five phrases which could define project outcomes in just about any organization. Experience with numerous project teams combined with survey input from hundreds of project professionals suggest that the most influential factor affecting project success is shared ownership of the plan and teamwork to implement it.

Bottom line – your role is to pull the project off – on time, under budget, and exceeding client expectations.  This can only be accomplished by carefully managing relationships, in the team and among the stakeholders, while keeping the project on track and up to speed.

project-success-continuum

Project Success Continuum

Relationship Planning

Don’t waste time constructing a plan until you have thoroughly explored the needs and expectations of your stakeholders.  We have emphasized the value of managing relationships with your stakeholders in previous stages, but it is even more critical here.  If an important stakeholder hears about your project from anyone other than you, or at any time after planning has begun, you have one strike against you.

If a key stakeholder is taken by surprise, gets angry, or perhaps worst case, feels embarrassed by being out of the loop, the relationship that will be tested is with you.  It is a test you don’t want to take.

When the plan takes shape, it will include firm requirements for people and resources.  This requires a budget, and that leads to spending.  And when money starts getting spent, stakeholders pay close attention.

To remain on-board with you, they will need information in advance.  Managing stakeholder information needs is a critical part of relationship management.

Some stakeholders are part of the core team and participate in every step of the planning process.  Other stakeholders function on the project perimeter, and have roles as decision makers or influencers.

Regardless of their level of relationship to the planning process, all stakeholders must be consulted before the planning process begins.

 

Relationship Building Tips and Reminders

August 31, 2016
  1. Schedule all key stakeholders for an individual interview (in person if possible) before a solution is defined.
  2. Learn all you can about your client’s cultural history, outlining key events that led up to their present situation and needs.
  3. Determine the client’s preferred form and style for proposals (media, level of formality, level of detail, etc.) before documenting the solution.
  4. Differentiate stakeholders as decision makers, influencers, and implementors and identify what each one expects from the project.
  5. Determine which decisions and approvals require consensus and which do not.
  6. Gain agreement from suppliers and clients on what will be measured and the measurement tools to be used.
  7. Define a solution that will meet the customer’s needs, then plan to over-deliver by adding value.
  8. Use clear benefits statements in addition to tangible outcomes when defining the project solution.
  9. Use terms and units of measure with which the client is familiar.
  10. Know (in advance) the specific criteria that will be used in the approval process (by both decision makers and influencers), and address them in the definition.

FIVE MAJOR INTERACTION-BASED CAUSES OF PROJECT FAILURE Number One: Unclear Definition

August 31, 2016

There are several schools of thought among project professionals on what the phrase ‘initial project definition‘ means.  Everyone agrees that the project outcome and deliverables must be defined, as a minimum.  Some feel it is important to define the delivery schedule and an estimated budget before approval is sought.  Others go the distance and outline a comprehensive plan, in addition to budgets and outcomes before deciding a “go or no go” decision can be reached.

Your ability to develop a good relationship with your client during early discussions and through the Diagnosis stage will determine how much influence you will have in recommending the depth of information required during definition.  If you have used the Diagnosis stage to establish yourself and the team as technical experts and top service performers, your client may simply require a clear definition of the solution to proceed.  If your rapport with the client is shallow and they have not developed confidence in your team, they may require a lot more up-front information.

The more information you must compile before approval, the more resources you may be wasting.  A tight, clear, accurate definition of the best solution for the client, based on a well-researched diagnosis, should be an adequate basis for approval of the project.  It should also be enough information to make an expeditious decision to pull the plug on an ill-conceived project before the use of people and resources start running up costs.

If you have established a good relationship in the Diagnosis stage, the definition stage offers an excellent opportunity to solidify it.  Your proposal of a tight and focused definition should convey to the client that you are interested in meeting their exact needs and minimizing waste.  On the contrary, unclear definition of the solution can lead to missed deadlines, budget over runs, stakeholder resistance, and a number of other problems, each leading to customer dissatisfaction.

In addition to being a pivotal element of project success, a clear definition can set a valuable precedent on how the client relationship will be managed and the project will be conducted.  If the definition is hurried, poorly worded, or otherwise misses the mark, the technical and service performance on subsequent tasks may reflect this initial weak execution.

Typical Causes of Unclear Definitions:

  • The client is not clear on what their real need actually is (a solid diagnosis could be instrumental in clearing this up).

For example, you are called in to stop a slide in profit margins for a manufacturer of resin-based patio furniture.  The management feels a switch to more contemporary designs is the solution.  What they haven’t explored are solutions for the real need: to stop eroding profits.  Are raw material costs too high – should they switch suppliers?  Are inventories too large, adding to overhead?  Are transportation costs eating into margins at an inflated rate?  In other words, their need may have a much simpler solution than redesigning their entire line.

  • The client is not willing to take the time to describe the situation (they may take the stance that your job as solution provider is to discover their needs without their participation).

For example, you are reputed to be the best ad campaign consultant in the East.  An importing firm calls you in to replicate their success in England with a line of tea biscuits, in New England.  They have no interest in retracing their steps or giving you time to diagnose the situation.  Your expertise is what they are buying and they expect to move forward quickly.  Do you think a successful campaign can be launched without the benefit of a well-defined solution?

  • You and/or the client assume that the solution is clear and understood.

For example, you are a trade show planner for a Software trade show that takes place every year in a major convention hall downtown.  The past two years have seen reduced booth reservations through the fall, until you announce a price reduction and free amenities.  This year the shortfall in reservations is the largest ever.  You and the client feel it simply requires deeper discounts and better giveaways – the same as every other year.  What you and the client have overlooked are an increase in similar shows in the area, the increase in e-buying for software, and the fact that fuel, lodging, and parking prices have doubled in the last 5 years.  Will discounts be the solution?

  • The client is uncomfortable disclosing all the details for fear of breeching confidentiality barriers.

For example, you are put in charge of implementing a complete backroom payroll administration system for a successful privately held construction company.  The CFO of the company refuses to release records on compensation history or current packages for principles and Board members.  Without this information you cannot fully define the best accounting practices for the client, but they insist the project move forward anyway.  Can you define a complete solution for the client?

Preventive Strategies:

  • Schedule a meeting to close out the Diagnosis stage (including incorporation of stakeholder comments), and dedicate a segment of the meeting to confirm the needs of the client prior to initiating the Definition stage.
    • Use the First Law of Service to assess the client’s satisfaction with the diagnosis.
    • Seek input and clarification on the needs you have documented from all stakeholders.
    • Explore the client’s preferences around proposal scope and sequence for presentation of the definition.
  • Use an informal event to initiate the Diagnosis and Definition stages (e.g., lunch, dinner, etc.).  This may help the client to feel more comfortable about discussing the issues in question.
    • Discuss protocol around confidentiality. Agree to sign non-disclosure statements to make the client comfortable.
    • Apply Active Listening techniques to acquire information
    • Discuss how you can access other resources in the client organization
  • Develop confidence in the Client that your methodology assures their satisfaction by proactively addressing issues that may negatively impact the project.
    • Describe your approach for testing assumptions
    • Explain the benefits of risk management
  • Challenge the assumptions that you and/or the client have regarding the definition of the solution.
    • Seek agreement on the scope and depth of the definition.
    • Probe for any insecurity on the client’s behalf regarding competence of team members.
    • Present a list of assumptions you have made regarding the client’s expectations, ability to secure necessary resources, time available, etc.

Contingent Strategies:

  • If the client is non-participatory, establish a process for the client to accept and approve (sign-off on) the definition that you have developed with the information you could gather. Include a detailed list of all questions and untested assumptions.
  • Submit a clear and comprehensive proposal for the definition. This will facilitate approval as well as serve as a foundation document should subsequent disagreements or challenges to the definition materialize.
  • Complete a Decision Matrix. It’ll be very useful if any disputes or misunderstandings develop around the definition.

Due diligence pays off.  Doing the homework required to produce an accurate diagnosis dovetails with the preparation of a clear and comprehensive definition of the best solution for the client.  And remember, your homework is not limited to data gathering and technical research.  You must be constantly promoting close communication, building confidence, and establishing a relationship based on teamwork and mutual support.  The best evidence of great service performance at this juncture is accurate reflection of the client’s needs in preparation of the clearest, most comprehensive definition possible.

Stages of Project/Relationship Initiation: Approval

August 31, 2016

This is the seventh in a series of twelve blogs that provide insight and tips on managing client relationships.  In this blog, we’ll discuss issues and solutions associated with the second stage of project/relationship initiation – The Approval Stage.

Approval

A sound diagnosis and a comprehensive definition set the stage for a smooth approval process.

In Diagnosis, the key is careful research into the organization’s history.  In Definition, the key is a clear understanding of the client’s needs and expectations.

In Approval, the key is firmly based in managing relationships, and in knowing the preferences and decision-making style of all the stakeholders (which you have identified in the process of defining the solution).

In the process of establishing Approval for the project, stakeholders fall into two major categories.

Decision Makers

These people are usually high-profile on the project, and they are consulted at all milestones and other junctures where “go/no go” decisions are made.  They can be:

  • The Project Leader
  • The Project Client
  • The Sponsor (providing funding, approval or support for the project)
  • Miscellaneous committees, boards, or managers who have a stake in the project’s success.

Influencers

While decision makers are fairly easy to identify, influencers may be obvious OR transparent in the project planning process.

Obvious influencers are the people who will use the project outcome(s) and/or those whose individual or department functions will be impacted by the project.  These influencers tend to be well-integrated in the project and part of the unfolding process.  Though they may not make decisions, they are constantly using their authority to influence them.

Transparent influencers can be senior managers, longtime ‘vets’ in the organization, and other core players whose position or history give them significant power over the company’s culture.  The influence these folks exert is not documented or directed at specific decision points.  It’s impact is both subtle and substantial as it shapes the way things happen more so than specifically what happens.  You may not be able to pinpoint the source of their brand of influence, but you will certainly feel the impact.

The key then, to a smooth approval process, is to understand the needs, preferences and expectations of as many stakeholders as possible.

The better your understanding, the better your ability to manage the relationships.

Keep in mind that the relationships you have with your approval stakeholders can be multifaceted, and perhaps fluctuating.  You may functionally report to a decision-making stakeholder as well as serve their needs relative to the project.  Your relationships with influencers may vacillate from supplier to client and back again, depending on the stage of the project.  The most important success factor is to keep these people involved by providing them with the information they want, when they want it, and how they want it delivered.

Stages of Project/Relationship Initiation: Definition

June 15, 2016

This is the sixth in a series of twelve blogs that provide insight and tips on managing client relationships.  In this blog, we’ll discuss issues and solutions associated with the second stage of project/relationship initiation – The Definition Stage.

Definition

Have you ever entered a theatrical performance after the beginning of the Second Act?  It can be challenging to ‘catch up’ with the story line and get involved with the characters and plot.

This is often the case with projects.  Clients tend to engage the services of project specialists once a problem or opportunity needs immediate attention and the First Act (Diagnosis) is over.

Some common reasons leading to your entrance at the Definition stage are:

  1. The client has done a rudimentary diagnosis, but is not committed to the information or intends to use it in the definition of the solution.
  2. Time or budget constraints have forced the client to jump right to the Definition stage with no investment in diagnosing the situation.
  3. Untested assumptions about their background/history lead the client to believe they know the cause and therefore they skip diagnosis.

All of these scenarios are less than ideal, and you will have to probe and sift to compose the clearest possible definition of the need, problem, or opportunity.  At a minimum, you should solicit answers to the diagnostic questions, at least informally.

Even if your research falls short of giving you adequate information for a good diagnosis, it will help you establish relationships with key stakeholders and get the project off on the right foot.

If, however, the client resists spending any time on diagnosis, you may need to abort any attempts to explore the past, and rely on your judgment and intuition to get the most from the information you have.  It is usually unwise, however, to put the project at risk in this way before it actually begins.

No matter where you become engaged in the Definition stage, there is one key point to remember.  The more accurate your understanding of the solution (and its evolution), the more likely the project outcomes will exceed the client’s expectations.

Most clients will request that you document or package your proposed solution.  This can be formal or informal.

Formal proposals usually require:

  • A format specified by the client
  • Submission requirements (number of copies, media, attachments, etc.)
  • A specific process for submitting changes or revisions

Informal proposals can be:

  • Written: letter, memo, or e-mail
  • Prepared presentation
  • Verbal ‘contract’ in person or by phone (often followed by written summary notes)

The opportunity to submit a proposal is also an opportunity to develop the client relationship.  Do your homework and find out as much as you can regarding the client’s preferences in the items above, and prepare your proposal as close to those specifications as you can.  This will demonstrate to the client that you are focused on their needs and committed to outstanding service performance.

Regardless of the depth or complexity of the proposal, it should include information gathered from the Diagnosis stage, particularly as it relates to identifying the root cause of the problem.  In fact, your proposal may actually help the client to rectify the root cause before implementing a solution.

Understanding and managing stakeholder needs is a significant part of relationship management.  The Definition stage is where relationship needs are interwoven with technical needs to craft a solution that can be embraced by the client.

Defining a solution requires answers to a few questions:

  1. Who are the stakeholders?  (Include those identified in Diagnosis, and others as required due to the additional clarity of the definition.  Remember, stakeholders can be decision makers, implementers, influencers, and those who are not involved but are affected by the project.)
  2. What are the needs of the stakeholders for involvement and information?
  3. Who will benefit from the need, opportunity or problem being addressed successfully?
  4. What would be an ideal outcome?  (Where and when would it be realized?)
  5. What would be delivered to whom and when as a result of this outcome being achieved?
  6. Who will receive/use each deliverable?
  7. Who would evaluate the success of this effort (i.e., which stakeholders)?
  8. What will the evaluation criteria be?  (What measurement tools or systems are currently in place?)
  9. What boundaries/constraints must be respected during this effort?
  10. What assumptions are being made about this situation and solution?

Comprehensive, clear answers to these questions will greatly improve your chances of exceeding your client’s expectations.

In summary, the successful solution will be a composite of the input from the stakeholders, project clients, team members, and lessons learned (history).  The more represented these players are in the solution, the more likely the approval process will proceed unencumbered.  Managing relationships among key players will facilitate participation in the project and ownership of the outcomes.

Stages of Project/Relationship Initiation: Diagnosis

June 15, 2016

This is the fifth in a series of twelve blogs that provide insight and tips on managing client relationships.  In this blog, we’ll discuss issues and solutions associated with the first stage of project/relationship initiation – The Diagnosis Stage.

Stages of Initiation

Your interaction with the client begins as soon as the client begins to formulate an impression of your organization.  This can be from an initial conversation with a receptionist, reading an advertisement, hearing word of mouth comments, or experiencing the first direct contact with you.  You may or may not have any control over the client’s first impressions, but you need to be aware of them in order to productively manage the initiation of your project.

If you can safely assume some interaction preceded your involvement:

  • Find out as much as possible about the previous encounters (who, what, when, where and why).
  • Determine what went well, and what didn’t.
  • If you uncover any pre-existing problems, make every effort to fix them without blaming or embarrassing anyone (you will be a hero to all involved).

Regardless of whether you are attempting to initiate a new relationship or expand one that currently exists, three stages within initiation will always take place.  There is no prescribed length for each stage, but there is a set order.  It is:

  • Diagnosis
  • Definition
  • Approval

These stages apply to project work as well as all types of supplier – client interactions (including work with internal customers).  Each stage has relationship management implications that need to be addressed.

Diagnosis

“Don’t ever take a fence down until you know why it was put up.”

                                                       – G.K. Chesterton

In you are entering the project very early on; you will most likely be involved with the Diagnosis stage (i.e., figuring out what the problem, opportunity or need actually is).

In the Diagnosis stage, your goal is to determine why the current situation exists, or metaphorically, why the fence was erected in the first place.  Invariably, this will require you to do some detective work, digging into the background and historical data that will develop into a clear picture of the events leading to the current situation.  The more intellectual and emotional awareness you acquire about the client’s relevant history, the better prepared you will be to craft a creative and effective solution.

A significant associated benefit is the client’s increasing confidence that:

  • You appreciate their evolution in arriving at this juncture.
  • You respect their past and present cultural trends and influences.
  • Your solution will reflect where they have been, and where they want to go.

In this stage, you are seeking to understand:

  • Why does something need to be done now (or soon)?

    For example:

      • Has there been an increase in new clients?
      • Has there been an increase in client complaints?
      • Does the business need to diversify?
  • What events have led up to the current state of affairs?

    For example:

      • Has there been a merger or acquisition?
      • Is new leadership setting new priorities?
      • Have market fluctuations required internal reorganization?
  • What relationships are affected (or were affected) by these events?

     For example:

      • Did relationships with existing customers change?
      • Have internal relationships between departments gotten better or worse?
      • Have reporting relationships changed for a number of employees?
  • What previous solutions/alternatives have been attempted, and what do the results of these attempts reveal?

              For example:

      • Can you draw from a repository of lessons learned or best practices?
      • Have there been training programs directed at the situation?
      • Have prior projects attempted to solve the problem?
  • Do different opinions exist as to the need, opportunity or problem?  (i.e., are there two or more ‘camps’ with competing ideas for solutions?)

            For example:

      • Are there two or more executives proposing differing solutions, or defining the situation in competing ways?
      • Are there different solutions for domestic and international interests?
      • Are there ‘old school’ and ‘new school’ forces in opposition?
  • Who are the stakeholders?  (Identify stakeholders who ‘own’ the situation and those who can influence whether or not a solution is pursued.)

             For example:

      • Who has the authority to interrupt or impede the project?
      • Who will derive the most benefit from project success?
      • What departments may not have an interest in the project but may be impacted by it?
  • What do key players believe to be the root cause of the problem?

              For example:

      • Will identifying the root cause have significant political fallout?
      • Is the root cause strictly financial?
      • Has the root cause been previously defined but ignored?
  • How well has the alleged root cause been verified?

             For example:

      • Is the data describing the alleged cause current and relevant?
      • Is the person or group who defined the cause unbiased and properly trained?
      • Have subject matter experts been called in to review the findings and verify their accuracy? 
  • What relationships need to be carefully managed during the Diagnosis stage?

              For example:

      • Are there any key stakeholders who may resist offering information important for accurate diagnosis?
      • Will it be difficult to enlist the support of some key influence stakeholders who don’t see the value of the project?
      • Do you have access to key decision-makers so you can determine how they will base their decisions?

Pursuing a solution or outcome without this vital information can lead to disappointing outcomes or abject failure.  Part of your role as a relationship manager is to develop the client’s commitment to honor best practices and lessons learned.  This will impress the client with the value of their own experience and history, and your value as a facilitator of positive change.  In particular, your interest in (and understanding of) key relationships will let the client know you are aware of the impact that these interactions may have on any new solution.

Control, Influence and Adherence

June 15, 2016

This is the fourth in a series of twelve blogs that provide insight and tips on managing client relationships.  In this blog, we’ll discuss issues and solutions associated with  Control, Influence and Adherence.

Control, Influence and Adherence

When managing relationships, you will often make an individual impact, and other times need to go with the flow.

You have the greatest degree of control over your own behavior, both in how you conduct yourself and how you respond to client preferences.

You can exude influence over the efficiency within your team. Your level of cooperation, responsiveness, and unselfish contribution will greatly influence project outcomes and customer satisfaction.

Unless you are high up on the leadership chain, you will need to adhere to the majority of cultural doctrine.  Over time, your contribution on the individual and team level can have a positive influence here as well.

Regardless of your level of control, influence, or adherence, you will always enhance client interactions through awareness, a positive attitude, and proactive behavior.

Remember:

  • The only person’s behavior you can change is your own.  If your client routinely shows up late, wasting everyone’s time, ask what you can do to schedule meetings at times the client has fewer pressing demands.
  • Avoid blaming the institution for disappointments in project outcomes.  If your company’s antiquated computer system accounts for delays and partial deliveries, suggest ‘work arounds’ such as out-sourcing some printing or scheduling heavy data entry early or late in the day.
  • Always look before you leap – understand implications of your behavior.  If your enthusiasm to gather project data motivates you to directly contact all stakeholders on the client’s side, hold off.  Consult with your primary client representative in advance to be sure you won’t be over stepping your bounds, violating client protocol, and complicating the relationship.
  • If your choice of action will not improve client interactions, reconsider.  If your response to a client’s over-use of acronyms and buzzwords is to resort to the same approach, take a deep breath before you RSVP.  Perhaps compiling a directory of technical terms and acronyms for the entire team will have a better impact on the relationship.
  • Don’t complain, offer constructive criticism.  If a team member is challenged by the workload and always late with the deliverables you need, respond with suggestions for time management rather than negative comments.