Posts Tagged ‘management’

Technology Planning via Life Cycle Management

In a previous post, I introduced the idea that technology planning and budgeting can be a paradox.  The opposing forces of the business’ need to budget and technologies rate of change, can result in a lack of a coherent trajectory for technologists.  When I was first tasked with the responsibility of managing a technology group, the primary means of developing a multi-year technology budget was to leverage a life cycle management approach.  Essentially we assessed the amount of money spent on equipment and determine the number of years this equipment should provide usable service.  With these two values, we could then fill out a multi-year replacement budget plan.  For instance, if we spent $40,000 on a firewall and it should provide us useful service for 4 years, then every four years we’d need to spend $40,000 to replace the firewall.

The primary benefit of this approach to budgeting, forecasting, or planning is that it establishes a predictable funding schedule.  Of course this schedule is based on the assumption that what we spent previously for the technology, is what it will cost to replace the technology.  Moore’s Law is the chief contributor to this assumption, and for many technologies this assumption is valid.

The difficulty of such an approach is that if doesn’t address incremental upgrades or enhancements, which fall outside the life cycle window.  Another difficulty is that this approach fails to encapsulates features or service differences or opportunities.  For example, when I first started purchasing wireless equipment the scope of this function was narrowly defined to provide an overlay or convenience.  Today, wireless networks are the primary networking medium students, faculty, and staff use for internet connectivity.  Had we solely utilized the life cycle management approach to budgeting, we’d could never appropriately fund the equipment to meet the increased demand and additional features.  A third difficulty with this type of approach is that the default motivation to replace equipment is because it’s funded.

While not perfect, leveraging life cycle management can be useful in developing technology spend forecasts.  It’s relatively easily to construct, give the amount of industry information related to replacement cycles.  However, such an approached doesn’t really provide a narrative or articulate where the technology or an organization’s use of the technology is going.

Making Big Rocks out of Little Rocks

September 25, 2013 Leave a comment

Today, I had a dialog with a visiting consultant about some of the struggles related to the constant demands IT organizations face.  We agreed there are “big rocks” and we typically address these with some significant and often appropriate measure.  However, it’s the “little rocks” which often are neglected and generate ill feelings from our customers.

While many people are familiar with Stephen Covey’s Big Rock analogy … fill your bucket first with the big rocks, and then follow this up with the little rocks.  We shared the assessment that this was a good start, in most of our lives not all the little rocks fit into the bucket.  Whether we are willing to admit it or not, Our bucket … time, attention, capacity, etc … doesn’t exist in a vacuum.  We aren’t static buckets, so even by focusing on the big rocks first, and following this up with little rocks, often we can’t fit in all the little rocks.  So while we have committed to the big rocks, there comes a time where we must prioritize which of the little rocks will make it into our bucket.

This is where the consultant offered a nugget that really struck a chord with me.  His advice is to make big rocks out of the little rocks.  He offered that often there are requests, activities, assignments, or opportunities that share cohesion because with each other.  He liken it to a mash up or a product offering that is made up of several different components.  When these cohesive little rocks are rolled up together, it takes the form of a big rock, and in turn gets more of our attention.  The consultant cautioned that by building big rocks out of little rocks, we don’t necessarily address the question, how do we not neglect the little rocks.  Rather, we have addressed how we prioritize which little rocks we will address and which we have to neglect at the moment.

The other benefit of this idea, is that we can communicate our framework … focusing most of our effort on the big rocks.  By telling customers and partners where our effort will reside, we essentially inform them that there will be rocks which will be neglected.  If we also offer the insight that little rocks can be made into big rocks, via cohesion, we invite our customers to assist in finding the cohesion that brings little rocks together to build big rocks.  Hopefully the invitation for others to participate in identifying the cohesion, will result in more of our time to tackle the little rocks that don’t necessarily share cohesion with other little rocks.