Hey all. This is a repost of my blog at
http://blog.onsavvy.com/post/52578909727/5-gotchas-in-open-source-projec...
I'm still climbing up the ladder of estimation proficiency so I'd really learn from you guys! Here are some of my experiences and thoughts - what do you think?
=======================
“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).
- 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.
- 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”.
- 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.
- 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.
- “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.
PS. I highly recommend these posts on Quora and CodingHorror too:
Why are software development task estimations regularly off by a factor of 2-3?: http://www.quora.com/Engineering-Management/Why-are-software-development...
How Long Would It Take if Everything Went Wrong?
http://www.codinghorror.com/blog/2006/06/how-long-would-it-take-if-every...