Kyle Ohme — In the life of a dot com

Can I become a happier person with better time management?

Wow - Recently I have really felt the pinch of time.  I have lists and lists multiple pages and tablets deep that acquire new tasks faster than I can remove them.

I am a list person - I have lists for things I need to do today, this week, month and year.  I have lists breaking my day down by how long I expect the task to take so I can fit it into a time slot when I have a free moment.  I have systems to determine long term goals and dependent tasks. I have lists created for things I must pick up next time I go to the store grouped by how close the stores are and what time I have available. I have sliced and diced things so many ways in search for the perfect solution more times than I can count. Excessive – possibly .. but our success is so often tied to time. Success of a relationship, carrier, friendship and overall wellbeing.

I have been working on a better overall time management involving breaking down my time into “goals” first. Picking three goals from my overall yearly goals (work related) … Breaking the goals down into objectives .. breaking the objectives into milestones and breaking the milestones back into tasks. In the mean time I am also using the Drucker time management assessment process for the next three weeks to better align my time with my tasks. You can find more info about Drucker here http://www.friendly-ware.com/dtm/whyShldCr.htm

Time management is not a new concept to me or will this be my last attempt to find a better model.

Peter Drucker “The output limits of any process are set by the scarcest resource. In the process we call “accomplishment”, this is time … Of the other major resources, money is actually quite plentiful … People … one can hire. But one cannot rent, hire, buy or otherwise obtain more time.”

More to come …

  Ummmmm beerrrrr.

Welcome Beer Friday!

So I’m sitting behind my desk right now with a Moose Head in my hand reflecting back on the week and scrambling to get a few things off of my plate before the weekend. Last week was the first day of Beer Friday – a portion of the day sliced up and set aside to hang out and talk about projects and up and coming ideas. (Yes Rob, We know =)  Happy hour is great but lack of white boards, pressing schedules and other distractions results in less productive beer time.  Besides, who wants to take Friday off now? 

We joked last week this was probably the fastest we have implemented a policy change in our history of a company. I of course welcome the change and look forward to talking to everyone about our next big idea. (Come on, it involves beer!)

So far? All I hear around the office is “drinking beer, cant get much better” – Brad =)

Stay tuned!

Just for fun …

(Sung to the tune of Doe, a deer)
Doh!…the stuff that buys me beer
Ray, the guy who sells me beer
Me, the one who drinks the beer
Far, a long run to get beer
So, I’ll have another beer
La…I’ll have another beer
Tea, no thanks I’m drinking beer
Which will bring us back to Doh!

More fun Simpsons fun:
http://quotations.about.com/od/funnymovieandtvquotes/a/simpsonsM.htm
http://homers-beer-run.freeonlinegames.com/

What’s the point of IT Policy?

When I talk about IT policy I am not talking about a step-by-step guide on what to click on and how to perform a particular task.

In my opinion IT Policy it the process that one must go through which in tales the entire change management, release management and testing process. Policy is constantly evolving with time and used as a guide to assure the proper steps have been followed.By following proper policy one can start to improve on IT value and a more focused approach to IT services in terms of error rate.

Some stats that I have seen in the past point to about 85% of all error within the IT infrastructure comes from human error error that I would contribute to poor policy.

If by following an outlined policy and a issue arises during or after the process it only means one of a few things.

1. The policy was not followed and its a human issue (deal with the human element)
2. The policy must be change to incorporate the additional change (reevaluate the policy and add missing components)
3. The policy was incomplete in the initial roll out(appropriate time was not given when outlining the policy rework the policy)
4. Missing policy (did this process cause an error then create a policy for the future)

Take for example the following: We roll out a change to an IIS configuration to a live environment, the policy helps identify the possible issues with this roll out by outlining what applications this change touched, what areas to test and how to assure the change was successful. If the process fails, it would fall into the 4 outlined issues above and we would have to change policy to assure this process does not happen in the future. This also opens the door for automated policy management insuring that all touch points are tested and if missed added to the automated testing policy.

In our environment, policy is not rolled out to inhibit change rater speed up the process. Nor does our environment justify a full blown change management sign off procedure (yet), however we are starting to look heavily at releasing ITIL in a staged and appropriate manner for our size of an organization. In doing so we need a way to identify critical changes from non critical changes, by outlining the above in a manageable way, we ever so closely become in line with ITIL.

As you can see from above, this is by no means complete nor is it meant to be. It not a new concept, its a simple concept that should be used as a repeatable means to create policy and help identify critical issues. IT is inherently identifying patterns having better control over repeatable processes assures we are able to handle critical issues in a way that will not interrupt routine day-to-day changes and tasks but puts emphasis on identifying patterns to help build policy.