WITH COST CUTTING EVERYWHERE THESE DAYS, PRIORITIZING IT SPEND HAS BECOME MORE CRITICAL THAN EVER.
To survive, IT managers need to find creative ways to meet customer expectations while keeping an eye on the bottom line. Many companies look at Open Source, SaaS and the Cloud for alternative software/hardware/development solutions to achieve strategic goals.
Yes, there are still some negative perceptions associated with implementing these options within the enterprise. Security, support, and customization capabilities are a few of the concerns that top the list. However, if a thoughtful decision making process is followed when working with these solutions, the perceived risks pale in comparison to the cost-benefit realization.
In a recent blog post my colleague has offered up some great guidelines for choosing the right low-cost or free technology alternative for your enterprise. We are also publishing some guidelines for ensuring that you a thoughtful decision making process is followed. Stay tuned or send me an email (firstname.lastname@example.org) if you’d like an advance copy.
So while Open Source, SaaS, and Cloud based solutions gain momentum as viable options for the enterprise, no matter the technical solution, the question of business impact and the costs associated with transitioning the enterprise from old to new needs to be considered. What can you do to minimize end-user impact when implementing these technical alternatives? Read on….
First, change the things the end users never see. Dip your toes in the water by transitioning lowest level infrastructure pieces first. Transitioning to an open source database solution or building a testing environment in the cloud are not likely changes that end-users will notice.
Take a lesson from Google…use the beta labeling to your advantage. When introducing a new technology look to your end-users are co-creators. Acknowledge that it’s not perfect yet but with some help from those that use it most it can be. The effect of end-users seeing their suggestions become functionality will be infectious. The positive internal PR generated by these people will help promote the tool, ease it’s adoption by others, and help bring a more intuitive application to the enterprise that in-turn requires less hand-holding and end-user training.
Enlist champions and give them responsibility. You can use beta labeling to organically create product champions or you can identify and enlist people upfront. Whatever your trying to implement –an OSS application server, SaaS CRM tool, or whatever – identify people from the stakeholder community that can help sow the seeds of change within their area of influence. Give the champions the responsibility of helping their functional area/business unit embrace and understand the new technology. You’ve now gained subject matter experts in each area that can lend the personal touch to helping with adoption issues.
Thoughtfully embracing low/no-cost technology alternatives coupled with strategies for leveraging your own resources to minimize end-user impact creates an unbeatable value proposition.
How are you being creative about your IT solutions so that you can achieve your goals while going easy on the budget?
Thursday, April 30, 2009
Thursday, April 2, 2009
My company and our consultants have been using Scrum and Agile techniques on both internal and client projects for years. Our adoption has been in an ad-hoc manner and often times behind the scenes without anyone knowing that's what we were doing. Things just got done. I have had the pleasure of taking 2 days to formally learn the Scrum framework and become a certified scrum master. I am using the training to pull all the techniques together and gain a better understanding of how to best use the Scrum theory of delivery with my client projects. During the training I had an "AH HA" moment (as Oprah puts it) - software/product development is an art NOT a science! The principles of scrum center on communication, collaboration, and using a feedback loop with stakeholders to produce a quality product in a short period of time. Notice I didn't mention anything about stages, gates, documentation, or sign-off. Not that a paper trail can't be produced along the way but Scrum is more about focusing team energy on getting a usable product out the door than hashing through getting the right requirements in a document. With Waterfall there is a certain amount of risk mitigation built into the formality of the sign-off process. If the requirements are written down and stakeholders sign-off, the risk of not getting requirements right shifts from the development team to the stakeholders. From the development team's perspective "They (the stakeholders) told us what they wanted and here's the proof". In Scrum people collaborate and come up with the requirements together. The stakeholders provide some high-level product requirements/priorities to set the direction and the team uses demos and stakeholder feedback to make sure they get it right. It's so simple and uncomplicated! The Scrum Master is really more team psychologist than Project Manager. Tasked with enabling each individual team member to speak his mind and foster a sense of shared ownership to complete the team's goal. Not pouring over the Help documentation in MS Project to figure out how to do resource leveling. Team members and stakeholders (via the Product Owner) get to communicate directly instead of through the formality of requirements documents and change requests. Imagine what is possible when everyone is collaborating and developing solutions together. All the innovation that the different perspectives can bring! I'll admit, I may be a little drunk on the Scrum kool-aid right now, but what were thinking taking the human element out of software development and communicating through documentation that quickly gets outdated?