More than communications skills, lean techniques to discard useless features with no value, more than ask "what do you want?" or "is there anything else?" to the customer.

Reading the book Agile Project Management of James A. Crowder, it says: "Organizations must strive to provide an environment where budget is not centered on time and motion, but must be centered on the perceived values of the objectives of the project.... In classical EV change is bad and uncertainty is worse".

From the book Brilliant Agile Project Management of Rob Colle & Edward Scotcher: "Agile embraces change and even encourages it. Change is not seen as the enemy, it's seen as an important part of the evolution of any good idea."

In an agile approach everything is speculative and scope never is closed until customer is satisfied.

It looks like to me that these statements are for internal projects in software companies like Facebook, Uber, Airbnb, or even in in-house projects where there is an initiative to improve processes continously.

In a context that you handle projects with external customers and projects with ad-hoc development, we are limited by the triple constraint all the time. What are the techniques you use to set up scope and minimize the number of iterations if we are in time-restricted contract?


*Triple constraint is the name that PMI uses to describe restrictions on any project in Time + Cost + Scope (+ Quality in 6th version of the PMBOK) Any change on any of this restrictions will affect the other. A change in time, it will affect your cost, any change in scope affects time and cost and so on.

This is so restrictive, fixed and old in terms of agile. Once you have your baseline, you cannot change it, but through a formal change process. With external projects based on classic perspective, you manage contracts to deliver a product or service in a specific time and in a budget.

That's why in classic approach change is bad. If you change your baseline (time or cost or scope) it will drive you into a rework or reschedule. Nevertheless in agile, change is accepted all the time. Kind of 2 philosophies conflicting each other in change management, but we need to limit changes in a way to fulfill with deadlines.

  • Can you explain what the "triple constraint" is and why you must always be limited by it? – Erik Jun 15 '18 at 13:58
  • @Erik I added an extra section on my question to explain triple constraint and the impact to me in external contracts limited by money and time. – Maximus Decimus Jun 15 '18 at 14:35
  • 2
    One constraint must always be flexible. If schedule and budget are fixed, scope is the flexible element. That’s the core strength of agile frameworks like Scrum. – Todd A. Jacobs Jun 15 '18 at 17:15

If I understand your Question correctly, you're asking how best to approach agile development in a situation where there is a hard cap on time?

The obvious answer is to constrain the scope. And a good technique to do that is to first develop towards a minimum viable product (MVP).

You start out by getting from the customer a list of the absolutely must have requirements. The requirements such that, if the product is otherwise 100% complete except that one requirement, and there's no way to add it - then the only option is to throw the product out. The collection of those requirements is your MVP.

You then estimate how long you think it will take to develop that MVP - you now have your minimum schedule. At that point, you add padding to the schedule. The padding serves two purposes. First, a safety net for if you underestimated. Second, room to iterate improvements - the more padding you have, the more 'should have' and 'could have' requirements you can fit in.

Importantly, though, once you've completed the MVP, show it to the customer. Requirements practically always change once customers have a working product in front of them. At this point, you can renegotiate any of the 'padding requirements' you added before, in exchange for adding new requirements. Either remove some of the old ones, or increase the time/cost of the project.

The goal is collaboration. As per the manifesto, 'Customer collaboration over contract negotiation'.

  • You gave me a new topic to research about, MVP. Can you suggest the best book to read about? I will develop my own strategy based on my experience and the MVP concept. Looks interesting. I realized that we need to throw away classic PM structure and embrace agile from conception. Instead of using all the time dedicated for planning as in a traditional approach, we need to quickly address evolving requirements from customer and develop our sprints quickly as we can in a recursive agile sprint execution process. – Maximus Decimus Jun 15 '18 at 14:47
  • 1
    @MaximusDecimus I first read about it in a blog, not a book, sorry. A quick google search for 'Minimum Viable Product' will give quite a few blogs/articles, though. – Sarov Jun 15 '18 at 15:11
  • Thank you so much for your answer and your advices. Really appreciate it! – Maximus Decimus Jun 15 '18 at 15:20
  • 1
    One good book talking about MVP's among other topics related is "The lean startup". – Roberto Anzaldua Jun 16 '18 at 16:03
  • This is a great but somewhat contrary article on the MVP. – Kempeth Jul 2 '18 at 9:08

In our company we face this situation every time we take Fixed Price contract. Please, look into our approach description here.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.