Home > Quality, SDLC, Software Development > Choosing Between Schedule, Budget, Scope, and Quality

Choosing Between Schedule, Budget, Scope, and Quality

Yaacov Apelbaum-Choosing Between Options

Argumentum ad populum is that the best way to beat your competitor is to one-up him. If he has 2 features, you need 3 (4 would be even better). If he is budgeting 1 x $  on his solution, you need to spend 2 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 envision the future, they can only dwell in the past. They don’t lead, they follow by imitation. If you want to rapidly build a leading solution and not merely mimic existing products, you need to focus on innovation and quality.

The Project Management iron triangle model proposes that every project is controlled by the following four elements:

  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 project managers believe that you can only pick three out of the four.  I don’t agree, because quality should never be compromised. would you buy a new car knowing that it has a defective engine or transmission? Most likely not, regardless of how many features it has or if it shipped on time to the dealer.  Quality is ‘given’, and as such, it should always be baked into the scope of the project.

I’ve seen numerous projects who compromised on quality by reducing unit test coverage and then engaging in creative bug severity reclassification, just to catch up with a slipping shipping date. In the end, no amount of Bondo and marketing spin can cover up the quality holes in your delivery.  Still not convinced, check out the annals of software development screw-ups , they are full of product humdingers that shipped on time, on budget, and scope, but failed miserably because of substandard quality.

So what do you do when the going gets tough? How do you make that difficult decision and chose the right sacrifice for the greater good? And while at it, what is the greater good anyway?

In this posting I’ll share with you a few insights into selecting the lesser of two evils, and some specific project hostage negotiation techniques that may help you get out of some tight delivery spots.

The Project Web
On the surface, each option from the list above seems to be equally weighted, but in reality, It’s not as simple.  In a dynamic living and breathing project, Schedule, Budget, and Scope actually carry different degree of importance and impact each other in subtle ways.

Yaacov Apelbaum-Choosing Between Options Pyramid

Illustration 2. The Project pyramid

It turns out that rather then a interwoven triangular knot that is made up of equal sides that can be resized and traded equally, the project elements actually resemble an intricate spider web (illustration 3).  The structure is controlled by many dynamic factors.  As you apply force (i.e. poll or push) to any strand in the web, the whole web flexes and deforms unevenly in multiple axis.  Each change you apply to the project (adding scope, increasing the budget, and etc.) will ripple through the entire project structure like a pebble dropped in a pond.

Yaacov Apelbaum-Project Option Grid

Illustration 3. The Project Element Web

As you can see in Illustration 4, increasing the budget and decreasing the schedule will adversely impact the schedule, scope and quality.  This action will also unproportionally deform all project axis and introduce a negative self reinforcing feedback loop. This is because the team will now need to quickly add additional development resources to complete the additional work, this will result investing less time on actual development on more time on knowledge transfer, which will introduce more bugs, which will ultimately result in a reduction of the overall quality of the software.

Yaacov Apelbaum-Project Options Budget Increase Schedule Decrease

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

This is counter intuitive to popular wisdom which states that increasing the budget for project can allow you to complete the work faster with more functionality.

The Project Annihilator Shooter
Software product development lifecycle is in many ways similar to a shooter video game.  You play each scenes collecting, oxygen, ammunition, and kill points.  If you are successful and survive enough missions without losing your vitals (i.e. reputation, stamina, leadership, etc.), you get to move to the next level and play again.  if you run out of ammunition, oxygen, or your life gauge falls below some critical level, you’re out of the game.

Yaacov Apelbaum-The Project Annihilator Dashboard

Following this corollary, your ability to continue to play the software development equivalent of Last Light, depends on your ability to juggle all the elements that go into a 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 on 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 that: 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 in within the allotted time and budget then 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 early a product that’s smaller is better than launching a solution that is full of holes just because of some magical date. Leave the magic to Siegfried, Roy and, their tigers. Your customer will measure 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 actually 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 your users for input, there is going to be a lot of change. Launch frequently, tweak, launch again, constantly improving your solution will help you deliver just what customers need and eliminates anything they don’t.

Breakdown Delivery to Phases and Prioritize Content 
This is an important exercise to go through regardless of project constrains. You have to figure out what’s important for your customer and how you can deliver 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 by far better than having a full poorly functional solution on your build server.

Be Flexible
The ability to quickly change is paramount for your success. Having scope, budget, and schedule fixed makes it tough to change. 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 (i.e. lengthy power point presentations, the fictional development progress reports, etc.) and force you to focus on building the real McCoy.

In larger organizations weeks can be spent on planning roadmaps and arguing about the fine details of each feature with the goal of everyone reaching consensus on what would be 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’s – resist the urge to engage in long-winded scheduling and especially stay a way from:

  • Senseless hundreds of page 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 in order to meet the 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 just need to simplify your solution and deliver it to the customer as fast as possible with the highest quality.

Or as Steve Jobs said it “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” .

© Copyright 2013 Yaacov Apelbaum. All Rights Reserved.

Advertisements
  1. November 7, 2013 at 1:13 am

    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

    • November 11, 2013 at 3:25 am

      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

  2. November 10, 2013 at 12:37 pm

    Very interesting! How would you actually measure the impact of these forces on the project web? Obviously, the relationship is not linear.

    • November 11, 2013 at 4:34 am

      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 variables, I’m not entirely sure that it can be modeled.

      It could be that if you pull or push on too many project strands, the system just becomes stochastic and unpredictable.

      Yaacov

  3. November 10, 2013 at 3:06 pm

    You may want to also to consider the fact that quality has cost and regardless of your development budget, you must set aside part of it to insure that it makes it into the scope.

    • November 11, 2013 at 5:04 am

      Hi Jamel,

      I agree, argo, “Quality should be ‘given’, and as such, it should always be baked into the scope of the project.”

      Yaacov

  4. November 11, 2013 at 12:55 pm

    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?

    • November 14, 2013 at 9:20 am

      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

  5. November 16, 2013 at 2:35 am

    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?

    • December 2, 2013 at 3:01 am

      Good comment, but even if we can forecast the needed effort accurately, quality should still be off the table.

      Yaacov Apelbaum

  6. MS
    November 20, 2013 at 2:15 am

    What is the source of your project elements vs. spider web deformity theory? Is this based on some published literature?

    • December 2, 2013 at 2:51 am

      It’s based on my own research and experience. I haven’t published any of this data in an organized manner yet, but may do so in the near future.

      Yaacov Apelbaum

  7. Lanny
    November 20, 2013 at 3:54 am

    How do you enable audio streaming on your pages? Are you using any special WordPress plugin?

  8. November 26, 2013 at 7:35 pm

    I’m not sure I get it, why would adding more time and money to a project put it at risk?

  9. FT
    November 27, 2013 at 1:13 pm

    Good day!

    Do you know if there is a Microsoft Schedule plug-in to do tradeoff and simulation calculations for a schedule?

    Cheers!

  10. Hanny Habib
    November 29, 2013 at 9:17 am

    Great blog! Would you mind if I reuse/link to some of your articles and graphics?

    • December 2, 2013 at 2:40 am

      Anytime… Just credit whatever content you use or link back to the original article.

      Yaacov Apelbaum

  11. Roseann
    December 3, 2013 at 8:09 pm

    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?

  12. Jillian Tuda
    February 3, 2014 at 2:17 am

    Nice graphics! I was almost moved to start my own blog (well, almost…Ha Ha!)

  13. Y Cohen
    August 1, 2015 at 4:21 am

    Nice posting Yaacov.

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

  14. August 12, 2015 at 9:15 pm

    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 ;-)

  1. November 23, 2013 at 1:57 am

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: