Managing a distributed project team takes real skill and a definite commitment to putting a governance structure in place that enables success. This is a cardinal rule that I learned firsthand nearly two decades ago managing project teams in Korea, and it stuck with me through my career in the military. The take-away I learned with a distributed project team: a virtual presence is an absolute absence.

So, if your absolute absence is a given because you have project team members operating on three different continents across twelve time zones, then you must put in place the policies, processes, techniques, and templates to standardize activities and ensure the team is playing from the same sheet of music.

Delivering Project Success via Good Governance

Governance is nothing more than how a project will be controlled to deliver intended outcomes. While a lot of effort can go into developing a viable governance structure, it doesn’t have to be that way on every project. In fact, the simpler the governance process and structure, the more likely it is to succeed!

When it comes to governance for a distributed project team, keep it simple. The more complex anything is with distributed teams, the greater the likelihood that it will fail.

Here are five actions I’ve cultivated over the past two decades that have helped me implement good governance on projects with distributed teams:

Set Expectations for the Team

If the team doesn’t know what is expected of them, then you leave the definition of what right looks like to each member of the project team. Original thought can be a good thing, especially if your projects require innovation and ingenuity to deliver new and exciting products and services to your market.

What doesn’t require original thought are your expectations. Established when initiating a project, your expectations of team performance, individual accountability, and standards of conduct must be known and not fluctuate.

If you do find that a change is needed, then ensure the adjustment is tied to project delivery or some company or client change in policy. Vacillating in your expectations is a project management risk that can lead to re-work, lost productivity or project failure.

Examples of distributed team expectations include:

• What the working hours are for each operating location
• What “good” or “effective” work looks like
• What an acceptable attitude is and how team members will contend with disagreements
• What issues are to be elevated as routine, urgent or emergency.

Generate Team Goals and Objectives

Whereas expectations tell the distributed project team what right looks like for individual and team behaviors, goals and objectives tell the team where to focus their energies. When you establish goals and objectives, you give your project team targets at which to aim.

One way to do this is to align objectives to work packages in the project’s Work Breakdown Structure. Doing this gives specific distributed project team members responsibility for executing their work package to meet an established target date. The goals then align to the rolled-up work packages.

Another way to establish goals and objectives is to cascade them from the project’s strategic rationale from the business case. Why is the project being executed? With that answer, you determine what is required to make the project a reality. Next you determine how you will achieve each of the goals – the project objectives.

Most people like to know why they are working on a particular task. Those of us with the highest work satisfaction are happy specifically because we can answer the question of “why.”

On a distributed project team, it can be very easy for a project team member to lose sight of why a project is being executed because they’re far from you, perhaps working solo, or miss out on the culture of the home office.

Ensuring that your distributed project team members are able to explain why a project is being executed, what is being done to achieve project success (i.e. goals) and how the work will be accomplished (i.e. objectives) will help significantly to mitigate the risk of members working on unnecessary actions or accomplishing work contrary to what is required for the project.

Establish KPI’s for Monitoring & Controlling Team Performance

You’ve established expectations of behavior and individual/team performance and set goals and objectives for your distributed project team. The next component of governance to put in place are Key Performance Indicators (KPI) for monitoring and controlling the project during execution.

One purpose for KPIs is to allow you to validate that distributed project team members are efficiently and effectively performing their work. Another purpose is to identify trends, both positive and negative, that may affect the project itself. Both are very important when you have team members working from multiple locations.

To develop effective KPIs, you will need to spend some time evaluating what the critical success factors are that will make your specific project team effective. Some examples include:

• Billable to non-billable hours
• % milestones met on time
• % of weekly coordination calls attended
• # of deliverables returned for rework / total # of deliverables

From my experience, keeping the KPIs simple to measure, limited in number, and tailored to the critical success factors yield the greatest return on investment of time. More importantly, you and your project team will have objective means by which to measure performance and hopefully lead-turn any negative trends before they manifest in a problem on the project.

Create Standard Operating Procedures and Templates

I am a large proponent for standardization when it comes to governance.

Project governance is more than an oversight function aligned with an organization’s governance model over the project life cycle as Project Management Institute (PMI) defines it. A better definition of what project governance is, comes from the U.K. Association of Project Management:

Governance refers to the set of policies, regulations, functions, processes, procedures and responsibilities that define the establishment, management and control of projects, programs and portfolios.

This definition of governance captures what right looks like and furthers my belief that to be an effective project manager, one needs to have standardized policies, processes, techniques, and templates – P2T2.

On a distributed project team, the implementation of P2T2 ensures that actions and deliverables look alike regardless who generates them or where they come from. As with expectation setting, original thought isn’t desired when it comes to governance. Instead, standardization is desired.

Not only is less energy expended developing new P2T2 on every project, you have the opportunity to determine which polices, procedures, techniques or templates boost efficiency and project success, and which ones hinder it. For the LEAN process types, this allows you to continuously improve your project management.

For the distributed team member, it carries expectations further to how they will do their work. Even if you are leading creatives on an innovation project, you cannot accept the risk that comes from having each team member do their own thing when it comes to generating meeting notes or formats for project deliverables.

If your company does not have a Sharepoint with examples of policies, procedures, techniques and templates, start one now. Use the project you are managing to create the baseline from which you can adjust during the next project.

Develop a Communications Management Plan

One critical governance plan for a distributed project team is the communications management plan. If you’re going to spend time developing just one plan, make it this one.

Distributed project teams are automatically at a disadvantage because they cannot take advantage of the multitude of informal communiques that take place between collocated project team members every day. So, to make the most out of the communications that do occur, it’s essential that a well socialized and staffed communications plan be developed.

The plan needs to address the following elements at a minimum:

• The meeting schedule to include location-adjusted times. If you’re team is comprised of people in different time zones, ensure you account for daylight savings, as not all locations change at the same time.
• Communications content. Leveraging your templates and procedures from P2T2, standardize the content for meetings and emails. For meetings, ensure there is an agenda and at least a record of actions and decisions (ROADs) generated. On emails, establish templates for transmitting issues, RFIs, and other project-related communications. Doing so makes it easier for the recipients to process the email because they won’t have to spend time determining what’s required, or what action is required.
• Communications methods. With a multitude of communications methods available, determine what the right mix is for your team. This might be email, VTC, phone and an IM system. Perhaps it’s phone only. Whatever method, identify it in the plan and address the back-up method in case the primary is not available.
• Communications platform. Identify a primary and secondary platform for conducting communications to ensure resilience if one system is off line. Nothing is more frustrating than hosting a call with tens of stakeholders, only to have the primary system go down and no back-up available.

Governance can be a challenge even for projects where everyone is working out of the same office. If you are leading a distributed project team, investing time in developing governance during the initiating and planning stages of the project will mitigate risks that otherwise will cost you time and money during execution and closeout.