I’m in the middle of an interesting conversation with a client, and I wonder if other clients and organizations are struggling with the same issues. In this client’s world, staff members who signed up as developers are now being asked (due to resource shortages and attrition) to also act as testers, business analysts (BAs), and, in some cases, project managers (PMs). The challenges this situation raises includes poor resource management, role confusion, poor fit of skills, morale and motivation issues, and difficulty in delivering business results. Let’s look at these challenges in a bit more depth.

When team members or contractors brought in as developers are also required to play the role of BAs and PMs, it becomes difficult to understand or manage the resource pool. How many hours will designated developers have for business analysis, for project management, and for testing? If the business comes up with a brilliant idea with high profit potential, how will they know who to ask for assistance, and what the availability of that resource will be? Most importantly, as a manager, how do you plan for your resource allocation and for future needs if your entire team is jumping from one role to another?

Role confusion within the staff is an extreme de-motivator. Individuals sign up for roles as testers, or developers, or PMs because that’s where their interests, skills, and self-confidence coincide. When we move them around indiscriminately from one role to the other, we’re sending a disruptive message: All of these tasks are interchangeable, and there’s no discrete talent or skill set associated with any one of them. Anyone who’s asked a team to perform a self-assessment knows that motivated individuals are usually harder on themselves than their managers might be. They expect a lot of themselves because they want to excel in their chosen field. When we haphazardly move them from role to role, we signal that we don’t care about their need for self-identification and self-esteem; we just see them as pawns on a chessboard, waiting to be moved to our best advantage. The effect on morale is obvious.

The required skill set for performing business analysis, such as requirements definition, database modeling, and business context understanding, are often quite distinct from those of developers or PMs. This is not to say that PMs or developers don’t need to have these skills as well; it’s a question of depth and degree. The strongest BAs I’ve managed were experts at developing relationships with their business counterparts and at understanding the unique challenges and characteristics of their businesses. They could apply their technical skills of database modeling to building a data model that could capture and maintain the information required to deliver the business’s application. They could predict the future business needs with enough foresight so that the data model they designed could be extensible and broad enough to accommodate future needs. In short, business analysis is a skill onto itself, and just pointing to a developer and saying “you’re a business analyst” is not likely to be successful.

In our current economic conditions, the motivation is to use staff as efficiently as possible, and getting budget for additional team members is a challenge. As much as we decry the difficulties that rotating roles can create, the economic reality often dictates this approach. Like my client in this scenario, managers recognize the disadvantages associated with multiple roles, but due to the budget realities must ask their teams to work in this manner.

For teams that must ask their staff to wear multiple hats as described here, some strategies that might help mitigate the risks include:

  • Performing a skills assessment: When you’re migrating developers into a PM or BA role, for example, it’s helpful to understand which of your team members might be most suited to those roles. There’s no disrespect intended in stating that certain developers might be more comfortable and skilled in the facilitation, data modeling, and business understanding required for the BA role than others, just as others may be experienced or skilled in the planning and leadership skills expected of a PM.
  • Defining roles: Clear job descriptions and role expectations are necessary, even if team members may be playing these roles only part-time or on a rotating basis. When we ask a developer to act as a BA or PM, it’s helpful to be able to describe exactly what that role entails, and how success in the role is judged. It’s hard to hit an invisible target; even if we don’t expect our team members to take on these roles permanently, documented guidance on the success criteria for these roles gives our staff a bull’s-eye to aim for.
  • Coaching and mentoring: If we expect our developers to take on BA or PM roles, the least we can do is give them training, coaching, and mentoring to help them succeed in those roles. This doesn’t mean that we need to take them out of the field for weeks at a time to train them on the entire BA or PM body of knowledge, but it does imply access to some basic facilitation training, for instance, and to skilled practitioners to whom they can turn when they get stuck.

This post is based on a real client situation, so I’m sure we’ll learn a lot more as this engagement progresses. I’ll report back and let readers know what other challenges and solutions we may uncover as we proceed. If you’re experiencing this situation in your organization, please share your experiences with the community.