6 Common Pitfalls to Avoid in Managing Distributed Project Teams

The following is a guest post from Andrew Filev of Wrike.

 According to a survey we ran with 1,000+ employees of various organizational levels, over 60% of them expect their work to go fully virtual in the next few years. Given that remote collaboration is becoming a more and more widespread trend, project managers need to quickly adapt their practices to the changing realities. So, what pitfalls are there to expect in managing distributed teams, and how can you avoid them?

Putting too much hope in self-organization leads to false expectations

Even though a virtual team generally enjoys some extra flexibility, it is deceiving to believe that it will function effectively without enough managerial control. Even more than co-located teams, distributed workers need common guidelines to get their efforts synchronized. For example, when and how to report on work progress, how to deliver results, which best practices and standards to adhere to in the process, etc. Simple and concise rules of work organization will help to get the team coordinated­ at any distance.

Reports instead of conversations lead to miscommunications

If the team’s communication is limited to exchanging tasks and reports, it’ll lead to at least two challenges. First of all, both the manager and the team will suffer from poor visibility into what’s really happening.  Second, this will make the atmosphere inside the team too formal. To avoid this, don’t stop talking! An ongoing conversation will keep everyone updated on the progress, help colleagues solve some questions together and also increase engagement. To add some face-to-face components, you might occasionally run a video-conference or even an offline meeting if there’s a chance.

Lacking the culture of sharing leads to frustration and low velocity

Transparency is one of the main challenges for remote teams. Often, workers get “siloed” with their own assignments, documents and reports, and all this info isn’t automatically accessible to their colleagues. Cloud technologies and social project collaboration software are great enablers in developing the habit of sharing within the team, so that work-related info isn’t isolated on personal PCs.

Not enough motivation leads to poor productivity and lack of satisfaction

Separated by distance, you can’t shake hands with every employee or pat high-achievers on the shoulder. But little things might matter. Express appreciation verbally, be that a thank-you note or a call. If your company’s policy allows, you can consider such acknowledgement options as flexible working hours, employer-paid leisure activities or personalized gifts.  

Making assignments too big leads to misalignment and poor visibility into progress

Without direct communication, there is higher risk of someone misunderstanding his goals. According to my experience, the key pain reliever in this case is assigning work in a more granular way. The remedy is simple: think big, but act small. With smaller assignments, a worker will understand them better, complete them faster and report easier. For the manager, in his turn, it will be easier to track progress both at bird-eye view and in detail.

Not believing in the efficiency of a distributed team leads to a self-fulfilling prophecy

To conclude, the biggest delusion of some project managers is being convinced that productivity stops at office walls. Yes, your employees do not gather daily at one location, but they are still a team that can be as synced, efficient and successful as a co-located one is. Don’t take the virtuality as a weakness. On the contrary – you have the opportunity to broaden your geographical, time and talent reach! You just need to find your own right mix of methods and tools to see the productivity of your distributed project team flourish.

Andrew Filev is the founder and CEO of Wrike, provider of popular project management software. He is a seasoned software entrepreneur, project and product manager, and advisor to several fast-growing ventures.

Refactoring

An interesting situation came up at work recently. I was leading a team that was reviewing an application that was developed about 18 months ago. There were some concerns around performance and scalability. The real question was, did this program need to be re-factored? How do you decide if/when it's time for refactoring?

One of the principles behind the Manifesto for Agile Software Development is Simplicity:

Simplicity--the art of maximizing the amount of work not done--is essential

In other words, keep it simple unless there's a current requirement to make it more complex. Don't try to design for some possible future requirement, design for what you know today...for what features are in the current iteration or release.

I've had architects that have struggled with this idea. They would argue that you need to come up with a comprehensive design up front. However, if the requirements aren't known completely (and when are they at the start of a project?) doing a full design will be challenging. I've seen organizations get caught up in analysis paralysis and have trouble getting anything built.

The key is to plan to the appropriate level of detail. At the beginning of a project there are a lot of unknowns, so a detailed design isn't practical. Focus on a design to get you through the first iteration, or maybe the first few iterations that make up a release. Know when you need to refactor.

What can change to require code to need refactoring. I can think of a couple situations;

• Change in requirements - Everything changes. As business needs change and evolve, the programs to support that business need to change as well.
• Change in technology - What technology are you using today that you weren't a year or two ago? Look at how popular devices like tables and smart phones have changed the the way people work and interact.

So what does this mean? The need for refactoring will always be there. I often advice clients that it's better to get a first release of an application to production as quick as possible, even if it's not perfect. You will start receiving some business benefits and it will give you better ideas on how to improve it.

Lean Project Management: How to Apply Lean Thinking in Your Next Project

This Guest Post is from Ian Needs of KeyedIn Solutions

You’ve almost certainly already heard of The Lean Startup by Eric Ries, a book that crushed business preconceptions by promoting a radically minimalist approach to new ventures.

Have you thought about how the principles of leanness can be applied to your project management? You should!

It isn’t all about ‘failing fast’. Lean project management boosts productivity and ROI by streamlining your project to focus on the aspects that have the greatest impact on success.

What Lean Project Management Means for You

Lean project management is the adoption of lean thinking in all areas of a project, from initiation right through to closure.

The aim is to deliver maximum value with minimum waste. In other words, you maximise your return on investment by investing as little as possible, while balancing this with optimal value to your business.

Adding lean thinking to your project management armoury helps you reach completion on time and on budget with minimum effort. To get you started, here are a few Lean Startup catchphrases translated into PM-speak:

“Eliminate Uncertainty”

Evaluate continuously, both to help you keep your project on-track and to know when it’s time to switch tracks entirely. Project management is an on-going process, and evaluation and feedback are vital for process evolution.

“Work Smarter, Not Harder”

Ask yourself first whether this project should be planned. A project whose rationale is shaky may not be worth your business’ resources. Second, ask whether what your need is already available – there’s no point reinventing the wheel if a solution exists that meets your project’s needs. Third, look at what elements you can automate to reduce waste.

“Develop a Minimum Viable Product”

For you, that’s a minimum viable project. Pilot your project on a very small scale, then measure and learn as you execute. By the time you initiate a larger-scale iteration of the project, you’ll already have collected a lot of valuable data to help you optimise the process.

“Validated Learning”

Incorporate empirical experiments into your project to validate your theories and test your assumptions. You can’t rely on an idea for project optimisation until you’ve validated it through the build-measure-learn process.

“Build – Measure – Learn”

For a PM, it’s execute-measure-learn. Never miss an opportunity to collect relevant, actionable data that can help you to laser-focus your project. Make sure that your plans include means and methods for making the most of this data once you’ve gathered it, too!

“Standardise”

In your projects, consistency of information, decision-making and communication are vital to smooth execution. Make sure everyone’s on the same page when it comes to outputs, and don’t forget the importance of standardising reward, too. Project culture and morale play a big part in the Lean Startup mentality for success.

“Pivot”

Sometimes, you have to abandon Plan A. This can be a stressful realisation, but don’t cling to your initial plans if the time for a course change has come. Plan B (or C, or D, or E) will give you a new horizon rather than leaving you stuck in a failing project.

If your projects have felt a bit bloated lately, try applying some of these lean ideas to clear the path. We’d all love to hear how it works for you!

About the author: Ian Needs works as Marketing Manager at KeyedIn Solutions. Find out about their comprehensive project management software package here.

Keeping Current

It's the end of the year. Have you had a chance to step away from your project and see what's going on in the world. Things continue to change.  Here are a couple of emerging trends that I've been thinking about lately.

Polygot Persistence - The database is no longer running on a single server down in the basement, and it's not even relational anymore. Martin Fowler gives credit for the term polygot persistence to Scott Leberknight in this blog post. The idea is that you may have many different data storage approaches for different data, and it may be spread across many servers, even in the cloud. NoSQL is the new buzzword being thrown around (including Fowler's and Pramad Sadalage's book, NoSQL Distilled: A Brief Guide to the Emerging World of Polyglot Persistence. Tools like Cassandra or MongoDB are gaining traction in this new trend. For example, Twitter is now using Casandra, Hadoop, and FlockDB in their polygot environment.

Cloud Computing - Cloud computing is where some part of your solution is in the cloud, a term that is used to refer to the internet. If you have a cloud based tool for running your projects, such as Rally, than you have SaaS - software as a service. If you have your development servers in the cloud, you have PaaS, platform as a service. If you've gone as far as having all your administration done by your service provider in the cloud, you're using infrastructure as a service (IaaS). Here's an article from Infoworld with more details on this trend.

Mobility - In case you haven't noticed, the age of mobile computing has arrived. IBM reported that 24% of people used mobile devices to visit retailers on Black Friday (disclosure - I work for IBM, but all opinions here are my own). We can't think about mobile as something we bolt on at the end of a project. We need to consider that a significant portion of our users may be on mobile devices exclusively and we have to design for it from the start.

As project managers in technology, it's important to keep up with the trends. What other trends are gaining traction?

Authentic Leadership

The keynote speaker at last week's PMI North America Global Congress was Marcus Buckingham. If you don't know the name, he has authored/co-authored a number of books including First, Break all the Rules, Now Discover your Strengths, and most recently, Standout.

His keynote focused on research he did on leadership as part of his latest book. What he found was that for large organizations, the local leader made the difference. However, no to leaders took the same approach. Trying to apply a single leadership model to all of them wouldn't work because you couldn't transfer a leadership style from one person to another.

What he found was a set of nine strength roles. Here's a quick overview of them:

• Advisor - someone that gives people advice and helps solve their problems
• Connector - someone that looks as the world as a set of relationships
• Creator - someone that's a thinker
• Equalizer - someone that looks for the right thing to do and meets their commitments
• Influencer - someone that is thinking about how to move people into action
• Pioneer - someone looking for what's next or what's new
• Provider - someone that creates a safe environment for their team
• Stimulator - someone looking to raise the energy level and get people excited
• Teacher - someone that looks at opportunities to learn and help their team learn

What he said that there isn't a perfect leadership profile, just leaders that understand and follow the practices of the style that aligns with their top two strengths. I didn't have a chance to buy Standout while I was at the Congress, but it will be in my next order from Amazon.

PMI Leadership Institute Meeting

I have been in Vancouver the past few days participating in the PMI Leadership Institute Meeting. As one of the leaders of the Agile Community of Practice, this was an opportunity to meet with my fellow leaders and work on our strategic plan for next year. 

However, there were also a number of great keynote speakers to inspire the 800+ volunteer leaders that were in attendance, representing both local PMI chapters and the 36 Communities of Practice.

Annie McKee was the first speaker we heard. She talked about being a resonant leader and the aspects of a good leader. Emotional intelligence was a key part, specifically, a strong self awareness, social awareness, and self management. If we don't have these skills, we can learn them. 

But being a resonant leader is more than just emotional intelligence. We need to use our power as a leader to serve others, not for our own personal gain. Renewal is also important, but it doesn't have to be 2 hours of meditation every day. Taking 5 minutes of deep breaths can do it. 

The closing speaker, Ed Tate, talked about how we focus. He had three principles; we can only clearly focus on one thing at a time, we get more of what we focus on, and avoiding doesn't work. He gave the example of a race car driver learning to control a spin. If his instructor tells him not to hit the wall, that is the thing he does. 

His presentation resonated with me from the view of not being able to multi-task. He cited some of the same examples of studies I've used when I present on the topic. I think this message is getting out, but there are still a lot of people and organizations that think they can multi-task, and then they don't realize why their projects fail. 

Are you good enough?

I'm currently reading Different Work by Bas de Baar and Lori Kane. It's a set of stories about people that have found work that they love to do. The fourth story is about an interesting couple. The husband has moved away from corporate life and is now a one-man consulting shop. The wife is an artist. One quote from the wife really stuck with me;

A lot of my energy had gone into worrying about not being good enough, instead of strengthening my abilities. 

Do we spend too much time worrying about how good we should be? How often do you really spend thinking about what your strengths are rather than worrying about what your weaknesses might be. Maybe you are in the wrong job, how do you know? There were a few bullet points at the end of the chapter that I think can help;

• Start with what you're curios about
• Pay attention, notice where your energy is, and trust that energy
• Move farther away from work you don't love

Have you had a job where you didn't think you fit in? You felt drained from work, not invigorated? You didn't even want to get up in the morning? I was there once. It took a layoff to get me to move in the right direction. If you need multiple alarm clocks or hit snooze to many times in the morning, maybe you need to start looking for a new job that's a different work where you don't have to worry about being good enough.