Tips and tricks to rescue overdue projects

One of my friends, who runs his own offshore development shop,
was having nightmare situation with one of his customers. He’s way
overdue on a release, the customer is screaming everyday, he’s
paying his team from his own pocket, customer is sending an ever
increasing list of changes and so on. Here’s how we discussed some
ideas to get out of such a situation and make sure it does not
repeat in future:

Kabir: Hey, can you help me? My customer is making us
work for free for extra two months to fix bugs from our last
delivery. We did what he said. But after he saw the output, he came
up with hundred changes, which he somehow presents as bugs or
missing features and make them look like they are all our fault and
making us work for last two months for free. He is sending new
changes every week. We have no idea when we will complete the
iteration.

Omar: I see. Did you get a signed list of requirements
from customer before you started the development?

Kabir: Of course, I did. He sent us a word document
explaining what he wants and we sent him a task breakup with hour
estimates and total duration of three months. Now after three
months when we showed him the product, he said, it’s no where close
to what he had expected. Then he sent a gigantic list of things to
change.

Omar: All of those are bugs?

Kabir: Of course not. Most of them are new features.

Omar: Then why don’t you say those are new features? You have
the original word document to prove. Just ask him to show where in
the word document did he said X needs to be done?

Kabir: Well…, he’s tricky. He somehow makes things look
like it is obvious that X needs to be done and he’s not going to
accept a requirement as done until X is done. For example, he said
there must be a complete login form in the homepage. So, we did a
typical login form with user name, password and OK, Cancel button.
Now he says where’s the email verification thing? We said, you did
not ask for it. He said, “this is obvious, every login form has a
forgot password and email verification; I said *complete* login
form, not half-baked login form”. So, you see, we can’t really
argue to keep our image. Then, we did the login form exactly how he
said. Now he says, where the client side validations of proper
email address, username length, password confirmation? We said, you
never asked for it! He says, “come on, every single website
nowadays has AJAX enabled client side validation, do I have to tell
you every single thing? Aren’t you guys smart enough to figure this
out? You are already doing this for the third time, can’t you do it
really well this time?”

Omar: OK, stop. I see what’s your problem. Some customer
will always try to make you work more for less money. They will try
to squeeze out every bit of development they can for their bucks.
So, you have to be extra careful on how much you commit to them and
make sure they cannot chip in more requirements while development
is going on or when you deliver a version. Mockups are one good way
to make sure things are crystal clear between you and
customer. Did you not show him mockups of the features that
you will be building and make him sign those mockups?

Kabir: Yes, I made some mockups. But they were simple
mockups. I did not show the validations or all those side jobs like
sending verification emails.

Omar: Did you run those mockups through your engineers?
They could have told you about those details.

Kabir: No, I did not because developers don’t work on the
project until I get a signoff from client. So, I prepare all the
mockups myself to save cost.

Omar: So, this is the first problem. The mockups were as
ambiguous as the customer’s word document. Basically the mockups
just reflected the sentences in word document. Mockups did not
really show all possible navigations (ok, cancel, forgot, signup),
system messages, system actions behind the scene, workflows etc.
Are you getting what I am saying?

Kabir: Yes. Come on, I am not a developer. I can’t think
of every single details. That’s what developers do when they start
working on it.

Omar: But you provide estimates based on your mockups
right? So, if mockup shows there’s only a simple login form and
change password link, you charge 5 hours for it. But then when you
realize you have to send email for change password, email needs to
contain a tokenized URL, that URL needs to show a change password
form, where you need to validate using CAPTCHA etc, it becomes 20
hours of work. Right?

Kabir: Well yes. Generally I multiply all estimates by
1.5 just to be safe. But things have gone 3X to 10X off original
estimate.

Omar: Yes, I just gave you an example how a login form
estimate can go 4X off when the mockup is not run through an
engineer and the important issues are not addressed.

Kabir: So, you are saying I have to prepare all mockup
with an engineer?

Omar: In general, yes, since you aren’t good enough to
figure those out yourself; no offence. You will get good enough
after you build couple of products and get your a** kicked couple
of times, like mine. Mine got kicked about 17 times. After that it
became so hard that when I sit on it, I produce really good
mockups. After some more kicks, I hope to get 100% perfect in my
mockups.

Kabir: Ok, so the process is, I get word doc from
customer. I produce mockups from it. Then I run them through
engineers to add more details to them. Then after review with
customer, I run them through engineers again to estimate. Then I
ask customer to sign-off on the mockups and the estimate,
correct?

Omar: Well, first let me say, you don’t do a three month
long iteration since you are far away from your customer. You do
short two weeks sprints. Do you know SCRUM?

Kabir: Yes, one of our team does it.

Omar: I assume the team that got their a** kicked don’t
do it?

Kabir: right, they don’t.

Omar: OK, then first you start doing SCRUM. I won’t teach
you details. You can study about SCRUM online. Now, you collect
‘user stories’ from customer. If customer does not give you user
stories, just vague paras of requirements, you break the
requirements into small user stories. Understood?

Kabir: No, give example.

Omar: OK, say customer wants a *complete* login form. You
break it into couple of stories like:

  • User clicks on “login” link from homepage so that user can
    login to the system

    • User enters username (min 5, max 255 chars, only alphanumeric)
      in the username text field
    • User enters password (min 5, max 50 chars, only alphanumeric)
      in the password field
    • User clicks on “OK” button after entering username and
      password.
    • System validates username and password and shows the secure
      portal if credential is valid and user has permission to login and
      account is not locked.

Understood what user stories are?

Kabir: Yes, but you are missing all the validations that
we also overlooked and now we are working two months for free. This
“user stories” do not help at all.

Omar: Hold on, you just saw basic steps of a user story.
Now you describe each user story with the following:

  • All possible inputs of user and their valid format
  • All possible system generated messages for invalid input
  • All possible alternate navigation from the main user story. For
    example, while entering password, user can click on a help icon so
    that user can see what kind of passwords are allowed.

Got it?

Kabir: Now it’s starting to make sense. Then what? Show
these user stories to customers?

Omar: No, show them to your lead engineer who has enough
experience to identify if you missed something. Your Engr should
point out all the alternative system actions at least.

Kabir: What if my Engr can’t figure them out? What if
he’s just as dumb as me?

Omar: Fire him. Get a pay cut for yourself.

Kabir: Seriously, what do I do if that’s the case?

Omar: Your engineers will *always* come up with issues
with your mockups. You should always use another pair of eyes to
verify your mockups and add more details to it. You aren’t the only
smart guy in the world you know?

Kabir: I thought I was, ok. What’s next?

Omar: File those user stories in your issue tracking
system in some special category. Say “User Stories” category. What
do you use for your issue tracking system?

Kabir: Flyspray

Omar: Good enough. Create a new project in Filespray
named “User Stories”. File tasks for user stories. Each story, one
task. Attach the mockup to the tasks. Then create one account for
your customer so that customer can login and see the user stories,
make comments, suggest changes etc. You will get the conversation
with your customer recorded as comments in the task. This comes
handy for engineers and for resolving dispute later on. Moreover,
get your customer to prioritize the tasks properly. Understood?

Kabir: I don’t think customer will go through that
trouble. Customer will ask for some word document that has all the
user stories and she will write in the document what are the
changes. I will have to reflect them in Flyspray. Is it really
necessary to file user stories in Flysrpay? Can’t I just maintain
one word doc with customer?

Omar: Absolutely not. Word documents suffer from
versioning problem. You have one version, your customer has another
version, your engineers have another version. it becomes a
nightmare to move around with word docs which has many user stories
in it and keep them in sync all the time. Moreover, referencing a
particular use case also becomes a problem. Say at later stage of
the project, there’s a bug which needs to refer to User Story #123.
You will have to say User Story #123 in
centralserverfileshareuser stories1.doc. Now if
centralserver dies, or you put it somewhere else, all
these references are gone. Don’t go for word doc. Keep everything
on the web that you can refer to it using a URL or small number.
Another problem is numbering stories in Word Doc. Word won’t
produce unique ID for you. You will end up with duplicate user
story numbers. If you use Flyspray, it’s will generate unique ID
for you.

Kabir: OK, let me see how I convince my customer to use
Flyspray.

Omar: Yes, you should. If Flyspray is hard for customers,
use some simple issue tracking system that’s a no-brainer for
non-engineers. Some fancy AJAX based todolist site will be good
enough if it has picture attachment feature and auto task number
feature.

Kabir: OK, I will find such a website. So, I got the user
stories done. Now I show them to customer, review, make changes.
Finally I get customer to sign off on User story #X to #Y for a two
weeks sprint. Then what happens?

Omar: On your first day of sprint, you do a sprint
planning meeting where you present those user stories to your
engineers and ask them to break each story into small tasks and
estimate each task. Make sure no engineer put 1 day or 2 day for
any task. Break them into even smaller tasks like 4 hours of tasks.
This will force your engineers to give enough thought into the
stories and identify possible problems upfront. Generally when
someone says this is going to take a day or two, s/he has no idea
how to do it. S/he has not thought about the steps need to be done
to complete that task. Your are getting an estimate that’s either
overestimated or underestimated. Forcing an engineer to allocate
tasks in less than 4 hours slot makes an engineer think about the
steps carefully.

Kabir: If engineers do this level of estimate, they will
think about each task for at least an hour. This is going to take
days to finish estimating so many tasks. How do you do it in a
day?

Omar: We do 4 hours Planning meeting where Product Owner
explains the stories to engineers and then after 30 mins break,
another 4 hours meeting where engineers pickup stories and breaks
them into tasks and estimate on-the-fly. This 4 hours deadline is
strictly maintained. If Product team cannot explain the tasks for a
sprint in 4 hours, we don’t do the tasks in the sprint. If the
tasks are so complex or there are so many tasks that they cannot be
explained in 4 hours, engineers unlikely to do them within one/two
week long sprint. Similarly if engineers cannot estimate the tasks
in their 4 hours slot, the tasks are just too complex to estimate
and thus have high probability of not getting done in the sprint.
So, we drop them as well.

Kabir: This is impossible! No one’s going to attend 8
hours meeting on a day. Besides, telling them to estimate a task on
the spot is super inefficient. They won’t produce more than 60%
correct estimates. They will give some lump sum estimate and then
go away.

Omar: Incorrect, if engineers cannot make estimates of a
task in 10 to 20 minutes, they don’t have the capability of
estimating at all. If your engineers are habituated to take a task
from you for estimating and then go to their office, talk to their
friends on the phone, drink soda, walk around, gossip with
colleagues and end of the day if they have the mood to sit and
think about the estimate then open a new mail, write some numbers
and email it to you; they better learn to do this on-demand, when
requested, within time constraint. It’s a discipline that they need
to learn and implement in their life. Estimates are something they
do from the moment they wake up to the moment they go to sleep.
Besides, the planning meeting is the best place to estimate tasks –
all engineers are there, product team is there, your architects
should be there, QA team is there. It’s easy to ask questions, get
ideas and helps from others.

Kabir: I have engineers who just can’t do well under
pressure. They need some undisturbed moment, where they can sit and
think about tasks without anyone staring at them.

Omar: Train them to learn how to keep their head cool and
do their job in the midst of attention. Anyway, let’s stop talking
about these auxiliary issues and talk about the most important
issues. Where were we?

Kabir:About dropping tasks, I already negotiated with
customer that we are going to do story A, B, C in this sprint. Now
after the sprint planning meetings, engineers say they can’t do B.
Problem is I have already committed to deliver A, B, and C to
customer within 2 weeks and sent him the invoice. How do I handle
this?

Omar: How do you commit when you don’t know how long A,
B, and C are going to take?

Kabir: Customer tells me to do A, B, C within two weeks.
And after doing some preliminary discussion with engineers, I
commit to customer and then do the sprint planning meeting. I
can’t wait until the sprint meeting is done and developers
have given me estimates of all the tasks.

Omar: Wrong. You commit to customer after the sprint
planning meeting is done. Before that, you give customer just a
list of things that you believe you can try to do in following two
weeks. Tell customer that you will be able to confirm after the
sprint planning meeting. The time to do a sprint meeting is only 8
hours = a day. So, end of the day, you have some concrete stuff to
commit to customer. From your model where you give engineers days
to estimate, it won’t work. You have to finish planning
within a day and end of the day, commit to customer.

Kabir: What if customer does not agree? What if he says,
“I must get A, B and C in two weeks, otherwise I am going somewhere
else?”

Omar: This is a hard situation. I am tempted to say that
you tell your customer, “Go away!”, but in reality you can’t. You
have to negotiate and come to a mutual agreement. You cannot just
obey customer and say “Yes Mi Lord, we will do whatever you say”
because you clearly cannot do it. The fact is, end of the sprint,
you *will* get only A and C done and B not done. Then customer will
Fedex you his shoes so that you can ask someone to kick you with
it.

Kabir: Correct, so what do I do?

Omar: There are tricky solutions and non-tricky honest
solutions to this. Tricky solution is, say you engaged 5 engineers
in the project who can get A and C done in time. But you realize
you need another engineer to do B, otherwise there’s no way you can
finish A, B and C in two weeks. So, you invoice customer with 6
engineers and get A, B and C done. Now customer may not agree with
you paying for the 6th engineer. Then you do a clever trick. You
engage the 6th engineer free of cost in this sprint. Don’t tell
customer that there’s an extra head working in the project. Or you
can tell customer that out of good will, you want to engage another
engineer free of cost to make sure customer gets a timely delivery.
This boosts your image. Later on, when you get a sprint that’s more
or less relaxed and 4 engineers can do the job, you secretly engage
one engineer to some other project but still charge for 5 engineers
to your customer. This way you cover the cost for the 6th
engineer that you secretly engaged earlier sprint. This is dirty.
But when you have so hard a** customer who’s forcing you “what”,
“when” and “how” all at the same time and not open to negotiation,
you have no choice but to do these dirty tricks. You can also add
extra one hour to every task for every engineer in a sprint or add
some vague tasks like “Refactor User object to allow robust login”.
This way you will get quite some amount of extra hours that will
compensate for the hidden free engineer that you engage. You get
the idea right?

Kabir: Ingenious! And what’s the honest and clear way to
do these?

Omar: You negotiate with customer. You tell your customer
that he or she can only have any two choices from Money-Scope-Time.
This is called the project management triangle. Do you know about
this?

Kabir: Googling…

Omar: Read this article:

http://office.microsoft.com/en-us/project/HA010211801033.aspx

It shows a triangle like this:


clip_image002

So, your customer can specify any two. If customer specifies
Scope and Time (“what” and “when”), then customer must be flexible
on Money or “how” you do it within those two constraints. If
customer specifies Money and Scope, then you are free to decide on
time. You engage lower resource and take more time to get things
done. Got the idea?

Kabir: Yes, understood. Nice, I can show this to customer
and educate him. Is there any book for the evil tricks that you
just gave me?

Omar: No, I might write one soon. I will name it
“Customers are evil, so be you”.

Raisul: Hey, I have fixed people engaged in a project. I can’t
change the number of people sprint-to-sprint to compensate for
change in money. So, the triangle does not work for me. What do I
do here?

Omar: Right. I also made a slightly different version of
it. Here’s my take:


image

This is for situation where you have fixed resource engaged for
a particular customer. In that case, you cannot reduce people
on-demand because you cannot reassign them. Such a case requires
different strategy. If customer forces you Quality and Time,
customer must be willing to sacrifice Quantity. Customer cannot
say, produce perfect login form in 2 weeks and add cool ajax
effects to it. Customer has to sacrifice cool ajax effects, or
sacrifice *perfection* of login form, or sacrifice number of
days.

From the above two triangles, which one’s more appropriate for
you?

Kabir: Second one because customer hires 5 engineers from
me. I cannot take one away and engage in a different project. Well,
not openly of course.

Omar: OK, sounds fair. What else do you need from me?

Kabir: Let me think about all these. This is definitely
worth thinking. I have to figure out whether to play fair or play
clever. End of the day, I need to produce great product, so that, I
get good recommendation and future projects from customer. So, I
need to do whatever it takes. It’s hard to run an offshore dev shop
where we kinda have to work like slaves and like a bunch of zombies
mumble every 10 mins – “Customer is always right”. You are very
lucky to have your own company.

Omar: I had two offshore dev shops before Pageflakes. I know how it feels.
Wish you good luck. I have seen your product, you guys are building
a great ASP.NET MVC+jQuery application. Release it. It’s worth
showcasing.

Raisul: Thank you very much. See ya…

(End of chat)

This is the diagram my friend produced, which shows the steps to
do before a sprint is started:

Workflow for Product Manager

Handy for Product Managers. Enlightening for developers.

kick it on DotNetKicks.com

19 thoughts on “Tips and tricks to rescue overdue projects”

  1. 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.

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

  3. 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.

  4. 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..

  5. Hmm. Theoretically right, but practically….. Client should be taught software engineering 🙂 Whatever you say, “Client is always right” ahh!

  6. 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.

  7. 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 🙂

  8. 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

  9. 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.

  10. 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?

  11. 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!

Leave a Reply to re: Tips and tricks to rescue overdue projects Cancel reply