Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I was asked to make a clone of this: http://www.bragster.com/
Ok, not a clone per se, but a site with similar functionality on a lower budget! How low might one ask? Under 10K, probably under 5K.
My question: how do I explain to a non-tech savvy friend, that this is not possible, in the nicest terms, and convince them not to go to rentacoder.com and try to pay someone to not do it for them.
Has something like this ever happened to you, and how did you deal with it?
people never want to hear "that's impossible" especially entrepeneurial types, it just makes them more dogged. so just show them what -is- possible for their 10k and let them come to their own conclusion.
So, while drawing on other sites for inspiration is fine, "recreate X" is not a scope, it generally means the client hasn't thought it through. For a start, you don't know which parts of that site are really standing out to the client.
So sit down with them and plan it properly, get them to lay out what they want from the ground up, without resorting to "however bragster/youtube/ebay do it".
Just bullet point it, really quick and dirty. you'll then have an idea of the true scope.
i want slick design
i want video uploads
i want video streaming
i want comments
ratings
sharing
competitions
blog
store
leaderboards
etc. etc.
then you can throw some numbers next to each one, and watch them add up to over 10k. this will illustrate your point, and help your friend/client far better than "Trust me don't bother it's impossible"
Extending Kyle's answer a bit - maybe try an analogy for their business.
For example, if they're involved in construction, ask them whether it would be possible to create a 1km bridge spanning a river for $500k (no idea what the actual cost would be).
The difficulty with IT is obviously that it's an intangible thing. Make an analogy that's tangible.
Find a site that looks like it cost $5,000 and send your friend a link to it.
Everyone knows a good website takes six to eight weeks to develop.
I was an a similar situation. A friend pitched me a business idea for a social networking site. I asked her, "sounds fun, but how exactly is this going to be competitive with all the sites that have well-established userbases?"
Granted, I wasn't expecting a good answer to that question, so maybe it wasn't incredibly nice. Still, she thought about it, and twigged that the idea wasn't going to make any money, and that she had underestimated the difficulty of the undertaking. I didn't have to tell her so in any condescending, didactic sort of way, so I didn't feel like too much of a jerk about it.
Come up with several metaphors that point out how out of place you think the request is, and use them repeatedly until the point is made. Brute force attacks for the win!
In general, it is not advisable to do rough estimations because the result will be wrong. You would be under estimating because of a lot of things.
In this case (and just because you are certain the task is impossible given the cost requirement) you could do a rough estimation where you divide the project in specific tasks and maybe milestones with time and resources required for each. Give this estimation to your friend and tell him that is a first-approach/very-rough-estimate/very-risky-because-of-lack-of-a-formal-analysis.
Other posts here in SO may provide some guidance to you: https://stackoverflow.com/questions/tagged/estimation
Shall I forward all the horror stories I get from people who used services like rentacoder? Yikes.
We all know that if they go that route, it's roughly equivalent to throwing the $5000 in the shredder. Maybe you can suggest they find a partner to start the business with who can do the coding. If they get someone jazzed about it, and offer them equity, a) they're not out the $5000 and b) they have at least a chance of getting code that doesn't suck.
Here in the bay area, at least, there are any number of hackathons and meetups where developers looking for projects go. If the idea is good, and the person promoting it is sufficiently enthusiastic and personable, someone will be interested.
check Clipshare, http://www.clip-share.com/
you need to "setup" an ffmpeg or another engine to encode videos, flix or another you want in the server, but its pretty easy to setup in general and cheap also.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I know this may not be exactly a coder question, but I feel it is still related to programming because I'm sure many developers have come across this before and might have some insight on how to resolve this or have advice. There is an actually programming question though.
My issue as a developer.
I work in a small company, roughly 15 people, 5 of which are developers include myself, the rest are tech support and management. Problem I'm having is, when we get a SOW (Statement of Work), our clients give us a rough description of the project they are requesting, which usually is a 1-3 page brief description, usually including a Visio document, now as a programming, I'm responsible for going over the document and relaying a time-line on how long it should take me to complete the project.
Unfortunately, there have been times, not only me, where we under-estimate the project because we didn't fully get into it till we actually developed it, which ends up slapping ourselves in the face, because my boss is upset because he is being hounded by the client, who is now upset because we missed our promised deadline.
My question is, how do you guys handle organizing basic project description when you need to give deadlines on more concept, and do you have any ideas on how to organize it.
I'm thinking of going to my boss and suggesting, instead of always pushing a estimated deadline to our clients which expect us to hit that, we should write up a detailed document that is more step-by-step (more like what to do) on how to develop the application they want, it may take a lot more time, but least if the project is moved to someone else it is laid out for them, and when I usually get back to it 4 months later, I don't have to refresh up again, I can just follow the steps I wrote.
What do you guys think? Ideas? Or better ways to handle this?
If you switch your development to using an iterative methodology (Agile, XP, Scrum, etc), then the customer will see results much earlier than any deadline you feel you have to promise - usually every 1 or 2 weeks.
The moment they see what you've developed, I can pretty much guarantee that they'll make changes to their initial requirements as they now have a visual representation of the product and it may not be quite what they were thinking of. Some of their changes might be quite radical, so best to get the feedback as early as possible.
In all the projects where i've insisted we do this, the customer was delighted - they saw the results early, could influence the project outcome, and we hit their end deadline. Unexpectedly, a whole load of features got left behind and - guess what - the customer did not mind at all as they got the top features they wanted and put the project/product straight into production as they'd had lots of time to refine it to suit their business, so they were already familiar with it.
It takes a lot of effort to get management, sales, creative, etc, to all buy-in to an iterative style, so you may need to implement a hybrid solution int he mean time, but in my experience, it is well worth it.
If a complete shift to iterative is not possible, split your project into tangible milestones and deliver on those milestones. As others have said, inflate your estimates. My previous manager doubled my estimates and the sales team doubled his too.
Inflate your project deadlines. It's something that most programmers should do (and I quote the VP of Freeverse, the company that I work at):
It is a well-known fact among people
who work in the software industry that
the last 5% of development always takes the longest.
If possible try to divide the higher level tasks as much as possible so that you can get a better approximation of how many man hours that sub-task would take.
Also, adding hidden buffers to your task execution helps in covering some of the unseen contingencies.
cheers
If you mock up (balsamiq or whatever) with your customer, you will get more details. Armed with those details and some experience, your estimates will be more accurate. And then double it and add 4 (hours,days,weeks,months)
First, unless you systematically under-estimate, your boss should not get upset. It's his job to answer to the client, and he should know that by definition, an estimate is NOT the future. Statistically, sometimes you should deliver earlier, sometimes later.
Personally, I think that the frame of "how long will it take" is not exactly the right discussion to have. Software development is a risky business, and change/surprises happen all the time. One approach which helps is to focus less on the "right" number, and more on the volatility. Look at the project, and consider the places where you are pretty clear on how long it will take (you have done it before and understand it well), and look at the places where you have uncertainty (unclear requirements, new technology), and for these, think about how bad it could go, and why. That will help you get not one number, but rather boundaries: what you think is reasonable, a worst-case scenario, maybe a best case scenario (which the client should never see :) ) - and convey that information to your boss, so that he can manage accordingly.
Additionally, this will allow you to identify the danger points of the project, and you can then prototype accordingly - look into the uncertainty points as early as possible, so that you can tighten up the timeline fast, and have early warnings for your boss and the client.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
If you are the lead programmer at a company and you need to complete a project that would require skills/knowledge that no one at the company currently has, what do you do?
I am not talking about something simple you can ask for help on stack-overflow for but for complex problems that you do not feel comfortable tackling and would take a significant amount of learning to be ready.
So at the point whats the best step to take?
Be honest with your management team, make sure they know. Don't ever try to mislead people about the scope of your knowledge - it doesn't impress them and only causes you problems.
Work with your team to evaluate your options - it may be possible to change technologies, or perhaps someone else in the organization can help mentor or support you. Changing course earlier on is easier and less expensive than later.
Adjust your project timeline to take into account the potential risk and delays caused by working beyond your core strengths. If you don't have enough knowledge to estimate the risk, be very conservative in the confidence factor of your estimates and timeline.
Look for an expert in the domain/technology and see if you can engage them either as a consultant or advisor on your project. Nothing makes a bigger difference than prior experience in a domain.
Take some time to try to create a simpe prototype or proof-of-concept in the domain/technology you will be working on. Look for possible issues that could emerge. Sometimes unexpected problems surface when you try to create a simple prototype - this can help steer the effort when working on the real thing.
See if the scope of your project can be scaled back. If you are already "behind the curve" the best way to improve your odds of success is tackling something smaller, rather than larger.
Seek out advise from people you trust. Especially people whose expertise and knowledge has some bearing on the problem or technology you're taking on. They may be able to give your more specific advise or ideas.
You have to take it outside the company to someone (person or consultancy) that can complete it. This means a contractor/consultant that will be with you for a temporary period of time. If possible have them work in house with your and your team and make part of their responsibility to train you.
You may have to explain to management that without this, the project could fail and will probably be late and over budget. Don't worry about outsourcing some projects - you and your team will still have lots of work.
Temporarily hire someone who has the expertise you're missing, and make sure they're prpared to transfer their knowledge to others in your team as well as work on the problem at hand. Be prepared to pay serious money; but if the problem really is complex, chances are you'd take much longer, get a much worse result, and pay more overall if you try to figure out out without any help.
First, +1 to Borgwardt, Oded, Bushkin. Great answers here. Now my two cents...
Your path forward should consider whether this is a skill/technology i.e. "capability" that your company needs to have internally. Depending on this, take the advice of either #Oded (Outsource) or #Michael Borgwardt (hire a contractor to do some knowledge transfer), or spend a lot of time (if you have it) and develop the capability on your own. For example, suppose you're going to interface with some purchased package that spits out magic numbers in some binary format. Hire a contractor to write the interface. Suppose your VP of fulfillment wants you to interface with a FedEx web service, and nobody at your company knows SOAP. And you know that more SOAP is coming, for all suppliers and partners. You'll need SOAP skills in-house, so get some training, do a prototype, and maybe bring in some outside help.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
Our profession often requires deep learning; sitting down and reading, and understanding. I'm currently undergoing an exam period, and I'm looking for ways to learn more effectively.
I'm not asking about what to learn, or whether to prefer blogs over books, etc. My question is much more physical than that -
What do you do when need to study, and I mean study hard?
I'm looking for answers such as
I slice my time to 2.5 hours intervals and make a break between them, but never during.
I keep a jar of water nearby.
I wake up at 6 o'clock sharp and start my day with a session at the gym.
What good learning habits did acquire, or wish you had acquired?
(I know this isn't strictly programming related, but it is programmers related)
I find the best way to set yourself up for learning is:
Get plenty of exercise and rest
Eat a balanced diet with little sugar and caffeine
Try to find a quiet area conducive to concentration
Try to practice what you learn from a book - theory is ok, but practice embeds the knowledge.
"The best way to test whether or not you know something is to try to explain it to someone else from scratch."
That has to be one of the best ideas I was ever given about knowing whether or not I really know something.
Make sure it's quiet and comfortable around you.
enough to drink and eat
don't just read but take notes, draw mindmaps and the like
don't just read but try
make a report, blog entry, presentation out of what you learned
learn the same thing from different sources: Don't just believe what person A has to say look for, read and understand the opinion of person B and C as well and understand the differences.
take nothing for granted
apply the knowledge to an actual project
I set aside time every day or x times per week. Otherwise I never do it.
I try to have a diff location every once and awhile (home / coffee shop / stay late at the office) keeps the tedium away.
I am careful about the music I use, try to make sure it is relaxing
Sometimes I leave headphones on even if music is off that way people don't talk to me.
I give myself specific goals before each break or for every session.
I reward myself
Read Andy Hunt's "Pragmatic Thinking and Learning" - lots of good suggestions there.
Tony Buzan wrote The Mind Map Book, describing his ideas for note taking. He also has some process ideas that I found very helpful. Foremost was this one: study new material for an hour, then take a short break (5-10 minutes) and then review the new material. Review the new material again an hour later, then two hours after that, then the next day. You need to refresh your exposure to the material multiple times over the course of time to really take it in.
While reading, I make sure I fully comprehend each section in the text before I continue.
Set up a time and take away all distractions. At home/dorm can be rough, so I would use the library while in college. Getting started is usually the hardest part, so don't set a specific time limit for when to quit. It is distracting, and you will be looking at your clock to see "how much longer you have." You don't want to be in that mindset. Work until you feel your brain is starting to lose focus, whether that is lack of comprehension or having to reread simple paragraphs repeatedly. Take a minute or two as a break, then refocus your mind. When that stops working, it is time for a real break.
Are you a night owl or early bird? Each person is different. I am very productive early in the morning, while my wife can barely function. We all have differences, so don't try to fight your nature.
+1 to what everyone else said. Making cheat sheet/notes were a very important part of my studying habits, whether I could use them on the exam or not.
I find it best to be fully dedicated to the task before I start. If you go into something with low morale, you will not do well. If you go into a task with high morale, you will understand things quicker, be able to apply it to real situations better, and will have a deeper comprehension. If I am not fully dedicated, I don't even bother. I've got better things to do with my time then half ass something, and you probably do too.
Expanding on a comment I left, see this article from Electronic Design from a few years ago: http://electronicdesign.com/Articles/Index.cfm?AD=1&ArticleID=5859.
If you can teach what you learned, you know it.
by Louis Frenzel
All learning is self-learning. Professors, trainers, and all teachers just organize and present the material to be learned. They don't teach it to you. You learn it. You're the one who actually absorbs, understands, and assimilates the knowledge by listening to the lectures, reading, thinking, solving problems, and other activities. Self-learning is a natural, human quality. While most of you have used this method in the past, you may want to do it on a more formal basis to speed up and fine-tune your methods. Here's a suggested approach (and trust me on this, you must write it down):
Clearly identify what you want to learn. Write it out.
Write some learning objectives for yourself. These statements clearly identify what you want to know and be able to do. For example, you should write something like "When I complete this learning assignment, I will be able to design and program an FIR DSP filter." The objectives should be expressed in "behavioral" terms, that is, using words that state some measurable outcome.
Identify some initial resources. Start with books at the local bookstore or go to www.Amazon.com or Barnes & Noble at www.barnesandnoble.com. Most cities don't have good technical bookstores, and it's tough to find anything at regular bookstores. Consider yourself lucky if you have a good technical bookstore or a good college bookstore. Plan to get multiple books to give you greater breadth of coverage with multiple explanations, examples, and perspectives. Don't forget to look through your stack of magazine back issues.
Check out online sources. Do one or more Web searches, or go to relevant company Web sites. You may run across an appropriate tutorial, white paper, or application note that will give you what you need. The large semiconductor and equipment manufacturers have tons of stuff on their Web sites, so start digging. Also check out the professional societies and other sources listed in the tables and sidebars.
Watch out for any conferences or seminars on this topic. Usually, such events never occur when you need them, but you might get lucky. If you find one, attend because it will provide a big head start for your own learning.
Organize your materials. Lay them out, mark them up, and then make an outline based on your objectives. See what you have and what you lack, and make an initial list of things to do.
Dig in. Set aside an hour a day or whatever you can to go through the materials. Turn off the radio, CD player, and television. Make a habit of finding some quiet time to read and learn.
Look for a human tutor. You could be working just down the hall from an expert on the very subject you're trying to learn. Pick his or her brain. Ask this person if he/she will help you understand and learn. Take this person to lunch or offer to pay for lessons. Most people will gladly share what they know, if you aren't too proud to ask. The best way to do this is to learn as much as you can on your own. Then, go for the professional, personal help with tough questions or when you get stuck.
Include some hands-on. Is there any hardware you can buy or put together to help you learn it? Maybe there's some software that will help. Buy it or have your employer buy it.
Write a paper or article or teach what you have learned. You have to know it to write it or teach it. There's no better way to learn for yourself than to have to explain it to others.
I generally find it useful to build a "cheat sheet" or other form of summary as I go.
On one hand, it forces me to reinterpret information and figure out what's really important.
On the other hand, I'm building a useful study tool for last-minute revisions, or future refreshing of knowledge.
2.5 hours without breaks seems like a lot. Experiment with different time slots to see what works best (personally, a sequence of 3x(20 work - 5 break) works well)
Pomodoro Technique for time management
http://pomodorotechnique.com/get-started/
(watch "how" tab)
And the code(for programmers)
while(day) {
for (int i = 0; i < 4; i++) {
work(25);
relax(i < 3 ? 5 : 15);
}
}
You should implement methods
void work(int minutes);
void relax(int minutes);
Variable day changes from other threads
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
You and I want to be the expert on computer programming or website design, but sometimes a customer would rather try their hand at your specialty than concentrate on real estate sales, marketing, or being a former member of the Israeli army. Then we have a choice: either figure out how to tell the prickly customer their logo would NOT be better spinning in 3-d with a righteous lens flare, or perhaps suffer the small indignity of making link texts as verbose as possible in direct opposition to any style guide ever written.
Have you been able to convince your customers to focus on whatever it is they are trained to do so they will let you execute your technical skill to the best of your ability?
I always try to point my clients in the right direction with regard to design. Sometimes it's just not possible though; they want something that's dreadful design, but they're convinced it's essential to their system. If they're unconvinced after a modest pitch, I just do what they want. They are, after all, the ones paying me (usually) thousands of dollars to build to their spec.
Often the reason the client wants to get involved is they are concerned consciously or unconsciously you don't understand the details of their business or how they do it.
The best approach is to work with the client to learn their business. This involves zero assumptions and learning the "how they do it" of their business. From that, discover all the data they use, what states the data sits in at what point in their process.
Keep taking it back to them and eventually they will realize that not only do you understand their stuff, what they want, and what direction they want to go in, but that you might even know the implications or impacts better than them.
After this they will usually stay out of your hair. This can be hard though when working with micromanaging types, or engineers. By nature they want to know how everythign works which is great. The timing of when it's best to learn how it works is the tough part.
Often you can get stuck in more conversing about solving a problem than it would take to just fix it. Maybe you can tell us more about the client's personality.
The trick is to get them to make the right decisions, but think it's their idea. :-)
You can't have this conversation with them easily in the abstract, but you can drill down and guide them towards the side of righteousness on each individual decision. Eventually, after you've been through this a few times, they'll start to trust you.
If possible, it helps to wait a day. Tomorrow they may be less clear on exactly what they asked for. (Do they really have their heart set on a flaming logo, or was it just a whim?) Then, in your response, you: describe what you recommend, and why. Restate agreed-upon objectives, and show how the solution meets the objectives. And make it sound like it was their idea. ("The point you made yesterday about xxx is really excellent, and I think that suggests a yyy solution.")
At this point you have a choice. You can ideally pretend you never heard their silly suggestion. Or if you feel you have to, respond to it tactfully and explain costs. ("I'm a bit concerned about the animated logo idea, because it may not convey the brand image the way you requested. Of course if you want to go this route, we certainly can--in which case I'd suggest we get our graphic design consultant involved. Let me know if you want to explore this further and get a quote from the consultant for his services.")
I found that customers are always easier to convince by "optical evidence" than by theoretical arguments - so you could e.g. show them logos or the general style used on websites which won a price for their usability, or maybe even show them how some big competitor is doing it, and then point out the benefits based on what they see.
I've also once managed to get rid of a really terrible user interface suggestion by making screen mock-ups of how this feature would actually look and work - and I made sure to make thes mock-up as unappealing as possible ;-) When I presented them, the client quickly realized that there were better ways of achieving his goal.
Knowledge is power. When you know a client is doing something wrong, have the facts ready as to why and present them quickly and in plain english. You need to remind them why they hired you in the first place.
Bearing that in mind, sometimes clients insist on shooting themselves in the foot. Have backups ready, use version control, but most of all: don't antagonize them. Your reputation is worth a lot more than their 3d-logo-spinny site.
Very carefully.
You've got several conflicting issues here: you want to keep the relationship (and the revenue), you want to do good work, and you don't want to end up with your name on a turkey.
Start by asking lots of questions about the business aspect: what do you want it to do, who do you want to reach, what impression do you want to give. Sometimes that will let you turn the discussion to more useful topics.
If that doesn't work, sometimes it helps to mock up the customer's idea and your idea, and compare them; if yours is clearly superior, they may see it.
If not, sometimes you have to remember that contracting/consulting is a form of prostitution; you do what the customer wants, whether it's your favorite thing or not.
The other thing to remember is a lesson I got from another consultant years ago: some customers aren't worth the trouble. he recommended that once you have enough business to live, you make a practice of firing your least liked 10 percent of the customers. Over time you develop a customer base that you can work with, and give the turkeys to someone else.
The problem with customers is that they are the customer. They have hired you to do a project to their specifications. What they seem to have missed in your example is that they have hired you because of your experience. You need to remind them of that fact in a gentle way. Perhaps a story such as "At one client, we used a logo like that and they expereinced a drop in traffic. Once we switched to a flat icon the traffic returned." Doesn't have to be true, per se, but you need to sell it.
All you can do it explain to your customer that they hired you for your expertise in design, but at the end of the day, the customer is always right.
If you find you don't enjoy working for customers like that, simply state at the beginning of a new project that you require complete creative control. If they still want rotating logos, then you'll have to put up with it for that project but at least you can decline any offers from the same customer in the future.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
How to convey a bad news to the client?
When something has gone wrong the client needs to know three things:
precisely what is wrong
what the impact is on them
what you are going to do about it
If you are not completely honest and transparent you will get found out later and will compound the trouble.
If your relationship with them is good then you probably will survive - presuming this is not completely catastrophic - but you will have to provide a decent remedy.
If your relationship is bad, then prepare yourself for them to start playing hard-ball with you on the terms of your contract.
HTH
Addendum: A good comment below about telling them as soon as possible, which I am happy to surface in this answer as requested. It reminds me of a saying "the sooner and in more detail the bad news is known, the better for everyone". As in life, so in project management.
With an emphasis on the solutions you propose to address the bad news.
We will not be able to have a moon
controlling functionality in our
system (due to ...) but we can and
will deliver the weather changing
module which is almost just as good
for your world domination plans.
Be honest and try to offer effective and realistic solutions instead of things that'll end up being more bad news.
Managing your clients/bosses expectations is a great way to avoid this.
In an engineering discipline, the old adage remains true:
Under promise. Over deliver.
If you've already got the bad news, well:
be honest and upfront about it.
give them options about how they want you to solve it; be detailed about cost estimates.
don't make any further promises "to make up for it". If some of your proposed solutions offer advantages down the line, tell them; but don't say that you'll add a feature at the same time as fixing the problem.
"Give the bad news all at once, and the good news little by little. -- Machiavelli" :)
Seriously.. investigate damage control or remedial measures before hand. Set them up in place to make sure it doesn't happen again. Fall back to a contigency plan if needed and you have one ..
Be objective, sincere, apologetic and don't play the blame game.
Be truthful, since nothing is more distracting than lies.
post a tongue-in-cheek apology, preferably starting with Simpsons artwork
What type of bad news?
People in general like to break bad news by stating that the corrections / new timelines will be in place much earlier than we truely can accomplish. Be honest up front and dont give false hope. One instance of bad news is enough... no need to create new promises that you cant keep in the future.
Bottom Line: be honest to your client and yourself to control expectation management.
Here's a link to a short Harvard Business Review podcast entitled: Speaking Well in Tough Moments
In the podcast, they broach different scenarios in which you have to have difficult conversations.
What I usually do is:
Good news
Bad news
Good news
And, for how you execute Bad news, the already mentioned answers can suffice. So, you should have 2 good news in-hand everytime OR you break one into two :)
First, bad news should ideally be delivered as soon as possible, even more so if there might be some sort of financial impact. Also, when you deliver the bad news you should make sure you address all of the concerns as quickly as possible, namely:
What went wrong.
How they are being impacted.
How long a fix will take.
What is being done to make sure it doesn't happen again.
How you deliver the bad news is a big subjective, but the rule of thumb seems to be that you should deliver it in person (e.g. phone call). Also, even if you don't know what is going on yet, you should at least let people know that you are aware of an issue and that you are working on it.
In addition to being honest and straight-forward about it, equally important is how you convey the news. A simple statement of "you are doomed" may be honest but improper. It is important that the customer be told all the due deligence been done by you, what (if any) are the options or workarounds available to him and propose to get together with him to find a way forward. You are not misguiding the customer but you are trying to provide him some avenues to think and the realization that you are not just throwing it all in his plate.