In previous posts I’ve written about the enormous productivity gains and costs savings to be made with rules engines and automated software development tools.
The only reason these aren’t mainstream is the barriers IT puts up to prevent change. Before I talk about overcoming these barriers we need to understand what the barriers are and why.
I read a forecast back around 2004/5 from one of the leading industry analysts that 40% of IT jobs would disappear in a decade. Ten yearslater this hasn’t occurred – but it could have.
The reality is that no organisation’s IT department and project management office is going to voluntarily adopt tools and methodologies that eliminate about 60% of their workforce.
Similarly large software development companies, particularly those with large government or corporate clients, isn’t going to downsize when they can get more revenue by staying big.
But it’s even more entrenched than this:
- The very reason many middle and senior IT management roles exist is to manage the existing IT structure and workforce. These are people with influence and trust in an organisation. They can say something doesn’t work, or doesn’t apply to their situation and their statement will go largely unchallenged.
- The powerbase and kudos of senior developers, system architects, data modellers and other specialists relies on preserving the importance of their role and discipline. Trust me this group can be scathing in their opposition to anything that challenges them. I call it technological arrogance.
- For many consulting firms their entire fee base is built on large, highly structured projects and the supply of large number of IT contractors. There’s not a lot of revenue in automated software development projects! If a consulting firm has a couple of hundred staff and contractors to feed don’t expect them to endorse Agile methodologies and automated software development tools. Sadly these firms are often the ones senior management and directors look to and trust for advice.
- There is a whole industry offering training and accreditation – particularly Prince2, APM BoK and, to a lesser extent, Agile. I know from experience that a competent developer can be retrained in model based tools in a week or two. Not a lot of training revenue here.
- The market is crowded with consultants and contractors needing clients to buy the big package to ensure a reasonable period of employment. An unemployed ex CxO looking for consulting work isn’t going to find much in the world I’m talking about.
- Our educational institutions that offer IT courses can’t string a degree in automated software development out for a couple of years!
So there is a whole industry built around the status quo and they are very effective at blocking the uptake of automated software development tools and efficient methodologies. Unfortunately they are often the people business executives turn to for advice and they fail the trust placed in them.
The drive has to come from CEO’s and boards fed up with the high cost and inflexibility of traditional software development…
…and the high failure rate of large technology projects. It doesn’t matter where you live or what industry you work in you will know of major failures and yet organisations continue to undertake large technology projects using the same tools, methodologies and practitioners, somehow thinking that their project will be different.
I was looking at an apartment building going up recently.
The tower crane was swinging precast concrete walls into place and I couldn’t
help thinking of the analogy between this and model based development tools.
The walls are poured in mould in a factory and shipped to the construction
site. In model based development the software functions are defined in a model
and the model generates the software code.
Now you wouldn’t dream of brining in a hundred or so foreign workers to work on site hand pouring every wall panel in the apartment building – but how many times do we see software projects in trouble, then outsourced off-shore or a large number of foreign programmers brought in to complete it.
So how do we fix it?
Let me give you an example, because variations of this are very common. We were looking at developing rules engines to replace a number of legacy financial products that couldn’t be closed because they still had members invested in them. The internal cost to develop a new system to handle all the products was over $2 million and couldn’t be cost justified. We could do the job comfortably for $3-400,000. A system architect blocked our bid. His sole justification was “we (meaning I) don’t want another technology on site”.
He worked for a large organisation whose accounting department undoubtedly monitors expenses. So it is highly likely that if this system architect was away and had a drink out of the minibar he would be asked to reimburse the company the $7 or so the drink cost. But his arrogant,
unjustifiable decision cost the company $millions and there is no accountability or recourse.
Boards and CEO’s must challenge the status quo if they want to bring about change.
- The first challenge is to understand where their CIO or IT manager sits.
- If they have a CIO who does want to change the IT paradigm then back that person to the hilt, because they will need it.
- If the CIO is opposed to bringing about serious change then get rid of them. Maybe the CIO is simply resistant to change, or even sceptical, then cut their budget by 50% and demand a 50% increase in output. This is feasible in an ARAD (Agile Rapid Application Development)
environment and will be an incentive for change.
- Dismantle the project management office (PMO).
There are project managers who adapt methodologies to deliver outcomes and there are project management practitioners who blindly follow a methodology regardless of outcome. The former you want to keep and they will thrive without a huge PMO. The latter won’t cope without a PMO and you don’t need them anyway.
- Be prepared to start again. Trust me, in some instances it easier to recruit a new team than to tackle the technological arrogance and blatant resistance you get from some groups. Sounds brutal but in reality the issue is often with senior staff, so there may be some very good
people in your teams that will flourish in a new regime.
- Put in an appeals process for vendors of alternative or “non-compliant” solutions. You want solutions to business requirements and if this means one or more of your technologists has to play in a different sandpit then so be it.
- Finally hold IT and external consultants to task. Ask them to justify any decision or position in business language (not technobabble) and in the context of the business needs.
For an expanded discussion on the issues download my eBook:
The Executive Guide to Slashing Software Development Costs from my company’s web site www.circatec.com.au/publications
In the book I explain in much more detail the alternatives to current software development tools and methodologies, plus there are some real examples of the barriers IT departments use to protect their domain.
Circatec offers two options for organisations wishing to break away from expensive and inflexible IT solutions:
- Using automated software development Circatec will build commercial systems or sub-systems substantially faster, cheaper and to a higher quality than any traditional development method.
- I will provide personal consulting services to organisations who wish to transition away from traditional development tools and methodologies.
You can contact me on firstname.lastname@example.org