The other week I had a long talk with Jen, a new friend of mine who I met recently when she visited Cebu (Philippines) 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 an initial version launched within six months. However, many issues came out during implementation. Jen complained that it took long for the team to get progress going with her project. There were a lot of iterations and back and forth work. There were also arguments over changes which the team insisted should be paid for separately as change request.
Over a year has passed now, and Jen’s project is yet to launch.
Yesterday, Jen gave me access to the beta version so I could check it myself. I was saddened. 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. But I have to be honest, this isn’t the first time I’ve seen this kind of problem. I shared some of my thoughts to Jen about what to do to save her project.
In this article, however, I’d like to share with you a few lessons which I think you could consider to prevent situations like Jen’s to happen. I’ve been both Studio Manager and outsourcing client myself, so I’ve experienced being on both sides.
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 request 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?
There are online templates which you can use as guide. You can also consult with a lawyer so they can provide help.
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. You can also send links to websites that you like. There needs to be meetings or conference calls 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
What I usually do is include 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 high 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.
I'm passionate about business, art, and technology. For more about me, click here.
Not sure if you'll find this one helpful, but here's a book I co-wrote with a bunch of industry colleagues. You can click the image if you wanna check it out.
Ateneo Graduate School of Business
University of San Carlos