Nov 26, 2018
My name is Dmytro Rastaturin, and I work for Daxx NL. 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.
The understanding of the following basics:
- 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.
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.
- 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
What to read:
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.
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 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: 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
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.
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.
- Proper communication of the progress to the customer and the requirements to the team.
- 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 that describes the relationship between a manager and business, not about common methodologies.)
- 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 deep configuration, Atlassian Portfolio, BI/process analytics systems (ServiceClarity & others).
What to read:
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.
- 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)
- 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 account the 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.