Productivity and the Big Project Myth

Job advertisements in newspapers and on the internet asking for IT professionals usually tout large projects as the sole reason for wanting an IT professional in the first place. A programmer, system analyst or system tester must have had experience in large corporate projects and the larger the better.

Many businesses, in Australia at least, see IT departments as a liability and a necessary evil so as little money as necessary is thrown into IT infrastructure where other areas of a business, for example the Engineering Department or the Buyers Department, get inundated with large budgets. IT Departments have to justify their existence with staff time-sheets and charging internal clients for IT solutions.

Although grandiose back-slapping projects bring in the money and look good on a resume these projects do not necessarily improve the expediency with which a company does business. In fact large corporate systems can increase the workload where more data is required to be captured by the users, call centre staff and so on.

Throughout my consultancy career my main philosophy has been to improve the user's or developer's work environment by making their job easier. As well as large projects I have developed many small applications that took anywhere between 15 minutes to an hour to create but have saved employees anywhere between hours to months of hard tedious work. The accumulation of small time-saving applications can out-perform some of the larger projects when measuring productivity especially when used over and again exponentially increasing productivity within a company.

Those employees who benefit from many of these small applications are usually confined to the IT department itself where users have direct access to an IT professional who can put together a small custom application during their spare time. Those outside of the IT department though are usually left to their own devices and this is where end users and macro recordable office suites or keyboard capturing software comes into play.

What begins as simple macro instructions within an application built by an end user eventually become large complex and business critical applications held together with chewing gum and string. As news of the application spreads throughout the department more demands are made upon the hapless user who provided the solution and ergo their stress is increased as they maintain the original solution with all its additions whilst trying to cater for a stream of new requests. When a system grows to the point of being unmanageable the department can then justify the expense of a business case which the IT department will then accept, all too often though the business case specifies an upgrade of the original system, a band-aid solution as the ultimate solution, where a total rewrite is really the only solution.

There would be more control over such a situation if IT departments provided small applications for individuals and groups, and companies realised the benefits of incorporating the IT department more into its overall infrastructure instead of annexing it to the companies structure as if it were a parasitic necessity.