1

I'm working in a medium sized company as a CTO, the business side in the company is sending an average of 5 proposals/day to be estimated in terms of working hours and cost for each proposal.

In that phase I still don't know which team will be assigned to the project as signing the contract phase may by in average more than 5 months.

The problem I've been troubling since 1 year until now is the conflict between estimating the deadline signed with the customer and the deadline planned by the Product Owner and the team which may vary up to 2x sometimes which means loss in time, cost, trust with the clients.

My question is, what is the best practice in estimating the projects while proposing the project to the clients considering that Cost and Price must be available in this phase as they are the factors that the clients are comparing the proposals with?

We are following agile methodology in the company, so this needs to be considered as well

  • 1
    Unclear what you're asking. You say you have a conflict between estimating the deadline signed with the customer and the deadline planned by the Product Owner. Why? What makes you think you can override the PO and then expect PO to make your new deadline. – Danny Schoemann Mar 6 '16 at 9:42
  • 1
    how is it aglie if you agree price and deadline upfront? – Ewan Mar 8 '16 at 0:19
1

This seems to be a common question theme lately. I recently answered similar questions in this thread and in this thread.

There are three main issues swirling around you.

Estimations are just guesses: In the 80' and 90's we somehow forgot the concept of "[Cone of Uncertainty][3]" in estimating. When you first estimate a project, you are lucky if you are even 50% accurate. And if you are not, then it will always be later. You will almost never over estimate the work to be done thanks to Hofstadter's Law, which basically says "We always under estimate, even when we know we always do." The only true way to know when (scope driven) or what (schedule driven) you will deliver for a project, is to start doing it and then use velocity to predict either when or what.

Scope vs. Schedule: I recommend my, short, slideshare presentation on this. I have full speaker notes embedded to explain each slide. It's a great way to visually explain Scope vs. Schedule so customers and teams understand. My personal recommendation, based on years of Agile development, is to always go with a Schedule Driven release with an MVP that is no more than 80% of what you think your Release Line is.

Release Lines vs. MVP Lines: We're all familiar with the term of Minimum Viable (or valuable) Product. However I see a lot of variation in what people think the definition is. I usually go with this "If we don't reach MVP, then we would throw away all the code and not release the product at all" and "MVP is what does the customer need for the product to be useful?". I usually cite the original iPhone. It didn't do BlueTooth, it didn't cut and paste, it had no real apps to speak of. And yet it exactly met the customer need (A dirt simple phone, with idiot proof UI that would allow phone calls, emails and basic web surfing).

Release Line is a term we don't hear enough of and is what causes us to run into so many problems with MVP defined projects. We'll say "these are the MVP features" of the project and "We must ship by August", however we rarely then look at what we think engineering can actually do. In the Schedule section of my presentation I show the worst case scenario of the team delivering less than the MVP because the product owner defined the MVP as exactly what engineering thought they could deliver.

Never do that. Always under commit and over deliver. If you think you can ship 10 features (engineering estimate), in the schedule, don't commit to more than 6. This allows for two very real things. 1- You under estimated the amount of work to be done. 2- Your customer/ product owner changes their mind and adds new features during development.

Finally, patience and Agile Value 3: We are trying to turn around thirty years of bad project planning and expectations that an estimate is a commitment. We won't change it over night. So always keep in mind Agile Value 3- Customer Collaboration over Contract Negotiation. Keep in constantly in communication with your customer and be totally truthful and transparent. If you think there is even a chance of delay, tell them right away. In the last seven years I've used this model. My customers (internal and external) love the total transparency and are a lot more tolerant of issues because I'm communicating as often as daily. When you can see the sausage being made, you are less concerned about eating the final product.

0

There is inherent uncertainty in any software development project. The two main reasons for this are requirements change and technical risk.

This uncertainty makes it very difficult to estimate in advance and the longer the project, the more difficult it becomes. This is described by the cone of uncertainty.

You have a number of options:

  • Take on the risk - if projects take longer than estimated then they may be unprofitable
  • Add contingency - add contingency to your estimates (perhaps adding more contingency the longer/riskier the project)
  • Offer a variable scope - break the requirements down in to those that must happen, those that should happen and those that could happen; complete as much as possible in the available time/budget
  • Negotiate a more flexible contract - work in a more collaborative way with your customers rather than having a fixed price contract

The agile approach suggests that the last option is the best: "Customer collaboration over contract negotiation".

One approach is to negotiate time and materials type contracts, where the customers pay as they go. There are also some agile contracts appearing that you may wish to consider.

0

The gap between sales and delivery exists everywhere and will never go away. The sales side of your business needs to sell the work and, as typical with a lot of sales, will over promise. Plus, they need to price the work competitively as price is a major driver in a customer's decision to buy. The delivery side of your business wants to successfully deliver the project with the resources they need, the time they need, and with a good chuck of contingency for just in case, often resulting in under promising. These two objectives between sales and delivery are contradictory.

You need to have the delivery side of your house to have the authority to "nix" the project if the sales side is over promising. You need to have a governance process that strives for consensus before a proposal is delivered to the customer. This process should / may help in chilling the over promising of the sales side while also chilling the costly over-allocating of the delivery side and help you arrive at a price and cost case that is closer to the middle.

That said, and even with a process like that in place, in my experience the sales side typically wins (you gotta sell to have work) and the delivery side is left holding the bag. Good news for you is, you're not alone in this struggle.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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