What Stormotion's Project Management Flow Looks Like

Published: November 8, 2022

15 min read

To successfully deliver external and internal projects, development companies and teams surely need some sort of structure during the whole workflow. For this matter, they implement various Project Management concepts into regulating the development flow.

We decided that it’ll be quite useful to share how Stormotion approaches Project Management. So, if you’d like to learn more about our approach and find PM insights from an experienced development company — welcome!

Project Management dashboard

In this article, we’re going talk about our PM stages (image by Conceptzilla)

Generally, our approach is based on PMBoK (Project Management Body of Knowledge) guidelines. We won’t talk about it in detail since it’s not essential to understand our approach — we’ll describe every step of our teams’ Project Management in detail.

As a development company, agility is something we need 99,9% of the time. For this purpose, we implement Agile Manifesto (a set of values for Agile Software Development) and Agile Triangle concepts into our workflow. The Agile Triangle takes value, quality, and constraints from a Classic Triangle (which are scope, cost, and schedule) as the main aspects that regulate PM flow.

Additionally, our team provides consulting services. Meaning that we help out Partners with Product Ownership (maximizing product value by defining activities that can help them achieve the desired outcome). Such activities can include:

  • building product vision;
  • defining, evaluating, prioritizing, and scheduling scope;.
  • preparing roadmaps and reasonable version limitations.

Without further ado, let’s take a look at how we help our Partners generate product value at each development step and how we deliver high-quality solutions no matter what! 🚀

Even though there’s a general pattern, each and every step might differ from project to project.

# 1: Project Initiation & Planning

To begin with: we are an outsourcing company so, for the most part, the projects are initiated by the clients. Nevertheless, our team has quite a few things to complete during the initiation stage:

  • Defining key values and goals of the customer for the project. By the end of the initiation stage, it should be done in a written form so that the team can use it as a reference. Make sure to double-check them with the client.
  • Determining success factors for ourselves so that we know what the criteria are for making sure the project development goes successfully.
  • Trying to predict all possible questions to reduce the number of uncertainties.
  • Documenting all the client requirements and expectations.

There are also several essential questions to cover before stepping into the planning stage. It includes whether the client is scope-driven, deadline-driven, or budget-driven, what their plans for future project development are, and some project-specific details like the regulations they need to comply with.

It's just a small part of possible questions because every project is unique and requires an individual approach but that already allows us to prepare a first rough estimate of the possible development costs.

Initiation & planning stages

The 2 first stages are initiation & planning (image by Viacheslav Ksendziuk)

After that’s done, the planning stage begins. We normally start off with the discovery stage which includes processes like risk assessment, defining the tech stack for the project, building wireframes, and approving them with the customer.

Another important thing to do is to prioritize the requirements to make sure that we know where to start — our general practice is starting with what’s the most important (core features) or the least certain features (high-risk areas). Handling “problematic areas” as soon as possible is a great way of providing customers with a more reasonable development time & cost estimation.

In case the client is deadline-driven, we additionally think about what features are possible to deliver in the desired terms and then build a development roadmap (level of readiness of the project by each set deadline).

For that matter, we surely need to assess the available team capacity and define team composition — how many developers are available, what other team members are needed (QA, Tech Lead, etc.), and so on. After that, we can provide the client with a significantly more precise development cost estimate.

Once we agree on each and every step of the development with the client, we set up internal and external communication channels, define our Quality Assurance methods, and have a final planning meeting with a Tech Lead, Project Manager, and QA. We wrap up the stage with a kick-off meeting with developers where we assign tasks and share the plan.

# 2: Project Executing

We base our approach on Agile Project Management methodologies like the Scrum framework when stepping into the development stage. This framework implies dividing the development process into various events. For us, the best structure is the one that includes such elements as a sprint, sprint planning, daily meetings, demo, and retrospective.

We’ll now talk about each event of the development stage. If you want to better understand Scrum and learn more about the terminologies to be on the same page with the development team, take a look at this great explanatory video:

Event

Description

1: Sprint

Sprint is the main event in Scrum. Long story short, it’s a time span (2-4 weeks, usually 2 weeks for us) where we complete pre-defined activities and tasks.

2: Sprint Planning

We plan the sprint on the first Monday of it. What we do is define the scope of work for the next 2 weeks, update the roadmap, distribute the tasks between developers, set deadlines for submitting code freeze (the moment where changing the code becomes more complex because of its level of completion), and talk about what Quality Assurance activities would be applied.

The main outcomes for sprint planning are a structured schedule, updated capacity expectations (there might be changes due to vacations or sick leaves), a clear understanding of the value that this sprint is supposed to bring to users, and approvement of the sprint structure with other Stakeholders.

3: Daily Meetings

During the daily meetings, we answer 3 questions: what each team member did yesterday, what they are doing today, and what problems they have. Such meetings shouldn’t last more than 20 minutes and be superficial, without going into details.

The goals are to get updates on the development process, synchronize the team, and do local troubleshooting. Of course, it’s essential to keep the client updated because the last thing we want to have with clients is misunderstanding and false expectations.

4: Demo

Demo takes place on the last Friday of the sprint. This is where we demonstrate the product we’ve built so far to the client and get feedback on new features. We always make sure to double-check everything before showing it to the client.

In case the customer wants additional changes, we discuss the influence on the budget, generally, adjust the product according to the feedback, and always get written approval of the changes.

5: Retrospective

It’s the last event of Scrum where each team member gets to talk about positive and negative experiences of the sprint.

What we expect to get is a list of things to improve in the next sprint.

Tips & Tricks from Our Project Manager

Apart from the general structure that we follow, we have some special methods that we apply to improve the quality of the Project Management flow.

Firstly, one of the main concepts that we apply is Continous Delivery (CD). In Project Management, the CD is a way of building the end products and achieving tasks in short cycles. It allows us to shorten the feedback cycle and increase the product quality.

Another important thing we pay attention to is WIP (Work in Progress or Work in Process) limits. It’s basically the maximum amount of work that can be done within various workflows. It’s essential to be realistic regarding the number of tasks that can be done simultaneously.

Additionally, we make sure that the gained value during the development is never lost. For this matter, we implement Knowledge Management methods to structurally store and document the information we collect during each sprint. This way, we can always get back to it and reuse it when needed.

Project executing stage

Project executing stage (image by Ali Husni)

Last but not least, these are several general Project Management rules and convictions that we follow:

  • Systematizing and automating processes is one of the key factors to higher efficiency.
  • Keep trying to reduce the level of uncertainty.
  • Always make sure to keep values defined during the initiation and planning stage in mind rather than simply perform the tasks.
  • Improve the self-organization skills of the team.
  • Maintain constant communication with customers.
  • Work transparently and systematically.
  • Don’t postpone issues that need to be solved to reduce the done drift — a pretty common problem in PM when extra tasks that we didn’t identify at the beginning are being added to the task or when there are change requests.
  • Be proactive.

# 3: Project Controlling

From the perspective of project management, project controlling (monitoring) is a regular comparison of planned and actual states and values of the project.

Our controlling flow includes 4 pillars of success: time control, task control, capacity control, and quality control. Let’s take a closer look at each one of them.

Time Control ⏳

When working with the development team, time control = budget control. Each customer has certain budget limitations and expectations, which is why a good time management system and regular reporting on time consumption are of high importance.

Clockify time control tool

Time control is an essential part of budget planning (shots from Clockify)

We have 2 types of time management:

  • Report on hours spent during the last sprint. Customers get it after each sprint.
  • Report on total hours spent on specific tasks from backlog.

We generate the first one by tracking working hours using Clockify or Active Collab. Apart from hours spent, the report also includes the sprint time and user stories. User stories are conditional statements of what a user might want/need to do in an app. For example, “As a first-time user, I want to sign up using Facebook”. It explains the needed features — in this case, it would be implementing the Facebook Login feature using Meta for Developers tools.

If you’d like to dig into the user stories topic, feel free to follow the link to our article where we cover all the detail in this regard:

Read also:

Project Discovery: What is it and Why Do You Need it?

To generate the second report, we need the first one because it works as a foundation for it. Its main purpose is to compare the total hours spent on each user story and compare them with the maximum estimates.

If we come close to exceeding the set budget, we immediately let the customer know to get approval to work further. If we don’t get it, we look for alternatives that satisfy both parties.

Task Control 📅

As the name says, this is the process where we keep track of all the tasks that we have to work on during each sprint. For task management, we use the Kanban board.

Task control software

Task control allows us to keep up with the development deadlines (image by Patryk Ilnicki)

There are several statuses that a task can have:

Status

Description

To do

The feature appears as a user story. We then make an estimation of the development cost and get approval from the customer. Last but not least, we make the task a part of a certain sprint and then assign it to a developer.

In progress

The developer works on the feature.

In review

Developer finished the code and submits it for review to the Tech Lead.

Merged

Code of a feature is being integrated into the app (an already existing codebase).

Ready for Quality Assurance

Code is being deployed to run QA tests.

Completed

QA team verifies the feature and it means that it’s done.

We also follow the rule of not starting to work on a feature until it’s designed & approved. It helps us avoid expectations & vision mismatch.

Capacity Control 💻

To make sure that we’re up-to-date on our internal capacities, we use the TimeOff.Management System. This is where we request and approve vacation days, sick leaves, keep track of holidays, etc.

It allows the Project Manager to plan each sprint according to the availability of the employees. It’s important to set reasonable scopes of work and provide customers with realistic expectations regarding what we plan to accomplish.

Capacity control tool

Capacity control tools help us maintain reasonable team composition needed for the project throughout the whole development (image from NovaIT)

Something we prefer to do is to never expect full availability of the developer for each sprint. Normally, it would be 80 hours (40 hours/week with a 2-week-sprint) but we assume 64 hours per person.

This is our way of implementing risk management methods into our work — it’s always better to complete more in a sprint than to set unrealistic expectations. Plus, they allow us to take time management deviations into account.

Quality Control 📝

For quality control, we create a document that’s called Master Test Plan. Generally, this document is created when we start working on the project and defines quality control rules. Surely, we update and adjust it later on during the development to make sure that it’s consistent with new challenges and values.

The content of the Master Test Plan usually includes:

  • the expected quality of the product;
  • a set of quality test methods for each feature;
  • entry/exit conditions for Quality Assurance managers. For example, to enter the project, they need to have access to all test accounts and documentation. On the other hand, they can exit once they go through every quality checklist, verify necessary features and bugs, and no bugs have a severity level higher than minor.
  • quality assurance risks. For example, no capacity, no access to the required resources, not enough input from various stakeholders, etc.
Project Management tool that allows creating QA tasks

As for QA, it’s an essential part of delivering any feature (image by Happy Tri Milliarta)

The one responsible for building this document at Stormotion is QA Engineer. The actual content of the document significantly depends on the project features but there are still 2 general rules to follow.

  1. Each feature must be reviewed by the QA Engineer before we say that its development is completed.
  2. Each new version of the app must be approved by the Project Manager before we can present it to the customer.

Last but not least, we’d like to share some insight from our Project Manager. First of all, we make sure that we’re consistent with the plan and budget. Handling risks like impossible integrations or estimation exceedings.

It’s highly important to tell the client what to expect whenever there are updates. Plus, setting suitable KPIs for quality control is one of the most important aspects — you get what you measure.

# 4: Project Closing

When it comes to closing the project, we do all the processes that we already performed for other steps. Except for this time, it’s going to be more large-scale and include significantly more information. The process includes:

  • Final check-ups and making sure that all the features are delivered.
  • Final quality checks.
  • Getting final approval from the customer.
  • Final invoicing.
Project closing stage

During the project closing stage, final quality checks play a vital role (image by Keanu Gaurava)

Something that might sound funny but actually makes a lot of sense — we try not to release on Friday. The reason for that is that there will likely be a certain problem after the release that we couldn’t predict even after several QA stages.

In case the release takes place on Friday, we'd have to urgently gather the team on weekend to fix it, which surely generates a lot of stress and overhours for both parties. Such challenges can happen and it’s normal for software development, but we try to decrease the chances of the occurrence as much as possible.

How We Manage Time Zone Differences

In this section, we’d like to talk about how we handle time zone differences.

To be honest, it’s the least worrying issue that we have in our practice. Since the software development industry has been highly internationalized for years now, we are 100% used to working with people from other time zones that are drastically different from ours. For example, while being based in Eastern Europe, we delivered products to our customers from the US and Australia.

Time zone differences

Handling time zone differences isn’t difficult at all as long as both parties as willing to build a great solution (image by Thiago Sanchez)

What we do to handle time zone differences is pretty simple since it’s more about Time Management. Thus, the solution to the issue comes down to quite simple concepts:

  • Wake up earlier or go to bed later to attend a call.
  • Send out emails in advance.
  • Find concurrent business hours.
  • Allocate time for delayed communication.
  • Take all of it into account when establishing Project Management.

Our Expertise: Case Study

To show you our approach to challenges, we’d like to share one real-life example of a Project Management solution we’ve come up with to both satisfy the expectations of the customer and have realistic deadlines in terms of product delivery.

So, one of our clients wanted to deliver quite a big scope of features in an excessively short period of time, which is a normal thing to face when working in Software Development.

However, the main challenge was that we couldn’t increase the velocity of the development by adding more developers to the team — technical limitations simply wouldn’t allow it. In other words, we couldn’t assign more individual tasks to more developers because the development flow required that exact team composition.

A case study of Stormotion’s PM problem-solving example

We always try to find solutions that’ll allow delivering what the client wants while being consistent with technical limitations (image by Rayfan Tio Saputro)

Our team needed to deliver a workout app that pairs up with various exercise machines. After a thorough analysis of the scope of features that the client wanted, we found out that we can break one development flow into a few releases.

To be more specific, users could access statistics only after completing a full workout program (with a minimum duration of 8 weeks). We offered to postpone the implementation of the statistics tab, which includes multiple large-scale features, to the second release (8 weeks after the first one). Between releases, the tab itself would be covered with the “Coming soon” sign.

This way, the customer doesn’t lose any value since the statistics would be shown after completing the first program (which lasts 8 weeks) anyway. On the other hand, we would have enough time to deliver a high-quality product on time and within the deadlines that the customer wants.

Plus, the client can use the “Coming soon” sign as a marketing tool for warming up the users for the next release.

How to Help Your Tech Partners Deliver Projects?

A subsection we haven’t announced at the beginning of the section but still wanted to talk about — how you as a client can help us build your project faster without efficiency losses.

Project Management Software

In this section, we’re talking about how you can help your development partner delivery the product more efficiently (image by Ofspace LLC)

First of all, understanding the development team from the point of technical requirements is an extremely helpful thing that clients can do. Sometimes, it’s not possible to implement certain features before the app is prepared for it or before it’s actually needed.

For example, instead of implementing a certain feature that won’t be needed for the next few weeks, we can focus on making sure that the ones we release don’t generate more technical debt and don’t slow down the development. Not following this principle can result in false priorities and impact clients’ budget goals negatively.

To deepen the understanding of technical debt and what consequences it might have, you can take a quick look at our Technical Debt article:

Read also:

How to Deal With Technical Debt?

What also significantly helps is when clients cooperate on specifying the requirements as much as possible. We fully understand that it’s not always possible to distinctly express what exactly clients want to see in their apps. But what’s important is willing to finally reach a point where it’s crystal clear what the next steps are. And we as Tech Partners always make sure to provide sufficient support in that regard:

  • We ask the right questions.
  • We always provide feedback and explain important technical characteristics.
  • We stay agile and adjust the development plan on the go.

Such an approach can also help to reduce the number of changes that would have to be implemented during the process of delivery. It surely saves budget and reduces Time-to-Market.

Last but not least, feeling the involvement of the client is something that boosts the energy of team members. The fact that we deliver high-quality projects no matter what isn’t even a question, but still — it’s always good to know that the customer and we are on the same page and want to build a great solution together.

We ALWAYS look for solutions and alternatives. And rarely say no since we don’t believe in the “impossible” — it’s about finding ways of reaching the desired despite technical and timely limitations (as in the previous case study section). But compromise is still important.

💡 Takeaways

Generally speaking, when we build our Project Management Flow for a project, we focus on the 3 key success factors:

  • Proactive all-around communication. It’s essential to have efficient ways of communication to enable rapid feedback, updating on development status, etc.
  • Systematization of processes while still maintaining high-level agility. By doing this, we make sure that there’s little to zero unnecessary micromanagement and that the time we dedicate to the project is being spent as efficiently as possible.
  • In-house product ownership. We pay a lot of attention to what a client wants, what we can offer to reach those goals, and contribute to increasing product value.
Takeaways

Staying agile is the key of most modern PM flows (image by Dmitry Lauretsky)

Despite the diversity of Project Management methodologies and tools, custom adjusting PM to each new project is of high importance — use cases might have to common patterns but are still unique.

That’s why creating a set of Project Management methods that allows you to stay resilient to unstable external factors (changing development standards, new priorities of the project that clients find out about on the go, etc.) is also the key to delivering projects successfully.

If you’re looking for more details on how our project management flow is structured, welcome! 🚀

Contact us

Read also

How can we help you?

Our clients say

Stormotion client Pietro Saccomani, Founder from [object Object]

They make the whole business work for us, and their improvements are fundamental to our operations. They’re reliable, honest, and willing to try new things that will help us. We appreciate how flexible and easygoing they are.

Pietro Saccomani, Founder

MobiLoud