Yesterday I wrote about charging for projects and doing it on a project-basis rather than hourly. I knew I’d get a reaction, and I did. Thankfully, everyone was really positive and raised good reasons why they preferred a hybrid model. Almost all the feedback circled around one particular trap that pushed people away from project-based quotes. Today I’d like to walk thru three strategies I use to make sure I never lose my shirt – which was the core of the reasons why people appreciated a hybrid model (even though those would be susceptible to all the issues I raised in my article).
Let’s imagine a scenario together
So to enable us to have more of a dialogue around pricing and quotes, I think it helps to ground our theoretical discussions with a practical (and hopefully typical) example that we can all refer to. Assume that this isn’t your bread and butter work, ok?
The Big, Complex & Unknown Project
Imagine that a company is asking you to bid on a project that they predict could months or even a year. Right off the bat this sounds larger than many of the projects you may have worked on in the past. But length doesn’t mean complex, so you pay close attention and listen for details.
What the client wants is a membership site that lets different “teachers” sign up and create their own courses. They want each teacher to have landing pages where they can direct traffic and collect sign-ups of their students. They want others to be able to send students to them, and collect a royalty or some affiliate dollars.
They want students, once they log in, to have access to parts of the site that others don’t have, to see their own progress across a course (from multiple modules), and they want students, teachers, and themselves to be emailed as progress happens. The content in these classes needs to be hierarchical supporting video, audio, and file downloads. They want students to be able to browse other classes and even enroll in multiple classes.
Additionally, they want the entire course catalog available to all, from one url – theirs. No subdomains, no other domains.
Lastly, they want to charge for all of this, and they don’t want to use Paypal (hey, it’s my example!).
Assumptions I’m Making
First let me say that before I suggest some strategies for how to quote this job, I’m making some assumptions.
- You’ve never built anything like this before.
- You have some e-commerce experience, but not tons.
- It’s you, and maybe a couple folks on your team – not 25 developers.
- You really want the job.
- You have no idea how long this could take. It all sounds initially like something you should be able to do, but you don’t know where the hiccups will appear.
Strategy One: Spec Writing
The first strategy I have used for projects where I feel like I’m a bit outside of my element is to break the project into two parts – spec writing and development. I explain that in order to make sure that there aren’t any misunderstandings we’re going to have to write the project up with a lot more details and specifics. This helps me quote the development and helps them with clarity about exactly what they’re trying to accomplish. I explain that spec writing is it’s own project and we price that.
The benefit for me is that I have time to dig into the details with them. I can create wireframes, discuss them, and write out exactly what we’re expecting we’ll see (user flow, etc). This helps me quote it better, or walk away – explaining that I don’t think it’s a great fit.
The benefit for them is two-fold. First, they get to see if they like working with me. Second, it gives them options. If they don’t like me, they can walk, and take the write-up to someone else for a great quote (win-win). If they like me, but don’t like my new quote, they can cut some features out or change how we’re envisioning doing something to make it easier.
Strategy Two: Prototyping
I know there are people who don’t like prototyping. And I have heard their arguments and while I hear some of it, I have experienced situations where it works effectively (but that’s another article), which is why I recommend it.
In this approach I break the project into two parts again, but this time, part one is a time-boxed effort to create a prototype to let them react to what it is we both think they’re talking about. They have to pay for this prototype, and I’m clear that the purpose of it is to tease out additional nuances, test our hypotheses, and be better able to quote the larger project.
The benefit for me is that I can get our team to try a variety of approaches while still being paid. It also lets me see what we know and what we don’t know. Lastly, based on these experiences, it helps me assemble a quote.
The benefit for them is that they can see and experience something like what they’re asking. When they do, it’s amazing how many things they realize they don’t need/want. It’s also amazing what other things they really care about (graphic details, visuals, etc). It helps us discuss expectations and finally, helps them generate excitement for the project internally, which always helps right before they have to look at a quote.
Strategy Three: Hiring
While it is true that I may never have done this before, it’s unlikely that no one has ever faced this kind of problem. So the trick is to find that person (or people) and hire them to help us think about things. We can hire them for the entire project (and put that into our quote), or better yet, hire them for the spec-writing (meetings) and/or the prototyping (development).
The benefits to me are immediately clear. I’m no longer out of my element because I have someone I can trust who knows what’s going on. If they tell me 4 hours, and can show me why it’s easier than I think, I can count on that 4 and use it in my quoting. If they’re involved with prototyping it changes our work (from brand new development to copying something we’ve already seen).
When I use this strategy, I make the expert known to everyone. I don’t try to hide things (ever). I find that if I’m up front by saying, “I’ve brought in this expert who’s done this 10 times already” – I look smarter and the customer is happier.
The Common Thread
There’s one common thread that runs across all three strategies – the goal is to accelerate my own learning and reduce both my ignorance and project clarity. All of them do that in their own unique way.
One Last Thing…
Here’s the reality from where I sit. I participate in two amazing Facebook Groups related to WordPress – the Orange County Facebook group, and the Advanced WordPress group. I try to be there daily. I try to answer every single thing I can. You know why? Not because I think I’m smarter than the rest of those talented folks in the groups. Nope. I do it because I never know if my answer is a good answer. So the crowd responds by letting me know if mine makes sense, or if there’s a better approach. Either way, I keep learning.
The point I’m making is about learning. When you have to quote something and it makes you nervous, it’s likely because it means doing something you don’t know how to do. The best way to mitigate that risk is to keep learning so that those situations happen less and less.
Sometimes, in one of these groups, someone asks if a plugin exists to do XX or YY. When it’s clear that it doesn’t, sometimes I try to create it. Some of those are over at github/chrislema. I don’t know if they’re right or great. I don’t care. The point is to try.
So my last words are simply this: Keep Learning.