There are a few recurring thoughts I’ve been having over the last couple of years that I wanted to share and get feedback. Most of my thoughts are aimed at creating an exceptional experience for both client (the person paying for the web development) and the company (the person or people doing the actual programming). Web development projects, in my mind, are unlike projects in any other industry. I’ve compared web development with graphic design, landscaping, auto repair, medical and legal work. Maybe the closest match I’ve come up with is a custom construction project or a car company that’s designing a new line of cars, but even that seems to be wildly different. Nothing I can think of really fully parallels a web design project — I’m using web design here to mean both web design (brochure sites) and web applications (software).
I’ve found that the biggest difficulties in software development come by a lack of communication and consequently disparate expectations about the project deliverables. In my experience there are two types of software/client relationships:
- Fixed: If a client wants a fixed price web site or web application it’s important that the company performing the work have a very clearly defined scope of work, and that the company also have experience and confidence in delivering the same or very similar sites. I’ve found that creating wireframes with the customer and talking through the required functionality is a good tool for guiding a conversation that aligns expectations. Wireframes, however, don’t define the business logic behind the application, so wireframes by themselves are incomplete. If there is complicated business logic it’s important to define this logic together with your client before agreeing to a fixed price. Time spent on the front end of the project (planning) is more valuable that time spent on the backend. With a fixed type project as a developer I’d suggest putting something in the contract that says something to the effect of if any of the code is used in a production capacity for 30 days of continuous or non-continuosuly that the software is automatically accepted and payment is due in full. This gives developers an assurance that the company their working with won’t just start using their code without paying for it.
- Variable: Clients generally know what they want and even have a vision of what they want, but they don’t know how to express their vision clearly and completely to the company. I’ve at times also come across clients who haven’t take the time to think their ideas all the way through. The company in this case must lead the the client in a discover process which facilitates communication and helps align expectations between client and company. UML was created for this very purpose to help graphically model and define the data objects and business logic of the proposed application. There are many arguments for and against it i.e. freqeuent software changes mean that you might spend a significant amount of time and effort creating specifications for something that in the end might not end up being used.
Payment types mirror the project types. Client/Company relationships typically end up being in one of the following payment categories:
- companies should only do this if they have enough padding built in that the company isn’t going to end up bankrupt (some multiple of the amount the company initially thinks it will take i.e. 2x, 3x
- fixed w/o padding, only take these types of projects if you’ve already done a couple of them, otherwise this can lead to a stalemate, the company can’t go on loosing money and the client thinks they shouldn’t need to pay more than they originally agreeded to
- Varialbe (time and materials) the client pays the price it takes for the company to complete the project
Maintaining a Healthy Relationship
I’ve found it’s heplful in any type of software project to follow some simple guidelines that will help everyone stay in synch with each other. It’s important to bill at regular intervals if you’re doing variable or time and materials type billing, or at predefined milestones when doing fixed billing. Don’t get too far ahead of each other. It’s better to stop development on a project and let a client catch up then to keep developing in hopes of some big final payment. I try to set expectations from the start that if a client stops paying or get’s too far behind that we will stop development and wait for them to catch up. When the gap between client and company get too big to fix, is when the relationship becomes unhealthy.
If, on the other hand, the client feels like they won’t get what they want out of the project they can walk away at any time with a variable project type, take whatever code they’ve paid for and find someone else to work with.