Choosing Between Schedule, Budget, Scope, and Quality

Yaacov Apelbaum-Choosing Between Options

The argumentum ad populum is that the best way to beat your competitor is to one-up him. If he has two features, you need three (four would be even better). If he is budgeting 1 x $  on his solution, you must spend 15 x $.

This arms race style upmanship is a dead-end. It’s a prohibitively expensive, reactionary, and is a schizophrenic paranoid way of developing software. Organizations following this philosophy can’t plan for the future; they can only react to the past. They don’t lead by innovation; they follow by imitation. To rapidly build a great solution and not merely mimic existing products, you need to focus on innovation and quality.

The traditional Project Management iron triangle model proposes that these four elements control every project:

  1. Schedule
  2. Budget
  3. Scope (features and Functionality)
  4. Quality

Yaacov Apelbaum - Iron Triangle of Project Management

Illustration 1. The PM Iron Triangle

Some development managers argue that you can only prioritize three key project variables—scope, schedule, budget, and quality. I disagree because quality should never be treated as negotiable. Would you buy a brand-new car with a defective engine or transmission? Probably not, no matter how many other features it boasts or how promptly it was delivered to the dealership. Quality isn’t just another variable—it’s a non-negotiable foundation that must be baked into the product from the start.

I’ve witnessed numerous projects where quality was compromised to meet deadlines or budgets. Teams reduced unit test coverage or creatively reclassified bug severity levels to meet slipping delivery dates. However, no patchwork fixes or clever marketing can hide the glaring flaws in a poorly built product. History is littered with examples of software projects that were delivered on time, within budget, and to scope—yet failed spectacularly because of subpar quality.

So, what happens when the pressure mounts and tough decisions need to be made? How do you decide which sacrifice will serve the greater good? And, perhaps more importantly, how do you define that “greater good”?

In this post, I’ll share insights on navigating these difficult choices, identifying the lesser of two evils, and employing practical project “hostage negotiation” techniques to help you tackle tight delivery challenges effectively.

 

The Project Web
On the surface, the four options listed above—schedule, budget, scope, and quality—may appear to carry equal weight. However, in reality, it’s far more nuanced. In a dynamic, living, and evolving software project, schedule, budget, and scope hold varying levels of importance and influence, often impacting each other in complex and subtle ways.

Yaacov Apelbaum-Choosing Between Options Pyramid

Illustration 2. The Project pyramid

It turns out that, rather than resembling an evenly balanced triangular knot where each side can be resized or traded equally, the elements of a project are more like an intricate spider web (see illustration 3). This web is controlled by numerous variable and dynamic factors. When you apply force—whether pulling or pushing—on any strand of this web, the entire structure flexes and deforms unevenly across multiple axes. Each change you introduce to the project—whether adding scope, increasing the budget, or altering the timeline—sends ripples through the entire project structure, much like a pebble dropped into a pond.

Yaacov Apelbaum-Project Option Grid

Illustration 3. The Project Element Web

As shown in Illustration 4, increasing the budget while simultaneously decreasing the schedule will adversely affect the schedule, scope, and quality. This action disproportionately deforms all project axes and introduces a negative, self-reinforcing feedback loop. Here’s why: the team must quickly bring in additional development resources to handle the increased workload. However, this often means spending more time on knowledge transfer than development. The rushed onboarding process and limited ramp-up time can lead to more mistakes and bugs, which ultimately reduce the overall quality of the software. This cascading effect highlights how interconnected and sensitive the project elements truly are.

Yaacov Apelbaum-Project Options Budget Increase Schedule Decrease

Illustration 4. The Project Element Web – Impact of Budget Increase and Schedule Decrease

This perspective is counter-intuitive to the popular belief that increasing the project budget will allow you to complete the work faster and deliver more functionality. While this idea seems logical on the surface, in practice, it often leads to diminishing returns. Adding more resources—money, personnel, or tools—introduces complexity, requires more coordination, and diverts time toward onboarding and communication instead of actual development. Instead of accelerating progress, this approach can create inefficiencies, increase the likelihood of errors, and ultimately compromise the project’s quality and outcomes.

The Project Annihilator Shooter
The software product development lifecycle can, in many ways, be compared to a shooter video game. In each stage, you navigate challenges while collecting resources like oxygen (time), ammunition (resources), and kill points (achievements or milestones). Success means surviving enough missions without losing your vitals—reputation, stamina, leadership, or team morale. If you keep everything in balance, you advance to the next level and keep playing. However, if you run out of ammunition or oxygen or if your life gauge drops below a critical threshold, it’s game over. Like in the game, strategic planning and resource management are key to staying in the fight.

The Project Annihilator Dashboard

Following this corollary, your ability to continue to play the software development equivalent of Metro: Last Light depends on your ability to juggle all the elements that go into your software project.

The following are your variables:

Ammunition/Oxygen = Funding/Budget
Scene Length = Schedule and drop timeline
Number of Targets per Scene= Number of Features of your project

Here’s an easy way to launch on time and budget: keep features minimal and fixed. Never throw more time or money at a problem; just scale back the scope. There’s a myth that states you can launch on time, on budget, and on scope while keeping quality in check. Well, it’s nonsense. It never happens, and when you try, quality always takes a hit.

If you can’t fit everything within the allotted time and budget, don’t expand the time and budget. Instead, scale back the scope. You will always have time to add more content later–later is eternal, now is short-lived. Launching a smaller product early is better than launching a solution full of bugs just because of some magical date. Leave the magic to Siegfried, Roy, and their tigers. Your customer will judge you on how well your features work, not on how many of them you’ve delivered.

Still not convinced? Here are some more benefits of fixing time and budget and keeping scope flexible:

Keep Scope Real and Relevant
Less is more. Less code, less documentation, less regression testing. Remove all but the essentials. Trust me, most of what you think is essential is not. Keep your solution small and agile.

Use rapid iterations to lower the cost of change. And believe me, if you plan to deliver a functional product and are soliciting input from your users, there will be a lot of change. Launch frequently, tweak, and launch again. Constantly improving your solution will help you deliver just what customers need and eliminate anything they don’t.

Breakdown Delivery to Phases and Prioritize Content
This is an important exercise regardless of project constraints. You have to figure out what’s essential for your customer and how you can ship the most critical functionality in multiple phases. Not being tied to a single monolithic delivery will force you to make some tough decisions but will also eliminate the need to prostrate yourself in front of the war console.

It may sound corny, but having a portion of a working product in the customer’s machine is far better than having a full, poorly functional solution on your build server.

Be Flexible
The ability to change quickly is paramount to your success. Having the scope, budget, and schedule fixed makes changing it tough. Injecting scope flexibility will allow you to be opportunistic in resolving technology and operational unknowns.

Remember, flexibility is your friend. So de-scope, reduce features, and break your monolithic delivery plan to smaller drops. In the end, there is no escaping the proverbial SDLC grim ripper and the fact that you will have to fold. The sooner you show your cards, the better you’ll be in the long run.

Dump the Ballast
Delivering less content will allow you to reduce all the fluff that represents managing upwards (e.g., lengthy PowerPoint presentations, fictional development progress reports, etc.) and force you to focus on building the real McCoy.

In larger organizations, weeks can be spent planning roadmaps and arguing about the fine details of each feature, with the goal of everyone reaching a consensus on the ‘best’  solution.

That may be the right approach for a $$$ mainframe product, but if you are developing in internet time, fast-quality shipping is the way to go. You can always trust the user to tell you if your scope is sufficient. If it’s not, you can always fix it in the next phase and re-ship it again.

When it comes to scope, there is no judgment better than that of the customer–resist the urge to engage in long-winded scheduling and planning and especially stay away from:

  • Senseless hundreds of pages of slideware roadmaps
  • Schedules that depend on a multi-year project plans
  • Pristine roadmaps that predict the future (in terms of market and customer needs)
  • Pie-in-the-sky solutions (technology that is immature or non-existing)
  • Reliance on never-ending status/staff meetings and project reviews
  • Dependency on hiring dozens of new resources to meet the current increase in scope
  • Endless version, branching, and integration debates

To succeed in building competitive software, you don’t need an excessive budget, a large team, or a long development cycle. You need to simplify your solution and deliver it to the customer as fast as possible with the highest quality.

Or, as Steve Jobs said, “That’s been one of my mantras—focus and simplicity. Simple can be harder than complex: You have to work hard to get your thinking clean to make it simple. But it’s worth it in the end; once you get there, you can move mountains.”

 

25 thoughts on “Choosing Between Schedule, Budget, Scope, and Quality

  1. I know this if off topic but I’m looking into starting my own
    blog and was curious what all is needed to get setup? I’m assuming having a blog like yours would cost a pretty
    penny? I’m not very web smart so I’m not 100% positive.

    Any recommendations or advice would be greatly appreciated.
    Many thanks

    • Hi John,

      The cost is minimal; the biggest investment is in generating some original/relevant content.
      You can use any of the free platforms for hosting (i.e. WordPress, Blogger, etc.). For authoring, I use a free tool called Microsoft Live Writer. For image creation editing, I use Photoshop.

      I try to publish once a month, try to write about subjects you know well, keeping it professional and none polemic also helps.

      Best of luck in your blogging endeavors.

      Yaacov

    • From my little research, it looks like the relationship between the cause and effect is fuzzy at best.

      Some of the short term effects are more understandable, but the long term downstream impacts are difficult to calculate. At that point It’s no longer a question of leveling resources, calculating slippage, or coming up with a new critical path. Based on the fact that the system is so complex and is driven by so many variables, I’m not entirely sure that it can be modeled.

      If you pull or push on too many project strands, the system will just becomes stochastic and unpredictable.

      Yaacov

  2. I am really loving the theme/design of your blog.
    Do you ever run into any internet browser compatibility issues?
    A few of my blog visitors have complained about my blog
    not operating correctly in Explorer but looks great in Chrome.
    Do you have any suggestions to help fix this issue?

    • I use a standard WP template and code all content in straight HTML. I also produce all of the images myself and stay away from linking to external on-line content.

      Let me know what specific issues you are having and I’ll try to troubleshoot it.

      Yaacov

  3. I would also add that when you examine any new project, you will find feature complexity and the need to learn and debug new technologies. Each of those elements has a vast range of potential overruns and associated costs. How can you trade between the schedule, budget, and features, when we can’t even accurately forecast basic effort for a feature?

  4. Pingback: Mary P
  5. I like really like your topics, artwork, and layout.
    If you don’t mind me asking, is this a paid venture or are you doing this as a hobby?

  6. Nice posting Yaacov.

    I like the illustration of the elastic schedule grid. What is the source for the non linear relationship?

  7. Thanks YC,

    The source of the illustrations is my observations i.e. tracking historical project’s expense, slips, feature creep, etc.

    Any yes, as we all learned from a certain project in D, the relationship is not linear ;-)

Leave a Reply

Your email address will not be published. Required fields are marked *