# 1: Project Initiation & Planning
# 2: Project Executing
# 3: Project Controlling
# 4: Project Closing
How We Manage Time Zone Differences
Our Expertise: Case Study
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!
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:
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! 🚀
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:
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.
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.
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:
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.
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.
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.
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 (image by Ali Husni)
Last but not least, these are several general Project Management rules and convictions that we follow:
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.
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.
Time control is an essential part of budget planning (shots from Clockify)
We have 2 types of time management:
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:
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.
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 allows us to keep up with the development deadlines (image by Patryk Ilnicki)
There are several statuses that a task can have:
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.
The developer works on the feature.
Developer finished the code and submits it for review to the Tech Lead.
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.
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.
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 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.
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:
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.
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.
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:
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.
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.
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:
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.
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.
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.
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:
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:
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.
Generally speaking, when we build our Project Management Flow for a project, we focus on the 3 key success factors:
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.
Was it helpful?
How We Handle Quality Assurance (QA) in Stormotion
How to Make an EV Charging Station App
How Much Does It Cost to Develop IoT Software?
Our clients say
They were a delight to work with. And they delivered the product we wanted. Stormotion fostered an enjoyable work atmosphere and focused on delivering a bug-free solution.
David Lesser, CEO