Common practices that complicate software projects
Unfortunately, it is still quite common for software projects to run into some of these problems.
Steep hierarchies
People generally have a hard time dealing with and communicating uncertainty. Along steep hierarchies, critical information is often simplified or even gets lost. The problem is amplified by budget fights where certain risks are purposely hidden to get funding. Maintaining realistic expectations along the hierarchy is difficult, time-consuming and ultimately often fails. This often leads to a multitude of problems. From being demanded unrealistic commitments to playing blame games: in the end, people start playing it safe. Less time is being spent on productive work, and learnings are ignored.
Takeaways for the management
- Hand over more responsibility to the team that is doing the work
- Cut out middle managers that don't add value to the project.
Takeaways for the team
- Have a direct channel to everyone along the hierarchy
- Be transparent about the uncertainties and risks
Fixed budget and scope
Particularly non-technical people often don't understand the nature of software projects and how software is usually written. They tend to apply the same methodologies that work in other areas of the business to software projects as well. Unaware of the complexities and uncertainties they often demand security and predictability in the form of estimates and commitments. This leads to mainly two problems: A waste of resources to make an inherently complex and unpredictable process look linear and predictable and too little flexibility and budget to adjust for learnings made on the way.
Takeaways for management
- Reaching product-market fit, becoming familiar with new technologies, or becoming a well-functioning team are complex and rather unpredictable processes. Try to facilitate those processes rather than demanding estimates and commitments.
- Pursue big enough business objectives so it does not matter if the project ends up taking slightly longer or costing slightly more.
- Leave the team enough flexibility to solve these issues and adjust to new insights
Takeaways for the team
- Educate your management about the complexities and [challenges of software projects](/blog/how-software-is-actually-written). Often they just don't know.
- Be transparent about the risks.
A big release instead of increments
Oftentimes business people think they know exactly what customers want. Yet billions of dollars are spent on features that are never really used. Having the humbleness to admit we don't know and instead rather organize the project in a way to enable learnings and adjustments as new insights come along can both increase the value as well as save costs.
Takeaways for management
- Release early, collect feedback and adjust
- The biggest value driver for software projects is almost always [risk reduction](/blog/risk-reduction-is-the-driver-of-value-generation). Measure progress by risk-reduction rather than %complete.
Takeaways for the team
- Educate your management on the risks you see and propose risk reduction as the progress metric
Dependencies between teams (internal and external)
Management is sometimes tempted to outsource or centralize certain activities to save costs or in the hope of increased efficiency. However, dependencies — particularly in complex systems — are extremely difficult to manage. Many of these "cost savings" instead create communication and coordination overhead and discourages cross-functional activities altogether. It is, however, exactly these cross-functional collaborations that are needed for innovation.
Takeaways for management
- avoid centralizing business units without considering the resulting coordination costs
- organize your company into self-sufficient teams that have all competencies that they need within the team
Takeaways for the team
- ask for dedicated people in the team if the team lacks certain skills