How to become a better project manager

Trying and failing TONS of times during different products, startups creation and launching, learning on my own mistakes, when finally, I came up with this short summary on how to work with requirements, clients, requests and how to support a project, based on my experience and common sense.

1. Project start:

You’ve got an incoming inquiry to your contact form or somehow got a client interested in your solutions, no matter how. The first step is going to be:

1.1. Initial meeting/call/intro to the project

Before the meeting we should dig all the possible information about the project, business and persons who will come to you, also don’t forget to ask for the all available materials and resources about an upcoming project in advance (if they have it), so the meeting is more productive.

ALWAYS make notes. You are a project manager, you need to know what happened, what are the requirements, when they have changed, why, etc.

The purpose of the current meeting is to get familiar with clients business / why do they need our solution / understand the purpose of a project.

List of obligatory questions you should ask:

1. How did they find out about you
2. What they have already done / what is their current progress with the project
3. Deadlines/release schedule
4. Impact of a project
5. Market research, whether they made it
6. Designs readiness
7. References to other apps they like
8. How they will promote the app
9. MVP, Phase 2, 3, 4, etc. / Scalability of a project.

Gather generic requirements (should be only high-level goals, ideas). You shouldn’t go deep into each detail, otherwise, you would lose the focus and end up discussing the “colour of the fence” instead of how nuclear reactor should work. You should understand in general what they want to do, how they see it doing, are there any limitations, specifics.

Understand their business — how they are making money. Is that huge project to them, side project or just an experiment.

Will it impact their current business? It determines how involved the customer is going to be in the project, how much of the time / control they will dedicate to you. Usually the more responsive client is, the better success app has. So, it should be meaningful to them.

Show some of your delivered products, the most relevant to their case or apps that you have recently released or are most proud of developing.

2. Scoping the project:

Create a Ballpark estimate:

Based on all of the information used on a meeting, we create a ballpark (very rough) estimate of the planned functionality based on your previous experience.

Our estimation spreadsheet template https://docs.google.com/spreadsheets/d/1-TCagYBnMe580_yU11urXBHppEhTpghJZwQp8P9Ul9Q/

The idea is to split all the development functionality into small parts and estimate them separately. It’s valuable for you as a developer — because you better understand the product you are about to create and by breaking down the project scope, you go into very detailed view and understand on what the technical difficulties and impediments are ahead.

It’s a great thing on the client side as well since it gives you the idea on agency overall pricing (what part of the app costs what). That helps you to compare agency with competitors and ensures that you can reevaluate the scope and remove some functionality, which means — reducing the price.

What if you don’t know how to estimate it?

Components, third-party integrations with unfamiliar services, external libraries — you can only speculate on how long it will take to develop/integrate it…

One of the most common issues — some technical task after deep diving into the issue appeared to be much harder than team initially thought.

What to do in this case?

As one great option, you can ask for a client to provide extra time for investigation, to be sure of precise estimate and remove it out of the scope for a while.

With ballpark estimate sent and when a client has reviewed it. After you both agreed that there are no more changes, all parts of the functionality are clear and understandable. We should confirm the estimate and transfer it from ballpark estimate to original estimate, that will be a baseline for a contract.

If the price is too big for the client, do not rush to make discounts or reject the offer — you can operate with functionality instead.

Development can be always split into some separate modules. Therefore, it allows to remove/add functionality.

You can remove unnecessary functionality from the app, to reduce the price — like: Two-factor authorization, FaceID, TouchID, etc., it can be added to the app later on and would not affect the app itself.

3. Technical specification:

3.1. Drawing functionality map:

Drawing functionality as a “mind map”, to put all the possible transitions, screens, states and events on a whiteboard

It’s done to make sure you haven’t forgotten anything. You can clearly see all the navigation and logical components/epics of the upcoming app. It also helps you to entirely understand the app, whether there are some strange moments and bad transitions / missing screens, etc.

It’s highly recommended to draw mindmap before drawing designs, straight after wireframes are ready.

Why?

1. Helps you with states
2. You understand how the app will work
3. Have a clear navigation model within the app

3.2. Writing it down to create specification:

Based on visual functionality map (mindmap), you should create a document with detailed technical specification.

It should consist of:

1. Generic requirements (OS version, hardware, software, agreements between parties, etc.)
2. Mobile requirements
3. Split by modules, epics (login/registration, chat, user profile, my profile, etc.)
4. On the left — description of what should be done
5. On the right — screenshot with wireframes/designs

Good examples can be found here -https://docs.google.com/document/d/1bmmO08woxz5aeJDhw2XqSbqOA5AGs7qz3mI0xHMMhzc/

3.3. Create a timeline:

The purpose for Gantt chart is to understand the development plan on a timeline.

For Agile projects — you should still create a timeline for project delivery. It can be done by sprints planned (usually sprints are done by modules / interconnected functionality).

For Kanban projects (support projects) — Usually there is no need to draw a timeline, however, if it’s needed — you can use release versions to put milestones on a timeline.

Tools:

• Microsoft Excel or Google sheets

• JIRA next-gen projects — Roadmap

• Confluence roadmap planner macro

4. How do you manage the project:

Your main purpose as a project manager — to identify issues and fix them in time. As well as, to overview if everything is clear for the team, client and yourself in order to burn the backlog.

If client requires some extra functionality to add for the scope of a project, don’t rush to make them happy and say YES.

First, take a look onto Gantt chart, on your burndown of the sprints and then, consulting with team lead of a project (senior developer), make sure that he/she understands the task. Estimate it and check the timeline again.

In most of the cases by doing so, you will identify that you are behind the schedule and it would be necessary to trade off some of the functionality

4.1. Dealing with unexpected problems:

• Understand the issue -> Find the possible solution by yourself -> discuss within a team -> Present at least 2 possible solutions to the client.

You don’t want to come to the client and stress them out that extra time. They have their own problems related to the business, so there is absolutely no reason to bother them with issues that you haven’t investigated by yourselves yet. It might stress them out and put anxiety not only on you as a PM, but to the whole team, partners, etc.

In the end, they are spending their money to us, in order to get rid of the headache of their problems (in this case — mobile app).

It might be adding additional resources, removing part of the scope, making a workaround, changing the behavior of the app, it can be anything, that can help you close this gap.

You indicate a problem to the client- after you have invested some time in it and got a solution/proposal.

A client should ALWAYS make the final decision, or propose some other way to solve the problem, but they should know that we are professionals and already have a plan on how to solve it.

4.2. Iterations, iterations, iterations…

• Sprint planning — it’s one of the most important “rituals” of the Agile. You should never skip the sprint planning, always to the estimation of tickets and make sure that you and developers / QA understand what can be done.
• Estimation — The good part is — with our current workflow you can’t skip the estimation. The importance of this field is essential as it helps you to plan workload to team members, budgeting and project completion.

Backlog must be reducing with each sprint, not increasing, or you are doing something wrong. (fixed scope projects)

• Burndown charts — it’s a metric on your team progression. Should be checked regularly, to track on how much of the backlog is burned and how much of the velocity your team had, so you can plan upcoming sprints accordingly.
• Team retrospective — the most important part of the sprint. Where you discuss what was done, what you did successfully, what not so good and what you can improve. Each iteration your team should be better than a week/bi-week before.

4.3. Backlog grooming

• Backlog grooming — preparation of tasks, in a way, that YOU understand it. You should use the old good CET (component, epic, task) system to split tasks logically. Based on that you have to write a user story to each task and approximate “To Do” as you understand it.
• Sprint grooming includes working with client priorities and setting the sprint goals from the business perspective. (Example — the client wants to have a learning module to be first on a staging server so they can finalize the requirements by that module to third-party supplier, etc.)

4.4. Sprint planning:

• Backlog & sprint planning — by doing the sprint planning with a team of technical people, you should explain every task in details, that is unclear to the (from the clients business perspective) and they, based on information gathered from you, should make correct “To Do” description, for the whole team to work with.
• It’s common that you will have duplicates and unnecessary items in your backlog, work evolves with each week and requirements change that’s okay. However, THERE SHOULD BE ONLY TICKETS THAT DEVELOPERS UNDERSTAND HOW TO COMPLETE in the sprint. If it’s not clear how to complete one or another task — it never goes to sprint until it’s clear.

4.5. Demo with the client:

• It’s one of the most important meetings from the clients perspective — they see the result and progress of the app each week/bi-week and based on that can correct the team / PM work by setting the priorities.
• By the demo we mean — Showing the real app (better on a real device using a third party service), or sharing the screen on an emulator for the job that was done just by this sprint. Don’t need to show all the functionality each week. Just the difference.
• By the end of a demo (usually, the demo is a part of sprint ending), you should note the next goals for upcoming sprint (module or functionality, that you would face on), for the client to be informed.

P.S.

I know it’s been a lot of reading and huge THANK YOU for making it till the end. I would love to hear your feedback on how do things differently, what you can add and what else to cover in upcoming articles.

Receive a new Mobile development related stories first. — Hit that follow button

Twitter: @ ChiliLabs

www.chililabs.io