Would you come down on price for a long term relationship?

Details

Posted: December 08, 2010

You've just moved to a new city or town, and your car needs an oil change. Since you just moved, you also need to find a new mechanic for your car.

You look online or in the yellow pages, and you identify a mechanic. You drive over, and ask the mechanic how much an oil change for your car would be. You also ask if the mechanic has done oil changes before, and if you can talk to anyone who's had their car serviced by this mechanic.

The mechanic says they've changed the oil on hundreds of cars just like yours. There's a waiting room full of people having their oil changed, and you are welcome to talk to any of them, or you can talk to a few people here on this list. The mechanic has various certifications hanging on the wall for all kinds of oil change training he's received.

Finally, the mechanic says the oil change is $40.

"$40!" you respond. "Wow, that's a bit more than I was hoping to pay for an oil change. You know, I want a long term relationship with a mechanic who I can trust to take care of my car. I don't really know you or your abilities, so how about this -- how about I pay $25 for this oil change instead. We'll see what happens from there. If you do a good job, then I'll have more work for you."

"Well," responds the mechanic, "I've done this kind of work for many years now. I know how long it takes to change the oil on a car. $40 is the price point where I am still making a little money, but it's also a fair price for you, since you are paying just a little extra for my expertise. You know I will do a good job because I have lots of experience in changing oil, and you won't get stranded because I forgot to put in the oil plug. By the way, I see your taillight is also out. We'll charge you for the lightbulb, but we'll throw in the labor for free."

I'm actually stretching a bit here. The mechanic actually looks at you and says, "Who the hell do you think you are? An oil change is $40 and I have an opening at 1 PM. Do you want it or not?" (And that taillight? They charge you $50 to change it, because you annoyed them by asking for a discount.)

Would you ever ask a mechanic you've never met before to give you a discount on your car's work because you don't know the mechanic? Or would you ask them to discount the rate so you can establish a long term relationship?

Chances are, the answer is no way. You get a recommendation for a mechanic, and you pay what they charge. You don't negotiate the price. As you know, good mechanics are worth their weight in gold. You develop your relationship with your mechanic by showing up to your appointment on time, paying the price of the repair promptly, and occasionally showing up with a plate of chocolate chip cookies. (Or so Tom and Ray say.)

So why is it different with web development?

Why is it that clients ask for you to discount your price to establish a "long term relationship"?

And why is it that you do it?

Do you need a client who is going to ask you to come down on price every single time they ask for a change made to the website? They asked you to come down on price the first time, and you did. Why wouldn't they ask a second time or a tenth time?

The way a long-term relationship with a web developer is formed is the same way a long term relationship with anyone is formed.

• Ask the web developer for a quote, for credentials, for examples of previous work, for references. These are all absolutely fair questions, and a reasonable developer is very willing to provide these.
• Don't talk the web developer down on price. You are welcome to ask for a breakdown in cost if one is not provided (i.e. X hours for design, Y hours for installation, etc). Shop around if you wish, but remember that web development is NOT a commodity. Working with the right person makes all the difference between a smooth project and one that's much more difficult.
• Work with the developer and see how the process goes.
• Did it go well? Great! Hire them again or provide some references.
• The web developer will likely do some little things for you. For example, they might make a tweak or two to your website, they might give you some on the phone training, answer a few questions -- all at no additional charge. If things go smoothly in the original project, they may throw in little things for you anyway.
• You do little things for the web developer. Provide a testimonial and allow the developer to put the site in their portfolio. Don't wait to be asked! Volunteer this information. Send a holiday card. Send chocolate chip cookies. 

Sound familiar? Yes, because you know how long term relationships are formed with friends, spouses, mechanics, teachers, bus drivers, and so forth. Why are web developers any different?

Joomla 1.6 ACL Explained

Details

Posted: December 02, 2010

Well, maybe explained is a strong term. But I do the best I can.

For my talk at Joomla Day NYC, here are my slides (PDF).

The two exercises will be based on my articles at community.joomla.org:

• Setting access levels to control who can read which content
• Setting permissions to control who can create/edit/delete content

The new 40/40/20 rule

Details

Posted: November 23, 2010

Yesterday, once again, I had the pleasure of being interviewed for the JoomStew podcast. This show was covering aspects of running your own Joomla business, including getting work, writing contracts, payment, and so forth.

One of the items discussed was how one collects payment for the job, particularly if you've bid a fixed price job.

Most developers will bid 50% upfront and 50% on launch. This is a time-honored tradition, if such a thing exists in a field as young as ours. The client gives you a check for 50% of the work before it starts. Then, typically as a condition of site launch, the client gives you the remaining 50%.

Positives? Everyone does this. You get some payment at the beginning, so you have funds to pay for any collaborators on the project (graphic designers, programmers, content writers, etc). The client feels they have control over you, because they won't give you the rest of the money, possibly a significant chunk, before the site launches. And you're happy, because you won't launch the site without the rest of the money.

However, there are significant negatives to this as well.

Any developer with a year's experience working with clients knows that the #1 delay on developing any website is the content. That includes images for the site, written content, logos, movies, and so forth. For smaller sites, typically the client provides the content.

At the beginning of the project, this is not such a huge deal. The client gives you money up front, and you're waiting to start the project. If they never deliver anything, perhaps you never start. (We have clients like this, who gave us money long ago but have not followed up with content, despite our pleadings.)

However, what happens when the client refuses to launch the site, because it's not "perfect", or they don't have exactly the right photos on each page, or they're missing this or that piece of content?

You built the site out, you've paid your sub-contractors, everything is tested and done and ready for launch. Now you're waiting for your own paycheck... but the client isn't finishing their part of the site, or they're refusing to pull the trigger for whatever reason. You've tied that final 50% payment to the site launch, and now that launch isn't happening.

When you run a company with employees who rely on a regular paycheck (and hey, that might even be you!), this can be particularly disastrous. You expect a payment to arrive around a certain time to make the payroll, but yet, the client hasn't sent that money.

This happened to us this summer, with four fairly good-sized jobs. We had weeks of payroll in accounts receivable, and not much in the bank.

As a result, we changed the way we ask for payment.

• We ask for 40% upfront. This gives us that budget to pay freelance help as required, purchase extensions, and put some to payroll.
• We bill 40% at the midpoint of the project, and we tie it to a date. On that date, the invoice is sent, whether or not the project has moved at all. The invoice is labeled "due on receipt", which means it's due immediately. (We have found that when an invoice is labeled "net 30", we get payment in 2 months. If we label it "due on receipt", we get payment in a month.)
• We bill 20% at launch, and we tie that to a date as well. The client still feels they have some leverage, because they haven't given us all of the money. However, we've collected most of it, which is great in case the launch moves out further.

We know that projects don't move because clients are not providing information we require to get the site completed. In general, delays do not happen on our end. If they do happen, we certainly would move these contract dates as required. 

We've applied these terms to two contracts at this point, and both are moving smoothly. No one complained about the new terms, and we're collecting payment, meaning payroll is much more manageable. What's more, our project management has improved, since we are working towards a more tangible launch date -- the date we put in our contract, not something we guess at, then re-negotiate as the site comes together.

I recommend trying this methodology for working with your clients as well!

The Importance of Planning Joomla Sites for Client Maintenance

Details

Posted: November 16, 2010

The phone rang at 8:45 PM. "Help!" the client said. "We just sent an email out to 18,000 people and the slideshow on the home page doesn't work. Please fix it ASAP! This is an emergency!"

This is a relatively new client, one with whom we just started working in the last 2 weeks, and they have an existing Joomla website. They asked us to add a few things here and there, but we had never touched the slideshow on the home page. We weren't even sure how it was put together -- we simply hadn't had the time to look.

Having poked around the back end of the site, as well as looking at HTML and the front-end layout, we realized the slideshow on the home page was built using Flash. The slideshow was a SWF file. It was nothing special -- just a fade-in, fade-out series of images that could be clicked to go to the relevant pages.

There are 64 image rotator extensions listed on the Joomla Extensions Directory. These extensions take images and fade them in and out, flip them around a carousel, spin photos down the drain -- every possible treatment for photos imaginable, every "just because you can, doesn't mean you should" moment encapsulated in an extension!

Yet this client had to purchase a Flash banner creation tool, put the photos in that and set up links to the website, output the SWF, upload it to the Joomla site, then change an article so the current SWF was set to play. Really? It was a simple fade in - fade out slideshow. Most of those 64 image rotator extensions do just that as a starting point.

Using tools like this Flash banner creation tool means that only one person can update the slideshow. Only one person has the software, and that person was out for the evening.

FrontPageSlideShow, our favorite image rotator extension, accomplishes the same effect. Upload the images you wish to rotate via a quick and easy interface that automatically places the images in the right directory, then specify the page to which you wish to link. Take slides out of rotation by unpublishing them individually. Change links anytime you wish via a simple browseable interface. There's nothing to recompile, no new output files to create and upload, and anyone with a back end login can modify the slideshow quickly and easily. What's more, the changes take effect immediately.

The client, of course, was upset that the slideshow was broken, and of course, they wanted it fixed immediately. Since we could not reach the person who created the slideshow, we replaced the SWF with a single non-rotating image to hold them overnight. The image was the most important slide in the rotation, featuring the event they just emailed to everyone. This morning, we're replacing the SWF with FrontPageSlideShow, so if this ever happens again, there are plenty of people who can fix the problem quickly and easily. What's more, the client can keep this up to date, anytime they want, by whomever has the back end login.

The moral of the story? When choosing functionalities for your Joomla website, you need to think bigger than "I need something to make pictures rotate". Your criteria for any piece of functionality should be:

• The functionality is what's required to fill the client's needs,
• With the simplest, easiest interface possible, so
• That anyone can use their back-end Joomla login and access, so
• If it breaks in the middle of the night, anyone can fix it, AND
• So the client can easily update it with the latest information, without a thick manual or years of web design experience.

When functionality is easy to use and update, the client credits Joomla. When the functionality is difficult, unreliable, or buggy, the client also blames Joomla -- even if it's a 3rd party add on feature that may have nothing to do with Joomla at all.

Have you heard of Joomla? Joomla Rocks!

Details

Posted: November 12, 2010

Have you heard of Joomla?

Samara Iodice, my fabulous lynda.com training producer, and I had a little time after my most recent lynda.com production trip. We moved around the lynda.com office, asking who had heard of Joomla, what is was, and what they thought of it.

Coincidentally, Ken Crowder was also there, which made for some extra fun.

The cast, in order of appearance:

• Samara Iodice and Curt Frye (author)
• Brian Ruiz
• Ken Crowder (author) and Jen Kramer (author)
• Andy Ta
• Fatima Anes
• (not sure)
• Tanya Staples and Garrick Chow
• Max Smith
• James Williamson (author)
• Tom, Ken's producer, with Ken, Jen, and Samara
• Nick Passick