6 Common Project Management Mistakes Software Development Teams Make
Starting with a new development project and want to know the most common mistakes that development teams make? Read this article to know about the 6 most common development project mistakes and how to avoid them.
Project management is always challenging. The challenges multiply as you increase the size, scope or complexity of the project. And every software development project is complex simply due to the nature of IT. A lack of understanding of this complexity by clients and bosses alike and the shifting environment creates problems and leads to many mistakes by project leaders. Here are six common project management mistakes software development teams make.Mistakes in Time Estimation
A common area where people make mistakes is estimating how long something will take. Developers may estimate how long something takes and multiply the time by two or three to give themselves padding. Managers may double it. Real problems come in when someone gives an honest time estimate in an area where we commonly lie, and then management cuts it in half assuming the person inflated the value.
Another mistake is "the pregnant woman" mistake. "The pregnant woman" fallacy is that you could shorten a nine-month pregnancy by finding nine women willing to be pregnant for a month. This fallacy comes up in scheduling quite frequently. Someone wants something sooner than the planned delivery date. It doesn't matter if you find more people to help – you can't speed up the process.
Throwing more people at a problem doesn't mean it will be solved sooner. In fact, by adding more people, you could slow the process down. Your expert takes time away from work to bring others up to speed or outright train them. In all honesty, no one can really hit the ground running. Or adding more people adds friction to the team, interfering in what was smooth progress towards the goal. Demanding more overtime out of overworked people could hurt quality or cause some to quit.
One solution to this is having work breakdown structures based on real-world data. What tasks need to be done? How long does a particular task normally take? In what order do they have to be done? Based on the work breakdown, you can create a realistic schedule everyone knows cannot be changed much.
In this work breakdown structure case study by Kanbanize, it was shown that productivity could be increased by using a computerized Kanban system with digital Kanban cards. People can see tasks that need to be done and pick up tasks as they are available. No one can start something before precursors are completed, and everyone knows the status of the project. A clear benefit of implementing Kanban in software development projects is that the method can be applied to any process. You don't have to reorganize your department, change the tools you're using or alter how people actually do their jobs. Just implement the project board with Kanban cards.Using the Wrong Metrics
There is an old saying that you cannot manage what you cannot measure. The problem for many software projects is using the wrong metrics. If you're collecting metrics that are not useful, you're wasting time and effort.
Sometimes people track metrics that don't matter much relative to others. One example is bug tickets as a measure of software quality. Managers can easily track the number of tickets and their decline. However, this doesn't provide much value, since tickets may be due to user error instead of reflecting actual bugs. Looking at ticket resolution rates is another poor proxy for customer service. The number of tickets closed per day or week doesn't reflect customer service, since someone measured by the closure rate might close tickets for things that aren't actually fixed. Or they may record multiple tickets for little issues simply to make their metric.
A better metric is the ratio of true bug tickets to the number of software changes and features deployed. Then you don't gauge the performance of your software developers on the failure of managers to train end users how to use the new features.
Another mistake regarding metrics is how someone determines code quality. A lot of developers pay attention to code cleanliness, but they don't understand how to determine whether a program is good enough – especially from the end user's point of view. Tracking the number of bugs and bug fixes in code isn't necessarily a measure of quality, either.
There are ways to determine whether or not the software code is actually good. How easy is it to write tests and test it? Is the code easy to scale vertically? How hard is it to change the name of a variable or method? How are the rules formulated? A large number of exemptions you have written in the code can be a warning sign. How many methods you'd have to redefine if you need to change something is another indicator the code isn't as well structured as it could be.Planning Too Far Out
Too many project managers assume they know what a software developer will be working on months from now. The longer the time frame, the more likely it is that timelines and priorities will change. You can make projections when you have a detailed work breakdown structure that factors in all tasks over several months. If you don't have that data-driven schedule, it is sheer conjecture. If you lack a detailed timeline that truly accounts for everything from testing to documentation, you'll probably fail to meet a deadline because you failed to account for tasks.Poor Communications
If you don't keep everyone in the loop on project status and task assignments, your project will suffer. As communication falters, trust weakens. So, too, may productivity. When business managers feel like they're being kept in the dark, they tend to over-compensate by micromanaging people. Or they try to force things to happen the way they feel it should be done because they don't know what is being done.
You can mitigate this by letting managers know what is happening on a regular basis and informing them when milestones are reached. Don't neglect reporting changes to the project status, as well.Disconnected Business Priorities
You only have so much money, time and talent. If you invest time and effort into the wrong thing, you've wasted it. Unfortunately, disconnected business priorities and a failure to work together to determine what is the highest priority can lead to mistakes or outright failure.
A common problem is giving priority to something that one department considers essential when no one else in the company agrees. Pouring resources into a project that doesn't generate revenue instead of upgrades that improve the company's business line is always a mistake, but this periodically happens because a single loud voice advocated for it. In other cases, software development leads don't prioritize something because they don't recognize its value to the company.Short-Term fixes versus Long-Term solutions
You should always prioritize long-term solutions over short-term fixes. Short-term fixes may be implemented faster, but they add complexity and increase the odds of failures down the line. Focus on long-term solutions that won't require another quick fix after the next browser or operating system update. Long-term solutions will be those that can exist for years without changes and smoothly connect with other applications and systems.
Assume that there is no such thing as temporary code. When writing or reviewing code, consider that it may stay there forever. Once you do that, investing more effort into creating a cleaner, permanent solution is recognized as the right choice.
Some of the most common software development mistakes plague all projects. Other mistakes are unique to software development, but they can be avoided if you know what to do instead.
