Need to Develop A Better Client Qualification Process

[labboy0276]

Prompt

Currently we will pretty much onboard a client if they give us money. We like money, but sometimes these clients can be difficult to work with for a variety of reasons. We need to identify a high level checklist to continue talks with clients in the sales process.

We should also take into account if a client is willing to adhere to our processes down the road. Which has happened in the past.

Ticket Checklist

Make sure you complete the following checklist

• [ ] I'm aware of what a discussion actually entails
• [ ] I've assigned this task to myself and one of the Keepers of the Faith
• [ ] I've not set a story point estimation
• [ ] I've selected at most two labels that best describe what part of the business this ticket improves eg sales, dev, etc

Ping some folks!

Hey @pirog @reynoldsalec @dustinleblanc @mikemilano @serundeputy what would be your high level qualifications for accepting a client into Tandem?

Follow up tasks

To Follow...

[mikemilano]

It think risks to consider up front fall into 3 categories;

Those that would compromise:

• Ability to execute (Due to technologies, infrastructure, security, or access)
• Ability to profit (Usually due to inadequeate discovery)
• Our reputation (Due to inability to meet deadlines or sites get compromised on our watch)

Here are some factors that could compromise us.

• Will we be able to develop with github and deploy to platform, or might we end up being surprised that we have to use FTP on a server with no SSH access. Something like this could affect all 3 concerns if we did not know in advance.

• Do we have sufficient access to files/assets, designs, data, information and any other dependencies required to do the job? Do we have everything at the start? If not, when?

• How is the project to be delivered, exactly? While we may be able to develop in github and platform, the delivery may come with surprise requirements.

• Does the site have existing vulnerabilities? It is a liability for us if a site has been sitting around with Drupalgeddon-like vulnerabilities unpatched. Has the site ever been in this state? They could lie, but it would be nice knowing if the site has been exposed or intruded on.

• Are there any known issues which prevent bringing insecure modules or core up to date? We should know ahead of time if there's a reason the site isn't up to date.

• Will we have access to a single person who has authority to make final calls on the project? If not, our process can be crippled by beurocracy on the client's end.

• What's the ideal timeline, and what's the absolute deadline. If it still seems risky, what is the impact of not making the deadline.

[pirog]

I really like how @mikemilano distilled things above here.

Another less sexy category or consideration here could be a "risk threshold" eg the amount of risk we are willing to accept based on any immediate financial realities. obviously if we are flush with cash and have a full pipe we can be more selective and obviously if we need the $$$ we have to accept more risk.