Mixing different responsibilities for the same role
Mixing different responsibilities for the same role
Combining different roles in project teams helps with budget saving and optimizing the workload of the team. However one person can’t have too many roles. But often the desire to save money and optimize produces some strange combinations of responsibilities.
Combining different roles in project teams helps with budget saving and optimizing the workload of the team. However one person can’t have too many roles. But often the desire to save money and optimize produces some strange combinations of responsibilities.
For example, take a look at the following requirements for applicants to a job, which are taken from different sites, but are for similar roles. What role in a project could match these requirements?
So, what was the advertised role? Architect? No. Team lead? Again, no ... Maybe an analyst? No again. This was a job opening for a technical writer. However, if we are to be completely accurate, most positions are double: "Technical writer / analyst", "Technical writer - systems analyst", "analyst (technical writer)." In recent years attempts to combine the role of technical writer and analyst began to appear more and more frequently. Let's examine why there was an effort to combine two roles that are so different.
This "innovative" solution arose because of how much the artifacts they produce resembled each other. Both should be able to write competently. Both should be able to write in a clear and correct way. And both should be able to properly format their documents and provide clear and helpful illustrations. So if you don’t go into detail the similarities are there.
However, this similarity is at most superficial. In fact, both in terms of content and process a technical writer and an analyst differ radically. Technical writers develop documents such as manuals or instructions - which describe how the system works. His task is to explain the process of working with the system in a language understandable to the end user. These documents may contain illustrations, screenshots and sometimes diagrams (UML).
But the development of these very requirements is the responsibility of the analyst. The collection, analysis and description of the requirements are carried out at a time when the systems don’t exist – just the needs of the stakeholders. In the initial stages of the project the system only exists in the imagination of the analyst and his task is to correctly describe this imaginary image. Describe it so that stakeholders make sure their business needs are met and developers understand what they have to develop. The documents may contain illustrations and diagrams which (UML, BPMN and other) the analyst should be able to develop on his own.
Thus, if you mix the two activities in the same role, you get a kind of an "honorary writer" role as part of your team which involves some risks.
On the one hand, if you hire an experienced analyst for this position he will cope with the work. But as a rule, an analyst will want a much higher salary for doing two jobs. And even if the analyst is not very experienced and agrees to such work, there is a risk that he will not be in this position for too long. On the other hand, if you offer this position to a technical writer, you will get well-written documents containing incomplete or poorly-designed requirements which may become a serious problem for the project.
So does it make sense to create such a risky role? As I mentioned above, combining the role of a technical writer and analyst may be appropriate, but only for a limited period. During this period (and this is probably no more than a year), the project will receive a certain number of user documents, and the employee will be able to make a new step in his career – becoming a full analyst.
For example, take a look at the following requirements for applicants to a job, which are taken from different sites, but are for similar roles. What role in a project could match these requirements?
- Experience in writing technical specifications for programmers
- Experience in website development and (or) information systems development and technical documentation
- Good analytical skills
- Willingness and ability to think, propose and defend their ideas
- Knowledge of the principles of building web-based applications (experience in developing web-based application)
- Know how to work with graphics editors, diagrams and flow charts (Visio, RationalRose etc.)
- Knowledge of the UML modeling language (Class, Use Case, Deployment, Sequence-State-Collaboration)
- Experience in optimizing and automating business processes
So, what was the advertised role? Architect? No. Team lead? Again, no ... Maybe an analyst? No again. This was a job opening for a technical writer. However, if we are to be completely accurate, most positions are double: "Technical writer / analyst", "Technical writer - systems analyst", "analyst (technical writer)." In recent years attempts to combine the role of technical writer and analyst began to appear more and more frequently. Let's examine why there was an effort to combine two roles that are so different.
This "innovative" solution arose because of how much the artifacts they produce resembled each other. Both should be able to write competently. Both should be able to write in a clear and correct way. And both should be able to properly format their documents and provide clear and helpful illustrations. So if you don’t go into detail the similarities are there.
However, this similarity is at most superficial. In fact, both in terms of content and process a technical writer and an analyst differ radically. Technical writers develop documents such as manuals or instructions - which describe how the system works. His task is to explain the process of working with the system in a language understandable to the end user. These documents may contain illustrations, screenshots and sometimes diagrams (UML).
But the development of these very requirements is the responsibility of the analyst. The collection, analysis and description of the requirements are carried out at a time when the systems don’t exist – just the needs of the stakeholders. In the initial stages of the project the system only exists in the imagination of the analyst and his task is to correctly describe this imaginary image. Describe it so that stakeholders make sure their business needs are met and developers understand what they have to develop. The documents may contain illustrations and diagrams which (UML, BPMN and other) the analyst should be able to develop on his own.
Thus, if you mix the two activities in the same role, you get a kind of an "honorary writer" role as part of your team which involves some risks.
On the one hand, if you hire an experienced analyst for this position he will cope with the work. But as a rule, an analyst will want a much higher salary for doing two jobs. And even if the analyst is not very experienced and agrees to such work, there is a risk that he will not be in this position for too long. On the other hand, if you offer this position to a technical writer, you will get well-written documents containing incomplete or poorly-designed requirements which may become a serious problem for the project.
So does it make sense to create such a risky role? As I mentioned above, combining the role of a technical writer and analyst may be appropriate, but only for a limited period. During this period (and this is probably no more than a year), the project will receive a certain number of user documents, and the employee will be able to make a new step in his career – becoming a full analyst.