Avoiding the pitfalls of service contracting

The other week I had a long talk with Jen, a new friend of mine who I met recently when she visited Cebu for an event. She runs a grocery-store chain in Canada.
 
In mid-2017, she contracted a team in the Philippines to do a small web-based tool for managing their company’s employee-evaluation process. The team she chose was a small development studio that was recommended to her by a former work colleague.
 
Jen actually had a good impression of the team when she evaluated them. They had a nice portfolio and a good list of past clients. 
 
In the initial months, Jen’s discussions with them were smooth.After finalizing the project’s scope and specifications, they agreed to have the project launched within six months. However, just few weeks into the project, issues started to come out, starting with the delays in the delivery of the initial wireframes and mockups. 
 
The next deliveries after that took way longer than expected. There were also arguments over requests by Jen which the team insisted should be paid for separately as change requests.
 
Over a year has passed now, and Jen’s project is yet to launch.
 
Jen gave me access to an initial version so I could check it myself. The app’s UI is a confusing mess. Navigation is unclear. I was supposed to log in as evaluator, and I did see a name for me to evaluate and a form to fill. But after completing the form, I didn’t receive any confirmation. I wasn’t sure what to do next after that. 
 
Jen gave me her original project plan and I checked it against the app. It seems a lot changed in the implementation, especially the features.

Listening to Jen’s story was disheartening for me being a service provider myself. I can imagine how frustrating it can be, considering these things are very costly in terms of time and money. But I have to be honest, this isn’t the first time I’ve seen this kind of problem. Over the years working as both client and service provider, I’ve learned a few things that help in terms of avoiding situations like Jen’s.  
 

1. Draft a clear contract 
A lot of projects I know fail because developers and clients argue over things that should have been cleared out in the contract in the first place. For example, as client, when are you required to pay? What should the developer deliver? In what format? How do you treat requests for changes? What should you do when there are issues that can’t be resolved? What happens if there are failures? How do you get out of the contract? These things should be covered in the Contract. 
 
There are online templates which you can use as guide. You can also consult a lawyer so they can provide help in drafting one. 
 
2. Communicate clear specifications
To eliminate back and forth work, create a thorough, clear business requirements document (or product requirements document) that includes general to specific information about your project. This is a business document that includes project purpose, target audience, features, sitemap, design requirements, even design inspirations. Make your business specs as visual as possible to avoid misinterpretation. You can send links to competitor websites or apps. You can also send links to websites or apps that you like. Schedule meetings to go over the requirements and make sure everyone is on the same page. Note that the business requirements document is different from the Developer-produced project plan and technical specifications. This document doesn’t deal with how the project will be delivered. It deals with what you want to accomplish through the project.
 
3. Create a product roadmap 
You’d want the developers to be able to see the bigger picture and be fully aligned with your vision for the product. I recommend creating a  product roadmap with clear milestones every month. A product roadmap is a visual representation of how you see your product or application evolve through time. It helps to have this as guide for the development team when planning their execution strategy.
 
4. Be careful with requirements changes
Requirements changes, especially those that are made late, are very risky. They add to the cost too. Make sure to prototype your project early on so you can review and adjust the specifications as soon as possible. Prototypes can be in the form of wireframes, storyboards, and quick mockups. Also, it helps to show the prototype to sample end users (in Jen’s case, their employees) so they can provide feedback. The earlier feedback is communicated, the better.  
 
5. Allocate time for your project
As service provider, one of my main challenges before was getting decisions from clients. Some clients just don’t have time for their projects. Some clients also take time to respond to questions. Others provide feedback late, which makes it difficult to adjust in cases where there are corrections.
 
Always allocate time for your project. Or if this is difficult for you, assign someone in your team to be your project point of contact. This person will make sure all decisions are provided whenever needed and that questions are addressed immediately. This person will also take charge of acceptance testing and getting feedback to the developers.
 
Of course, do a careful due diligence prior to signing a contract with any developer. I also suggest reviewing the profiles of the team members that will work on your project, especially that of the project manager. There’s a likelihood that they will change team members during implementation, but the project manager will most likely be the same. If you see signs of trouble while the project is ongoing, raise it right away. Get it resolved before it becomes big.
 
Outsourcing web projects requires work and patience, but it can be fulfilling. I know of so many projects that succeeded, projects that led to even bigger ones. In fact, the company I work with right now started as a small project that later on became big. It led to the building of a development company in the Philippines.