In an ideal world every project would be as clear as a client's initial proposal and I would accomplish all my projects long before the proposed delivery date. It is uncommon for everything to come together on a project exactly as planned. In order for the perfect project to happen here is a short list of what you would typically need:
- the scope not to change
- the project to be finished on time
- everything to work in all the major browsers
- the launch of the project to take minutes not hours
- the client to pay their invoices on time
- no one to get sick, have a computer break down, or have a family emergency
- other resources all ready to go when needed (API’s, designs, the content)
- someone to ask the important and sometimes forgotten questions when the project starts (what php version is the production server going to run anyway?)
- plugins and libraries the project depends on to work seemlessly without having any bugs or undergoing significant changes throughout the development time
Smart (or at least experienced) clients and developers will make sure to include time and budget buffer to allow for those factors to influence the project's outcome, but, in so many cases, both parties plan for the best case scenario of perfection. I want to offer some tips on mitigating some issues before they even happen and dealing with them if they do.
The scope is going to change, be ready
This happens all the time! The project is going along great and the client realizes they want something even better. I’ve spent weeks working on a feature to then have the client decide they want the system to load the data in a totally different way, or, once they finally start to play with the new functionality, they get inspired by a way to make it even better. Sometimes it is very clear that something is new scope and the client needs to pay more for that extra work, but often it isn’t so black and white. The document that outlines your project and what is included doesn’t usually cover every single detail about the work to be done, making mutual trust and common goals the foundation of scope balance. Be honest and communicate with your client when things feel out of scope; they may have the same feeling.
If something is new scope it’s a good idea to clarify that fact in writing and track the time separate from the original project to make invoicing easier down the road. Sometimes it makes sense to do the new scope during the current work phase; other times it just fits better into a future phase to be completed after the first phase is all polished and live.
Please allow for some margin
Our friends at Zao have a great article on the concept of margin and there’s a wonderful book on the subject , but how does that apply to your projects? Be sure you have extra time for handling the unexpected bugs and tweaks that come up. Be sure your project can still be profitable if everything doesn’t go as expected. Be sure your business can survive a delay in getting paid that big final invoice. Be sure that if a developer on the project needs a sick day it doesn’t throw off the schedule of this project and every project stacked after it in your companies workload.
Do some planning
I hate to admit it, but sometimes I get so excited to jump into the guts of building something new or solving a problem that I rush the planning phase and miss out on the big picture ideas. Take the time to have the meetings, read the documentation, and understand the why and the where of the project. Why are we even building this new feature? Why does it need to be done now? Why are we building this feature instead of another feature?
Where will the code end up? There can be a big difference between building something to go on a Hubspot site, inside a WordPress page, in a static html file, or packaged into a WordPress plugin. Get a deep understanding of where your pieces of a project fit into the bigger puzzle. You can build the most amazing piece but if it doesn’t fit into the puzzle it’s pretty worthless. Don’t make assumptions, but do ask questions and document answers so you don’t need to ask the same question again later.
The process of launching a site goes a lot smoother when you have worked with the host before (or at least know what makes it different from other web hosts) and have been testing the site on a server with a similiar server setup. A local development environment and a staging environment running the same server operating system, HTTP service (Apache, nginx, etc), PHP version, mySQL version, RAM limitations, and caching configuration can help to catch potential bugs or bottlenecks before the new site goes live. Part of the planning process is knowing the final resting place for the project so you can strategize accordingly.
Don’t let the success of your business depend on someone else
It’s tough to build a theme without the design, publish a site with no content, and create a product feed plugin when the product API isn’t ready yet. Going into the project you and your client probably don’t expect those things to be delayed by days, weeks, or even months but it happens all the time. What will happen to your business if the design for the new site isn’t ready on July 1st when you are supposed to start development? Do you have other work to do? Will you still get paid? Is there sufficient pressure on the client to deliver the content or resource needed for you to do your part?
Look after your business first. For your family, for your future, and for your clients make sure you are protecting the longevity of your business. If your contract says you don’t get paid until the site is live, does that mean you could be waiting months (totally out of your hands) for website content to be written and edited first? Protecting your business means setting limits on how long they have to work on content (or maybe even requiring content before the project starts). Protecting your business could mean charging clients weekly, and if they haven’t kept up their end of the deal they get charged for the week even though you were not able to work on the project.
Let’s all work to improve our projects
There is no perfect client, no perfect project, no perfect developer. However, with a bit of foresight, an extra chunk of space in those margins, a healthy dose of planning, and a penchant for overcommunication, we can get pretty darn close.
What do you think? Have you worked on the seemingly perfect project and been frustrated with the end results? What could you have done differently? How would you plan better in the future?
Have a great idea and want to see how we can tackle it together?
Send us your thoughts and ideas either through our contact page or twitter.