9

I work as a lone programmer on web-development projects(front and back-end) - I have completed a couple of projects, so I'm fairly new at this, I have read and tried a few approaches and reached a way of going about them. The question and my description is fairly long so please be patient.

What I am looking for, is :
1. Preparation/Planning that would be typically done before you start development, once you know exactly what needs to be built.
2. From your experience please give me feedback/suggestions on the process I follow currently.

The clients I work with are generally startups and have limited budgets so I can't charge them on a per/hour basis(I think that is how large companies usually bill their clients[on man/hours] for development projects) and have to work with a fixed budget.

This is the process I currently follow :
1. Gauge the scope of the project and try to understand what they are trying to accomplish in a couple of meetings.
2. Give them a rough ball-park figure with a quotation that describes in general what they expect to get from the project, I try to be specific about features, but, I'm not putting too much time into this because I know the client may just be asking around for quotes, and not actually convert.
3. I follow Jeff Atwood's suggestion for payment & work :

15% payment - Upfront before starting any work
During this phase HTML mockup of the end website is made, a flowchart(with yEd) describing the website in as much detail as possible and a document that mentions other features that are not there in the flowchart. This is done by going into all the details of the project and finalizing the bits that will fit in and stuff that is too much work to implement for the agreed price. Because specifics are not discussed earlier, portions of these are also more or less a negotiation on what they will actually get. Because this is a fixed budget project, there needs to be fixed requirements, else, my price keeps going down as more features are added.
A color scheme, design wireframe and design PSD is also finalized.

35% payment - Start Development
The project is fixed, begin development. I Host the site on my server, where the client can access the front-end, but, doesn't have access to any code.

30% payment - Shift code to client's server/give client the server access details
Make the site live.

20% payment - Couple of weeks after the site goes live, once all the bugs have been fixed.

Questions :
1. Once you know exactly what you are going to build, what sort of planning would you do before you begin coding?

2. From your experience, what parts of the whole process would you do differently?

4
  • Unfortunately a lot of clients never reach the point of knowing exactly what they want you to build. The best approach I've found is to do mockups of some of the important pages and then sit them down and start telling User Stories. I deliberately make some of the stories obviously wrong to force the client to say, "No, I want it to work this way ..." This eventually gets us to something approaching a project spec, but it invariably gets changed latter on. Sigh.
    – Peter Rowell
    Commented Jun 13, 2011 at 15:00
  • @Peter, Purposely introducing bogus user stories can sometimes backfire on you and cause the client to lose confidence in you. That technique should be used carefully.
    – maple_shaft ♦
    Commented Jun 13, 2011 at 15:03
  • @maple_shaft: I realize that. When I say 'obviously wrong,' I mean so Blatantly Bogus® that I normally get more than a few chuckles. Getting a client to become fully invested in their website (vision/time/money) is critical to a successful project. It is shocking (at least to me) how many people think that a new site is something they can handwave and it will magically appear.
    – Peter Rowell
    Commented Jun 13, 2011 at 15:59
  • I agree about mockups as well, no amount of written text will get the client to understand what they will get(most can't understand it or care to understand it) -- a mockup will make things clear for the client, also some documentation(spec) + a contract or something that says : "You will get all this, and exactly this, nothing more" helps. While development, I think there can be some flexibility to change things around, but if something comes that shows up as more work than you accounted for, I think the mocks and spec docs need to be pulled out and additional work means added costs also.
    – DMin
    Commented Jun 13, 2011 at 16:56

2 Answers 2

Reset to default
10

Great points for discussion!

To qualify - I work in BIG web development projects in the defense industry. We generally have a team of 10-40 people supporting a single customer, projects last years, and the customer has both money and high demands. So mileage may vary - you don't want to overplan!

1 Once you know exactly what you are going to build, what sort of planning would you do before you begin coding?

This is after the 15% section, at the start of the 35%, right?

  • Decide on target web server and language
  • Decide on data storage - XML, Database, which database?
  • Decide on major APIs - data persistence, GUI, logging, dependency injection, etc.
  • Decide on login mechanisms - with an eye to risks and the information you are trying to protect. May include payment mechanisms.
  • Plan out a high level architecture and naming conventions
  • Pick an order of feature roll out, so you know a good place to start
  • Decide on a test strategy and stage automated test framework if applicable
  • Set up CM system

2 From your experience, what parts of the whole process would you do differently?

I wouldn't over plan. I'd focus my planning work on getting things done - like build environment, server, testbed, CM - and spend only a small amount of time planning an architecture, picking tools, and deciding where to start. I feel like no matter what, the amorphous planning stage always involves a lot more time wandering in a desert of cluelessness than it really should.

If you're dealing with fixed fees and customers who are not making technical demands (such what language or APIs you use), I'd plan in 1 item that is always a push for you, technically. Just 1 and keep the rest the same. I think on every project, you want to broaden your skills, but you don't want to go so wild that you aren't working in anything you know or understand well.

2

My biggest advice to you is to be extremely careful with a fixed price development job. If you don't get a good handle on the requirements before work begins then one of two things could happen.

  1. Estimations on scope turned out to be undershot and you lose your shirt.
  2. The customer does not or cannot know all the scope before you start resulting in them being unsatisfied with the end result.

For you number 2 is a better situation because if they sign off on scope and then change their minds later you can renegotiate for more money. Just make sure that YOU understand the scope before you estimate, and that THEY understand the scope and what you will deliver.

Make sure that they sign off on the scope! Companies that insist on a fixed price and refuse to sign off on scope are BAD CLIENTS and you do not want to waste your time with that. You will always lose.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.