Software Project Management 101
The statistics presented in the graph above are based on a survey of 5500 project management professionals. The survey was conducted as part of a report made by PMI. To understand the graph, let’s look at the topmost line which reflects the number of software projects between 2011 to 2018 that meet the project's original goals. In 2018, 70% of the projects succeeded to meet the business intent. Or from a different perspective, in 2018, around 30% of projects ended and didn’t provide a solution to the business needs. A huge percentage in my opinion. We can further see that more than 40% didn’t complete in the original budget and more than 45% didn’t complete on time. In this article, I give a few insights that I collected over time that will help you avoid falling into these statistics.
Develop Something Relevant
One of the biggest wastes of resources in software development is developing products, features, or software infrastructure that nobody needs. Ask any programmer how many times they work on something that nobody used and you will be amazed. We develop things that no one needs very often. Some of it is due to an objective uncertainty of product development, but a big portion of this waste can be avoided.
Listen To Your Potential Client
Make sure you know who will use what you are going to work on before you start the actual programming. It doesn’t matter if it’s a client outside the company or someone within your company, you should make sure that they are going to use the product once you finished working on it. Here are a few questions to help you do that:
- How are they currently solving the problem? If they already have a different solution to the problem you are trying to solve then they will most likely not need your assistance.
- When will they start using this solution and how often? If they are not eager to start using the product then you should suspect that they might not really want it.
- How many urgent or important issues are they dealing with apart from the current issue at hand? If they have a lot more urgent or important issues then they will most likely not use your product when the time comes.
The questions mentioned above, focus on the potential client's needs instead of the solution you are offering. Try to listen to what they have to say. Don't try to convince them that the problem you are trying to solve is important or that your solution is great. Check out the lean startup or the mom’s test for a much deeper understanding of this topic.
Communicate
Developing relevant software is all about communication. Communication between the team to clients, between the company’s management to the product management, and between the programmers to the product manager. Behind each feature, there is a programer that codes it. Usually, this programmer doesn’t communicate with the feature’s client regularly. To make sure that he or she doesn't work on something that no one needs, we need to constantly communicate with them and let them know what is the most relevant thing they should do. The following are some practical suggestions to implement:
- Schedule periodic events to synchronize between the different roles of the organization. I think that 2 weekly meetings of half an hour with the developers will work for most cases.
- Build a workflow where a task is not considered done until the project/product manager approves it.
- Don’t let programmers be the final call on what to develop next. Programers are busy solving technical challenges. Hence, they don’t have a lot of time to understand what are the most needed features.
- A good project/product manager should take part in the management program. They should be able to open it and understand what are the upcoming tasks. In my opinion, not having a project manager that constantly looks on the team tasks is a great recipe to develop something that no one needs.
Complete Development On Time
Software development inherently has a lot of uncertainty. It is hard to estimate how much time a task will take, what tasks we don’t know about, and how future findings will change the requirements. Yet, we don’t build our product in a void, which means we have to give time estimations to our management or to our clients. How can we improve our time estimations? We need to put more time into it, but not too much time. We need to find cheap mechanisms that will allow us to better predict how much time our development will take.
Be Realistic
When asked to give time estimation, programmers often give overly optimistic estimations. Here are a few reasons why:
- Wanting to look good — Saying a task will take a long time in front of other teammates or in front of the managers can be perceived as weakness or inability to deliver.
- Programers are under pressure to give an unrealistic estimation. The managers often don’t believe them. When programmers say that something will take a significant amount of time they know what they are talking about. Don’t push them to say unrealistic estimations because this is what you want to hear.
- We are not always at our best. When programmers try to estimate the time a task will take they usually think of times where they were at there best performance.
- Take into consideration leave days, vacation days, training, and sick days, etc. Programmers won't do it for you so help them to think of those factors.
Except for the obvious solutions of considering all of the above, I want to give a rule of thumb. Multiply the time estimation by a constant number. The number changes between people but I would say to add at least 50% to the time estimation. If you don’t trust me, ask programmers in your surroundings what should be the magic number and you will be surprised by the answers.
Meet The Required Quality
Low-quality software is expensive. It creates endless problems, from system downtime, unworking features to a bad reputation, and much more. Creating high-quality software is challenging. It requires a lot of knowledge, time, and budget which is often limited. Sometimes it is fine to sacrifice our product quality to save time or money but we need to be very cautious about it.
The Filter Method
The filter method is a name I use for a basic concept — Our workflow should contain stages to improve our software quality. Each one of the stages is like a filter that prevents low-quality software from moving to the next stages of our workflow. There are many mechanisms that we can use as a “filter”, here are some:
- Code Review — Letting different people in the team review the same code.
- Define tests — Whether automatic or manual, we should test our code before releasing it to clients.
- Penetrebility test — Defining the test we make to be sure that our project meets the security standards.
- Gradual releasing — First release the product inhouse, then to beta testers and only then to the clients.
The list I gave above is partial, but the idea is clear. We should define what our quality standards are and how we are going to meet them. Once we put our strategy on paper, then it is much easier to make sure it happens.
Find Problems Early
Another important concept is that you should catch your defects as soon as possible. Whether it be design problems or bugs, you want to become aware of it as soon as possible. The chart below, which was created by IBM System Sciences Institute, demonstrates this nicely:
According to their research, solving problems after releasing the product costs 100 times more! The message is loud and clear. Your quality strategy should focus on the early stages of the development process when it is cheap and easy to fix them.
Wrapping up
I discussed three of the main pillars of software project management — developing something relevant, doing it on time, and with high-quality. Each one of them is a whole world and I covered just a fraction of them. Yet, implementing even one of the principles I went over will improve your chances to have a successful software project. It takes time and effort to apply them, but it will be totally worth it.
