6

What can I do as a project manager to ensure new team members are quickly brought up to speed within the project team?

The team is multidisciplinary, having mobile software engineers, UI & UX designers, front-end and back-end web developers, and testers. Team members are coming in fast; they need training to get used to our systems and processes, but they also need to feel they're in the team.

In managing a project the most important factor is to have people working on the project like it is their own. With dispersed teams that don't have a common workplace, and that may never meet, that purpose is hindered by communication issues, mistrust, cultural differences, you name it.

How should I approach this issue from a project management perspective?

Improve this question
8
  • 1
    Is your team doing software development?
    – Matthias Jouan
    Dec 27, 2012 at 0:18
  • 1
    Hi sqreept, welcome to PMSE. I edited your post a bit to make it sound less like a poll and also to make it a bit more applicable to project management. It could probably use a bit more details about the project and systems so people don't make incorrect assumptions. Hope this helps!
    – jmort253
    Dec 27, 2012 at 4:23
  • 1
    Let me give more context here:
    – sqreept
    Dec 27, 2012 at 12:10
  • 1
    In managing a project the most important factor is to have people working on the project like it is their own. With dispersed teams that don't have a common workplace, and that may never meet, that purpose is hindered by communication issues, mistrust, cultural differences, you name it. What I'm asking here is what others tried and worked to improve the synergy and sense of belonging of a dispersed team.
    – sqreept
    Dec 27, 2012 at 12:18
  • 1
    Excellent clarifications; I've added them back into the question because I think it increases the value.
    – MCW
    Dec 27, 2012 at 15:39

3 Answers 3

Reset to default
3

The Project Management Perspective is Process-Oriented

Project management is about shepherding process. As such, implementation details such as XP practices or training are (at best) tangential to the role.

However, there are things you can promote at the project level. For example:

  1. Make on-boarding a defined process.
  2. Make the development team responsible for designing and implementing the on-boarding process.
  3. Work with the development team to identify metrics and milestones for on-boarding.
  4. Agree on a "definition of done" for the completion of the on-boarding process.
  5. Enable success, but fail early when (not if) on-boarding is occasionally not successful.

Why the Details Don't Matter

Specific implementation details will vary based on project requirements, organizational culture, team composition, and (most important of all) the personalities of those already on the team. That makes prescribing a generic "best practice" almost useless.

From a project perspective, the focus on the entrance and exit criteria for the on-boarding process is what's most important. For example, the project might:

  • Want all new developers to be competent to handle routine bug tickets, with deeper mastery of the code base reserved for "down the road" somewhere.
  • Want initial on-boarding to be completed in six weeks or less.
  • Want some way to know if the on-boarding process was successful or unsuccessful.
  • Want a feedback mechanism to inspect-and-adapt the on-boarding process to make it more efficient.

On one project I managed, the on-boarding process included daily pair-programming focused on unit tests, which is often an excellent way for a new programmer to understand the underlying assumptions, assertions, and expectations that an application has. The team considered on-boarding successfully completed when the new hire could turn an uncomplicated SEV-3 ticket into a failing unit test within 48-72 hours.

If your shop doesn't do unit testing, resists pair programming, or has some other metric for deeming on-boarding to be complete, then you will obviously need a different process and a different set of procedures. The people who are best able to identify those processes and procedures are the development team itself, so why not let them do what they do best?

Focus on tracking project performance and the exit criteria for the on-boarding process. Don't try to do the development team's job for them. At the end of the day, integrating a new team member may be a project process, but it's inherently the development team's responsibility.

Improve this answer
3

Short answer : the most efficient way that I know to train and integrate a new team member is Pairing (pair-programming, I don't know to what extend this can be applied testers etc.).

With pair-programming, new members will be in the team right from the start, they will learn how your organization works from the inside and begin to do their job really fast; but you might have to make sure that the team is ready for pair-programming and accept it before to try it with a new recruit.

Improve this answer
2

My experience as a developer is - never underestimate meeting in real life.

After meeting my remote team members in real life for the very first time my interaction with the team members changed drastically. After all it is very common with team building activities when forming new teams, the rationale is that out of office activities will improve the communication within the team. The remote team members are not only forced to communicate over a telephone of telepresence but it will also isolate them from the day to day chit-chat the is so crucial in forming a team.

The other option is to work with what you got and therefor giving isolated tasks to the remote team enabling them to form a sub team of their own.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.