In the previous article, we looked at how business' ideas and strategies are affected by the constraints and preferences of the available IT presence. We discussed how technology can be a leash on growing businesses and international enterprises alike. But there is always another side to the story, and in this case the alternate view on the topic of business versus IT is that of IT itself. To the Dev. Space!
Most IT staffers nowadays are veterans of some or other piece of technology, the remaining few being the lowly interns and sub-juniors. By our very nature we are lazy (subject to opinion) but dedicated, with an almost zealous dedication to whatever we believe to be our favourite tool or language. The more time we spend with a certain technology, the more we form a dependence on it and the harder it gets to leave it behind. It's from this that the greatest problem with modern IT is born, the unwillingness to move on.
There are countless different technologies, methodologies and tools available to perform a myriad selection of tasks with new ones popping up every day. They all have their strengths and weaknesses, as well as their own fan base. This makes it difficult to pick a select few to specialise in, and there's no guarantee that they will survive the onset of the ages. There are too few timeless standards to make a career on, and far too many hopefuls spinning around to secure permanence. This is why most IT veterans do not like change, they've been burned in the past by a hopeful that may have once flared brightly, but is now reduced to cinders.
However, let us not forget the other killer of ambition: Business. There are many untold tales of proposed improvements to ageing infrastructures and excited requests to refactor processes to a new standard that tragically end with a refusal to comply by business users. Business is made up of humans, and humans fear the unknown. For business, changes are high risk and may equate to reduced profits or worse. For business, all changes that they did not think of are potential hazards to what they believe is "fine as it is".
Because nothing on IT can be done without approval from business, development and progress is hampered by what is seen as red tape and bureaucracy. No one wants to have to fill out forms only to repeat their contents to an audience of naysayers for a chance to have something from their suggestion to be approved. Plus there is always the risk of the suggestion being pounced upon by business and warped into some horrible monstrosity that can only require large amounts of effort and willpower to carry out. There's nothing quite as pitiful as a developer who has to create said beast and constantly be told that it was their idea in the first place.
There is also the occasional request from business that, according to them, should be a simple thing to do, but in reality will lead to a much larger workload for whomever gets stuck with it. For an IT person, there is no phrase more despised and feared than "But can't you just..." or "That's nice, but...".
So how do we handle business' red tape and awful requests without offending them? It takes social creativity and a good understanding of what's possible. If you can tell business that adding a search feature to the company's mobile app will delay deployment by several weeks without rambling on about indexes and input parameters, you win. But can it be consistently? No, it cannot. At some point business will wonder what on earth is actually happening, which means more meetings and more documentation. Scary, no?
There is another way. Give business more control over IT's more unstable requirements, such as adapting rules to new market requirements. Of course, don't give them too much power that they start getting in the way. The point behind this method is to allow them to handle "their" requirements, without sucking in resources from IT.
But how can this be done? Usually through BPM software, but such tools can be limited in usability or capability, or might be "too technical" for the business users. So solving this problem will take nothing short of a miracle? Not necessarily. A balance between business' docs and dust, and IT's ability to keep the code going is more than possible, with the right tools. But what are these amazing tools that map the path to true business/IT co-existence?
Share