Well, readers, here is my perspective on my practices. Not that this is exactly what I do. Self awareness is a particularly hard state to achieve. (So, if you have worked with or observed me, I stand to be corrected.)
Q1. How do you select/choose the best possible candidate of your technical team? Do you have some sort of criteria / selection process which you may want to share?
In hiring a technical team I am looking for things like motivation and attitude. Professional skills like how you handle conflict and pressure, how you work in a team, do you have a structured approach to your personal work?
I refer to a technical specialist to assess technical skills. In the past I have encouraged some peers and friends to set test questions for interviews.
Q2. How do you ensure that each person on your project team is highly motivated?
I expect people to come motivated. If they don’t, I refer the issue to the team as something for them to sort out. I do my best to assist my team in personal interactions, but I can’t really solve all their personal issues. That’s up to them.
If it affects the team’s ability to deliver a product, that’s an issue for me and the team to work on collaboratively. Personally I tend to focus on positive feedback rather than disincentives. I would try to make the team work together effectively before dumping someone, for example. Opening communication and building trust is a useful technique.
In the best teams I have worked on the team genuinely like each other and so are willing to help each other out and to contribute so that everyone can be successful. Where teams don’t like each other, you work on getting people to understand each other. In intractable situations you can remove the problem people, based on team fit, or park them into non critical roles where they don’t have to interact with others.
Q3. How do you cope when one (or some) of your project(s) is/are getting way behind schedules and upper management is pinching you on the matter?
The main reasons for this are unreasonable expectations from the upper management, often based on poor communication from the PM or project leadership team. In this instance I try to shield my team from this political noise and deal with the misaligned expectations outside the team’s focus. Here is another area where a (leadership) team working together is critical.
If the frontrunners for poor performance are internal to the team there are two likely candidates; technical capability and team cohesion. You can augment technical skills with one or two highly skilled people (skilled in communication as well as technical skills) and you can train your staff. If the issue is team cohesion, that’s a tougher nut to crack. Revisit the team values formally as a group, identify problem areas and have the individuals come up with their own plans, and so on.
Bullying people into submission may work in some places, but I prefer to take a problem solving approach. You’ll need to get the problem identified, understood and acknowledged first.
Q4. How do you decide on the methodology with which to apply on your project?
Methodology is made up of 2 parts; what you need to do to deliver a good product, and what external people expect.
I suggest that you augment your team with a pair of process masters who can whip up any documentation as required for external stakeholders, and then as a team focus on what are the most important things you need to do to get your product to the client a fast and effectively as possible.
This does require some forethought, so a couple of days or sessions early in the project should be dedicated to bringing the team and key stakeholders together and discussing these issues.
Q5. Best advice (or something learned) ever from a person on your project team?
All project problems find their root in poor communication. Not all your stakeholders or team members want to communicate.