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. First ones usually are developers themselves and know how to handle a project to a team. Second ones don’t have to know that specific; they are businessmen who want to solve a specific problem. This article is devoted to them. I manage incoming project inquiries at ADCI Solutions: I collect initial information about a project, lead a client through a discovery stage, and handle a project to a development team then.
Your potential vendor validates your project and you. Not everybody has a clear goal set, nor a vision of project future, its relevance at all - and that’s totally fine. We want to see you succeed with our help and then see you 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 we answer “yes” to all these questions - 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 the technical specs are, why gather specs at all
Specs are the bedrock of your project’s success. It is a list (preferably in a written or documented form) of all the goals, tasks, and requirements. You as a client are interested in quality, timeline, and a budget. Having agreed on what exactly should be done and what shouldn’t (it’s not a typo), a development team is highly likely to provide a ballpark estimate in terms of money and time.
If you have taken some preliminary actions and have read our article on web development methodologies and approaches, you may have put your mind to the fact that sometimes the specs are being omitted. It’s only possible if the dev team sticks to the approach like Scrum. In this case, only a project outcome is described by a client. It happens to be a productive work when you’re not limited on budget, but if you want to have control over it - write specifications and discuss them with a team.
I also mentioned the importance of goals. Yes, you call the shots, but if you welcome any different points of view, a project manager and a tech leader can help you specify how your goals can be reached better and faster than you imagined while writing specs. Proceeding to even a higher level of abstraction, I will ask you why do you want to do this project at all. Once one of our clients outreached us with an ask to migrate his site to a newer Drupal version. Having discussed a situation we found out that he actually doesn’t need to do this! He simply needed one small module adjusted to his website.
Always ask yourself: why do I want to make this project this way? What do I really need and what is my business goal?
What information a team needs to plan your project delivery
When reaching out to a web development team first, you’ll be asked for details of your project.
Information that only you can provide
- Goals of a project
- What business goals your project will help to reach
- The feasibility of an idea and if there’s a demand from your customers
We need to know point 1 to understand what your project will be like in terms of functionality (to develop an e-commerce website where visitors can customize t-shirts and make orders), we need to understand point 2 to seek for a better tech solution, we need to understand point 3 to plan 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 critical 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 needs.
- The project schedule with key delivery dates.
Some also make a list with possible risk and issues. We do it in projects where specs are highly likely to change or where timelines and a budget are somewhat really tight.
How to collect this information and handle it to a team
How to answer point 1
Here it’s your business goals. Imagine, 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 much involved) and decide to go online. But all of your customers are not big fans of the Internet and you need to run an offline campaign instead. Does it make sense?
How to answer points 2-3
Okay, let’s pretend you need to go online! The project scope will be to develop an e-commerce shop. We will deliver a shop, not any other kind of a web app. Then we start planning the major deliverables. Since you need to increase sales and don’t 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 they will be able to actually pay you money and increase your wealth.
How to plan resources (point 4)
“..if you need tight, reliable estimates, you also need clearly defined and agreed requirements”
One painful fact: no one on Earth knows what exactly will be delivered, when and how much it will cost until everything is actually delivered. You need to choose one thing you’d like to remain the same from the very beginning: the deliverables, the budget, the timescale. The other will vary.
To decrease the strength of risks, we add contingency to each piece of estimated deliverables. In this case, it is some percent added to time estimates. Thus you won’t miss any important deadlines just because you didn’t pay attention to contingency.
When it comes to resource schedule, we plan what developers we will use at each stage of a project, also, we plan accompanying project management work (hi there, it’s me), post-release support, emergency support (if needed).
How to compose timeline (point 5)
We finalize planning with a timescale of a project: it will show what and when is supposed to be done. Bear in mind that you’ll have a timeline only if requirements are strictly fixed.
Now when 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!
Useful links
Web development methodologies and approaches
Why write user stories
