In the second part of the series I am building up on building and managing tech teams in Asia, I want to focus on the problem of scope creep and why paying something cheap might cost you more. The other highlight of the article is to understand the various cultural nuances present in Asia when it comes to getting your Asian engineers to deliver a product without flaws. Finally, we conclude on how to reduce scope creep by focusing on the business people with a simple argument of efficient feature rather than adding too many of them that do not work.
Asia Tech Teams and their Cultural Nunances
Probably, if you have the time to speak to various founders of a technology start-up in Asia, you will hear this common feedback from them about their teams, be it outsourcing through a vendor or programming house or building internally:
- They over-promise and they cannot deliver: This is common but there are two sides to the comment. The first is from the perspective of the business owners. They want to get the product out quickly but the problem is that they under-estimated the amount of scope required to build the product, and usually they introduce scope creep to the product without confining the scope of the product properly. The problem lies in the business owners’ lack of familiarity on the technology aspect. To cure that problem, the business owner should do three things: (a) talk to friends who are product managers or CTOs to get some realistic gauge of the product that they are building, (b) read books on project management, agile software development and get some thinking from web design blogs, for example, Smashing Magazine, to learn some best practices about web design and (c) reducing the scope of the product to three features of the prototype and stick to it.The second perspective is from the technology people who are often either too honest or too ready to get business. The “too honest” group will get fed up with the business people for full of scope creep, and the “too ready to get business” group will end up taking the project without realizing that hell has just begun.
- They can build the feature but the product is imperfect: Sometimes, the management team dictates how the product is built and to the credit of the technology team, they build it. However, the product can work for the test case but failed for the other cases. How can that happen? The problem is that there is no planning on the technology team to provide adequate unit testing or even instructions to the layman how they can use the product.
- They cannot imagine beyond the technical scope of the product: In harsher words, I often hear my western counterparts or fellow Asians educated either in the US or Europe saying, “They can’t think.” I do agree with the “they can’t think” given the Asian hierarchal culture nuance of “obeying your elders”. However, as product owners and managers, we should encourage to work out how the product works and then put questions to the issues which they might be facing before they start coding. The missing link between the engineers and the business people is the social practice on how the feature is delivered. To mitigate that risk, the engineers should code the feature with an internal discussion on brainstorming the problems which might arise from usage and let the business people test and offer feedback. The tech team should look at several examples of how the same feature is delivered through other web services or mobile
It is important to note that all project managers or business owners should know that they should add a 2x to 5x to the number of days which the whole software development project take. So, if your programming house tells you that they take 100 days to finish the project, be prepared that it will be 200-500 days. The best programming house will finish it within 150-200 and the rest follows. Most outsourced programmers and freelancers will give up the project if they exceed 300 days. So, here’s a rule of thumb. Why does this happen? In a project that you outsourced to a vendor, you have to pay half the money upfront first and then the rest upon completion of the project. In some cases, the payment is split due to the completion of milestones. It’s a problem of economics when the vendor or freelancer takes half the payment and then runs away by the time when they realize that it’s too much work and it’s never going to end because of scope creep. What happens in the end, both loses. The business owners have to salvage the situation and look for another vendor, ending up paying twice the amount. The vendors walked out burnt too with their teams not paid properly and all hell broke loose.
The real challenge is …
The best way to deal with the scope creep is to be really honest about what you want and what you can’t have. Draw up a list of 20 things you want on your site, then systematically eliminate and prioritize which ones come first. Then in the end, focus on the 3-5 things on the list that really matter to the business. If something can be added without hassle, you can get the software engineer to add them later. Life is never perfect, and half the time, you are trying to constrain resources to deliver the highest amount of impact. Business people should learn that the perfect product should have lesser features but works in a seamless way without hassle. The best way to explain this to them, “You can create a feature of buy and add an e-commerce element to your platform, but what’s the point if your payment page keeps getting errors because you don’t spend money to perfect the experience of users buying the stuff from your site?”