Table of Contents
As COVID-19 dominates our day-to-day life by making us change the way we live, work, entertain and even eat, it also requires us to change the way we manage software projects. Project management of remote teams during pandemic is the same as crisis management. Essentially you have to figure out how to keep the big project going without team members that get sick or were fired due to cut of costs, with the 30% budget decrease and with lower efficiency due to people working from homes. Below are a few remedies we applied to the complex big projects in our company, see if they can also be useful to you.
What project is considered to be big?
We consider a big project to be the one that involves at least one of the next items:
- Heavy loading on the software (whether it is a mobile application or WEB portal) in terms of users number and activity;
- Support of several platforms, e.g. iOS, Android, WEB;
- Need to be compliant with the special requirements: industry standards, legal compliance, etc.;
- Have complicated infrastructure;
- Industries with the changing conditions and regulations that require frequent changes to software.
The management of a big project is pretty challenging itself not to mention when you experience the lack of people, tech or financial resources for it.
Below we are giving the list of frequently experienced complications as well as remedies to apply in case you were hit by one of those during COVID-19 crisis:
Uncertain requirements
Uncertain requirements are usually the result of insufficient, outdated or non existent documentation. Due to this problem, teams have to do extra communication to find out if this is a bug or a feature, how it is supposed to work and if it even needs fixing.
This can become even worse for the softwares that have special requirements, standards to follow. The failure to meet them may result in penalties or even the shutdown of a software.
Moreover, as project scales, so does the uncertainty connected with how the project is supposed to work bringing the conflicts into logics that are fixed with hardcode, leading to another problem – Code Quality.
What do I do to have my big software documented?
If you were hit by this problem, do not start the documentation of the project from scratch and do not try to document everything at once. You will fail and will never get back to documenting it again being demotivated by the amount of work ahead of you.
Document what is necessary: The good approach here is to document only those things that come up from day-to-day activity. A manager and developer were discussing how the feature works? Document their decision into a separate article called with the name of the feature and add some search tags to it so that anyone can find it later.
Once you are caught up with day-to-day nuances of software features, start to document the next scope that the team will be working on and make sure the team works off your documentation. During this exercise you will find that you need to describe the related already developed functional pieces too, which would lead to gradual coverage of functionality with documentation.
Documentation is the collaborative responsibility: The team has to understand that they take part in writing and support of documentation too. Business Analytic, Tech Writer or Product Owner do not bare sole responsibility over documentation, even though a big part of it is on them. All team members have to contribute to keeping the documentation updated and full. E.g. If a tester determines the discrepancy between a coded feature and documentation, and based on communication defines that the result of this was a mutual agreement between a product owner and a developer, he/she can update the specification or leave a comment for the product owner to update it.
By having all team participate in documentation you will save the spendings on the time of tech writers, BAs and Product Owners on its maintenance.
[/fact]
Dynamic Changes into operational requirements
Since there are a lot of people working on the project, there are lots of stakeholders too. The processes, ways of communication and requirements themselves become a constantly changing environment that leads to misunderstandings. Trying to figure out how to solve the miscommunication can be time consuming and non productive.
How do I keep my team informed of the changing processes?
In order to help resolve this challenge, you have to remember the next rules:
Consult with the team before implementing the changes. We often forget: the team that does the development might already have the solution to most of the problems we are trying to resolve. And by consulting your team on one of the processes you can address the problem without even changing anything. Team will also be more inclined in accepting and adapting new processes in case the idea came from them or they were consulted with.
Use several channels of information. Due to high speed of work on hard projects sometimes we simply forget to read the news posted to us from different departments. This is not because people do not care, but rather due to the high workload. By using several channels of communication apart of regular corporate email, you will make sure the team does receive those regulations they now have to follow.
Collect feedback. First and obvious feedback you have to collect is the confirmation that a team received and understood the new operational procedures. However, make sure to also gather feedback on potential facilitation, optimization or cancellation of new process.
Unless this is a legal requirement, use fast communication means to inform your team. Create a separate corporate channel in the chat messenger, where you can send the updates and the team can comment on them by adding their reaction with a smiley or similar. This way you can save time on all emails sending and additional procedures of feedback collection.
[/fact]
Keeping project stable
Since the pace of big projects development is under harsh deadlines and within the cut timeframes, the code quality is usually the first to suffer. Wise and experienced teams already add the time for refactoring into their deliverables, however the newbies into big projects always postpone it to “when we do release 2 then we will do refactoring” only to find themselves in release 4 with more accumulated code problems.
Lack of automated testing is another problem that can lead to project instability. With every bug fix the code needs to be retested, even if this is a small bug. Teams that were lucky enough to get financing for the autotests that they run on each deploy are less touched by this problem, but smaller ones are doomed to manual testing.
And of course security is one of the foundations of having the project stable. Data security was one of the biggest news last year (before COVID-19 took over) for a reason. Losing data especially during the crisis can lead to shut down of the software. This is especially true for sensitive industries such as Medicine, Trading, Legal, Manufacturing, etc. Get our Web Development Security Checklist here.
How do I keep my web or mobile application stable?
In order to keep your software stable it is extremely important not to sacrifice the time for refactoring. In order to avoid its accumulation, track this number. Having the code legacy is ok, unless it goes over the critical margin. So define that margin for your project and if it is crossed, then put aside all new features and do the refactoring. This is the will decision rather than a strategy. However, this is good practice to always spend 1/4th of your sprint on code optimization and refactoring. You might think this is just a waste of time, but this makes fixing of bugs easier and quicker later.
Use end users of software as your testers. With all content and politics of your software you have to transmit the one and important message to your users: “Everybody has bugs. Even Facebook, even Apple,eEven SpaceX. And you are good not because you do not have bugs but because you fix them in time”. So if you offer a reward to your users such as a promo code, or maybe a special Thank You bange for each reported bug to your support team, you would get loyal customers and cost savings for testing.
[/fact]
Bureaucracy and long decision making process
Big project is similar to a big organization where you have to go through several Tech Leads to approve something, not to mention all those accountant and legal procedures that have to be met before you even contact someone. We all hate bureaucracy but the truth is sometimes, it is simply necessary to have the big project working and ensure its quality. However, there are also good news, we are in tech and tech can simply automate it.
How do I cut the bureaucracy in my project?
Solution is simple here: automate the process. We often invest into the commercial project because we have a clear vision of the profit we would get based on direct income but we forget about the profit we might receive based on cost saving that investment into the development of internal management tools can bring. Imagine, that one click on a button, would send out the chain of requests for approval from all authorised people with in time reminders and algorithms of execution depending on the presence or absence of such approvals. This would bring self managed system where your tech team is not slowed down by the decision making process.
You might outsource the automation of such processes to external teams, keeping your own free for commercial projects but at the same time getting quick solutions from others. During crises the outsourcing teams decrease their rates, so this might be a good time to invest.
[/fact]
Lack of people and roles
As you go with the development of a big project and as it grows you will always feel the lack of one more tester, one more developer, one more tech writer, etc. This is normal because as the project extends, more job needs to be done. You might remember those times when you were a sole project manager, business analytic and marketing manager at the same time, but now you need at least 3 separate people to do all that scope.
How do I compensate for the missing roles?
An easy answer is: you can’t. You can compensate around 10-20% of the works of each of the necessary roles by redistributions of the team. For example,
- You can have more heavy demo sessions where all team tests the solution to save on testing;
- You can have loyalty programs for end customers to test for you to compensate the lack of testing;
- You can involve all team members into documentation and architecture to compensate the lack of BA;
- You can give free memberships to beta testers to get the marketing info and compensate for the marketing researcher role, etc.
While some of the mentioned items are more effective than others, all of them are rather short-term solutions and in a few weeks you’ll face the same problem, where now you absolutely need a new expert and quickly. But what you CAN do is facilitate the process of new people integration. It is extremely important to have the infrastructure and organizational processes to be built around fast and efficient integration. When a new expert joins the team, the system needs to be self explanatory to the newbie by guiding him/her through each stage without spending time with a mentor.
Self-management can be a BIG save of money for you. You can embrasse the self-management practices in the company by keeping people as independent as possible, asking them to take responsibilities they were not taking before. It is a risk that they will do something wrong, but at least you will not be micromanaging and will be saving time of Project Managers. Scrum methodology would be a good assistant here.
[/fact]
Conclusions
The list above is not exhaustive but rather includes only a small portion of challenges a big project brings. They are quite obvious and straightforward but still most teams struggle with them and are always lacking the time to resolve those. Crisis is a killer for some businesses but is also a driver for others. If you have the processes set up properly on your software project it will be more prepared not only for the crisis but also for a big success.
