What To Do With Team Members Who Game The System?

For virtual teams in software (SW) engineering, it is very difficult to get productivity out of programmers who refuse to participate in the ISO standards based “Deliver by Documentation.”

In SW engineering, the (generic) life cycle is Requirements –> Analysis –> Design –> Construct –> Test –> Release –> Maintain.

True functioning deliverables don’t start until the Construct phase. Many software engineers (outsourcing) are not good at the written English word. Combine this with the tricks of knowing that one can use a thousand excuses why “something didn’t work.” The result is that SW engineers working remotely can squeeze two months into a schedule where they do nothing on the project before the customer can take action.

How do you, with kindness, communicate the requirement to document thoroughly yet reasonably? This is very difficult to do if the team is already in place and you are brought in as a new leader. Conversations can be held on the side using IM, or with subgroups of the team. Subversion can easily occur. Falsehoods can be communicated for weeks, that are not known or discovered. Requiring everything to be written down is overkill. Some superb programmers simply cannot produce complete sentences, and it may be embarrassment that drives them to skip documenting. Serious tricks of the trade are needed here. Thanks.

The Team Doc Says…

No special tricks of the trade needed here. Simply put, your leadership skills will be tested with this team. So will your project management skills. so put on your armor shield.

Starting right now, you need to call a project meeting of all involved. Your meeting objective is to find out from all team members where the project stands.

This meeting will be a status meeting where each team member explains where they are in their deliverable process. In addition, they will provide tangible proof that their deliverable is at the point they say it is.

You will then conduct regular project status meetings that “prove” progress is being made toward the deliverable. I used to manage a tech group and know it can be a challenge, but it can be overcome.

It would also be a good idea for you to meet one-on-one with each team member to find out what challenges (if any) there are. Communicate to them how vital they and their work is to the entire outcome of the project and how important it is to you to know what obstacles lie in their way.

Then you need to take action to leverage the strengths of each team member. If you have people who are great coders and not so great documenters, team them up with a technical writer. There is absolutely no excuse for not completing deliverables that have been agreed to.

And, one last note. If these team members are outsourced, there’s no reason why you should suffer through this unless they’re the only people who can do what you need. I recommend you seriously look at the possibility of finding a new vendor — if not now, then for the next project.

Anyone else have suggestions? Please leave a comment.