What I bring to the OPI table:
- Understanding of and hands-on experience with SMC/IS staff, processes and systems
- Competence with the English language and ability to handle documentation, where necessary
- Coupled with an appreciation that documentation is an important, but ultimately only a small contributor to the successful implementation of any initiative/project
Aspirations:
- Work closely with SMC/IS staff to be more effective, efficient and resilient by making better use of systems and tools (technological and otherwise, corporeal and cerebral) at our disposal
- Apply the theoretical concepts learnt at Lean 6 Sigma and NTU Knowledge Management courses, as well as the many books I have read on related subjects.
Background:
- In my early years of working, namely 1996 to 2000, I was part of a small team that provided the bridge between Editorial and Technology colleagues to bring SPH’s English language newspapers into the Internet medium.
12 December 2016 addendum:
In SGX today, our approaches toward system improvements/enhancements can be viewed through 2 lenses.
In the first approach, we meticulously draw up all our manual processes. Then we try to find a system that replicates every step, down to the last detail. This is often very costly and back-breaking due to the massive amount of customisations required. And sometimes projects are abandoned because they were found to be prohibitively costly (resources, time, etc).
The other approach is to take a product off the shelf and have Ops staff make up for whatever deficiencies in the product. Oftentimes, we wonder why we pay so much for a defective product that seems so inadequate, i.e. why we even bother to change in the first place.
The first approach is far too onerous on our Tech colleagues while the second shifts the same burden to Ops. In both cases, Ops and Tech seem to operate independently of each other.
I’d like to propose a third way that calls for Ops and Tech to work together. Instead of requiring a new system to do everything the existing system already does and more, we should evaluate what we really need and want of any system. Furthermore, we should also seek to understand (and take advantage of) what the new system has to offer and open our minds to the possibility to paradigm shifts that make old assumptions obsolete.
It would, imho, be so much more productive if Ops and Tech were to understand and appreciate each other’s perspectives better and jointly work out solutions. I think that is what Agile seeks to achieve.