Faced with the need for the first time to create not only a summary of the principle “I worked so much in such a position here”, but also to illustrate my skills and experience, I was a little confused.

How exactly to show what was effective and what was not, how to tell about teams and projects without getting lost in the context? In this post I want to present my experience in compiling a portfolio of a project manager and discuss it.
')
I divided the document into blocks, each of which deals with the experience of a manager in the context of a specific indicator. The document is informative and capacious, but it should not be large, each block is presented thesis so as to give a general idea of a particular skill.
Subjects of projects that led the manager
With this all my conversations about work experience began. Integration of either the web, commercial or for internal use, it became the basis of conversations, so I began with this item portfolio.
The complexity of the projects
Evaluating the complexity of projects that led the manager, the easiest way for the number of man-hours spent by the project team to implement it. However, in my opinion, this indicator is more effective to consider as man-hours for the period in which they were spent. For example, a project of 800 man-hours does not give an understanding of the nature of the workload, but specifying 800 man-hours of a team in 2 months already fully demonstrates the complexity of the project.
The size and composition of the project teams
This indicator is indirectly related to the laboriousness of projects, but as a rule, it gives the manager's assessment in terms of competence and communication development, therefore, he considers both the size and the composition of project teams managed by the manager. It is clear that the more people are directly involved in the project, the more effort is expended so that there will be no downtime of specialists, losses in communication and at the joints of the areas of responsibility of the performers, therefore the value of the team is an estimate of the project. As for the composition of the teams, the ability to divide responsibility between specialists, control the transfer of the result of the tasks and the integrity of the solution to the customer’s task is assessed. It is also important in this vein to understand the role of each member of the team and his area of competence, experience in working with people from different backgrounds. In the same block, I would indicate the maximum number of projects that the manager conducted in parallel.
Structure, communication and motivation in projects
I put in one unit very different things related to the inner world of the project team precisely because here I propose to speak not about roles, but about people. What difficulties in interpersonal relations faced, how they worked with conflict situations, what motivation options were used, how they worked out the feeling of a team member in the project as parts. Formal relationships were built, supporting the spirit of “only work and nothing personal” in the team or, on the contrary, becoming a “gang”. The more versatile this experience, the easier it will be to enter a manager into a team or assemble it.
Delivery of projects on time, project planning
This indicator reflects the number of projects from the total number of projects that were completed according to the plan, for a selected period of time (month, half year, year). It is better to clarify here than due to the violation of the deadlines for the remaining projects (to highlight common factors) and to show how the experience of these projects changed the approach to planning and was taken into account later.
Directly, this indicator, of course, does not reflect the effectiveness and professionalism, but is important for the evaluation of the manager.
I would also add this indicator with risks and changes that were taken into account when building a plan with risks that were not taken into account (with an indication of why). You can touch the same way planning tools and achieving predictability (splitting tasks into small blocks with a meaningful result, engaging the client at the stages of internal acceptance to demonstrate the result of work in the moment, etc.). I would not make any questions about the tools to ensure the plan, I would leave it orally for discussion.
Work with project documentation
Here I propose to talk about what the manager did with his hands: he collected and formalized the requirements, divided them into versions of the product, wrote TK, analyzed the client’s business process or compiled instructions for using the product. Even if the manager works in conjunction with analysts, this experience will illustrate an understanding of the tools and mechanisms for turning requirements into a task, a test script and an instruction manual, which, in turn, is the basis for setting and accepting tasks for analysts. If the manager does not have this experience, and such tasks were solved in his projects, then the experience of control of analysts and technical writers will be reflected in a couple of points above.
Project budget control
In this block, I would indicate whether there were projects with budget overruns, with an undeveloped budget, and would note their number in the total number of projects. It is important, in my opinion, to also reflect the measures to prevent the overspending of the budget and the way it appears, to indicate the points of control of the project budget. If the budget is not monitored directly in monetary terms, in this block we can talk about the costs of the project’s tasks in any other equivalent (for example, labor costs) and their management.
Project success
I met the assessment of determining the criteria for project success at the stage of defining the project concept and controlling these criteria when delivering the project to the customer, and monitoring the externally fixed success criteria at the stage of commissioning the project and its operation. Speaking about the success of the project, one can note the profitability of projects, their payback, and any other indicators reflecting customer satisfaction with the quality of the product.
Applied technologies, methodologies and tools
Often I am asked if I worked in the Scrum paradigm or with Atlassian Confluence products. Just listing, as a rule, was enough.
Such a document gives an idea of the key skills of a project manager in development and, in my opinion, helps to determine whether the candidate in question is in line with the company's expectations and, in turn, gives an idea of the level of the candidate and the potential interest in the vacancy.
However, the structure of the presentation and the thesis presentation does not wallow in the details of either the compiler or the reader. And, of course, there is always room for dialogue.For example, a compressed portfolio of a web project development manager:
- Specialization in projects: web projects, integration with settlement and information systems, data import and export.
- Projects from 40 (week) to 8000 (one and a half years) man hours.
- Teams from 1 to 15 people. The team included developers, technologists, system analysts, designers, layout designers, telecommunications systems engineers, content managers, testers. In parallel, there were up to 10 projects at different stages of development.
- The teams used material (bonuses) and non-material motivation (training, emphasis on the importance of the performer for the result, praise, etc.). The interaction between colleagues was built as informally (stand-ups, coffee breaks, etc.), and formally (reporting on tasks in information systems, fixing the coordination activities).
- The manager carried out the elaboration and formalization of requirements, writing the TK and dividing it into product versions, coordinating the TK with the customer and transferring parts of the TK as tasks to work, drawing up a testing plan and operational documentation, and training the client to work with the product.
- Of the 40 projects for the year, according to the plan, 90% were handed over; in the remaining cases of the deadlines, the reasons were insufficiently developed TK, inaccuracy in the assessment of tasks and changes in requirements caused by the change of legislation. Such predictability was achieved through frequent (for small tasks - daily) control of tasks, setting tasks so that you can test the result of the task and present it to the client and the division of tasks between developers in parallel.
- Of the 40 projects submitted during the year, 10 have exceeded the budget (in labor hours). The reasons for exceeding are the inaccuracy of the formulation of the task to the developer and, as a consequence, the inaccuracy of the assessment of the task. Budget control was carried out after a third of the tasks, so the deadlines were not affected in some projects. In the future, in order to avoid budget overruns, I apply a double task reconciliation: with a technologist (lead developer) and project developer.
- Of the 40 projects, 30% paid off, 10% did not pay off, the rest are in the process of reaching the planned profit. Half of the clients recommend the development company to their colleagues; every 5th client orders additional services.
- In the handed over projects "falls" and agile were applied, documentation was conducted in MSWord, tasks were controlled in Jira.