Does Your Web Development Partner Tend To Go Over Budget?
The Problem Could Be Poor Documentation
Look, no one is perfect. Every project has its challenges. But, if your web development partner constantly goes over budget, they likely aren’t setting expectations effectively. And, this problem scales. So, the larger the project, the more over budget they will tend to go. That’s in part, their fault. I’ve been there. Before I learned how to accurately document a project before providing an estimate, I would throw some random number out there. “Ok, this looks like it will take 100 hours.” I would make assumptions and so would the client. Herein lies the problem.
Without clear documentation, your developer thinks the project is a lemonade stand while your client thinks it’s a lemonade factory.
How do I fix this problem?
On your own, you can’t. You need to work with the right developer. In my experience, you can’t teach good project management. People either have it or they don’t. Sure, you can train someone how to fill out a document. But, you can’t train someone how to ask the right questions. And, that’s the skill your web development partner must possess.
How does DevSavvy solve this problem?
Answer: Good documentation. I’ve discovered that, especially on larger website development projects, good documentation is the key to keeping a project on track and on budget. No one actually plans to go over budget. But, as a result of scope creep, inaccurate estimates, and misunderstanding expectations, it’s inevitable that a project will exceed the original estimate.
Through good documentation, I’ve learned to accomplish the following very essential project goals:
- Set the client’s expectations from the start
- Help everyone in the team understand what will be developed (and what won’t)
- Set milestones and timelines so things are moving along smoothly
- Have something to revert to when additional project features are requested outside the original scope
- Remove all the guess-work and nasty surprises
What documents are you talking about?
I’m glad you asked. Next, I’m going to discuss each of the documents in question. To access these free documents, simply fill out the form on the right (bottom on mobile) of this page and I’ll send them to you.
Document 1: The Business Requirements Document:
This is the “here’s what we want you to build” document. This is often what a client provides to the web development partner. This is what most clients and many developers end up calling a “Spec.”
Here’s the problem with this document. Let’s say this document included a request like “we’d like to have a calendar on our website.” That’s great. Unfortunately, no other functional requirements are mentioned in this request. We don’t know if this calendar is supposed to send out email notifications or reminders. We don’t know if it needs to be accessible via RSS feed. We just don’t have enough to go on here. That’s why we need the next document.
Document 2: Procedural Requirements Document:
This is the “ok, what does that really mean?” document. This is what DevSavvy uses to clarify the unknowns. For the calendar example, we might say, “do you want this calendar to be accessible to an admin in-house? What will happen when an event is posted to the calendar? Should it do anything more than display the event on the website?” These questions drive the client to think harder about what they actually want. In fact, they’re now beginning to think about how this feature could solve a problem versus create new ones.
Document 3: Final Project Spec Document:
Once all the answers have been provided, the final spec is created. Now, based on this spec, DevSavvy can provide a final web development estimate based on this spec. This clear and obvious spec will guide the project. Any deviations from this spec will clearly add to the scope and cost of the project.
See the next installment in this series: Web Development Budget:
Communication
Have a question?
Thanks for reading this blog. I hope it’s been helpful to you.
[cta id=”617″ vid=”1″]