7 Tips for non-techie clients

I’ve been brainstorming with a very good friend of mine who runs a shipping business. V is my climbmate, tentmate, drinking buddy (sometimes), Viber sounding board, and former classmate in MBA school. ​

Our tent is lined up alongside others at Mt. Naopa. Photo via Dale Tisoy.

V is now starting to work with a team who’s developing a web app for her. This may be her first software project as a client. I thought to give her a few tips that might help her get started quickly.  I've written those tips below too, for those of you who might be interested. 

1. When planning a software project, it helps to create the product specs/product plan first. 

This part you can do yourself, or you can do with the help of an IT person. The product specs is a business document detailing the high-level features of the product.  Among the questions that will be answered through this document are the following:

• What is the product about? Who is it for?
• What will users accomplish through your product?
• How will you make money out of it? What is the business model?
• Why are you developing the product?
• What platforms/devices will your customers be using to access your product?

To help communicate the product vision to your development team, you might wanna identify competitor products or products with similar feature sets. 


2. Review your development contract with your lawyer carefully

At this point you should already talk a bit with an IT person, but if you haven’t identified anyone yet, talk to a lawyer who has experience with software development contracts. Make sure that:

• You have milestones properly identified.
• Payments are tied up to milestones (if developers are paid on project basis) or certain achievements (if developers are paid hourly or monthly).
• You get to check who owns the in-progress code. I know of a lot of cases where clients and developers get into trouble with this part. As a client, you'd want ownership and access to the code as work progresses. This might not be achievable in project-based engagements, but make sure you schedule payments in such a way that you get to delay as much payment as possible after the final code has been turned over to you.
• There are certain consequences specified in the contract in case of delays or issues with quality.

3. Do a kickoff call to set expectations with developer team

If the developer team doesn’t request for a kickoff call, I think that’s a sign that they’re not organized enough. If they haven’t yet, make sure to schedule this with them. At a minimum, you should get the following from them:

• Single point of contact (POC) and contact details as well as availability
• High-level timeline
• Schedule of regular calls
• Milestones and expected output
• Reporting frequency and form (how often will they report to you and in what form)
• Collaboration approaches (email? project management tool?)
• Schedule of user-acceptance reviews

Calls or physical meetings can be done weekly to get you updated on what’s going on with the project. In case there are issues, you can easily address. 


4. Allot some time for your project or hire a PM if you’re too busy

Ideally, if you’re a top exec and busy with other things too, you’d need a PM who will liaise for you. But if you don’t have anyone yet, not a problem.  Just make sure you allot enough time to review progress and communicate project decisions needed of you. 


5. What you can expect of your POC

As a client, you should expect your POC to keep you updated on the project’s progress without waiting for you to follow up. They should follow the timeline you both agreed and inform you in case there are issues that will affect delivery schedules. They should suggest solutions when they present problems to you.


In addition, they should make reporting easy for you. You’re not expected to be the technical person. You’re the business person needing technical solutions to your business problems.


6. Always find a backup

Make sure that when choosing which programming language to use, you also consider resource availability for backups. For instance if your development team suggests PHP - check too if it will be easy for you to find another PHP team or resource that can continue to work for your project in case the current development team fails or leaves the project. 


7. You don’t want very long timelines

If your software is very large and complicated, I suggested breaking it into phases and starting the earlier phases with features core to customers. 2-3 months max or less are ideal in my opinion. You should identify with your developers the content of each phase. Perhaps you also can release to your test clients gradually so you can gather their feedback and make improvements based on these. 

I might still have a few more tips to share later. 
Meanwhile, I hope the above help. 

Cheers!