Every time I read a new post on Andy Rutledge’s blog Design View I feel the need to comment. Andy has made the decision to not allow comments on his site so instead I’ll comment here. The latest article on Design View is about Pre-Bid Discussions, in it Andy explains how his company turned down a $50/60k project because they could not see the project succeeding according to their terms. For the fact that he turns down projects for integrity reasons, I applaud him! As far as the article, his analysis and process are insightful and I’d love to be able to use them, but for now I’d just like to expand on them.
I would like to add two questions to Andy’s list of five, and I’ll continue with his format of stating the questions and then coming back to them, so numbered for reference:
- Am I or is my team able to develop with the technology stack?
- Would I invest my own money in this project?
As Andy laid out in his article, these are questions that should be asked during the pre-bid discussion. There is nothing worse than blindly responding to an RFQ and winning the job only to find out that the client does not want somebody to help them implement a solution, they want somebody to blindly do their bidding without question. But I digress, ladies and gentlemen, the questions.
6. Am I or is my team able to develop with the desired technology stack?
I have seen this question extract chunks of flesh more times than I can count. Most programmers will tell you that programming is programming and the difference between languages is small enough that given a few weeks a real programmer can learn any language. I’ve said it myself, and I thoroughly believe it. However, I’d much rather have the end results from a programmer who’s an expert in a language or framework than a programmer that only learned it a few weeks ago. Think about these questions when discussing the technology stack:
- What version of X Technology are you using?
- Do you have internal coding standards to which we’ll need to adhere?
- Has something been developed and deployed to this platform before?
- Will your team be interacting with our code directly?
- Will we be interacting with your team’s code directly?
These questions are more technical than Andy’s, but they’re vital for determining the overall scope of a project which is necessary for placing a bid. Software versions can make huge differences. I whole-heartedly agree with coding standards, but if the standards say no open source or external code you may be up a creek if you rely heavily on Jakarta Commons. Is this stack even possible? Sure, the bigwig sales guy said a heterogeneous solution of Company A’s ORM and Company B’s DB and Company C’s development environment would work, but have you seen it and can you get support for it when it fails? Finally, if you’re co-programming this project with the company, will they be changing your code? Will you be changing theirs? What does their programming team think of bringing in outsiders? How long will it take them to make a code change that you need and who’s responsible for making up that time? Think about who’s making the rules, who’s following them, and who’s enforcing them.
7. Would I invest my own money in this project?
Nothing will kill the morale of your team like working on a project they think is doomed to fail. I really hate to tell you to judge somebody else’s ideas, and 9-chances-out-of-10 I’d take the client that has a few million in VC-backing, but sometimes it just doesn’t make sense. This especially comes true when the sales pitch for the idea starts with: “
It’s like some-other-app but…” Let’s all face it, twitter is a huge surprise and everybody loves it, but that does not mean “
It’s like twitter but instead of other users subscribing to your tweets you get to publish your tweets to the people you want to see them,” will ever make billions. If they’re not the first, the free, or the best, let somebody else implement the failure. I guess this is a bit of a sore spot for me personally, but ignoring that, here’s some questions to ask:
- Have you done focus groups or would you like us to help you do them to support the feasibility of this project?
- How do you intend to monetize this idea?
- How do you intend to build your user base or generate buzz about this idea?
- What happens if the users adapt your system for some other use beyond or in contrast to your initial plans?
- What is your reason for starting this project?
- What is your goal, how do you define success for this project?
No audience, no plans to obtain an audience, and no way to make money are surefire signs for failure. If you still like the idea and you think you can help, at least make sure you get paid up front. The next few really don’t have right or wrong answers, but the foresight to know that the agility to adapt might be necessary is a good thing to have. As for reasons, you might want to get out your moral compass, if it’s for world domination, drug trafficking, destroying the ozone layer or patent trolling you may not want your name attached to it as the implementor. Finally, it’s good to know the client has a plan, how can you define the success of this project if they can’t.
My Main Point
Like Andy, I’m definitely saying that if you establish your own rules up front it will make it easier to say no to a job no matter how big or easy is might seem. Unlike Andy I will say that I understand the necessity to bend these rules on occasion to at least keep your team busy, if not productive.
But let me stress the “on occasion” part. It is not good to be the bargain basement whore of web application design. Your reputation can mean the difference between finding jobs and having them find you; or playing the part of the expert-consultant or errand-boy slave. Your portfolio, client-list and case studies can speak worlds about your company, but not if every client that’s ever worked with you has gone out of business or insists on not being on the list. Even a big-name client means nothing if they’re using some propriety or ill-conceived tech-stack your team would rather quit their job than use.
Think about it. Make your choice. Reread the title.