Time to Market – Can It Be Associated with the Project Methodology Being Used?
By Ambadapudi Sridhara Murthy
Recently, We have been visiting some local mobile stores in search of buying a smartphone and observed a common delivery pattern which can be mapped to projects/products and their quality and methodology. We observed that the the rate at which new devices were released into the market was very high (meaning very low time to market) and that the overall quality of such products on an average was OK or only reasonable for the functionality they were delivering or supposed to deliver. Each device that we tested was having either something more or less than what we were expecting it to have. However, looking at the marketing strategies, various metrics shared via advertisements/media and market share information – devices of only a reasonable quality (or with only needed features) captured the majority of the market share when compared to the other devices which were of a higher brand name, more robust, or with more functionality and which took comparatively more time to enter the market. Thinking more deeply, we can anticipate that one of the main reasons for this increased market share seems to be that those devices had 90% of the basic and popular functionality working and that the rest 10% functionality was either not built-in or had quality issues which were slowly rectified using the product patches/services chain.
An alternative analogy can be derived by hooking the above with the methods or the methodologies that we use for delivering projects – it makes us think that rather than waiting for a “Waterfall” or “any other long term delivery methodology” to give a complete functional and robust product after a defined length of long time-period (and with a possibility of losing market share within that defined time-period), an “agile” or a similar “small and working features delivery model” might be able to deliver a given product faster to the market (and hence help increase the market share – though in increments). Though this “small and working features delivery model” may not be able to deliver all the functionalities in the first product release, it would at least deliver the more popular features in pockets thereby enabling more product features to be exposed to the external market quite early and hence increasing its demand and popularity day by day and with every release. We can apply the 80/20 pareto rule (in a cascaded manner) to agile-kind-of-model wherein the Product Owner prioritizes the features/functionalities to be implemented first based on the return on investment these would generate for the project/organization. In other words, delivering an optimized % of the “important scope – early” can provide the most used/required functionality of the product in a shorter timeframe and hence help increase the products market share.
To Sum-up, “Features Priority”, “Need” and “Popularity” can be the drivers for a “small and working features delivery model” and that there will be an expectation from the market for incremental features delivery/product upgrades – but this approach could help organizations to launch their product early into the market (early time to market) and start reaping rich benefits incrementally even before the product is promoted to its full functional capacity over a period of time.
Ambadapudi Sridhara Murthy, M.Tech, PMI-SP, PMP has extensive experience in the fields of software project planning, scheduling, risk management, budget management, vendor management, contract management, execution, tracking, monitoring, controlling, quality assurance, and on-time delivery. He has delivered projects over a wide range of domains, such as Leak Detection Software, Semiconductor software, implementing desktop/mobile websites, and Bio-Information Management Systems, in addition to the field of software services.