This guest post is by Neil Matthews of wpdude.com.
The majority of work to run a WordPress blog can be done by non-technical people, but about 20% of the work requires in-depth knowledge of the technology that sits underneath the hood of a WordPress site. This is when many blog owners call in technical support from developers.
There is a good chance that you have never hired someone to provide technical support for your blog, so this post is designed to give you pointers to successfully work with technical contractors when the time comes.
Set a project specification
The specification you pass to your contractors can make or break the project. Here are some pointers to help you create a foolproof spec.
Be thorough
The spec needs to be detailed enough so that your contractors can translate your requests into technical action items. This is often overwhelming for people who are trying to convey technical information, but don’t have the technical vocabulary to do it.
The good news is that you don’t need to get technical if you are working with a good team. They should have enough experience to translate your request into geek and fix your problems.
The simplest way to start is to break down your project into manageable chunks and list them, with a brief description for each.
Sometimes I receive one-line vague requests or imperious demands to “call me” as a specification. That is always a red flag to me. If a potential client can’t spell out their requirements, it usually means they are going to be difficult to work with. Keep your techies happy by spelling out your needs thoroughly.
Use screen grabs or screencasts
I recommend adding screen dumps and screen casts to your specification, it helps to stop a lot of misunderstandings. A great free tool for this is Jing, which allows you to grab areas of your screen to send to your contactor as a link, or even record quick videos of your screen to point out exactly what you need.
Some of the best project specifications I have received are two- or three-minute screen casts of the problem my client wants fixed.
Point to examples
If you want something for your site that you have seen on someone else’s blog, send a link.
Your technician should be able to reverse-engineer how that feature was implemented and suggest a plugin or other solution to give you the same results.
Ask for confirmation they understand your spec
Ask your contractor to confirm that they understand your specification and for them to explain what they will do in technical terms to meet your requirements.
This is particularly important if you are outsourcing to countries where the native language is different from your own.
Use their expertise
If you are not sure how something can be done (or if it it technically possible) spell out what you want and ask if it can be done. Your developer should be able to make a recommendation and give you a price.
Get fixed-price quotes
If you are new to outsourcing technical work, get a fixed-price quote rather than by-the-hour work. This will prevent any unpleasant shocks at the cost of your project.
There are unscrupulous techies out there who will run the clock up on people who don’t understand the technicalities of development. The solution is a fixed price project. Don’t pay for everything up-front (but expect to pay a deposit), and only pay the balance upon completion to your satisfaction.
Also look for some sort of guarantee. If the techie can’t fix your issue, expect a no-fix, no-fee guarantee. It is for them to decide if a project is feasible; sometimes it cannot be fixed and your money should be refunded.
Information you need to supply
There are certain credentials and other information that you will need to pass to your contactor so they can work on your site.
Admin-level login
Your developers will need an admin-level user id and password so they can get access to your site to make any changes.
I recommend to my clients that they create a new user ID for the duration of the project and pass that to me and my team, rather than giving out their own admin user ID. Then they can delete this login ID once the project is complete.
Control panel hosting login
If your contactor needs to work on the database or backend items such as the DNS setup of your system, they will need to have access to your backend database and hosting account.
Again, I recommend creating a new user ID for the duration of the project. Check out your hosting setup: some companies like Godaddy or Dreamhost allow delegation of the control panel to other users so you don’t need to create a new ID.
If you have to pass over your hosting credentials, change the password during the project and swap it back once the contactor is done.
FTP details
If your contractor needs to upload any files to your site, they will need to have FTP credentials. Most hosting control panels have an area where you can create a new FTP user.
Create a specific user for your developers, don’t pass over your main FTP credentials.
Security
I’ve talked a lot about temporary passwords, so let’s talk about broader security issues.
I’m not suggesting technical people are nefarious by nature and will try to hack your site once your back is turned, but if you passwords start to be passed around and shared with contractors, the chance they might be compromised increases.
Ask your contractor to delete all references to passwords from their inbox. We do this as a matter of course, but many people simply archive details in their inboxes.
If you are concerned about this, check out Lastpass.com. This service keeps your password safe while allowing you to share them with contractors.
Managing expectations
If you’ve never hired someone to do technical work for you, then you will have no idea what kind of communication to expect. It’s a good idea to spell out to your contractor what kind of communication you would like, to keep you in the loop.
Managing that expectation can help to alleviate the stress of outsourcing technical work. Often it seems the contractor has disappeared into a black hole and no progress is being made. This is probably not true—they may be working on a development version of your site, or the work may be invisible to you.
There’s nothing wrong with asking your contractor to report in at the end of each day with a progress report on what they have achieved and what still needs to be done.
If you’re outsourcing across time zones, more communication is vital. I’m based in the UK and most of my clients are from the US, so I find being open and communicative about time zones and when I’m ending for the day is very helpful.
What not to do
If you want the relationship with your technical team to work, there are a couple of things you should avoid:
Avoid scope creep
Write your specification correctly from the beginning of the project. If you forget something and try to slip it in mid-project, you might get push back from your contractor.
It’s a common tactic by some shady characters to add items mid way through a project to try and get them done for free. I’m sure you are not one of those people, so include them in the spec at the project’s beginning. If you forget it, ask your contractor to update the original quote.
Don’t micro-manage
Hand over the project and relax a little. Micro-managing your contractors and monitoring every aspect of their work is a pain in the behind for you and for them.
You are paying professionals to do a job, so don’t give yourself more work managing them. They don’t need hand-holding—let them do what you paid them to do.
Don’t double-guess project time and costs
Nothing annoys a techie more than someone saying “I’m sure this will only take you 30 minutes since you are the expert.” You should expect to pay for their expertise, not their time.
If you are worried about run-away costs, ask for a fixed price quotation.
Make the daunting manageable
Outsourcing technical work can be daunting the first time you do it. Trying to work with someone babbling in octal when you want to achieve blogging business results can be tough.
Get the spec right from the beginning and be prepared to pass over control to the technical team. It can save you a lot of headaches, and help you get the best job for your money.
This is a guest post by Neil Matthews, owner of wpdude.com, a WordPress technical support firm.
Maybe this would be a good follow-up piece — I’d like a few words of wisdom on doing a project alongside a contractor. I actually had a good experience with this when I was switching the site over to Genesis — I had some of the technical expertise but not all of it, and by working at the same time, we got the switch (and “fixing problems” that had existed in the previous theme) done a lot faster — and at a price I could afford, while I also learned from the contractor about features of the new theme. But I’m guessing that many contractors would not have been as open to working with someone — or perhaps have worked as seamlessly.
Have you done anything like this? Any thoughts?
Hi Carolyn
I often work with people who want to not only have technical items fixed, but want to learn how to do it themselves moving forward. So what I do is factor in some coaching time where I can do a screen share with skype and show the client how I fixed their issue.
If timezones are an issue I sometimes record the coching session using camtasia. and send that.
It may add a little to the project costs, but it stops you being reliant on the contactors moving forward
I agree that WP is much more than a blog platform. I have use it almost exclusively for new websites I build since it is so easy and flexible. To make it more powerful and custom function, I often outsource an Technical
You are right we have to be so cautious while outsourcing our work because giving login details of your project means you are giving the key of your warehouse to someone stranger. Therefore every precautionary measures should be adopted while transferring such details to techies who already are smart enough to do whatever they want if we select someone problematic.
Mi Muba
If you have any concerns with your technical team, go with lastpass
beautiful
Sounds like a good description of how to deal with any IT project… the people I work from right now (completely unrelated to my blog) could do with reading this :-)