|Pushing along the project...|
finishing up and moving along
A project I've been working on is moving along nicely, however, I've been waiting on some adjustments the company wanted to make...without the list I'm going to have trouble finishing up and getting paid. Are there some good ways to apply a bit of pressure without sounding to pushy?
Clean it up to the best of your ability, present an invoice and a 90 day "fix-up" guarantee,"fix-ups" being the things you are waiting for, not site redesigns, etc.
Post it live. Send the Bill. Follow up with a courtesy call.
Give them the full enthusiasm treatment. Your site looks great now that its finished. I'm pleased with it. How about you? Oh before I go did you get my invoice? is there anything you would like to change before I go.
That usually gets them to focus on your project as the fear of missing a deadline promotes a primeval subconcious fear in most people.
You could always say that dev time was however long and has now past. Add on a few days to this from today. Tell them that any ajustments outside of this time bracket will incurr additional dev time and therefore, additional fees. ;)
<edited for nonsense>
Id get paid for what youve done first before threatening to bump up the bill! :) Been burnt on that one before!
I was only kidding. :) But usually outside developers will give clients a timeframe for development and changes (say 6 weeks) and anything outside of this is billed seperately as extra. Its probably better to explain this to clients before the project starts rather than at the end though... ;)
<edited for more nonsense>
I've used the "play dumb" method and acted like the project was finished. Worked great for lighting a fire under them.
If, however, they've sent you some written communication regarding additional work, then you have a little bit of leverage. Written communications are usually dated and you can use it to gently indicate how long you've been patiently waiting to finish thier project - and get paid.
In either case,I'd suggest you give them a courtesy call and ask when you can expect to see the changes and kindly remind them that you've been waiting on them. If the changes are going to be more than 30 days out from your last invoice, then tell them you will invoice them for the project in it's entirety and offer to complete the changes when they get to them (make sure to quantify the changes).
Thanks, great ideas...After wading through hollow promise after hollow promise- the quickest way to get things moving along was to give them a week to get the changes (or they must be satisfied right?) to us or the invoice would be sent for the remainder.
I don't even think I hit send before I got the call;)
The big question is - did you get paid!?
Half of it. So, once the changes are made, the invoice for the remainder can be sent. I would never start a project without money up front.
>>Pushing along the project...finishing up and moving along<<
madcat... I hope I'm not distracting your thread with this. I have a slightly different version of the same problem...
I have several projects that were contracted for a flat fee where I've been paid in full... but the clients are just dragging their feet about finishing. On all of the projects, the attention spans of the decision makers are spread too thin.
This comes back to bite me because I'm constantly having to remind myself what the project was about. In one case, I'm dealing with a small ad agency and they're dealing with the client, and they're as frustrated as I am. I want to keep the ad agency as a client, and they want to keep their client as a client.
There's no way of getting more money... the area's still in big recession, and everybody's spread too thin, both in time and money.
What are some good techniques to get clients moving?
In many ways this is impractical advice, but I have found the best thing to do is find clients who are as dedicated to finishing the project off as you are. The ones who drag are a terrible waste of your resources, because doing nothing on a project is costly in so many ways.
We have found the best way around this problem is to have a very tight contract, which deals with all of these timing related problems.
i dislike tight contracts - they tie tbe developer and the client in knots. i think i've had just one client that has presented all the required information on time. i have a clause in my contracts specifying a completion deadline at which point the site will be posted online and the client gets the bill, whether the site is complete or not. it's worked ok so far. clients often wait months to give me the remaining content and then pay extra for me to add it.
(A) Put them in the same position you're in.
Subtract the half you weren't paid for from the half you were. The result is zero. Therefore, why should they be entitled to anything at all? Delete ALL work you've done.
Once THEY'RE upside down on the deal you'll be in a position to bargain. Until then you'll be hitch-hiking in the bushes.
With me, the first feeling I'm being played like a fiddle I'm gone. I learned long ago to go beyond the negative situations. They're one piece of gum I refuse to get stuck on.
(B) Deal only with those who value your work, forget the bums.
I'm friends with a fine art dealer in NYC. He claims it's easier to sell a $100K painting than one worth $50. His clients KNOW the value of the $100K painting. There is little selling involved. Then there are the bumpkins who know nothing about fine art who haggle for hours over the $50 piece of framed wallpaper.
(C) Look in the mirror.
Are you the "fine art" or the "framed wallpaper"? If you're the former, go find knowledgeable clients. If your the latter, continue dealing with the client you have.
Nell has some very good points.
I have had some pretty lousy experiences with clients over the past 10 years. My advise
1. as nell said dont take clients that dont appreciate the value of your work - they think you are ripping them off.
2. document document document. Write up a list of features, requests etc and make them sign off on everything. This way when they come to you with a new button, GIF, whatever - you can say ok that is not part of the original plan...all additional features need to be signed off on with a new time estimate.
3. take 30% up front. 40% upon first installment and 30% upon final review. i usually have trouble in the last 30 percent - here is where they like to do feature creep. Again the best way to prevent it is to show them the original specs. Also dont begin production until the design is completed and signed off on. tell them that design changes in production cost more.
I used to have this problem all the time, madcat. It was especially vexing for me because I usually work on large projects and have a full-time development team. When I don't get paid on time, I have to finance payroll. Gets tough after a few pay periods.
I switched to hourly billing with detailed time slips. No more flat rate pricing. We bill weekly for all hours expended that week. We do use a "not to exceed" budgetary figure, but that simply means that we will not exceed the budget without prior notice. We always try hard not to exceed the budget to meet client expectations, and we are almost always successful. The times when we don't are always due to change orders.
Managing change orders means having a detailed specification written up front, which is something very few web development companies do. We use the IEEE 830 specification for SRS (Software Requirements Specification). At first, it may seem difficult and time-consuming, but I assure you that it's the most essential ingredient of accurate estimating, implementation, and change order management.
We even go so far as to break all project into two phases: requirements analysis and design/implementation/testing.
We do the requirements before giving clients an estimate for phase II (implementation etc). We charge separately for it. Once we have a specification, we can give a very accurate detailed estimate. Clients really like that.
It may sound like a tough sell to get clients to pop for a SRS when few developers structure their engagements this way. I can tell you positively, that if you refine this technique you will be able to afford to walk away from any client who refuses to specify what they want you to build in advance. (it is common sense so pitched properly, it will disqualify any competitor who does not use this approach).
Clients almost always want some kind of budgetary figure up front. I strongly resist giving one, constantly looping back to the argument that any number given in advance of the spec is meaningless, why go forward with a chimera? Not to mention that almost any number you throw out will stick in their mind (and often their formal budget allocation) no matter how much the spec is changed.
Doing an SRS up front is SAFER for the client, as well as for you. Make sure they actually get this point. Repeat it in different ways as many times as necessary until they demonstrate that it has become part of their belief system. Again, it once it does, they will quickly disqualify competitors who give them fantasy estimates before they even have a thorough understanding of the task at hand.
For more information about SRSs and a chapter on why they are absolutely necessary, see Alan Davis's excellent "Software Requirements" ($40) and the IEEE web site (the SRS doc sells for about $90 I believe.) I also recommend Ed Yourdon's "Death March" and "Decline and fall of the American Programmer" and anything else Yourdon writes.
One final note in an over-long post (sorry).
I ALWAYS use PERT and GANTT project charts. Every time, even for a week long project. They are a beautiful tool to set the client's expectation and *get their commitment for "latest finish" dates*. A PERT chart shows each task, the resources assigned to it, the task duration and the latest finish and the dependencies between the tasks. (It can show a lot more if you choose). I always diagram in the client tasks.
Project charts are a tool that few really use (many talk about it or use them very poorly). Get expert at Critical-path project management and your trouble with clients delaying will be much reduced. They will really appreciate your professionalism.
Microsoft project is one of the most popular, there are many others available. If you're on a tight budget, buy a used copy (with manuals - you'll need them if this is your first go at CPM), it will still do everything that you need.
I've been a software developer for 16 years and I promise you, the techniques above have absolutely made the difference between the scenario you describe and getting paid in full and on time.
Your points are very valid and I've used them myself for larger projects. The operative words here are "larger projects." The problem that we are all dealing with is the fact that we must judge both amount and quality of documentation against the risk of needing it.
GANTT charts are great if you understand critical path projects and can explain them to your client but most businesses I work with haven't a clue. It's all smoke and mirrors to them. So I work to pin them down on the key pieces I must rely on from them in order to complete the job and set target dates for when I'll need them by.
And while I haven't tried it, I've been thinking about adding a clause that states if the client is more than X months beyond the date they agreed to have content to me, we will call the project over and bill them for the hours we have not been paid for to date regardless if it exceeds the lump-sum quote or not.
But I'm still thinking about it.
This probably wont help you in your current situation, but might help some of you later.
The most important thing is to remember that you are the Project Manager and that a project is a process, and you need to handle a project that way. It's your resonsibility.
Besides signing off the contract, you have to create a time table listing what needs to be done, who has the responsibility to do it, and when tasks, small or not, must be finished. This has to include *all* tasks, for instance if the ad agency is to deliver a logo to you, and your job is to put it on the web pages, that's two tasks - and they are both part of the same subprocess.
Equally important, when you agree with your client about the content of the site (number of pages), you need to create a webmap using Word (or something), and mail that webmap to the client. Then you may refer to the webmap later if there's a problem.
Third, as suggested, get the client to sign off during the process, or make it a habit to send the client a weekly mail, outlining what has been done, and what's left to be done. The burden then shifts to the client to let you know.
However, some clients initiate projects without even knowing what they really want. Projects will fail, that's just a part of the life.
|... or make it a habit to send the client a weekly mail, outlining what has been done, and what's left to be done. The burden then shifts to the client to let you know. |
Excellent point. Regular communications.
iconoclast - thanks for your detailed post : a great starting point for 2003.
|if the client is more than X months beyond the date they agreed to have content to me, we will call the project over and bill them for the hours we have not been paid for to date |
Nothing will get the materials to you quicker.
The great thing about project charts (especially PERT) is that once you come up with a good format, you can re-use the project chart very easily. Where it might take you 10-12 hours to do a two month, $30k project, it will only take you an hour or two to use that same chart for the next project. (how much does your development process vary from project to project?). That's why we use project charts even for one-week projects. How many week long projects have you done that turned into month-long projects because of client delays - usually due to lack of understanding or preparation or time budgeting for the things they have to do. Project charts take care of all of the good suggestions above about communication and documentation and managing the project. I did software development for 5 years without them, and now 11 years with them, and I can not imagine going back to any other format.
At very least, you're using a standard. Many clients will at least be familiar with the process from business school. Even if one person in the organization is, you'll get kudos, respect and support from that person for your professionalism.
I've never had trouble explaining how to interpret a PERT or GANTT chart - they are very simple to read. It's great when a client hangs yours on his wall as a constant reminder of his responsibilities to get you the content, review and sign-off you need to proceed with delivering your product on time for him.
Your post #16 above should go into the webmasterworld
hall of fame. Thanks for sharing; appreciate the
details and references.
You don't say how long you've been waiting for the information. A few days? Week? Month? Knowing that information would affect my answer.
Do you hae a contract with them?
Can you let the know that you expect the end date of their project to be "x", and if it goes further than that _____. (they'll be a rush or late fee, you might not be able to finish their project because of other committments, etc.
I'm working with one now who legitimatly has no time to get together what's needed. It's a total re-design with SEO being built in from the ground up, and there will be modifications as relevant information is added - whenever that arrives.
We've discussed it, and what I proposed to relieve the pressure and be able to get moving on it, which was agreed upon, is that we start with what's already on the site and work on the project in phases, doing regular monthly maintenance and adding to the product and service line and text as we go along.
There's a third down, and while ordinarily I'd wait for payment in full before uploading an optimized site, I'll most likely upload this one as soon as the second 1/3 installment is sent. The only thing that will be held out on for the final 1/3 of the initial payment is breaking out into the individual product display pages. That will be contracted out either for flat HTML pages or to be done with a database. Those will bring the specific, very targeted traffic, which is what the client wants, and will have to wait for the client anyway, because while I've got it down just fine for the primary keyword phrases, I don't have a clue what all that stuff is. This was easier than most to figure out.
This is unusual, because there's a high level of trust on my part for the client's integrity. The company will go on as copyright owner right off.
I've found over time that there are different issues that come up with straight optimization or consulting with others' sites and when design & optimization are combined. There do have to be time caps built in, but with design there can be a cut-off limit and anything beyond can go onto maintenance.
Not so with SEO, and that's something I'm trying to get straight with some new policies for the coming year to re-do agreement stipulations and make it clearer. It's not a tangible where they can look at the HTML on a page that's done per page or hourly; consulting is a different matter altogether, and there's a different level of control over what's implemented.
Text is text either way. But a page can go up with just products, without text, while you can't optimize and edit text without there being some. We ourselves need to know when to call it quits - and a nice way to let it be known that we're not partners for life, which some assume.
Sheesh, even kids get a monthly allowance, their parents don't give them ten bucks for life. What's the value of "chores" like taking the trash out? Let it sit for a week collecting fruit flies and we'll find out just how much value it has.
A developer by the name of Steve McConnell did a talk on the pitfalls of project management a couple of years ago which supports Davis and Yourdon's recommendations.
Dr. Dobbs' TechNetCast has a copy at
Technet is great to know about in any case, some of the greatest minds in software development give talks on everything from high-level process to detailed code. Highly recommended.