Thanks for that one Aristotle! In addition, you´d better believe it, there is actually no way to improve yourself without knowing how things are right now.
In some sense, pretty much all of us are all aspiring for excellence somehow, doing things smarter and all in all improve. If you are happy with exactly where you are, do not want to evolve, rather just keep things exactly as they are, you can stop reading here. This particular blog post will not give you much. But, then again, perhaps you should read anyway and maybe, just maybe I will inspire you to re-think just a little bit.
Imagine going on a road trip. You get yourself a good car, you decide where you want to go and then just sit yourself down in the car and start driving. Therefore, anyone would like to add a few elements more in this road trip equation. How about considering the actual trip, with distances and other relatively fundamental aspects of transportation?
Unfortunately, this is how many IT organizations are considering development. They have a very clear goal, the have great machinery but instead of considering the actual journey in terms of resources needed, direction and other rather obvious aspects of actually making improvements, they just run as fast as they can. In addition, often even before it is possible to see the actual outcome some other change will be initiated. Also, this create a type of change numbness, resistance to change and several other negative things, actually opposing forces, greatly complicating change. However, this is another blog, let us talk about doing the baseline assessment.
There is a lot to learn about how to perform a good baseline assessment, but to make things extremely practical I would say it is very similar to take a snapshot of something. You get a good enough picture of exactly what you want to change. However, you need to take more photos from different angles. I always use the ITIL approach, studying the four P´s: Process, People, Products and Partners. This is merely to get a structure, the photo angles, to make sure you capture what you need to see in order to support your changes. You need to read documents, look at the tools used, go through training material, corporate messages, but you also need to talk to people, I always use the “grey zone principle”, as long as my map, my snapshot, has grey areas, I keep on collecting information. When I am starting to get the same stuff repeated, I know that I am good. Verification is always needed. In addition, make sure to take away psychological issues such as having people talking with their boss in the same room. This is also another topic we will deal with later, information collection techniques and much more.
So, why is it so damn important to do the baseline assessment? First, of course it is impossible to reach goals if you just try to catch them running, you need to calibrate your efforts, your activities based on the goals, and your unique set of preconditions.
Secondly, trying to improve something by totally replacing it with something else is very contra productive; you will actually impair your IT organization this way. Therefore, you need to make sure you preserve the things you do right, fix the things you do wrong, and implement the things you do not do currently. Of course, I am talking about using available best practices such as ITIL, CoBIT, SCRUM and other popular frameworks within IT.
But remember, do not fix what is not broken!
This illustration explains what I just said, preserve what works, fix what is broken and implement new stuff that will help your organization evolve.
The only way you can do this is by knowing what works, what doesn’t work or could be improved and the things your organization currently are not doing.
Sorry, this post became rather long and I still feel like I have a lot more to say on this topic. But I think that these aspects will be subject for other posts in a while. Let’s do the overview first and then drill down.