My name is Dmytro Rastaturin. I’m an Operations Manager at Pindrop NL (Daxx 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

These components should be considered as one since they are dependant 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.

Architecture Fundamentals. Release Management.

Junior

The understanding of the following basics:

Middle

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

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

Senior

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

Case Study

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.

Product Quality Management 101 Reveal the most efficient techniques for Product Quality Management that help you raise the quality bar across the organization and reach high-level goals. Download My Guide

Planning

Junior

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.

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)

Building Gantt graphs for the client.

Proper Release and Integration Planning

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

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.

'Agile Estimating and Planning' by Mike Cohn

'The Lean Startup' by Eric Ries.

Case Study

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

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.

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

Communication Management

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.

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.

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

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

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.

People Management

Junior

Proper communication of the progress to the customer and the requirements to the team.

Middle

The ability to solve conflicts

Risk Management

Conducting one to one meetings.

Senior

KPI implementation, performance evaluation (integration with BI).

Management of cross-project/shared/remote teams

Conducting interviews.

What to read:

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

Tools

Junior

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

Middle

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

Senior

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

What to read:

'JIRA Essentials' by Patrick Li, the Third Edition

Requirements Management and Documentation

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)

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

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)

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: