“Quick-Win” in software development is sort of a down to earth version of Agile methodology commonly employed in many organizations today. It literally means quick delivery of project results by breaking down a sizable software project into several small manageable modules. The quick turnaround also enables the business to spread out the overwhelming activities like functional test and data preparation across all the modules and provides timely feedback to the IT for quick fixes. Quick-Win is a business jargon that resonates well with many stakeholders to the extent that sometimes, it overshadows accuracy and quality, the critical attributes in any technical work.
A large enterprise tends to have many projects in progress and in plan at any point in time. For the projects in progress, it is vital to commission them as per committed timeline without any distraction. The stake of missing target is high such as implications to cost, business and most concerning, staff competency. For the projects in plan, the various business owners are eager to commence and commission the work at the shortest possible timeframe for understandably, the first-mover advantage. I often caught a quick frown from the project sponsors on the proposed project timelines, no matter in weeks, months or sometimes, years for mega projects. Frankly, there is no standard approach to decide the optimal project schedule as situation varies. One usually assesses the required efforts of design & coding, technical complexity, hardware readiness and human resources, etc. but these factors are far less significant and deliberated than the extent of the business ownerships, data readiness, clarity and stability of the business requirements. How possibly Quick-Win can be tweaked to tackle the issues and deliver results not only in speed but with accuracy in project timelines?
Among all the impact factors to project timelines, the most inconspicuous one is the extent of business and process ownership involved in a project. Seeking consensus for diverging business requirements and harmonizing processes cutting across multiple owners in a large enterprise just take time if not politically challenging. Sensitive matters like refusal ownerships, transferred workload and added responsibilities among the business units do not command much attention until confronted upon the details given by the Quick-Win at the module level.
Separately, we know the functional specifications in software development is a high-level abstraction of the system design and coding logics derived by IT based on their best understanding. What happen if the business has overstated the requirements? How about a workflow looking simple to the business but not in proportion to the intense IT efforts as proposed, what could be the causes? What is less known on Quick-Win is that the technical considerations and IT efforts provided by Quick-Win do allow both the business and Enterprise IT coming to terms at the fitting moments before the technical work begin. I have some pleasant experience with Quick-Win as once commented by the business, “we do not realize that the required data source for the function is missing and let us take a different approach”. As for the IT, “we can optimize the IT efforts since we have better understanding of the requirements now”. Yet, the most astonishing is from the project sponsor, saying that “I do not think this function is essential to the business since it takes so much effort and let us defer it”. The details exposed by Quick-Win does force meaningful discussion and sensible compromise between the business and IT on the project timeline without jeopardizing the project outcomes. That’s win-win for all.