Tips and tricks to rescue overdue projects

re: Tips and tricks to rescue overdue projects

Tahmid Munaz — Tue, 03 Nov 2009 05:39:54 GMT

Nice post! It's a good stuff you shared to enlighten the Project Managers and the offshore dev shoppers or outsourcing service providers (watever we call)! :)

I believe that scrutinizing the requirement and verifying it by the customer before sign up - makes things better! I faced few ppl around me who says.. "Ok.. don't discuss about those possible additional requirements with the Customer cause s/he may agree to include in the task list and increase the list of tasks". But i believe if we can figure out their (Customers) exact requirement clearly - we will never have to face such quote - "Aren't you guys smart enough to figure this out?" Negotiation of money and time and the list of requirements shouldn't be the in your concern when you analyze the requirement. Cause you are thinking and trying to understand his business language! These two different role should be followed in two different techniques.

Any vague idea or assumption on Project Management or Development might kill you on the spot!

Thanks for sharing such a valuable discussion. I would love to share this URL with other Technical buddies in other groups!

Tips and tricks to rescue overdue projects

PimpThisBlog.com — Mon, 12 Oct 2009 01:06:10 GMT

Thank you for submitting this cool story - Trackback from PimpThisBlog.com

re: Tips and tricks to rescue overdue projects

Ali — Fri, 25 Sep 2009 14:28:50 GMT

Very good article. I agree with this approach. Customer should be aware of the process from the beginning before they commit.

Customer should understand that they are the owners of the solution. Whatever they like can be done but with a cost. They should have the option to say yes/no after estimates.

For prototyping I think Microsoft has done a very good job with SketchFlow part of Expression Blend. Its a very quick and visual way to demonstrate solution and collect feedback.

Problem with doing business with SMB, alot of the time spent in requirement gathering and prototyping is not paid. Whats the best approach to bill that as well?

re: Tips and tricks to rescue overdue projects

Ahmed Ibrahim Rubayet — Tue, 19 May 2009 09:30:01 GMT

Thanks a lot. This will really help to gain knowledge based on real life scenario.

P.S.

Shoeless Joe — Sat, 06 Dec 2008 02:24:27 GMT

One other great toolset we've added to our approach is prototyping. It works so much better than traditional mock-ups and can be done quickly and without programming knowledge.

Check out www.axure.com for a very cost effective piece of software.

Great advice...some of the time.

Shoeless Joe — Sat, 06 Dec 2008 02:21:00 GMT

I think a lot of this stuff sounds really great when you have a customer who's willing to pay you for two weeks of work at a time and will agree to start a project based solely on time & materials. I can tell you that most of my clients don't operate like that and I've been doing this for 10 years now.

When you are working in the SMB market customers typically have smaller and much tighter budgets and pick their vendor based, in part, on price. Asking customers for a blank check because "it's too hard to quote" is not an option in many cases.

While I agree that walking the customer through the entire requirements and user stories is the best approach sometimes that's just not practical on smaller projects. What could be a $5,000 project could easily turn into a $15,000 project just because of project management and mock-up time. Customer don't understand where the extra $10,000 is coming from so you just lost the bid.

I think there's a paragraph missing in this document right after, "this is obvious, every login form has a forgot password and email verification; I said *complete* login form, not half-baked login form." If it was so obvious why did the customer express his wants and needs. If he knew what he wanted why didn't he tell me.

You have to politely treat your customer they way they are treating you. Project managers and developers are not mind-readers and the minute you act like one that's where the problems really start.

A useful response to the above statement is, "I'm sorry Mr. Customer but you didn't specificy you wanted these extra features and while you may think those features are standard I could show you lots of website that don't have them. We did not put them into our estimate when we quoted the website but we'd be happy to add them now. If you would like us to do that it will be and additional $X,XXX.XX."

At that point it is up to the customer to make that buying decision. Ask them where in the specification or mock-up does it show AJAX enabled anything or a forgot password link. And if they can show you you'll happily build it in.

Additionally, maybe you purposefully left out that functionality out of the mockup because you were trying to keep the price reasonable. Maybe this was a prototype and not a 3rd generation Facebook application.

All in all, this is a very good article for "some" projects and I could see making our process a bit more strict and structured. I would just say that the two triangle diagrams in this proposal should come at the beginning of the process and not in the middle. This is an exercise in setting and meeting expectations more than it is getting everything right the first time.

re: Tips and tricks to rescue overdue projects

Asheesh Soni — Mon, 27 Oct 2008 23:53:22 GMT

Have you ever been to a car mechanic and asked him how much would it cost to service your car and fix all the issues?

If you have, you'd recall that he takes a 'quick' look at the car, asks you a 'few' questions, and gives you a 'ROUGH' time and cost estimate subject to his detailed inspection.

At this point, if you want to proceed further, he'll charge you for a detailed time and cost estimate, which will serve as a contract between you and him.

Software development is no different.

Instead of dividing the process into these 3 steps:

1. Vague requirements from client.

2. Detailed Mockups and Final time estimates

3. Development (the fun bit)

I've found it useful to divide it into the following four steps:

1. Vague requirements from client.

2. Quick n Dirty 'Business Requirements Document' (BRD) with rough time estimates. This is free of cost to the client, a bit more detailed than the crappy requirements from the client, and doesn't cost you too much.

This is where you tell the client that if this initial BRD and rough time estimates looks ok to him, we can go ahead and provide a "Functional Specification" (at a cost) which will be an 'unambiguous' set of requirements, with itemized price and will serve as a contract between the two parties.

So, step 3 is:

3. Detailed Functional Specification. Remember that you are charging the client for the time your engineers spend on this. (so you could enjoy a nice cold beer.... and buy me one too)

4. Development (the fun bit)

This solves your problem (@Dejan) of weather to charge the client for mock-ups or not, and also solves the real problem that Kabir was facing (or, any soft engg / company faces) by having an UNAMBIGUOUS set of requirements.

My 2 cents

re: Tips and tricks to rescue overdue projects

Dejan — Mon, 27 Oct 2008 09:10:49 GMT

Hey, nice read, but I still have some things that bother me. Like the following:

Customer sends in some basic mockups, by basic I mean just the usual "user must be able to login using his username and password".

At this stage you can not tell the customer how long it will take to complete the task nor how much it will cost, it requieres some further analysis. Making this further analysis already costs you money. Just to be clear I'll use an example:

The task requieres 2 engineers, each 3 hours to create and validate a complete mockup of the login form requested by the customer. Now this is the point where you can tell the customer a date and a value.

The customer always decides whether he will order the task or not at your company, based on time and money, so the task of creating a complete mockup is kind of unavoidable (taking projects over due usualy eats more money than taking some more planning anyway...).

OK, so far we have spent 2 x 3 x 50$ = 300$ just to tell the customer when and how much. Now if the customer says "thanks a lot" you just wasted a few pints at the pub :)

... now you might think "I'll just send a bill to the customer for the mockups I made". Ofcourse the customer doesn't want us to create a complete mockup, since all he wants is just a date and the costs, but how to achieve that on our side without making a analysis of the project ?

Another solution would be to add the analysis costs directly to the total project costs, this way the customer wouldn't even notice that you're charging for the mocks. But the risk here is that the customer doesn't order the project in which case you lose again.

So what would be the best way of providing the customer with the when and how much ?

Maybe here's one to think about also:

Company A creates mockups for free at first glance, but is actualy adding them to the total project costs. Company B charges for everything it does, including mockups. Both companies hand over the mockups for client inspection and approval. So the price fo the login form at company A is a rounded up 500$ and the price at Company B is devided into 200$ (mockup) and 300$ (dev of login form). Now I am a very smart customer, so I ask Company B what would it cost without a mockup ? So they tell me I'd need to deliver a full mockup and they would only charge me some minor changes + 300$ of dev time. So I go to company A and send them my login form request like this "I want the user to be able to login using his username and password". After 2 days I receive the final mockups from company A and that's the point where I tell them they're too expensive so I send the mockups to company B :)

re: Tips and tricks to rescue overdue projects

codebounce.com — Fri, 24 Oct 2008 19:53:46 GMT

This is a common scenario and tips discussed here makes sense.

Bookmarked here:

http://codebounce.com/ASPNET

re: Tips and tricks to rescue overdue projects

Vikas Sharma — Fri, 24 Oct 2008 06:04:46 GMT

Thanks, I think this'll help me...

re: Tips and tricks to rescue overdue projects

Lee — Thu, 23 Oct 2008 21:46:38 GMT

This reminds me of one particular customer i was dealing with. He wanted to be able to create his own customer forms including questions, steps, validation etc himself in the admin panel. We told him that might take abit of work and he replied how is that difficult when he can create forms in word really simply. I felt like saying well if it's that simple then why don't you build the thing yourself but i held back :). In the end we produced a detailed spec and it resolved most the issues but it still didn't stop the customer from being a pain though.

I think if you can identify a problematic customer early then make a decision to either abandon the project or add a higher margin of error than you normally would.

re: Tips and tricks to rescue overdue projects

Jahedur Rahman — Thu, 23 Oct 2008 14:14:30 GMT

Hmm. Theoretically right, but practically..... Client should be taught software engineering :) Whatever you say, "Client is always right" ahh!

re: Tips and tricks to rescue overdue projects

mike kidder — Wed, 22 Oct 2008 20:56:55 GMT

This is an awesome dialogue and will definately be sharing with others at my company. Your blog never ceases to amaze me. thank you for your insights..

re: Tips and tricks to rescue overdue projects

TeYoU — Wed, 22 Oct 2008 17:08:57 GMT

Wow! tricky and it's very useful.

I've learned a lot from this.

re: Tips and tricks to rescue overdue projects

omar — Tue, 21 Oct 2008 08:01:39 GMT

Not all customers are like this. Sometimes you get understanding, tech friendly customers who knows what s/he asks for and realizes how much effort is required. But sometimes you end up with customers, who's probably doing first development in their life-time and they just don't understand how soft dev works.

re: Tips and tricks to rescue overdue projects

Tommaso Caldarola — Tue, 21 Oct 2008 07:49:33 GMT

I think worldwide managers should know how to "manage" a Customer because this is the main cause of IT projects failure.

re: Tips and tricks to rescue overdue projects

Peter — Tue, 21 Oct 2008 07:17:12 GMT

My God you are a good friend. It's lucky Kabir has ever made any money from software. Let's hope he can turn it around.

re: Tips and tricks to rescue overdue projects

Muhammad Mosa — Mon, 20 Oct 2008 19:46:37 GMT

Thank you Omar, I didn't read all of it, but I must continue. It is valuable.