How to combine two roles in one person

In modern IT companies, roles in the team often overlap. This happens not only in small companies, where resource limitations are obvious, but also in large ones. It would seem natural to divide the roles in the team to increase efficiency. However, the need for analytics is growing, and often you can see a specialist, combining the analyst and project manager (PM) roles in one project. And in product companies such combination grows into a separate Product owner position.

In this article, we will consider the reasons for such a phenomenon and the mistakes that must be avoided if you practice or only plan to use such a combination.

Responsibilities

Analyst is an information manager;

PM is responsible for project management.

In a standard project, both specialists participate in all stages: from pre-sales training to implementation.

Fig.1 Project stages

In this case an analyst is the internal employee of the project in relation to a PM:

Fig.2 The project team

Both roles have clearly defined responsibilities:

PM’s responsibilities

1. RESULT - achievement of project objectives, developed solutions to issues;
2. BUDGET - adherence to the established expense framework;
3. TERMS - Timeline compliance.

Analyst’s responsibilities

1. QUALITY OF REQUIREMENTS - extraction, formalization, management, transfer of requirements;
2. COMMUNICATION - teamwork and customer relationship;
3. EVALUATION AND TERMS - adherence to established labor costs of analytics.

The main reasons for combining the roles:

• Finance - reduction of financial expenses;
• Operational management - tasks are coordinated faster;
• Decision making - decisions are made faster.

There is also a bonus of getting experience and growing rapidly as a specialist, who in some projects combines roles, and in others performs them separately: in projects where you are an analyst, you get the experience of a PM and vice versa.

9 mistakes to avoid while combining responsibilities

I'm ready to take another project!

Expectations: you, as an analyst, have one project ending and you are getting a new one, in which you will have to be an analyst and PM at the same time.

Reality: balance between communication / administration:

PM: 70% / 30%

Analyst: 30% / 70%

Conclusion: you have two projects instead of one.

The excellence pursuit

Expectations: perfectionism of the analyst generates new ideas and new functionality that would improve the developed system or application.

Reality: for the benefit of the budget, some of the functionality should be deleted.

Conclusion: focus on the release of a specific version that meets the budget and business requirements of the client.

Not elaborating the specification

Expectations: I can quickly explain everything to the developers and I will not waste time on the specification. Or instead of a spec we will use only a detailed prototype.

Reality: high requirements for administration and management. Some developers in the team may not have high qualifications, which imposes high demands on documentation as well.

Conclusion: adequate documentation means that the well defined tasks must be kept in the minds of developers, not just in your own. The developer must be able to use the spec productively, instead of constantly nagging the analyst.

Frequent switching among projects

Expectations: the rapid development pace and the maintenance of several projects require a quick switch among them.

Reality: ragged loading; difficult to evaluate your performance; difficult to switch; management and administration suffer.

Conclusion: what to implement:

1. Calendar of events;
2. Prioritization;
3. Allocation of a limited amount of time to your tasks;
4. Reducing the number of projects.

Transfer the right to make decisions

Expectations: The analyst often consults with the developers about possible solutions in the project.

Reality: The analyst consults the team, clarifies technical issues. If the analyst role prevails, then their authority as a PM deteriorates.

Conclusion:

1. PM makes project decisions;
2. Decisions should be discretionary;
3. Publicly the analyst role is included only briefly.

Not sharing all information

Expectations: as a leader you concentrate all the information in your own hands and don’t share with the team, compensating the desire to retain power. Only I can give you all the information!

Reality:

1. Project risks in case of your incapacity or leaving;
2. Time spent on information and contacts transference;
3. All disadvantages of switching among projects

Conclusion: The team should have all necessary information to work on their own. Planned meetings according to the scheme: updates, statuses, questions and issues.

Estimating your labour effort optimistically

Expectations: as a PM I estimate my analyst role in the project too optimistically.

Reality: ragged workload; failures to meet time limits and labour efforts;

Conclusion: consider risks.

Carrying out QA’s duties

Expectations: taking on 2 roles and being responsible for project quality, you join acceptance process and check not only developers’ work but also QA’s.

Reality:

1. Decreasing QA’s competence in the eyes of the team and their demotivation;
2. Budget overrun;
3. Doing overtime.

Conclusion: if you find a bug overlooked by a QA, personally inform them about it.

Doing overtime

Expectations: realizing your importance and responsibility, you find it necessary to work more.

Reality:

1. Health deterioration;
2. Professional burnout;
3. Management mistakes;
4. Company has to pay for your overtime.

Conclusion:

1. 40-hour work week;
2. Overtime is compensated with time-off;
3. Obligatory vacation!

Let’s make a conclusion

It is known that an average number of the projects that an Analyst or a PM can manage at the same time should be distributed as follows:

Analyst

• 1-2 large projects for 5-10 people;
• 2-4 medium projects for 2-5 people.

PM

• 2-3 large projects for 5-10 people;
• 3-5 medium projects for 2-5 people.

As for roles combination, the number of projects should be 2 times less:

• 1 large project for 5-10 people;
• 2 medium projects for 2-5 people.

The article presents personal experience and knowledge of the author. Perhaps, this knowledge will help you avoid serious problems with combining the roles on the project.