December 21, 2007 9:27 pm

Under Promise, Over Deliver

Well, I posted couple of other items about my experience with ordering a Dell computer. What I am always impressed with DELL though, with several 1st hand experience with Dell in the past, has been Under Promise Over Deliver, for most of the time (although my previous posts did not mention that 🙂 ).

The first time I bought from Dell was 6 years ago, I was told that the manufacturing and shipment would take X number of days and can be expected to be delivered in X+5 days. It was actually shippped within X-“n” + shipment delivery (UPS) days. I was very impressed back then.

Later I had few technical issues with Inspiron 8000 and I called up Dell technical support. I had a prompt support and got many issues resolved just over phone.

Later around 34th month (I had 36 months extended warranty) laptop’s casing started to break. Called up Dell, and they said it was under warranty for 2 more months, and they sent someone to have it fixed for free. Thats again impressive service I aplaud about.

I recently placed an order for Inspiron 1720 earlier this month. I was told that the system would be shipped by around Dec 27 and plus the shipment about 3 to 5 business days and expected delivery around Jan 2nd. However, I received it on Dec 18th. I am very impressed with the delivery schedule again.

That’s a great customer service in terms of delivery and support. And, I am sure, a lot of people would grade much higher satisfactory rate on such a service.

Lets look at the related comparison with some of our projects (I am referring to IT projects for now, since I am from that background):
a. Project Management asks for invidual estimates from dev and test teams
b. individual teams provide their estimates for deliverables in terms of hours or days
c. dev team reaches the code complete milestone 2 weaks early
d. test team completes their task an additional week ahead of schedule
e. project is delivered almost a month early for a 6 month project

Now, IT (information technology) folks, what does this convey to the project management.
i. Oh, we thought the complexity level was high, but we figured it was much less
ii. Oh, we actually had added 40% buffer in our estimates, just in case we would get into any issues. (but this was not conveyed to the project management during the estimation process)
iii. Oh, we screwed up on our estimate process – it is probably a lessons learned for next project.

However, What does project management draw from this (when they allocate the budget for the project)
A. Ok, agreed with your points #i and #iii, lets make it better for next time
B. hmmm… it appears like project management need to scrutinize more and not trust the dev and test teams on their estimates for 40% buffer in the estimates.

What are the downsides of providing estimates with large buffer?
In my experience on project estimations and getting the buy off from the business customers, depending on the funding situations, it is possible that business team might move away from your quote and look for some one who can deliver better product with reasonable price. So chances are either we get the business or lose it without further discussion into prioritizing, cut scope, etc.

What do you think from your experience on providing more buffer in the project estimates?