After contracts are signed and your new software team is kicked off there are many things to watch out for, but by then your money is already flowing.
What should you look for before choosing that team, when your time and financial investment with the consultant is still minimal?
Here are five flags that you should watch out for. These aren’t in order of importance, but are most likely in chronological order.
The important part is this; don’t hesitate to pull the plug at any stage – and ignore your sunk cost. Starting over at any of these pre-contract stages will be enormously cheaper and faster than trying to fix your bad choice after coding has begun.
Many companies we talk to have wasted more than half their budget trying to fix a bad software team. Hire fast. Fire faster.
Treat it like dating. Swipe left at the earliest opportunity.
1. Website review
Start by looking at their website. It doesn’t have to be perfect – the cobblers shoes and all that – but it should make sense. It should be written in your native language by a native speaker.
Don’t forgive websites with bad grammar or typos. The website may be lacking content, but what is there will reflect their professionalism. Just like on a resume, be strict about typos.
The quality of the code you get from them will reflect what you’re seeing now.
2. First contact
You’ve reached out to them, perhaps via email or perhaps their toll-free number. What are your first impressions? Were they quick to respond? Was it a call center?
Remember this is speed dating. Every interaction with you is an opportunity to impress you. Not underwhelm you. You don’t need to be pushing the relationship because there are many alternatives out there.
It should come naturally – you should immediately like and respect the people you’re talking to. If not, move on – this is as good as it gets!
Other flags are techno-babble and mansplaining. Depending on your technical expertise you may not know the deep technical terms, or be able to detect techno-babble (AKA B.S.) but the team you choose should not be talking over your head anyway.
Beware of anyone trying to sound impressive with acronyms. Even if you don’t know the technical details, you can still ask them to justify their choices between, say, Angular and React, or AWS and Azure. Then just listen.
3. Prior work
While you’re on the call, ask them to send you a list of case studies of similar projects that they’ve done. You don’t necessarily need case studies in the same vertical as your project, but it’s preferable. But don’t use that as a reason to say no, yet, because they still may have built the exact system you need for a different market.
Ask for client references too. Call them all. Really. Ask them about their experience from start to finish.
- How was the final handoff? Or are they still in an ongoing relationship?
- Did all their launches go smoothly?
- Any missed deadlines?
- How was their performance to budget?
- How did they communicate problems?
4. About your team
When you met your prospective team, did you do it in person, or over video conferencing? More and more projects are handled remotely, and you may never meet truly in-person, and that’s ok. But you do need to see them. No phone calls, ever – use video.
Like interviewing, you need face time. Watch expressions, body language, and what’s in the background. Do you have a large national consulting company budget, or a scrappy startup GSD budget? Choose appropriately.
In all cases, judge what you see in front of you. Smooth sales people will not be involved during your project, even if they promise that. You may get “touchpoints”.
Don’t be sold on a company before you’ve actually met the technical team. And this is key – I mean the technical team who will be working on your project. Not the A Team they roll out for sales calls.
You can ask, “Are you the team that will likely work on our project?“.
Ask for resumes of your team and principals, then review them closely. Look at their LinkedIn profiles, and see how many contacts they have, and how many recommendations. How much BS is on there? No photos on LinkedIn is a flag.
5. The Contracts
Finally, we get to the paperwork. This is probably the most important part, because it will define your ongoing relationship. Until now, they are courting you. Now you’re getting married and any breakup gets expensive. You can still walk away!
There are many things to consider here and I could blog about each of them, but to be brief, look for answers to these questions – they should all be YES!
- Did they send a Mutual Non-Disclosure Agreement (MNDA) to you before your discovery meetings to protect you?
- Was all paperwork sent via an e-signature platform like Docusign?
- Did they send a Master Services Agreement (MSA)?
- Did they send you a Statement of Work (SOW)?
- Did the MSA/SOW define the following?
- Can you cancel at any time without notice?
- Is your engagement Time & Materials (T&M), i.e. you pay only for work done?
- Are the payment terms what you expected?
- Do you own all the IP, domain names, code, documentation, build and deployment process.. etc?
- Are they clear and concise agreements? 🙂
- Does your engagement include dedicated Project Management and have they spoken about communication cadence already?
- Daily standup to monitor progress and any impediments
- Regular Demos (Weekly or Bi-Weekly) to demonstrate progress and ask for feedback
- Backlog grooming
- Executive level oversight (at least monthly)
- Have you both identified roles and responsibilities on both sides?
If you got this far without any hesitation – Congratulations! You’ve done your due diligence and are ready to sign and start with your project kickoff – the first step on your next phase of engagement with your development team.
But don’t get comfortable or disengage just yet.. the first few weeks are critical. We’ll cover that in the next post.
Be sure to read our other post How Much to Build a Website to validate quotes you might receive.