Definition of a Successful Project – It’s Different.
While managing any project, a project manager (PM) is challenged with successfully juggling three variables at a time. And they are scope (includes the quality requirements), cost (due to resources) and time. If you disturb any, the other two may require adjustments to maintain all three in equilibrium.
In a traditional approach, we understand scope thoroughly (signed off requirements), using which we try to determine how much it would cost and how long it would take. Once you determine this equation, all three are supposed to be fixed. That is you must deliver said features in said time and said budget. In fact that has been the definition of a successful project!
However, every project is full of so many uncertainties (risks) that juggling this equation becomes too difficult in reality. We invariably run out of time! So, when a project (mostly every project ) reaches a stage where you realize that you can’t deliver said scope in given time, the most obvious (??) thing done is to add more resources to “somehow” get everything “out of the door” in given time! And then we say “we successfully delivered this project”
Have You Ever Thought Of This….?
You take any product – e.g. your mobile phone – how many features does it have? Probably hundreds. And how many do we really care about? You can count them on your fingers.
This is true with any product. Take your bank’s website or any e-commerce website or any damn thing – this is always true!
Less than 20 % of the features of any product provide more than 80% of the value! Not every feature is equally important in any product.

 

How Agile Takes Advantage Of This Fact?
Now, agile tries to take advantage of this fact. Out of the three constraints described above, usually time will be absolutely important! If you are late in market, you can be out of competition (and existence also). You usually have limited dollars to burn while building any product. And time is money as well. Whereas, we just learnt that not everything is so much important in any damn product! With agile we build product incrementally and iteratively. So, then, can we lock the two most important constraints, that is, time and cost and choose to deliver as much as we can within those constraints, ensuring that we get at least those 20% of features out which matters the most for success or failure of a product? So, we will have “time-boxed” iterations, and each iteration producing a small increment of product. Thus, now we will have only one variable to juggle – that is scope, since we have locked the other two!
There comes prioritization of scope (features) to be delivered in a project (hence prioritized product backlog).
So, now when an agile project (like every other project) will reach a stage where you realize that you can’t deliver everything in given time, that you once thought you will, we need not add more resources to “somehow deliver” everything, but rather drop certain items from scope! So, instead of compromising on quality and cost (by last minute addition of more resources), agile says it’s better to compromise scope! Because not everything is equally important  and you would know your “chopping block” of scope, if you are maintaining a disciplined and prioritized product backlog.
So, think – what should be the definition of a successful project now?
Food for thought…
Assume that building just the following screen is your project. We have to get this out in three weeks with great quality.

Think of following questions…
1. How many features do I notice on this screen?
2. Are all of them equally important?
3. Do I clearly see some feature(s) which must be and can be done in 3 weeks’ time?
4. If we fall short of time, can we “leave something out”?

If you are able to see at least 7 different items (or features) in this scope and can clearly notice difference in their “value” to end user of this screen, I think you can now deliver this project “successfully” in 3 weeks’ time-box