This short walk down the corridor often speaks volumes more than the weekly project meeting. To me this signals a time when a one-to-one meeting is required, in order to get to the bottom of the problem.

With remote team members this type of reaction seeking or non-verbal communication is not evident. It is possible to hear fear when a person speaks, yet in a teleconference it is possible to hide – simply by remaining silent. When you are in a teleconference with your remote team members do you ever ask for personal feedback from every person present? Trouble is that it is all too easy to forget the silent ones even in a face-to-face meeting.

Generally speaking in any meeting there are two reasons to be silent. Firstly shyness, and secondly because that individual has something to hide.

Shyness is a symptom of managing comfort zones. We can all be shy when confronted with something new, and perhaps a little intimidated particularly when we understand very little about it. It can normally be managed by coaxing that person out of their existing comfort zone and expanding that comfort zone to include the new working environment.

Having something to hide is a different matter. These team members are the onces who are most likely to bring bad results on a project, irrespective of the circumstances. Projects are always limited by time and resources, whenever there are problems it is always vital to share. Managing projects via Agile methods does allow problem areas to be ring-fenced and focused on more thoroughly at a later stage. I am always more concerned about those who hide away because they have a problem than I am the shy person.

Despite sayings like “a problem shared is a problem halved” having entered the main-flow of society, people tend to be concerned that when a problem is identified then it is their personal challenge to solve it. They hide the problem in the hope that no-one finds out about the problem. Sadly this is the point when it starts to have a negative impact on everything that you do. Project working is not generally the place for heroics. That person who focuses on the problem and tends to lose sight of their deliverables.  Here we are back at the team member who rushes back the other way when when they see you, their manager, in the corridor. Something is wrong here and needs to be solved.

BUT how do you do this when the person is working remotely? Many project managers believe that having remote workers is too risky. Yet it is the things we do not wish to do that we are often forced to do.  There is a certain amount that can be achieved by regular visits to remote sites, yet at all times you remain a stranger at that remote location – so there is a psychology to managing remote visits. Remote project workers are a fact of life, as are constrained project budgets. The latter reduces out ability to complete regular remote-site visits, so it is essential to identify remoteness challenges of virtual teams in other ways.

It is vital all virtual team members are a part of developing and following the team plan – this must be lived and breathed. Knowing each remote worker is important – you probably need to spend a disproportionately high amount of time developing this relationship. You need to stay in touch, daily is best; set and follow an agenda for all meetings – ensure it is business focused. Leverage technology where appropriate – particularly collaboration tools.

• 80 percent of time and effort goes into deploying the 20 percent requiring the most customisation.
• Developers spend 80% of their time debugging applications and 20% writing new code.
• Getting 80% competent as a developer isn’t really hard — but that last 20% to go from competent to great is really, really tough

Even the business world has its versions of this rule e.g. “80% of your sales come from 20% of your customers.” Each of these has a certain element of truth in it, but they should be seen as a guideline rather than as a hard rule. In the old days when I used to cut code my own version was that I spent 80% of my time on the toughest 20% of functionality. Now there is is a new rule in the operational computing world. When it comes to running a computer program 90% of the execution time is spent executing just 10% of the code.

So is this all just a bunch of stats dreamed up by academics and management to justify the amount of time taken to deliver solutions?

It could be argued that IT leaders have been leveraging the 80-20 rule in order to maintain budgetary control. I would argue the reverse. Because IT spends more effort making things 100% perfect, would it not be better to live with 80% of the functionality and minimise unnecessary expenditure?

It is my belief that the type of deployment or development will aid cost saving. There is a law of diminishing returns that applies in all circumstances. Agile deployment, for example, is the 80-20 Rule at work. It emphasizes speed and adaptation to changing business realities, including the option to decide when the delivery is good enough. It is important to deliver the features of most value to the bottom line of business, other functions can be axed or delayed till later stages. Also project delivery is not about being fast, but about the quality & effectiveness of the delivery to the business.

Agile delivery will also allow the option to stretch out all delivery timelines for the current period. To acheive this you reduce the number of active projects and the size of the teams.