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 plan for the future, they can only react to the past. They don’t lead by innovation, 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 traditional Project Management iron triangle model proposes that every project is controlled by these four elements:
- Scope (features and Functionality)
Illustration 1. The PM Iron Triangle
Some project managers believe that you can only pick three out of the four variables. 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 other features it has or if it shipped on time to the dealer. Quality is not a variable and is a ‘given’, and as such, it should always be baked into the the product.
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 of the four options from the list above seems to be equally weighted, but in reality, It’s not as simple. In a dynamic living and breathing software project, the schedule, budget, and scope actually carry different degree of importance and impact each other in subtle ways.
Illustration 2. The Project pyramid
It turns out that rather than 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). This structure in turn is controlled by many variant and dynamic factors. As you apply force (i.e. poll or push) to any strand in this web, the whole web flexes and deforms unevenly in multiple axis. Each change you apply to the project (adding scope, increasing the budget, etc.) will ripple through the entire project structure like a pebble dropped in a pond.
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 disproportionally deform all project axis and introduce a negative self-reinforcing feedback loop. This is because the team will now need to quickly add more 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.
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 the 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.
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 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 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 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.
The ability to quickly change is paramount for your success. Having the 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 planning and especially stay away from:
- Senseless hundreds of page of slide ware 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 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 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.
25 thoughts on “Choosing Between Schedule, Budget, Scope, and Quality”
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.
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.
Very interesting! How would you actually measure the impact of these forces on the project web? Obviously, the relationship is not linear.
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.
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.
I agree, argo, “Quality should be ‘given’, and as such, it should always be baked into the scope of the project.”
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.
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?
Good comment, but even if we can forecast the needed effort accurately, quality should still be off the table.
What is the source of your project elements vs. spider web deformity theory? Is this based on some published literature?
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.
How do you enable audio streaming on your pages? Are you using any special WordPress plugin?
Try this code snippet:
[audio http://URL of your MP3 file]
I’m not sure I get it, why would adding more time and money to a project put it at risk?
It’s called Brooks’s law.
It states that: “adding manpower to a late software project makes it later”.
Check it out at: http://en.wikipedia.org/wiki/Brooks%27s_law
Do you know if there is a Microsoft Schedule plug-in to do tradeoff and simulation calculations for a schedule?
You can find some tools for doing CPM and schedule calculations here:
Great blog! Would you mind if I reuse/link to some of your articles and graphics?
Anytime… Just credit whatever content you use or link back to the original article.
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?
Nice graphics! I was almost moved to start my own blog (well, almost…Ha Ha!)
Nice posting Yaacov.
I like the illustration of the elastic schedule grid. What is the source for the non linear relationship?
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 ;-)