Leadership

Mitigate project role confusion for staff wearing multiple hats

If you expect your developers or contractors to take on business analyst or project manager roles, here are three ways to help them be effective and stay motivated.

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.

About

Rick Freedman is the author of three books on IT consulting, including "The IT Consultant." Rick is an independent consultant and trainer, working, through his company Consulting Strategies Inc., to help agile teams and organizations understand agile...

10 comments
lars.aarby
lars.aarby

I think the main problem here is the lack of skills. You have to recognize that different roles requires different skills. Will working in a agile matter help solve this problem? I dont think so because thats all about the team having all the competence and being self organised. This is about the way you work and not the competences you have. A team should consist of people with the RIGHT compentences. And, even though one works agile the PM role (or rather the compentences) is still needed. Think about the product owner. Agile requires also planning and some are better than this than others :-) I have personally experienced something similar to the problem described and had to find a way through. The assesment of ressources skills is key. My problem was that a date for a release was set and it couldnt be moved. The testteam didnt have any more ressources but my development team could free up ressources to help, but they where not skilled (or very fond of the thought). What we did? We broke it down so the real tester produced the testcases and the developer executed the test. The tester then reviewed the testresult. This way we recognized the skills of tester and the lack of skills at the developer. The developer liked this because it sort of freed them from the responsibility of doing a good test. Same approach could be done in a scrum team where the tester will produce the testcases and make use of the speical skills required. Developers (or others) can then execute the test and so on.

iosivp
iosivp

All what was told here is available in the "traditional" (?) Project Management methodologies. And the problem is that the business and even the team members are not prepared to play equal roles in a Agile / SCRUM team where we do not have any role... Not either PM :) The problem is that for an Agile / SCRUM team all the members should be "seniors" and they should be able to do any part of the job - business analysis, development and so on. Except Project Management. There is not this concept but all the team does it in a more dynamic way. In traditional PM we can leverage the cost by assigning tasks to juniors and call them developers. Seniors should be analysts. Grisoned should be PMs. Isn't it? :)

QAGeek55403
QAGeek55403

I am often tapped to perform a number of roles in a project. As a consultant, I don't feel that I can really say "No," even if I wanted to. I'm there to serve the needs of the client, and that means wearing many different hats. It's my sense that some clients would rather grind down their 'hired help' than to create stress and extra work for their employees. It also means that the employees miss an opportunity to showcase their additional talents (if they are actually good at these other roles) or commitment to the project. I try my best to help the project any way that I can and build my skill set with these extra requests.

mjd
mjd

Excellent read, I find myself in this exact position, being asked to assume a role that isn't my most productive for me or the company. PMPsicle, sounds like a misread. I believe the intent was to convey that disregarding where strengths coincide and indiscriminent movements impart a view that "All of these tasks are interchangeable, and theres no discrete talent or skill set associated with any one of them." Which IS THE DISRUPTIVE MESSAGE that should be avoided not that the writer believes the message to be true.

TownsendA
TownsendA

Its great that some readers have not had these hassles but some have - be prepared. These situations are normally back to the wall desperate ones where time becomes such a problem that just looking for people can be a stumbling block. I am sure all PM's would let their Sponsors/Clients know that this approach is a second prize with results that usually are not top drawer unless its a miracle. Its not what Agile is about (I am waiting for the critics)- not that I follow that methodology.

PMPsicle
PMPsicle

To quote "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." Your disruptive message is built into that whole paragraph. And as a former developer, BA, QC, QA and current PM I take extreme exception to that statement. BA, Developer, QC (i.e. Tester), and PM are ALL discrete talent sets. I would no more assign a BA as a PM than I would a QC as a Developer. They are all discrete (although they do share some skill sets). In fact, a PM shares more skill sets with a BA than he does (or should) with a Developer. I have led many projects in many different project areas from construction to marketing to IS/IT and I have yet to use my IT developer skills in any of them (including IT). I have, however, used the same PM skills regardless of the topic of the project. Director of Project Management and Programs -- Rick you should be ashamed of yourself.

normancarr
normancarr

So we have determined that there are many cases where a person has multiple roles, but should they hold more than one role for the duration of the project? Working in a small team may require one to be Project Manager, Business Analyst and Developer in the same project, requiring a constant switching of hats. Also one can be working on multiple projects at the same time. Slightly different but similar question: should develoment staff do operational work too, beside project (development) work?

c.walters
c.walters

(1) Defining roles should be done for any project. (2) Whenever roles are combined compensating controls should be implemented for risks as scope creep, poor requirements analyses, time creep, poor quality of end products (documentation and software products),

Lance Foss
Lance Foss

This role confusion and related morale and competency issues as you report are solved by maturity and twenty or more years truly managing and working projects of any type and size necessary. It is the experience, education, ability, flexibility, professional development and motivation that happen over several decades of hard work that's missing from the equation. Young people continuing to grow-up, middle-age actors or old and safe are just that.

RickFreedman
RickFreedman

PMP,Sicle; Sorry if my commentary was unclear. Not sure exactly what you're taking extreme exception to here. You take extreme exception and then go on to agree with my point - that all of the roles mentioned are discrete skill sets and are not interchangeable. If I could navigate my way to the meaning of your comments I might be ashamed of myself, but since I'm finding it hard to grasp what you're trying to communicate I'm not sure what I'm supposed to be ashamed of. There's little in your comments that I disagree with - these are discrete skills, assigning a BA as a P M is probably a mistake (as my client is learning), and PM skills apply whether the project is IT or construction. I do disagree with your comment that PM's won't use their developer skills - on every IT project I've managed, there have been attempts to "pull the wool" by some developer who thinks that, as a PM, I can't possibly know what's happedning in the code or what a reasonable extimate is...these are the situations in which having development chops is crucial. Wish I understood what you're getting in a flurry about - I might be able to respond more substantively.

Editor's Picks