5 must have skills for a project manager or how to be promoted to middle and senior positions at your company

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.

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).

• 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.

The understanding of the following basics:

• Client and server side (Back-end, Front-end)
• Application programming interface
• HTTP and requests
• Object-oriented Programming (OOP)
• 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.

• Client and server side (Back-end, Front-end)
• Application programming interface
• HTTP and requests
• Object-oriented Programming (OOP)
• 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.

• Version control

• Version control

– 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.

• Gitflow

• Gitflow

– Also one of the best Git-models.

• 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.

• Continuous Delivery Practices
• Business Intelligence (BI): Implementation and Automatic Reporting
• Real-time Processes Monitoring
• The configuration of automatic analytics notifications for the selected metrics;
• EazyBI is a good start

• Continuous Delivery Practices
• Business Intelligence (BI): Implementation and Automatic Reporting
• Real-time Processes Monitoring
• The configuration of automatic analytics notifications for the selected metrics;
• EazyBI is a good start

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.

• What is the Waterfall model?
• What is Agile (first, we need to understand what is Scrum/Kanban)
• What is Lean?
• Types of contracts. The difference between Fixed Price vs Time & Material types of contracts.
• Budget management.

• What is the Waterfall model?
• What is Agile (first, we need to understand what is Scrum/Kanban)
• What is Lean?
• Types of contracts. The difference between Fixed Price vs Time & Material types of contracts.
• Budget management.

• 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)
• Building Gantt graphs for the client.
• Proper Release and Integration Planning
• 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)
• Building Gantt graphs for the client.
• Proper Release and Integration Planning
• PMBOK, PRINCE2 practices and how they differ from Agile.

• 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

• ‘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.
• ‘Agile Estimating and Planning‘ by Mike Cohn
• ‘The Lean Startup‘ by Eric Ries.

• ‘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.
• ‘Agile Estimating and Planning‘ by Mike Cohn
• ‘The Lean Startup‘ by Eric Ries.

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:

1. 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.
2. 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.

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).

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.

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.

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.

• 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.

• 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.

• 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

• “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.

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.

• 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.

• 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.

• The ability to solve conflicts
• Risk Management
• Conducting one to one meetings.

• The ability to solve conflicts
• Risk Management
• Conducting one to one meetings.

• KPI implementation, performance evaluation (integration with BI).
• Management of cross-project/shared/remote teams
• Conducting interviews.

• KPI implementation, performance evaluation (integration with BI).
• Management of cross-project/shared/remote teams
• Conducting interviews.

• “Manager’s Black Book” by Slava Pankratov (a book is about the relationship between a manager and business, not about common methodologies.)

• “Manager’s Black Book” by Slava Pankratov (a book is about the relationship between a manager and business, not about common methodologies.)

• Jira (user level), Confluence, Google Docs, Email/Slack.

• Jira (user level), Confluence, Google Docs, Email/Slack.

• Jira advanced level, Confluence, prototyping tools (Balsamiq Mockups, Proto.io, Axure, etc.), MS Project or similar.

• Jira advanced level, Confluence, prototyping tools (Balsamiq Mockups, Proto.io, Axure, etc.), MS Project or similar.

• Jira deep configuration, Atlassian Portfolio, BI/process analytics systems (ServiceClarity & others).

• Jira deep configuration, Atlassian Portfolio, BI/process analytics systems (ServiceClarity & others).

• ‘JIRA Essentials‘ by Patrick Li, the Third Edition

• ‘JIRA Essentials‘ by Patrick Li, the Third Edition

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.

• Project Scope Management (budget management–middle level is the very minimum)

• Project Scope Management (budget management–middle level is the very minimum)

• 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

• 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

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.

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.

Tags

Cross-industry

Strategy

Share

Follow

Subscribe

Follow