Why you cannot deliver fast with the same quality?
and why your software project is always late.
Have you ever been part of a project where new features seem to pile up daily, deadlines are often missed, and everything needs to be done for yesterday? If so, you're not alone. This story includes the challenges described by the Project Management Triangle—a model that illustrates the trade-offs between a project's scope, time, and quality.
Another important aspect that causes projects to be late is the complexity of software engineering. We'll also discuss different complexities and examine practical strategies for dealing with them.
So, let’s dive in.
Protect Your Cloud Investments with Archera (Sponsored)
Archera is unique among cloud cost management products for a simple reason: they insure your cloud commitments.
That means if you underutilize an AWS Savings Plan commitment, they will write you an actual check to cover the difference.
They also allow you to achieve the cost savings of native AWS Savings Plans / Reserved Instances with a commitment as low as 30 days instead of 1 to 3 years.
What is the Project Management Triangle?
You've probably been part of a project where you were a feature factory, with new features added almost daily, and were expected to deliver yesterday with excellent quality. Our experience says it is impossible, but we are still unsure how to explain this properly.
This was explained a long time ago by the famous Project Management Triangle, also known as the triple constraint or iron triangle, which has been fundamental to project management since its introduction by Dr. Martin Barnes in 1969, which says that every task can have three constraints:
📐 Scope: The scope of the task.
⏳ Time: Time we need to finish the task.
✅ Quality: The quality standard we need to hold.
Here, we can satisfy only two vertices, not all three. So, we must always sacrifice one of them.
Understanding the Trade-offs ⚖️
The Project Management Triangle helps us understand the following trade-offs:
📈 To increase scope and maintain quality, you must sacrifice speed.
📉 If you want scope and speed, quality is likely to suffer.
🔍 If you want speed and quality, you must reduce the scope, known as an MVP approach.
Understanding these trade-offs allows us to make better decisions about project priorities. For instance:
🕒 If time to market is critical, you might sacrifice some quality or reduce scope.
🚨 If the software is for a critical system, you might prioritize quality over speed or more features.
💰 If the budget is fixed, you might need to reduce the scope or extend the timeline to maintain quality standards.
The fourth dimension: The cost 💸
While the Project Management triangle focuses on scope, time, and quality, we should also consider cost a fourth important constraint. Cost interacts closely with the other three factors:
Accelerating a project often requires additional resources, increasing costs.
Expanding scope typically demands more time or resources, driving up costs.
Higher quality can require more skilled people or better tools, increasing the budget.
This is important to drive our project in the right direction and communicate constraints with all relevant stakeholders. However, we should know that adding more people to the project may not yield the same results.
Strategies to mitigate the triangle's effects 📐
Yet, with all this in mind, there are some things we can do to mitigate the effects of the triangle:
🔄 Iterative delivery. Breaking the project into phases allows for delivering core functionality quickly while extending the timeline for less critical features.
🧩 Modular architecture. Designing a modular system, such as a modular monolith, can allow for faster development of individual components without sacrificing overall quality.
🧪 Automated testing. Comprehensive automated testing can help maintain quality even when development speed increases.
🛠️ Manage Technical Debt proactively. Acknowledge when speed and scope are prioritized over quality and plan to address technical debt before it spirals out of control.
🗣️ Clear communication. Ensure all stakeholders understand the trade-offs, which can lead to more realistic expectations and smoother project execution.
📅 Add deadlines. Parkinson's Law states that work expands to fill the time available for completion. Here, deadlines help by setting them proactively or timeboxing things.
📊 Agile methodologies attempt to address the Triangle's constraints through iterative development, frequent checking of priorities, and stakeholder involvement.
Also note that, regarding quality, research shows that high-quality code makes us slower at the start of the project but allows us to be faster later, as it reduces technical debt, so quality is something we should always have as a selected category.
Why is your project always late?
You can hear this question many times from business or product people. While several factors contribute to project delays, one of the most significant is complexity. In software development, complexity is always present in different forms.
We have three basic types of complexity:
1. Essential Complexity 🌩️
Essential complexity is the difficulty that comes from the actual problem the software is trying to solve. This complexity is unavoidable because it relates directly to the project's requirements. It can only be removed or reduced by altering the application's functionality or scope. Yet, sometimes, we need this complexity to have the necessary capabilities or quality.
👉 Examples:
Developing a weather prediction system involves handling complex meteorological data, sophisticated algorithms, and weather parameters.
Building a financial trading platform requires implementing complex algorithms, ensuring regulatory compliance, and processing real-time data.
2. Accidental Complexity 💻
Accidental complexity refers to mistakes or poor choices in the software development process related to the technologies, tools, and techniques used. And this kind of complexity should be removed.
👉 Examples:
Using a programming language with poor library support makes simple tasks more difficult.
Managing inconsistent development environments that cause integration issues.
The usage of microservice architecture creates complexity between different components.
Dealing with software bugs due to lack of automated testing.
3. Incidental Complexity ⚙️
Incidental complexity results from outside factors that complicate the development process but are unrelated to the software's core function. This can include issues like using outdated tools, dealing with complex integrations, or having inefficient workflows.
👉 Examples:
Selecting an algorithm with higher time complexity when a simpler one would suffice.
Implementing a feature in a more complicated way than necessary due to misunderstandings or overengineering.
Strategies to manage and reduce complexity
How can we deal with the complexity? There are a few things we can do:
✂️ Remove unnecessary components. If you have more tools for the same thing, eliminate one.
👌 Apply the KISS (Keep It Simple, Stupid) principle. Avoid overengineering and choose the most simple solutions.
🧩 Decompose the system into smaller, independent modules. As in the modular monolith approach, ensure each module has a single responsibility and clear interfaces.
📏 Adopt coding standards. Enforce consistent coding conventions and styles. Use linters and formatters to maintain code quality.
⚙️ Automate everything, including repetitive tasks such as build, test, and deployment processes. Implement CI/CD pipelines to enable development workflows.
🛠️ Prioritize refactoring. Regularly refactor code to improve its structure and readability (without asking for permission).
📝 Maintain documentation. Document system architecture, codebase, and decision-making processes.
📢 Share knowledge. Facilitate knowledge-sharing sessions and push people to do collaborative problem-solving.
🏛️ Implement design patterns: Utilize established patterns to solve common architectural problems efficiently.
🧪 Invest in testing: Develop a proper testing strategy, including unit tests, integration tests, and end-to-end tests, to identify and mitigate potential sources of complexity early in the development process.
Bonus: Planning Fallacy Bias
When we start new projects or initiatives, we tend to underestimate the effort, cost, time, and risk involved in completing them. We can often see this in software engineering, which is complex because we tend to plan on (almost) ideal conditions and ignore things that can happen along the road. Many things can happen, such as technical issues, scope changes, resource limits (e.g., integration with external systems), etc.
Why do we do this? Sometimes, we are under pressure from stakeholders, occasionally overconfident, and sometimes, it is just an optimism bias we see among software engineers.
How can we deal with this bias in software projects?
Analyse experience: Use data from past projects to inform more accurate time and cost estimates.
Risk assessment: Identify potential risks early and develop contingency plans. This includes brainstorming sessions, previously mentioned analysis of past data, checklists, and qualitative and quantitative analysis. Ultimately, we need to prioritize those risks and assign owners to them.
Iterative planning: Use agile methodologies that allow for regular reassessment and adjustment of project timelines.
Cross-functional collaboration: Involve all stakeholders in planning to uncover blind spots and set realistic expectations. This means also having open communication between different departments in the company.
Transparent communication. To manage expectations and secure support, keep stakeholders informed about risks and mitigation plans.
Also, learn more here to deal with estimations:
More ways I can help you
LinkedIn Content Creator Masterclass ✨. In this masterclass, I share my proven strategies for growing your influence on LinkedIn in the Tech space. You'll learn how to define your target audience, master the LinkedIn algorithm, create impactful content using my writing system, and create a content strategy that drives impressive results.
Resume Reality Check" 🚀. I can now offer you a new service where I’ll review your CV and LinkedIn profile, providing instant, honest feedback from a CTO’s perspective. You’ll discover what stands out, what needs improvement, and how recruiters and engineering managers view your resume at first glance.
Promote yourself to 35,000+ subscribers by sponsoring this newsletter. This newsletter puts you in front of an audience with many engineering leaders and senior engineers who influence tech decisions and purchases.
Join my Patreon community: This is your way of supporting me, saying “thanks, " and getting more benefits. You will get exclusive benefits, including all of my books and templates on Design Patterns, Setting priorities, and more, worth $100, early access to my content, insider news, helpful resources and tools, priority support, and the possibility to influence my work.
1:1 Coaching: Book a working session with me. 1:1 coaching is available for personal and organizational/team growth topics. I help you become a high-performing leader and engineer 🚀.
Excellent points regarding trade-offs as they’re different depending on org focus
Why the need to refactor if you designed all the components properly upfront? design, design, design. Iterative design, incremental development.