My name is Dmytro Rastaturin. I’m an Operations Manager at Pindrop NL (Grid Dynamics Digital Team client). Our end-customers come from Europe, the main operating market is in Benelux (we also work with the customers from France, UK, Italy, Spain, and others).
The following article will be interesting for beginners or mid-level managers. However, I believe that an experienced manager can find here something useful as well. The article shares what aspects one has to learn, where to begin, and what to do in order to improve his/her skills in the field of project management (or an IT-related position).
In this article, I am considering middle-level projects only (complex enterprise projects and single-page websites are not part of this topic). An example of such a project is the SaaS-platform for event management automation at a big vendor company in several locations.
What does a project manager position contain?
Software development management spans a lot of related areas, that is why the responsibilities of a Project Manager at different companies will undoubtedly vary. I am talking about the duties regarding the project management (the project is kept as the main focus) as well as the concept of delivery/operations management (your primary focus is the process via managing various or related projects and distributed teams).
The main components of a project manager’s role:
Architecture Fundamentals. release Management.
Planning Management
Communications Management
People management
Tools Selection
Requirements and Documentation Management
Budget management
Architecture Fundamentals. release Management.
Planning Management
Communications Management
People management
Tools Selection
Requirements and Documentation Management
Budget management
These components should be considered as one since they are dependent on each other. Therefore, let’s take a look at these within a conventional structure since we should understand first how the components of the system work and then move to Junior, Middle, Senior levels.
Release management. A release is the “heartbeat” of your project. It has to deal with the implementation and quality control of your product. As part of the release management framework, the new policies of the software and hardware versions are being developed and implemented.
Release management. A release is the “heartbeat” of your project. It has to deal with the implementation and quality control of your product. As part of the release management framework, the new policies of the software and hardware versions are being developed and implemented.
– The understanding of 1. a GIT-process; 2. Committing the changes 3. The technical side of the release. However, please keep in mind that the manager is not responsible for the implementation of a project. It is the responsibility of the team to check the pull requests and implement them technically. The manager has to coordinate the process, but not particularly implement it.
An understanding of how the product is developed, deployed to the right environment: development/QA, staging/UAT, production/live (exact naming can vary at the company).
What is Continuous Integration (CI), namely CI of the code (frequent updates of your system/code of your project, which are performed in phases) and the further automation of this process.
An understanding of how the product is developed, deployed to the right environment: development/QA, staging/UAT, production/live (exact naming can vary at the company).
What is Continuous Integration (CI), namely CI of the code (frequent updates of your system/code of your project, which are performed in phases) and the further automation of this process.
Often it is considered that the more frequently releases happen, the better. I agree only partially: releases have to be performed regularly, but their frequency depends directly on the company’s business needs.
In this article, I will not be explaining when and why you need Agile, but generally speaking, an iterative development sometimes is the only right decision to successfully deliver the project to the customer as well as significantly decrease the stress level for your team.
Types of contracts. The difference between Fixed Price vs Time & Material types of contracts.
Budget management.
Middle
Planning Management
The ability to perform the responsibilities of a Scrum Master (often coincides with the responsibilities of a Project Manager)
The ability to work with estimations (more in a Mike Cohn book), simultaneous work on several levels of planning (high-level, story level, technical level)
PMBOK, PRINCE2 practices and how they differ from Agile.
Planning Management
The ability to perform the responsibilities of a Scrum Master (often coincides with the responsibilities of a Project Manager)
The ability to work with estimations (more in a Mike Cohn book), simultaneous work on several levels of planning (high-level, story level, technical level)
PMBOK, PRINCE2 practices and how they differ from Agile.
Senior
The implementation of various planning models and understanding what is appropriate for the specific project.
Cross-project release management
Release management in the project portfolio
Selling the sprints to the customer
The implementation of various planning models and understanding what is appropriate for the specific project.
Cross-project release management
Release management in the project portfolio
Selling the sprints to the customer
What to read:
‘Scrum and XP from the Trenches‘ by Henrik Kniberg. A must-read book for beginners. It is available online and clearly explains how flexible Agile methodologies work.
‘Scrum and XP from the Trenches‘ by Henrik Kniberg. A must-read book for beginners. It is available online and clearly explains how flexible Agile methodologies work.
We work simultaneously on different levels (as an example, we will take a general model, not the contract)
High (Epic) level: rough planning (range pessimistic/optimistic + communication of the risks to the customer (if possible). The classical model PERT is used to estimate the probabilities. At this level, we generally sell the project
Business (story) level: (user story level). The planning of an iteration with the proper description and acceptance criteria (but no technical decomposition yet). Preparation of features with the help of the Kano model. It is an iteration planning after the project was approved and the scope of the project was prioritized.
Technical (sub-task level): technical tasks for developers. Planning occurs within one iteration. The tasks at this level are as detailed as possible.
High (Epic) level: rough planning (range pessimistic/optimistic + communication of the risks to the customer (if possible). The classical model PERT is used to estimate the probabilities. At this level, we generally sell the project
Business (story) level: (user story level). The planning of an iteration with the proper description and acceptance criteria (but no technical decomposition yet). Preparation of features with the help of the Kano model. It is an iteration planning after the project was approved and the scope of the project was prioritized.
Technical (sub-task level): technical tasks for developers. Planning occurs within one iteration. The tasks at this level are as detailed as possible.
We use classical two-week sprints and adhere naming to «Sprint-X-year-month-week» format to:
Make sure the Product Owner knows when he/she will receive the particular functionality on a staging environment without the need to check a releases calendar every time.
Be able to tell six months later when and in which release, specific functionality was finished.
For example, we are finishing the Sprint-3-18.6.2, which means that the Product Owner will see the required functionality in demo-version at the end of the second week in June. It makes it easier to schedule tasks for the next iteration.
How do we manage versioning?
Because a release of an iteration is not always a release in live deployment(s), we use the following versions control: in Git and in a release ticket to deliver a release to the customer (staging) or live deployment(s).
How do we do it in Jira? What if we need a hotfix before the end of integration?
By creating a ticket with the customs issue Type = `Release,` where we indicate (Git) version, and later on the ticket is planned as a part of the iteration. I recommend you to read carefully what the version management is since there are a lot of dependencies in any process and the correct versioning allows to manage them properly.
How do we estimate the resources, which can be divided among several small projects?
We use the term Capacity for each FTE, which means that every team member (the teams are also depicted in Atlassian Portfolio) has a particular amount of hours in the sprint. Capacity includes additional time in case of the unforeseen risks.
This means that using the proper configuration, and the manager can control the resources flow and make plannings fast and efficiently (the two-way synchronization with Jira should work). He/she should remember that a release has to be rolled out (it can be several releases if we are talking about portfolio management) and the sprint scope should not be overbooked
Capacity is taken into account in case of release workload planning, which is highlighted with red if the Manager needs more resources than required.
Offshore Developer Rates Guide
Get outsourcing rates in Eastern Europe, Asia, Latin America, Africa as well as tips on how to choose the country for offshore development.
Communication is an essential part of a project manager’s work. I believe, the process is the main thing, while communication is one of the system components we manage.
Junior
English level: Upper-intermediate (B2 is the very minimum)
Proper communication of the risks
Communication within the team, the position of a Team Lead.
English level: Upper-intermediate (B2 is the very minimum)
Proper communication of the risks
Communication within the team, the position of a Team Lead.
Middle
English Level: Fluent (C1, C2)
Project management since SOW has been signed (it’s possible before a release, but excluding budget management).
Project Risk Management and proper communication of the risks to the customer.
English Level: Fluent (C1, C2)
Project management since SOW has been signed (it’s possible before a release, but excluding budget management).
Project Risk Management and proper communication of the risks to the customer.
Senior
English Level: Fluent (C1, C2)
Experience working with C-level stakeholders (people who are interested in the project)
Participation in pre-sales
Delivery Management
English Level: Fluent (C1, C2)
Experience working with C-level stakeholders (people who are interested in the project)
Participation in pre-sales
Delivery Management
What to read:
“Everything is Negotiable” by Gavin Kennedy. It is crucial to know how to negotiate with the client and provide reasonable argumentation when saying “no.” Otherwise, you will end up working under extremely tight deadlines, because you failed to take the risks into account. As a result, you will pay the overtime from your budget, the project result will be unprofitable, and the client won’t be satisfied with the delivery
“Everything is Negotiable” by Gavin Kennedy. It is crucial to know how to negotiate with the client and provide reasonable argumentation when saying “no.” Otherwise, you will end up working under extremely tight deadlines, because you failed to take the risks into account. As a result, you will pay the overtime from your budget, the project result will be unprofitable, and the client won’t be satisfied with the delivery
Since customers often want to change the project scope when it’s in progress (this is called “scope creep”), you should pay particular attention to change management.
Case study
Due to some changes in internal policies, the client started acceptance testing two months after the project was delivered. They started sending numerous requests for change, which, in their opinion, should have been implemented within the original budget.
What have we done?
We described the scope changes according to the new requirements as the Time & Material
Decomposed it into the several phases (Epics), starting with MVP (Minimum Viable Product)
Prioritized the stories together with the Product Owner
Negotiated the project scope with the client, referring to the initial requirements
Built planning and were keeping customer posted on the whole process.
We described the scope changes according to the new requirements as the Time & Material
Decomposed it into the several phases (Epics), starting with MVP (Minimum Viable Product)
Prioritized the stories together with the Product Owner
Negotiated the project scope with the client, referring to the initial requirements
Built planning and were keeping customer posted on the whole process.
People management
Junior
Proper communication of the progress to the customer and the requirements to the team.
Proper communication of the progress to the customer and the requirements to the team.
Documentation, as well as its structure, is essential. We use a hierarchy identical to all projects (an example is below), so it is vital to create a structure that can be copied from project to project. It also helps a new member or the project stakeholder easily find the needed data. That is why we started creating the templates for document management.
Traditionally, we work with Confluence. Although it doesn’t matter what tool do you use, the main thing is that the documentation is always available for viewing and simultaneous editing to all the team members.
Not only requirements, but meetings, processes, and policies within the company are also documented.
Budget management
Junior
Project Scope Management (budget management–middle level is the very minimum)
Project Scope Management (budget management–middle level is the very minimum)
Middle
Evaluation of the project and the communication of data to the customer
Time Tracking Analysis
Budget Communication/budget Management (depending on the policy of the company)
Reporting
Evaluation of the project and the communication of data to the customer
Time Tracking Analysis
Budget Communication/budget Management (depending on the policy of the company)
Reporting
Senior
Time Administration
BI Budget Monitoring
Automatic notifications of budget excess (by iterations/releases)
Team/Project Budget
Budgeting of a certain time period in advance
Flexible invoicing of T & M hours (export configuration depending on the account)
Time Administration
BI Budget Monitoring
Automatic notifications of budget excess (by iterations/releases)
Team/Project Budget
Budgeting of a certain time period in advance
Flexible invoicing of T & M hours (export configuration depending on the account)
In many companies (ours is not an exception,) the project is profitable during the support phase after the main phase of development has been completed. Therefore, support can and should be sold as additional scope/ hours
Conclusions
Intentionally, I provide the information in the way above, so that a new-coming specialist won’t end up lost in a massive amount of information. A ladder “junior-middle-senior” should also be considered as a conventional unit. Similarly, you can apply “A-B-C,” so please don’t assume that a Middle Project Manager should have precisely this specific set of skills.
Key takeaways:
Here are several important points, which define a qualified and experienced Project Manager:
Controls the process. If the manager isn’t in charge, the project most probably won’t be successful.
Knows the product architecture. Namely, understands the logic of the product, what is delivered to a customer, how the modules interact, etc.
Optimizes work processes. Tries to simplify everything that can be clarified.
Doesn’t make decisions instead of developers. Never sells a project without the evaluation of the team.
Can “walk in the customer’s and team’s shoes.” Studies the customer’s business goals and the subject area voraciously.
Plans and manages planning on several levels.
Takes into accountthe potential risks.
Always controls the budget. Time is money.
Structures and predicts the processes. Processes must be predictable for the team and the customer.
Makes sure the processes are flexible. If the process collapses with the slightest deviation from the plan, it is not an appropriate process.
Always works with people. Without a team, you can’t build a product, and without a client, you aren’t able to pay salaries. That’s why a good Project Manager works on both sides simultaneously.
Controls the process. If the manager isn’t in charge, the project most probably won’t be successful.
Knows the product architecture. Namely, understands the logic of the product, what is delivered to a customer, how the modules interact, etc.
Optimizes work processes. Tries to simplify everything that can be clarified.
Doesn’t make decisions instead of developers. Never sells a project without the evaluation of the team.
Can “walk in the customer’s and team’s shoes.” Studies the customer’s business goals and the subject area voraciously.
Plans and manages planning on several levels.
Takes into accountthe potential risks.
Always controls the budget. Time is money.
Structures and predicts the processes. Processes must be predictable for the team and the customer.
Makes sure the processes are flexible. If the process collapses with the slightest deviation from the plan, it is not an appropriate process.
Always works with people. Without a team, you can’t build a product, and without a client, you aren’t able to pay salaries. That’s why a good Project Manager works on both sides simultaneously.
