brady gaster

Bill by the hour.
Document all changes/problems daily.

Some projects are not made to succeed. That is not your decision. You have to try to make it succeed if at all possible and part of that is documenting problems, offering solutions, and making sure that those involved are aware of both at all times. They can choose to not act on your advice, that is their choice to make. Suck it up and get over it. Sometimes you get paid to do a great job, sometimes they pay you to follow their stupid orders. As long as they are the ones paying you, they choose what they pay you for.

BUT, make sure that THEY are the problem and not you and make sure that you show them this and can document it.

Unfortunately, this is part of the reason why jobs are being outsourced. Ignorant Middle-management gives bad orders and run up costs for jobs that fail. The bulk of the cost is due to programmer labor, so middle-management suggests next time they outsource/offshore the labor.

But if you don't take the job just because it is being ran wrong, someone else will. I highly suggest against trying to over-ride/over-rule the manager or going over his head. I tried to make a project succeed like that once, it doesn't work.

we need a book on the subject.

Just nod and increase your rate.

I agree with part of what Shannon wrote; that is: document and give feedback daily.

Obviously though, having said that, it would be pretty difficult to create something in 2 months which didn't have any sort of plan attached which demonstrated that it was "do-able". In other words, I would lock the client in to agreeing on a "must have" outcome - or the minimum that must be achieved in order to claim success, then, look at your resources and time and draw up a plan which demonstrates whether the minimum is achievable.

Don't let "no time" stop you from planning :-)

I might be back later with fun comments and analogies...

Darren has one of the keys;"lock-in".
Don't let the client lock you in when he has no matching lock-in.
A contract is to protect both parties.

If a project is a "rush", you or your employees may be required to work exagerrated hours. You may need to accomodate a "rush" billing rate for these hours.

Reward your own success with a bonus for meeting deadline. This can be touchy, but introduces the idea that arriving at that deadline is not a forgone conclusion. Even if it doesn't end up in the final deal, the client won't forget.

Express all timelines as effort required. A module that depends on the length of the bridge cannot be begun before that length is known and cannot be behind schedule until after it is known

You are confusing 2 similar but definitely different jobs, the consultant versus the contract programmer. The consultant is paid to consult the client on how to best go about developing an app, work out something suitable to the client, and then do it. The contract programmer is told by the client how to best go about developing an app, and then do it according to the client's wishes. Consultants get paid more, but have a higher risk, and sometimes have to take one for the team (aka the person the hired you). A contract programmer doesn't get paid as much as a consultant, and isn't paid to think. Don't ever confuse one role for the other, it will only cause endless fustration for both parties (i.e. make sure your role is known ahead of time). Sometimes clients are paying for contract programming, when they really need a consultant, and that is when consulting gets a bad name.

DonXML Demsak

Saying No...

We look for people who can say yes until we are surround with yes-men, then we look for people who say no (know-men). When the no-men say yes, the answer is probably yes.

If you really can't do it, or it can't be done , don't take on the job.
(Don't tell the client it can't be done, just that you are not in a position to do it or don't know how in the timeframe)

You might lose your client, but If the job fails with somebody else, the client will come to you first the next time.
Hopefully the client now thinks of you as someone who won't promise what they can't deliver.

A few approaches to this:
1) Attempt to educate the client. If you have a pragmatic client with whom you can communicate based on a shared common goal - a successful project - this may be worth the trouble. You can point them to statistical information on the high percentage of failed software projects, the advantage of iterative development cycles, etc. It often helps to name drop Microsoft (probably the most successful software development shops in the known universe) and push MSF documentation (http://www.microsoft.com/technet/treeview/default.asp?url=/technet/itsolutions/tandp/innsol/msfrl/msfovrvw.asp). Sadly, adgile methods are probably too much of a shock for a lot of business folks, but MSF is a good middle ground.

2) Don't be the bad guy. "Sure, that's a great idea and we'd love to do that for you. We think it will take about 2 weeks of work - we can either push out the delivery date by two weeks, or add it in the next release of the product. What would you like to do?" The idea here is that they're paying for the work, and they can make the decisions, but they have a decision to make.

3) Document what's important. This is like saying "you should back up your computer" after someone's hard drive dies, but it's true nonetheless. It's important to document assumptions and scope when a project is estimated and signed off on. Then you can keep taking the client back to the written document when they change the plan. Again, this should be done in an accomodating manner (point 2 above), but with the documented "facts" as a basis: "Great, that's a good feature that will add a lot to the user experience. That's outside the scope we agreed on for this Phase - that's in the Scope of Work document, section 3.2, by the way - but we'd be happy to restimate this for the current phase or to add this to the feature list for the next phase. Which would you like?"

4) Estimate conservatively. My first programming mentor told me repeatedly that the hardest part of programming is estimating. Very true. This is tough balance - if you bid conservatively, often someone who's less experienced will underbid and make it up as overruns. Probably the best work this out is to show successes early, which argues again for phased, incremental development.

Charge them more and build them a tunnel.

First I would show them the bridges that you have made in the past. Ensure that what they need is really a bridge. Perhaps a ferry will be more up their alley. Try to get them thinking about how everyone will use the bridge (customers, employees etc.). Use this discussion to build the requirements. Help them to understand the risks involved when building a bridge without plans and document them. Do not be afraid to undertake the project if they are willing to accept the risk, they hired you and there must already be some level of trust. This still may not prevent the phrase: “That is exactly what we didn’t want.”, but as long as they are: agreeing to the process, agree to the risk and everything is documented with their approval they will have to assume the overall risk associated with it. On a final note a successful failure is not always a bad thing.

My responses:

Part One - http://weblogs.asp.net/rmclaws/posts/43657.aspx
Part Two - http://weblogs.asp.net/rmclaws/posts/43686.aspx

I started with a comment, but it grew into this monstrous entry. Take a look:

This Consulting Business - http://udidahan.weblogs.us/archives/005984.html