#drupalplanet

By Farez Rahman

How many agencies or freelancers have you come across that can inspire us with their work. How many times have you looked at one of their websites and thought, "That's who I want to work for/with".

In my experience: rarely.

It's not that most people don't or can't produce great work. It's because there is lack of investment in one essential element: communication

You may have built the most amazing site/app/vehicle/insert-amazing-product-here, but if you don't communicate it, nobody will know.

And if you want it to stand out, tell a story. 

Some people put their "achievements" in a CV/resume. Some create a website telling people what they've done. Some create a portfolio of work.

The inspirational ones... they do this:

Which would you rather spend time on... writing your boring CV, or communicating your work.

Tell a story.

By Farez Rahman

"So how much will this project cost and how long will it take?"

The million dollar question every freelancer and agency faces. Nothing moves before the client gets a satisfactory answer to this question, and signs it off.

Estimating projects is one of hardest thing to get right. And there are no shortcuts - experience is still the only reliable teacher. 

With all our best efforts to create a tight spec, project scope and estimate, there will always be "grey areas" where whether something is within scope or not can be argued either way. I like to call this the "twilight zone" are of the scope - where time just don't follow normal rules of reality!

Below are some from my own experiences as a freelancer and owner of a web development agency. Anticipating them and agreeing up front with the client on how to cost them, and whether they constitute billable work, will help reduce these grey areas. 

Some of them are relevant only if you're building your product on open source code built by a community of developers (I use Drupal extensively, so the examples below was from my experiences building websites with Drupal). 

1. Site administration training

Once you hand over the product, lets say a website, you will need to train the client on how to use it. The user-facing side of it should be familiar already to the client because they would have seen the designs and functional spec. The gotcha here is in the admin side - the tools they will need to manage the website and its content.

You would normally have a bit of training set aside for this, but will you be covering every single admin situation in your training? Most likely no.

So if the client emails you a week later and asks you to show you how to do something, is that considered billable time?

Or if you don't provide an admin manual, and they forget the training you provided, and call you at 8pm about an urgent content change, which they've forgotten how to do, is it your problem? Should you assist them? Is that billable support time?

Thankfully we had a post-launch support arrangement in place, so we just used that budgeted time to handle this.

Suggestion: Outline in detail what your handover training will cover, and state that anything outside of that training scope will be either billable time.

2. Technical handover

Recently my team and I completed a project and handed it over to a client that has in-house IT personnel that will be responsible for maintaining the site.

It turned out that they then required some admin features that can be easily implemented using ons of the site-building modules the site uses (this was a Drupal site and the module is Views). We ended up training the client on how to that module. This was the equivalent of providing a half-day training which some training companies charge hundred of Pounds for.

Training the client in using developer modules was not "in scope" but doing what we can to help them maintain the site themselves was. We were just not aware how deep the technical knowledge was required on the client side. A clearer support scope would have made this easier to deal with.

Suggestion: Make it clear in your project scope what a handover entails. You could simply set aside and agree a few hours of billable for "unforeseen training requests".

3. Bugs in the community code

During a project, we encountered a really frustrating bug. It was frustrating because we simply could not find anything in our custom code that was causing it. 

In the end it turned out that the bug exists within the open source software's community core code. In this case it was in a Drupal module.

We spent a lot of time checking our code, checking the downloaded Drupal module code, checking the issue tickets on drupal.org, and managing communication with the client. All in all about 2-3 days worth of our time. 

Suggestion: Just be aware that this happens, and set aside a buffer for it in your timeline.

4. Fixing the bug

Once a "community code" bug like in the example above was encountered, is it clear in the project whose responsibility it us to support the fixing of that bug?

If you're responsible for delivering a working product, the client has a right to demand that you fix all bugs, including those not in your own custom code. This could be a huge cost on you, because the process of fixing bugs and submitting a patch in open source software not only involves fixing the code, but discussions with others who use the module and working with the module's maintainer to get the patch in. 

Our client understood open source software so they were happy to sponsor the bug fix, which we will contribute back into the community.

Another option would have been a workaround to the bug, which may involve some spec or UX changes. Does your project terms cover these potential scenarios?

Suggestion: For open source projects, I would highly recommend that fixing community code be something the client support. They are the beneficiaries of thousands of hours contributed by the community so its only right that they also contribute to its development. Make it clear in your client agreement about this.

5. "Quick changes"

Ah, yes, those "quick changes" a.k.a. "easy fixes" a.k.a. "small thing". A.k.a. "free work". Clients like asking for these.

But programmers are also at fault. We tend to underestimate the effort required for tasks.

These little things add up, and as a result both developer and client get frustrated because the developer starts realising how much he has underestimated the work by and he's not getting paid for the additional time, and the client starts wondering what's taking him so long.

Every request cost more time than we usually think. Each one of them takes time to scope, sign off, work on, QA, tweak, test, deploy, train, track (for billing), and invoice.

Suggestion: I found that the best way to deal with "small requests" is to batch them. I try to batch them into roughly a 2 or 3 days' worth of work (at initial ballpark estimate) before start scoping and quoting for the work.

A note on billable time: it really is up to you how you treat these unexpected work. You may bill for it or you may just do it for "free" out of goodwill, if it's a client you'd like to keep a good relationship with. You you opt for the latter, do make sure they know what you're doing for them and the work it involves - it's up to you to demonstrate that you're giving them something of real value for "free".

What about you? Have you encountered any "twilight zone" requests in your projects? How did you deal with them? I'd love to hear form you.

By Farez Rahman

Winning freelance work can be a hit and miss affair. It really is case of winning some and losing some; hopefully more winning than losing as your freelancing career progresses.

One factor that will increase your win rate is the “chemistry” you have with the client, and the only way to make chemistry happen is to find the right kind of client and project. This will allow you to be excited about the project and fall in love with the client.

Let me give you an example from our latest website client project, an organisation in the film industry. Who doesn’t love films? Especially one that produces world famous names. We are huge fans, and this really got our juices flowing!

Despite being twice more expensive than our nearest competitor, we won the pitch. How? In the client’s own words, because they “fell in love with us”.

Heres’s why:

We were genuinely excited about the project, and it showed. Our initial meeting was 4 hours long and that time just flew by. There was no doubt in their mind that if they hired us, we’d be giving the project 110%. Simply because we love everything about it.

We understood the client because we made a huge effort to. We went to meet them at their premises, spent hours understanding their needs, took a tour of their building, met their staff and spoke to them, and tried to absorb the “vibe” in the organisation so that we can understand how to translate that into the website design and branding. We stepped into the client’s shoes and tried to “get” them. All before sending them our proposal.

We wanted to be in their “gang”. We genuinely saw ourselves as part of the team, rather than “hired guns”, and that created an atmosphere of collaboration rather than one of client and supplier. We bounced off ideas from even before we won the project, and every meeting has been inspirational.

The only reason all that happened was because we liked the client and we loved the project. 

Don't get me wrong, the project had it's own share of difficulties (what project doesn't?!), but the fact we were all committed and had open communication throughout, meant we were able to get on top of these and produce a really nice piece of work.

Clients love hiring people who are enthusiastic about them and their work, and you can’t fake it, so pick clients/projects you want to work with. 

So, think about who you’d like to work with and the type of project you want to work on, and then go find them! It makes winning projects so much easier.

I’d love to hear what your ideal client or project is below! Or if you have an OnSavvy developer profile, I recommend describing them there too (post a link to your profile in the comment so we can see it).

By the way, OnSavvy is dedicated to specialists and freelancers who love what they do, and want to shape their career by being picky about the projects they take on, and immerse themselves wholeheartedly in a way that enhances the end result. Come join us.

Do you have any other tips for winning freelance work? Or are you struggling with winning pitches? Why not share in the comments area below, or you can tweet me at @farez.

By Farez Rahman

Freelancing is a very satisfactory way of earning a living. The money can be quite good, and the freedom you get is priceless. In a time where job security is an oxymoron, freelancing is sometimes the only avenue, even if temporarily. For most freelancers, the primary concern is uncertainty of the income stream. You are not being paid a regular income each month. Instead, you need to go out and look for work, and sometimes things may be dry for a few weeks, which can be very stressful. If this is where you are at the moment, don't worry, you're not alone. I've been there several times! In this post I'll show you how to increase visibility for yourself and increase your chances of being hired. It's not an exhaustive list for sure - advice is aplenty online - but here are some that I've known to be quite effective. Find a niche One of the surest ways to blend into the greyness of obscurity is to be just like everyone else. Instead, branding yourself as a specialist in one skill or industry will help work find you. For example, when I changed from being just a run-off-the-mill web developer to calling myself a "Drupal specialist", I started getting a consistent stream of enquiries. Until now, I've never had to respond to job ads nor pay to advertise my consultancy. Pick a niche where the demand for good talent is growing. Your mailbox isn't going to start filling up by being a COBOL specialist. Create a presence You need to be visible before people can find you. This means having a website or a profile online that has your name, contact details and all the info relevant to your skills. Here's what you need to have on your website, as a minimum:

Your name or business name

Contact details

Address or location(*)

Short description of what skills you are selling (try not to go crazy here... niche, remember?)

A portfolio of previous work, including any personal projects

Links to all your social media profiles

Use a bit of SEO savvy to make sure your website gets a chance to be discovered on search engines (*)I am a huge supporter of working remotely and hiring offshore, but the majority of employers would still prefer to hire locally. Having your location down will make it easier for these employers to find you. Speak up Well, even with the best website in the world, nobody is going to know about you unless you show the world that you exist. You could spray paint your name all across town, but that would attract the wrong sort of enquiry. So how do you get noticed? Here are some things that have been known to work:

Help people. Wherever you can. For example, helping other developers in chatrooms or forums (e.g., Quora). Or responding to public tweets or Facebook posts asking for assistance. Or commenting on blog posts.

Start a blog and post regularly. Post content that is relevant to your niche, not just random stuff. Do some research on SEO and how relevant content helps your site ranking.

Give away useful stuff that people will want to share, like tutorials, templates, ideas, code… anything that will be helpful to others in their work, or help them learn something new.

List yourself on relevant, reputable, directories. You may have to pay a bit of money, but it can be worth it. For example, our Acquia partner page contributed to new enquiries and business in our Drupal niche.

Get involved Gone are the days of the solitary programmer sitting in a cubicle coding away in isolation. Ok, maybe the cubicle bit still exists, but almost all digital work now are social. Open source software is created collaboratively and knowledge is shared on best practices. Even proprietary technology have communities of users and developers that collaborate to contribute and share. By getting in involved, you not only help nurture and grow the community you're in, but you're also making yourself visible and heard, which could lead to referrals. Employers whom I have spoke to increasingly cite involvement in the community as an important indicator of the your passion and interest in your field. Try collaborating in an open source project or volunteering at events or conferences. If there isn't an event in your area, create one! Demonstrate knowledge and ability Unless you're applying for a job that involves training at the start of the contract, you will need to hit the ground running. Employers need to know that there's zero ramp-up time from hiring to you getting into full flow. This is why demonstrating that knowledge and skill is important. You can do this by…

Having a portfolio of work - this is the first thing employers will look at. Unless you're just an illustrator or designer, don't just post images. Describe the work you did, your role in it, and how you made a difference. If you don't have any previous relevant work, build something yourself.

Give talks, however small. Talks give you visibility and shows potential employers that you not only have the knowledge, but know how to communicate it. Valuable stuff.

Collect testimonials. Confirmation from past clients and peers that you are a good egg carries a lot of weight.

(This is an adapted repost from Redkey's blog, which we feel is absolutely relevant and timely for Savvy).

Finding good Drupal talent is a challenge. In fact, it's a real pain in the arse. The fact is (says Dries Buytaert, creator of Drupal):

"The demand for Drupal experts continues to be much larger than the supply"

Lots of businesses (like The Economist, and NBC Universal) have invested deeply into Drupal as the primary technology to power their online services. The shortage of Drupal talent is bad news because:

It makes finding Drupal skills costly, time consuming and sometimes just plain impossible.

Bugs in the Drupal core (the code that is at the heart of Drupal) and contributed modules (the code that the Drupal developer community makes public and free) don't get fixed, for a long time, because there just are not enough developers or developer time to work on them.

It drives up Drupal developer rates, and consequently, the price that Drupal agencies charge. If this gets inflated too much, it will kill the Drupal ecosystem.

It becomes hunting ground for cowboy recruitment agents that just want to make a quick buck, hiring out poor skills disguised as experience, and leaving a bad taste in the mouths of those that used them. By association, it creates a bad experience on Drupal's name. 

So if you need to hire, and can't find the right people, what do you do?

Here are your alternatives: training and mentoring.

Nothing new there, in general. Most industries do this. But I'm surprised there isn't more of this going on within the Drupal community. That's how it looks from where I'm sitting anyway... do correct me if I'm wrong.

Training

If you have in-house PHP developers already, train them. If not, hire PHP developers and train them. PHP developers are less difficult to find than Drupal developers. (And why PHP? Because Drupal is built with the PHP programming language).

How to train? If you are in the UK or US, you have some obvious choices for training companies, like Lullabot or Brightlemon. (If you are a Drupal training provider, please feel free to add yourself to the comment section below). 

If there isn't a training company or trainer near you, go online. Buildamodule.com do Drupal training videos. I think Lullabot does too. Drupal Dojo is a also a good source of free videos. See also the Drupal Open Learning Initiative.

What are the benefits?

You will get yourself your own Drupal developer! 

If you are training an in-house PHP developer, s/he will be able to pick up Drupal skills that are directly relevant to your projects. 

Help grow the global Drupal talent pool. You will be benefitting, or have already benefitted, from the open source nature of Drupal, from the countless hours of developer time that the Drupal community has contributed, for free. This is your chance to give something back and support it.

Bonus: If you are creating an in-house training programme, it's an opportunity to package it for general consumption and resell.

Mentoring

Alternatively (or even in addition to training), you could hire an experienced Drupal developer on a freelance, part-time or on-demand basis to guide your in-house developers to be proficient in Drupal. 

Mentoring is great because most of the time your developers will be able to learn or research solutions themselves. However, Drupal is a complex system and there is a steep learning curve to doing anything new in Drupal. Having access to someone who has done it before will save a lot of time.

To a certain extent, Drupal developers are already doing this in discussions on drupal.org and on IRC drupal-specific chatrooms, but this is unreliable if you need immediate access to help. Most developers are busy (there's a shortage, remember?), so it's not always possible to find someone in the chatroom who is free. Furthermore, there's a timezone issue if you're relying on real-time chat.

So how do you find a mentor? Some options to get you started are listed below. Again, if you are a mentor or know of resources for mentors, do post in the comments section.

Post an ad on drupal.org jobs section or the specific city/country Drupal groups.

Look for Drupal professionals on Savvy, the dedicated Drupal professionals profile site.

Buildamodule just started a list of mentors so you can look there. 

Try the groups on Drupalkata.

Network. Go out and meet Drupal developers. Easiest way to do this is to find a local Drupal meetup. Here's one for London, for example.

Options

So, in short, you have options. And remember that this is not only relevant for Drupal developers. You can do this for your developers, themers, designers, project managers, and content managers. 

So some options to consider if you are..

An employer: 

Consider training existing in-house PHP skills, if you have any.

Hire PHP developers and train them.

Hire part-time or on-demand mentors.

A recruitment agent:

Consider providing training programmes (and stop only thinking of selling meat)

Find and offer freelance mentors

An experienced Drupal developer:

Make yourself available as a mentor and spread the word

Consider providing training

Create training videos

An aspiring Drupal developer:

Find an experienced Drupal developer and ask if they can be your mentor. Maybe trade their time for yours.

Offer yourself as an apprentice to experienced Drupal developers.

Learn Drupal yourself. It can be a headache at first, but it's not rocket science. There are lots of videos and articles online. And get yourself on IRC.

Get involved with writing themes and modules and contribute them to the Drupal community. It's a great way to learn and gain confidence in your Drupal skills. And it will make you visible to people looking for Drupal talent.

A Drupal training company: