How to suck at managing software projects
Project management is not an exact science, let alone of software projects. In software engineering, there is some uncertainty in methodologies, estimates, representations, among others.
Unlike in other engineering domains, it is easy to fail in software, as there are no general recipes of how to do things well. A person itself can be complex; a group of people can be much more.
Managers and developers need to realize what fails when projects skid in time and costs. It is important they “take two steps back” to understand the patterns emerged over time. There are many techniques that can be used for this purpose (e.g.: 5 whys , analysis of failure cases) but here, I’ll try to summarize what I have observed being done wrong throughout my career.
Inadequate management models
One of the major flaws I identify are inadequate and outdated management models; many managers think they are running a factory or an assembly line, when, the reality is that software development is not a mechanical process and involves creativity and inspiration.
A programmer is not a robot; the programming process involves iterations, optimizations and collaboration. You can even recognize similarities with art as:
- it involves inspiration;
- has a personal touch;
- there isn’t a recipe to program well.
Therefore, the ideal algorithm/program is the culmination of something; it’s not an automatable or repeatable task.
As with artists or designers, putting pressure on developers to work faster and longer hours only brings short-term results. In the medium/long run, the product quality is compromised and the motivation of programmers affected (both are very hard to recover). The manager who doesn’t realize this might be in the wrong business.
Another common problem is the inflexibility. There are managers who believe that management models used successfully in some projects may be applied indefinitely and indiscriminately to others. Even Scrum, a trendy agile methodology, is not the solution for everything (e.g. consider XP or Kanban). On the other hand, some managers like to enforce the use of tools that are often inappropriate or unnecessary; it’s better if the team gets to decide what brings more value to the project (hence, to the company).
The incorrect use of methodologies can have a big impact and dramatically change the course of the project. For example, most managers completely devalue widely known techniques such as task analysis, paper prototyping, pair programming and even the value of iterative development. It’s well known that a few hours of analysis can spare a lot of hours of programming.
Lack of transparency
Managers should communicate with the team, informing about the business, objectives, context, next steps, road-maps, partners, etc. Little or nothing must be hidden from the team. Only in the possession of the project metadata, developers can give their best. Everyone should be allowed to give their best. For example, if a programmer knows that some feature will evolve later, he can prepare the code for that.
Fully analyzing a problem and then giving it the team to implement it, just shows lack of confidence in their skills. No one likes being a simple performer with no say in the matter or impeded to question things. Most programmers like to make use of their critical thinking. The causes behind a request feed the developer motivation to implement it.
Separating the requirement analysis from developers harms their motivation and hence the project. Analysis and implementation should go hand in hand.
The bottom line is that everyone is fighting for the same goal: the success of the project and the company, so all should share the same information. It is indeed very bad to ward off developers from the business, customer and especially users.
Imposition of technologies
One of the most serious points in project management is when someone imposes the use of certain technologies. Whether the manager has used and liked it, the CTO read it in a blog, a developer has a whim, or because a friend told him; those are not motives. Even worse is when this is done before the requirement analysis.
The technologies must emanate from the needs and should be decided by the team, i.e., they must be a consequence of a necessity rather than the opposite. Imposing can only result in team demotivation. Even if the technology makes perfect sense, it is necessary to “win people” through logic and reasoning. Programmers like that.
Wrong team scaling
Another serious problem that often occurs at the end of the projects is when, in desperation, managers (who barely know the team) begin to add elements, convinced that this will accelerate the completion of the project. The classic story that illustrates this situation is that 9 women can’t give birth in one month…
The ramp-up of a new element requires extra time of the existing team, delaying the process as a whole. Additionally, that period imposes a low relative productivity. Hence, adding programmers can be counter-productive.
Therefore, the growth of a team must be gradual and sustainable. New elements should be added previously and properly guided, but this requires a good ability to forecast needs, which in turn requires knowledge of the team capabilities.
Another problem is when managers find it fun to spread a project through multiple sites around the world, believing that this will speed up the process or “create quantum synergies”. In fact, dealing with many timezones can only make things harder. It is difficult to work this way, unless we are talking about the maintenance phase with well separated components and well-defined borders.
I have always advocated a more informal management model, in which the boss is a leader and not a classic “dictator”. A leader does not give orders; a leader controls the direction and speed of the “boat” and avoids obstacles. The boss, or rather, the leader, can emerge naturally, when possible. Ideally, the leader should be part of the team (perhaps getting ‘hands on’ from time to time or with reduced allocation). This has beneficial effects such as:
- Creates a more cohesive team spirit by sharing the problems and successes;
- Allows knowing, in real time, the current state of the project;
- Imbues autonomy and decision-making power within the team;
- Permits learning more about the team members (e.g. their problems).
More important than mastering MS Project is to empathize with people, being sensitive to their potential, concerns and aspirations.
It’s true that project management is a discipline itself, applicable to any domain. However, I’m skeptical when it comes to “generic managers” with no training/experience in software. Can they can take this type of project to success?
Any programmer gets annoyed and discouraged with unfounded high-level estimates like “that takes five minutes”, “it’s just connecting the dots” or “that only takes 5–10 lines of code”, showing total ignorance of technology and disrespecting the team and their work. The most annoying thing, are managers who think software are just pieces of Lego that you can move around and smoothly connect and disconnect (still, you should aspire separation of concerns).
Managers who only speak in general terms, buzzwords to impress and mumbo jumbo are alien to the team quotidian. A manager must know the team and only being near can be protective and supportive. Managers and leaders in isolated offices belong to the past.
In summary, what not to do:
- Manage software like an assembly line and treating the team like machines (in fact, they are creative people like designers);
- Hide important details, creating a gap between the team and the management and business;
- Force the use of methodologies, techniques or technologies;
- Blindly add new elements in the illusion that this speeds up the execution of the project.