What happens when a development team gets an incoming project inquiry
There are mainly two types of customers in web development: middlemen and direct clients.
— The first ones usually are developers themselves and know how to hand a project over to another team.
— The second ones are business owners who want to solve a specific problem. This article is addressed to them.
I manage incoming project inquiries at ADCI Solutions: I collect initial information about a project, lead a client through the discovery stage, and hand the project over to the development team.
Your potential vendor validates your brief and your project. Not everybody has a clear goal set or a vision of the project's future figured out, and that’s totally fine. We want to see you succeed with our help and then see you come back for another project. That’s why we will ask you a couple of inconvenient questions. Stephen Barker and Rob Cole have a checklist on the project’s health; I revised it a bit.
A quick project health check
- Are the project’s objectives clear and measurable?
- Have you checked the feasibility of your project? Have your customers signed up to this?
- Do deliverables, deadlines, and resources look realistic?
If the answer to all the questions is yes, congrats, you’re going the right way. If there’s no wandering — hey, we’ve just discovered a project’s weak point and fixed it.
What technical specifications are
A technical specification document (or tech specs) is a list (preferably in a written or documented form) of all the project's goals, tasks, and requirements.
Specs are the bedrock of your project’s success. You as a client are interested in quality, deadlines, and saving the budget. Having agreed on what exactly should be done (and what shouldn’t!), a development team is highly likely to provide a ballpark estimate in terms of money and time.
If you have come prepared and already read our article on web development methodologies and approaches, you may have noticed that sometimes the specs are omitted. It’s only possible if the dev team sticks to an approach like Scrum. In this case, only the project outcome is defined by the client. It happens to be a successful strategy when you’re not limited by the budget. But if you want to have control over it, write specifications and discuss them with the dev team.
I also mentioned the importance of goals. Yes, you call the shots, but if you welcome other points of view, a project manager and a team lead can help you figure out how your goals can be reached faster than you imagined while writing the specs.
Proceeding to an even higher level of abstraction, I will ask you why you want to do this project at all. Once one of our clients reached out to us to migrate his website to a newer Drupal version. Having discussed the details, we found out that he actually didn’t need this! He simply needed one small module adjusted on his site.
Always ask yourself: Why do I want to do this project this way? What do I really need and what is my business goal?
What new project information a dev team needs
When reaching out to a web development team, you’ll be asked for details of your project.
Information that only you can provide
- Goals of the project. We need to know them to understand what your project will be like in terms of functionality.
- What business goals your project will help others reach. We need to understand it to seek a better tech solution.
- Feasibility of your idea and if there’s a demand for it. We need to know this to distribute our resources in advance if you’re about to start a project.
Information that we collect together
Next, we turn your information into an action plan. It’s amazing if you already have one; if you don’t, we create it together.
Five essential elements of any good plan:
- Project objectives and supporting key requirements.
- Project scope: what will be delivered, what won’t be delivered.
- Major deliverables: each deliverable should relate to a particular objective. “Deliverable” doesn’t stand for “activity”.
- Resource planning.
- Project schedule with key delivery dates.
Some also make a list of possible risks and issues. We do it for projects where specs are highly likely to change or where timelines and a budget are really tight.
What a project brief should include
These stem from your business goals. Imagine that you approach us to develop a new website. Ask yourself: what problem do I try to solve in terms of business? Probably you’d like to increase sales of your offline shop (but without being involved in the process too much) and decide to go online. But all your customers are not big fans of the Internet, and you need to run an offline campaign instead. Does it make sense?
Project scope and deliverables
Okay, let’s pretend you need to move your business online! The project scope will be to develop an e-commerce shop. We will deliver a shop, not any other kind of web app. Then we start planning the major deliverables. Since you need to increase sales and not waste much time on that, we will develop a website, say, with an online order and payment options: this way, customers will take care of orders themselves and not through your managers.
“..if you need tight, reliable estimates, you also need clearly defined and agreed requirements”
One painful fact: no one on Earth knows what exactly the final product will look like, when it will be delivered, and how much it will cost until everything is actually delivered. You need to choose one thing you are not ready to compromise: the deliverables, budget, or timescale. The others will vary.
To reduce the risks, we add contingencies to each piece of estimated deliverables. In this case, it is some percent added to time estimates. That way, you won’t miss any important deadlines.
When it comes to resource scheduling, we plan what developers we will use at each stage of the project. We also plan accompanying project management work (hi there, that's me), post-release support, and emergency support (if needed).
We finalize planning with a project timeline: it will show what is supposed to be done and when. Bear in mind that you’ll have a timeline only if the requirements are settled.
Now that you know what info is crucial for a development team, download our brief and fill it in. We’re looking forward to working with you!