Recently I've come up with a simple approach that brings some structure to the analysis portion of this exercise. I don't have a lot of mileage on this method but it seems worthwhile to talk about it.
This approach is currently aimed at functional areas. I believe it could be applied in a larger context but I haven't given that much thought yet.
The first step is to identify the required outputs for a particular function. Since Information Technology is my field I'll use it in my example. Lets imagine a high tech company that has two different types of internal customers. Administrative/Sales/Marketing/Operations/Etc. (ASMOE) & Engineering/Development. (ED) Both groups need IT services but their needs are going to be different. I'll discuss this more below.
There is a saying in project management that you can choose any two of "Cheap/Fast/Good". What if we apply this rule to satisfying our required outputs?
The ASMOE group needs reliable industry standard solutions that are cost effective. That need for reliability means that rolling out the latest and greatest update to a particular piece of software right after it comes out is a bad idea. It also means that they likely have a lot of automated processes in place that are going to have to be tested and verified any time a change needs to be made. They usually don't want to know anything about the "man behind the curtain". Computers are just tools they use to get their jobs done. Throw in training and it is safe to say that for IT to effectively support this group Cheap & Good are the two best choices.
The ED group is in the business of solving cutting edge problems as quickly as possible. Time to market is often critical and having to wait six to nine months for a new piece of software or some other IT related task to be completed has the potential to cost the company a lot of money due to missed opportunities. IT Customers in this area are going to be highly sophisticated when it comes to technology and capable of solving many of their own problems. In regards to IT they will generally be looking for somebody who they can partner with to help solve complex problems. For this group Fast & Good are the two most important things. Cost should always be a factor of course but it is less important than getting good quality solutions in a short period of time.
Based on this brief analysis it's clear that the two groups listed have different needs. Trying to support both with one monolithic IT organization will inevitably lead to both being unhappy as the approach that needs to be taken to satisfy the needs of each is different. In the case of the ED group you need staff who keep up with the latest technologies and are able to move quickly. Rapid prototyping is a necessity in this space and too much process and planning is going to cause things to grind to a halt.
The ASMOE group on the other hand needs industry standard solutions that are applied in a consistent way so that the exchange of information within the company and with external partners and vendors can take place in a timely and efficient manner. To best serve the ASMOE customers you need employees who are disciplined and skilled in gathering requirements and turning those requirements into services that are cost effective and sustainable. Time to deployment is a factor, but it is almost always less important than reliability, sustainability and cost. ITIL provides a framework for this kind of IT
We human beings love cookie cutter approaches. By that I mean we'll find some success doing things one way and then try to apply that approach elsewhere without fully understanding why the approach worked in the first place and how the initial situation differs from the current one. Bad things tend to happen when this is done. Taking a step back and doing some analysis isn't optional if you want to have any chance at success in business, or life for that matter. Making the Good/Fast/Cheap evaluation is just one possible approach. You could pick any two, three, four, etc factors that seem most applicable to a particular situation and do the same analysis.
Image via Wikipedia
No comments:
Post a Comment