Most software projects fail for one of two reasons: Either because complexity grows and becomes overwhelming. Or because the product works but is not used by the target group.
For both risks to mitigate, project managers need to do one thing: Say “No” often enough. Kindly. But firmly. No matter whether they build with no-code, low-code, or full-code.
Now saying “No” is not the same thing as ignoring feature requests. On the contrary: Project Managers must encourage stakeholders and potential users to bring in their needs and ideas. Their engagement and creativity is essential for the success of any software project. Good priorisation includes a careful examination of these ideas, driven by the desire to deeply understand the underlying problem and the resulting benefits.
But is it the wrong perspective to see priorisation as a decision on what will be built. This is the easy part. Much harder is deciding what will not be built. Carefully considering a feature, and then deciding not to build it is the true achievement! This is what takes weight off development teams, relaxes budgets, speeds up timelines, and reduces maintenance effort long-term. And the harder the decision feels, the more we are in love with the feature we decline, the more helpful our decision is.
By the way, the cost-benefit calculation when deciding on a new feature is not only based on the present state. Each new feature also increases the product’s complexity, and while it may add some value today, this may backfire later. Thus, saying “No” also reduces the risk of suffering from excess complexity in the future.
Additionally, declining requests helps to keep iterations small and to test the product earlier. This way, we can test the product with users before we invest too much. We avoid large software projects that do not meet a demand, and are able to improve the product and change course more frequently.
Now saying “No” comes with a drawback. While it is the true achievement of project management, it often does not feel like it. Saying “No” can lead to conflicts, and gets harder the higher the position of a person supporting a request is. Still, I am surprised how well stakeholders often perceive a “No” to their request. Not always, but more often than you would think. My perception is that also stakeholders can value the clear direction and focus that comes with a “No”. At least when project managers explain the context, make clear the “No” may be temporary, and stay firm but humble in doing so.
What does this mean for NodeMasters?
One thing we are aware of at NodeMasters: For external agencies which manage projects and implement software for clients, the incentive to just say “Yes” is even higher than for internal project managers. After all, suggesting a “No” not only disappoints some stakeholders – it also shrinks the revenue of the project on our end.
To counter this, at NodeMasters we have made the clear decision to always act with an in-house project manager mindset. If project budgets remain unused, no one will be criticised internally. If a budget target is missed, we question ourselves. We are convinced that delivering good software projects is the best way to maintain a healthy client relationship. And this in turn is the way we want to expand our business long-term.
