Skip to main content

Outsource, Offshore, Offshelf – value in your IT department

Today I enjoyed a creative workshop with strategic leaders of our company. Almost all were collectively of a similar mind on one topic which had me soul searching for the remainder of the day.

Aside from confusion over terminology, the common theme was to not build things within our own IT department if we could buy the software from another source, saving money and getting it quicker.

During the meeting I felt duty bound to point out that off the shelf software was still written by actual people and then spent most of the flight home pondering the wisdom behind the notion of ‘any software, as long as it isn’t written by you guys’, or rather that was how it felt for me, to hear their opinions on the topic.

Perhaps it’s difficult for us in our IT department to consider buying software and integrating it into what we already have because we know too much about how this could go. Given our recent experience of a user base that wants highly customised software we are sceptical of their ability to take the software ‘out of the box’ and bend processes to fit the application. In fact projects have been commissioned in the past on the basis of giving our systems ‘the wow factor’.

Off the shelf software has it’s place in the world, I believe the way to get the most value ‘out of the box’, is to keep it like that – vanilla, un-customised, as the maker intended it to be. Once you start messing around with it, you are locked in, to that provider, to the version you created, and to the cost of supporting the changes. This total cost of ownership also includes the upfront investment in the selection process for the software, which can be expensive if exhaustive.

As a department and as an organisation we will henceforth hold everything up for scrutiny against pre-built software solutions, with a collectively open mind. The goal being to achieve a balance between the money that can be saved in off the shelf and the additional total cost of ownership incurred by buying software in.

It’s a challenge as undoubtedly our comfort zone is to build on the current solution we know and love. Equally our value as an IT department is the business operations and processes that we know in such intricate detail. I’m hopeful the outcome will be ‘any software solution, as long as you guys are along for the ride'.


Matthew said…
I find your comments very interesting and have faced these challenges several times in the past. I think the other argument that requires consideration is in in fact whether the current processes are best practise, or whether vendor applications can support a better process.

If the current process is best practise, is the vendor willing to develop their application to support this process. It may be that a strong, but independent vendor relationship may lead to better practises and supporting applications and lower TCO through less in sourcing.
Matthew said…
This comment has been removed by the author.
I appreciate this POV Matthew and agree to a degree, however I also think if you change your processes to become 'best industry practice' (if such a thing exists) have you just lost your competitive edge? If everyone in your industry jumps on board your vendor's solution then you have just leveled the playing field. Maybe your competitive advantage is your specialised process?

Additionally your newly introduced/requested features can realistically make it into the vendors 'standard set' removing your competitive advantage even further and handing it to your potential competitors.

Interesting conundrum....

Popular posts from this blog

Business Requirement Documents are just no good and should be abolished from the world of creating software

I had hoped the world could have wholeheartedly rejected Business Requirement documents by now. For too long I’ve seen the repeated scenario of only commencing the creation of a new initiative with a requirements document.Unfortunately most organisations that have teams developing software still use these flawed anathemas to creativity as the status quo. Despite agile approaches maturing and customer-centric modes of design emerging, requirements documents still persist. 
If you work in an organisation that doesn’t use business requirement documents any more, read no further. You are lucky; sense has prevailed at your place however in my experience, you are still the minority.
Let's face it; addressing this issue is not always the point you want to start your improvement work when there's much that could be dysfunctional with how a team is delivering software. But now, I find myself as mad as hell, and I'm not going to take business requirement documents anymore. I want to …

Gamify your children

Inspired by James Ross’s LAST conference talk on The Shamification of Lamification and the Reclaimification of Gamification I was motivated to try and “Gamify” the school holidays for my three children, Leo aged 8, Chloe 9 and Max 10.
Buy-in is everything, so the first thing we did was a quick workshop to extract the kids ideas. I asked them to write their ideas for good rewards on sticky notes, with a few examples for context, such as ‘trip to the movies or ‘play date with a friend’ . They had 5 minutes to come up with their ideas – one idea per sticky note (as always).
They then read out their ideas for all of us to hear, there were a few duplicates and also a few comedy suggestions. Even though we had ruled out crazy stuff, such as rewards of a million dollars, Leo had written down ‘A unicorn for the back yard’ reading it out with gleeful giggles.
Then they spent 5 minutes writing down tasks that they could do to earn rewards. By now they had the hang of it and quickly came up with t…

Agile Australia 2011 Series - Agile Governance

If you are in an industry that is heavily into governance you need some structure and process around your projects or you could find your Agile projects getting usurped by the culture of command and control. So it’s important not to shy away from the topic but to work with the entities that enforce and monitor governance. In this way you can create something that is fast and easy and not laborious to work with.I work for an Apra regulated organisation and we made keenly aware of our obligation under Apra to evidence documented change when audited. However in all organisations I’ve ever worked in, there are boundaries that bend quite a bit, ways to change things and ways to get by that satisfy governance process without crippling your agile process.There’s almost two alternating schools of thought here which are ‘work within process’ and ‘decide to change the process’. It’s actually pretty easy for my team to work within process. Project approvals, mandates and PIDs that are important …