In part 1 of this series I asked the question, "Are you running IT like it's your business?" Then I highlighted five barriers for preventing IT leaders from being able to transform their IT shop into a well oiled, cost effective machine?
- Resistance to change
- Lack of resources (time, money, and human capital)
- Lack of tools
- Lack of metrics
- Lack of process
What are some of the most common phrases you hear when attempting to promote change within your organization? The top one I hear is "I don't have time", followed by "I don't have money", followed by "I need more resources". These are the biggest cop outs in the world. The reason why nobody has time, money, or resources is because they don't put any initiatives in place that allow them to do anything other then put fires out.
At some point you should reach a threshold of pain and realize that there must be a better way. Everybody is working 50-60 hours, all the projects are late, production support continues to increase, and the users are screaming. Everybody is working hard, but nobody is working smart.
If this sounds like your shop, you might want to take a step back and put a plan together to stop the madness. If you owned your own trucking business and you spent most of your time repairing your fleet of trucks you would probably be out of business. So why do so many IT shops spend countless hours every day in repair mode? It's time to make time, time to spend your shareholders' dollars effectively, and time to maximize your precious resources.
Let's start with time. Where are you spending your time? Do you have any metrics that allows you to proactively manage and control your projects or your production support? In many shops, the main cause of all these issues is lack of a sound project prioritization process coupled with a lack of a resource allocation model. If projects get accepted at will, priorities change like the seasons, and you have no data to show that your resources are over allocated, you will become a reactive culture. If you are not practicing Portfolio Management, you should make that a priority (view this article I wrote on Portfolio Management). If you have no visibility into how much time you are spending in production support, what categories of issues you are encountering, and how long it takes to fix issues then you should make change management a priority. If you are meeting with the business to discuss the next wave of new projects and do not have a clear picture of your resource capacity, you need to start practicing human resource planning.
Next is money. Obviously, if you are spending too much time keeping the lights on then you are wasting money. But are you wasting money on infrastructure? Are you still pouring millions of dollars into big name vendors like Microsoft, IBM, Oracle, and HP? Are you paying huge amounts of money for "Gold Support"? You need to start evaluating Open Source alternatives. If you believe in the myths of Open Source, it's time you start doing your homework and read about these 50 Open Source success stories. Oh, and that Gold Support you are paying for each and every product...there are many Open Source Support Providers who can support a variety of open source products at a fraction of the cost. What is better is that these folks earn their stripes supporting customers and are actually extremely interested in helping you resolve your issues. This is their core competency. I wonder how much effort Big Blue would put forth to help a small $100M company resolve its problems. The days of saying, "Nobody every lost their job buying Microsoft and IBM" are long gone. If that is all you are buying you are definitely not seeing the big picture and your CEO might start giving you that look.
Are you still buying rack after rack of servers to support your test, development, staging, and production environments? Have you embraced Virtualization Software like VMWare yet?
And what about human capital? We already talked about spending too much time keeping the lights on and spending too much time maintaining rack after rack of servers. But what about development and testing? Do you have an architecture that allows rapid deployment and reusability? Have you separated your business rules from your applications? If your business rules are embedded in your applications then you are creating additional work to maintain and test your applications thus increasing your chances of creating defects.
Let's say you are a retailer with 1000 stores and you have a business rule for defining what a high volume store is. You have several different systems that use this business rule (billing, inventory, eCommerce site, financials, etc.). Now you want to change the definition of a high volume store. You now have to make that change in each of these systems and implement all of the systems at the same time. This simple change has turned into a project. Wouldn't it be better to go to one place, make the change, test it in one place, and roll? You don't need to practice agile methodologies to be agile. You just need to be smart! My recommendation is invest in your architecture. Create a business rule layer that sits between your applications and your presentation layer. I would go one step further and create a service layer to orchestrate your business rules and allow other applications and/or customers to access your business rules.
Well, I have rambled a lot longer then I usually do so I will pause until part 3 which focuses on Lack of Tools. I will add a conclusion after part 5 that tells you how to prioritize these initiatives and how to get started.
