<body><script type="text/javascript"> function setAttributeOnload(object, attribute, val) { if(window.addEventListener) { window.addEventListener('load', function(){ object[attribute] = val; }, false); } else { window.attachEvent('onload', function(){ object[attribute] = val; }); } } </script> <div id="navbar-iframe-container"></div> <script type="text/javascript" src="https://apis.google.com/js/plusone.js"></script> <script type="text/javascript"> gapi.load("gapi.iframes:gapi.iframes.style.bubble", function() { if (gapi.iframes && gapi.iframes.getContext) { gapi.iframes.getContext().openChild({ url: 'https://www.blogger.com/navbar.g?targetBlogID\x3d7181760\x26blogName\x3dOffpoint+-+From+Singapore+To+Seattle\x26publishMode\x3dPUBLISH_MODE_BLOGSPOT\x26navbarType\x3dBLUE\x26layoutType\x3dCLASSIC\x26searchRoot\x3dhttp://offpoint.blogspot.com/search\x26blogLocale\x3den_US\x26v\x3d2\x26homepageUrl\x3dhttp://offpoint.blogspot.com/\x26vt\x3d-740194547652384018', where: document.getElementById("navbar-iframe-container"), id: "navbar-iframe" }); } }); </script>
Thursday, July 17, 2008
Moving forward, or back?

In big organizations like where i work, there'll be a lot of projects that go on and on. Some of these projects are for process reengineering, while others are technological upgrades for what is known as line-of-business services/applications.

When a technological project is funded, the most common goals are in terms of achieving higher automation with less manpower, increasing throughput, higher consistency and quality etc. There usually isn't any activity driver as a result of "version 3.XX of some technology was just released and we want to be using the latest programming technology". Specific and measurable goals, which typically have financial implications, are the main drivers of technological projects.

The main goals for the project that i'm referring was increased throughput with quicker processing, and better monitoring tools that imply lesser manpower.

Looking back (yet again), the goals were fine, but the road to hell was paved with good intentions.

Instead of higher automation with less manpower,... let me think about it. The service used to have Randy as the primary person supervising the service. Then i took over. And then Andrew joined. And when this current service was rolled out, we added a huge team of service monitoring and support folk to sustain it.

Now i don't even dare to think how many people we've gotten that directly or indirectly have to handle this service.

Indeed, i might be unfair because our current volume and service is so much more than what Randy used to handle, but in essence, it's the same thing right? With better technologies all around, why do we have to get such an increase in manpower to sustain it, i wonder?

At risk of beating a dead horse over and over again, it really fall back to the one single wrong decision made. To accept the service as-is.

Operationally, emotionally, logically, functionally, I don't think we ever recovered from that.

posted by Jonathan at 9:51 PM | Permalink |