The Wrong Way
A typical, but simplified, flow for a large company to brief a new project consists of 3 steps. And each of those steps has reasons as to why it is the wrong approach.
- Internally gather requirements - usually done by a project manager with limited hands-on technical experience. They will be able to interview stakeholders to gather user requirements but they often fall short of asking the right questions to address the technical aspects of those requirements. They also base their brief purely on given requirements and do not consider how they impact each other technically.
- The brief is then sent to one or more vendors with the expectation of receiving a detailed estimate back. The vendor will be unable to effectively estimate a project without the right technical questions being asked of the stakeholders or having a full understanding of the business goals, overall strategy, growth/scaling plans, risk factors and more. Basically, to provide an effective and detailed estimate they need solution architecture documentation. Vendors will also not invest significant time in projects that have not been awarded to them, the cost is simply too high to do that level of research for free. So what the vendor will provide is a ballpark estimate which is only slightly better than an educated guess.
- The client will then internally submit their budget based on this ballpark and typically there is very little flexibility, if any, to go over this budget. Deadlines are also established and plans are made around those deadlines. But all of this is based on a ballpark estimate which was based on an incomplete briefing. This would be like selling an unbuilt house for a fixed price based on a sketch someone made on a napkin. And yet, when it comes to custom application development this is accepted as the norm.
The result of this flow is often the same: project going over budget, deadline not met, features not implemented or insufficient testing and other corners being cut.
Some vendors margin for this, marking their project up by 50% or more in an attempt to offset the risk but this is the same as gambling as it’s impossible to predict an exact outcome of a project. Especially if it’s the first time the client and vendor are working together. So the result is that the client pays more than needed or - more often - the vendor still runs out of budget.
Some vendors simply swallow the cost of the additional work, then wonder why they don’t make a profit. Others stop working when the budget runs out, and the client is left with the choice to launch with an unfinished project or to try and get more budget to finish it.
Typically the experience is not pleasant for either party and both move on more experienced but also more cynical and wary of the next project. But there is a better way of doing things and that is what this article is about. No system is perfect but if we can address the shortcomings of the current one and propose a different way of working we can certainly improve things for clients and vendors alike.
Solution Architect
There are 2 approaches to writing a briefing. If you have a solution architect on-board - either internal staff or an independent external vendor - you can do a full detailed brief. This will ensure that the ballparks provided,while not perfect, are at least as accurate as possible. A detailed brief includes doing internal research, speaking to each stakeholder, asking the right technical and strategic questions, and gathering as much information as possible before consolidating it into a single detailed project brief. If stakeholders have different requirements for the same feature then those need to be resolved between the parties before being finalized in the brief. A ballpark based on a detailed brief should be reasonably accurate - typically within 30% for the specified requirements.
If you do not have a solution architect then you will need to do a more detailed brief in the next stage with the chosen vendor’s solution architect. In this case you should focus on getting the main requirements from the key stakeholders as the vendor’s solution architect will speak to them all in detail in the next stage. Note however that a quick brief results in a substantial difference between the vendor’s ballpark and their detailed estimate but as the goal in this stage is to compare vendors and each vendor has the same information to base their ballpark on then that goal can still be achieved. The ballparks provided should not be relied on to confirm the project budget however.
Viewpoints
A great briefing includes different viewpoints on the project within the business. For example, a finance person may have different goals and requirements of the project than a salesperson. It is important to understand the needs and goals of each and every stakeholder and to find consensus in the final brief. Factors you should consider and understand are:
- Business goals and target audience
- Technical requirements or limitations
- Project budget
- Timeline, milestones or phases, and deadline
- Launch, growth and scaling requirements
For small businesses without staff, the entrepreneur may have all of the above information but try to have additional input such as an external consultant or someone from your target audience that can help provide viewpoints you may have not considered. A single point of view is never a good thing when it comes to briefings.
It is important to note at this point that you need one or at most 2 decision makers. Too many decision-making stakeholders will result in delays and a messy, incoherent brief and project. When it comes down to 2 stakeholders wanting something different there needs to be one person who makes the final call on how it will be implemented.
Budget range
Budget is a bit of a polarizing matter when it comes to briefings. Do you include your budget range or not? From the vendor’s perspective there are, depending on their capabilities, thousands of ways to implement a given project - each with different budget and timeline requirements, technical constraints and level of quality. Most vendors will want to implement the best solution because it will be a high quality, properly tested and fully scalable masterpiece, but these are also the most expensive solutions and may not suit your budget.
Stating your budget range will manage the expectations of the vendor and they will be able to propose a solution that best fits your available budget. This may be a solution that uses a design template instead of a custom design services, or an existing CMS product instead of custom development, both of which can make a difference in the thousands of dollars.
If you really have no idea about your budget or it’s a strictly kept secret then ask the vendor to ballpark 3 versions. The cheapest they can do, a middle option and a high quality option. Ensure that they clarify the differences between each solution. This will enable you to fairly compare the different vendors on a similar level of quality for each project.
Other topics to cover in the brief
The brief should include the type of implementation for the project as this is key to establishing the size and general scope of the project. (see an article on this topic here). Note that the type will heavily influence the budget of your project.
Also include a description of the main expected features, your key business goals of the project, the target audience, the platform your project is intended for and, for web applications, any specific browsers you want to support or a general year (“all browsers from 2015” for example). If the vendor is to provide design services you should also reference 2-3 websites or apps with a design style similar to what you are looking for. There are a few other topics you should include but this will depend on the type of project you are briefing.
Estimate
To manage expectations, it needs to be clear to both parties what is expected from the briefing and the estimate. Vendors should not be expected to spend a significant amount of time on researching and working on a detailed estimate before the project has been awarded to them. This is a very big risk to vendors as such detailed estimates typically include valuable consultancy and many great ideas. But you, as the prospect client, should also be able to form a solid fact-based opinion of each vendor and their budget proposal for the project. To satisfy both of these requirements you can follow a 2-staged approach:
Stage 1 - Ballpark, a quick proposal which includes a profile and ballpark cost estimate. This is to be provided free by each vendor. A vendor should not need more than a day to write up a ballpark based on a given brief. It’s important to note that a ballpark should NOT be used to establish a final budget within the business as this is very likely to change during the next stage.
The vendor should also include an estimate for stage 2 as this will require significant effort on their part.
Stage 2 - Solution Architecture, a fully documented project plan which includes research, detailed cost estimate, timeline proposal and more. This will be the first paid stage of the project after you have selected a vendor. The accuracy of the included estimate should be sufficient to establish an internal budget but still be sure to include some margins for new features that are requested during development.
Profile
Besides a proposal based on your brief, you should also request a profile from the vendor whereby they answer at least the following questions:
- What programming languages do they specialize in
Is your tech consultant knowledgeable of this language? - What infrastructure do they use
Cloud or server, they should include a ballpark of the expected costs - Are their solutions scalable (automatically or manually)
should include an explanation of how they implement scaling, automated or manual for example. - How do they manage development and live systems
Will they be developing in your live application after it launches or will they have a separate development environment and change-publish strategy. - What are their testing/QA processes
Internal by developers, internal testing specialists, external testing specialists, on-site testing or a combination of multiple methods - What are their backup and staff redundancy policies and measures
If their developer is sick does the project stop, do they do versioning and/or backups of the code, media, content store and databases - Can they provide an example of a backend interface they offer
Does it look intuitive, something you would be happy using on a day-to-day basis - Do they provide full server and source access
At which point in the project life cycle is it provided - What is their policy on bugs
Is debugging within the specified scope, limited or to be paid per hour, is there any warranty period or do they offer an SLA for long-term testing and debugging. - What are their payment terms
Everything up front or in stages pending your approval of a milestone for example - For mobile apps, do they develop native apps, native-generated or html5 apps.
There will likely be more questions specific to your industry or project so think carefully about what would be red-flags or requirements for your particular situation.
Ballpark and profile evaluation
After receiving all replies you can evaluate the vendors. Look for red flags to quickly rule out vendors that are not suitable or higher risk than others.
- Any specific requirements or questions that were ignored (clarify why they were ignored, do they not have the skillset for this for example)
- Repeatedly late for meetings, conference calls or the ballpark deadline
- Vendors suggesting a project type different to what you requested (clarify with them first to ask the reason as they could have a good case to do so - lacking the skills or experience to implement the preferred type is not a good case)
- No contract/vendor agreement, vendors without at least a basic contract are likely also falling short in other areas of account and project management
- Vendors proposing features purely for the sake of the feature without any thought to the business goals (upselling). All features, and especially complex and expensive ones, should be justified with a strong business case.
An orange flag is if the vendor does not have a solution architect or a senior engineer that can fulfil this role. If you have your own solution architect then this is less important but be prepared for a vendor that is likely to follow the blueprints and implement features exactly as requested without any thought for the result, overall strategy or long term goals of your business.
Make sure to review the vendor’s contract. Is it heavily biassed towards the vendor, the client or is it balanced? Are there clauses that are vague or at odds with their pitch, what they have said or answered to the profile questions or during meetings or phone calls? The contract should also allow you to cancel the project after the Solution Architecture phase if the detailed estimate/timeline turns out to far exceed your budget. Note that you are still expected to pay their time spent on the Solution Architecture but you should be free to discontinue the project at that point.
A good vendor will tell you if certain features are a bad idea, will be honest and transparent and will make an effort to have a long-term business relationship with you because they know their service will live up to, or even exceed, your expectations.
A bad vendor will implement all features without question regardless of their added value, they will be secretive and evasive about their experience and existing client details, contractual obligations and pricing, and they will focus on getting as much work approved and signed for in the first step because they know they might not be considered for a second step.
Once you have made your decision make sure to also select a backup vendor for redundancy. This backup vendor should be specialized in the same programming language or skill set as the selected vendor to ensure compatibility.
Stage 2: Solution Architecture
Once you have selected your preferred vendor the agreement/contract can be signed, the next step is the solution architecture with detailed estimate and timeline. During this paid step - which the vendor estimated with their ballpark - the vendor will do any research and prototyping needed to produce an estimate that should be very close to the invoice at the end of the project for the listed deliverables. There should also be recommendations on which features to leave for later or new features that could increase your chances for success. Click here for an article on why solution architecture is important
There are a few ways to go about creating the solution architecture.
- If you are a tech business running multiple projects then it’s likely you have an in-house Solution Architect. This person can write up the solution architecture documentation and work with the vendor to get the detailed estimate and establish a realistic timeline
- If the vendor does not provide a solution architect or you prefer to use a third party one you can enlist the services of a vendor or freelance solution architect. If you enlist the services of an independent Solution Architect for your detailed briefing then they will be able to expand that briefing into a full solution architecture and work with the vendor to create the detailed estimate and establish a realistic timeline for your project.
- If the vendor has a capable and experienced solution architect they can take it from here. They will write up the solution architecture documentation as well as the detailed estimate and a realistic timeline for the project.
At this point you should have a very decent idea of your project, the risks faced, the costs and the timeline as well as an understanding of your vendor and how they work. All of this should leave you feeling confident that the project will be implemented on time and on budget.