In system theory there are two basic design approaches on how to implement a system: Top-down (“decomposition”) and bottom-up (“synthesis”). These approaches play a role in many areas – for example in product design, software development or organizational design and are also a hot topic when it comes to the definition and implementation of an IT Service Management system. Often this leads to dogmatic discussions about which approach is right, but at the end such discussions hinder project success – regardless which approach is right. Keep in mind: Both approaches – top-down and bottom-up – can have disadvantages: Top Down tends to reinvent the wheel each time and become a costly & endless project. On the other hand bottom-up often forgets what the requirements are by implementing vanilla processes and tools which don’t fit the needs. In this article I would like to show you why it is in practice imperative to combine both approaches to get to the best result. Let’s first have a look at both approaches:

Top Down: The classic old-school approach

At first glance the Top Down approach is the one which always makes sense. In the context of IT Service Management it roughly goes like this (other top-down approaches are possible as well):

1. First you need to get an understanding of the business process which you want to support as an IT Service provider (“WHY?”). For example this could be the Sales Process.
2. You design the IT Services which support the business process (“WHAT?”). For example, this could be the design of an e-Mail Service which supports the Sales Process and many others.
3. Furthermore you define the IT Service Management processes which support the IT Services, including the IT Governance around it (“HOW?”). Another simple example: In case one of your IT Services breaks down, you need an Incident Management process to recover it as fast as possible. You need to have an idea how to control this process.
4. As the process is organization-independent, you now need to design the functional structure to efficiently support the processes (“WHO?”). Example: You need to establish a Service Portfolio Manager role to support the Service Portfolio Management process.
5. Finally the right tools need to be chosen and adapted to support the organization in the execution of the processes (“WITH WHAT?” Click here for an interesting article about Vendor Selection process).

Below image illustrates the approach:

In theory there is nothing against such an approach, but if you have followed it ever in practice, you know how costly and time consuming this can get. This becomes especially a problem because many of the IT processes that are in focus of an ITSM project get more and more industrialized (typically this would be: Incident-, Problem- and Change-Management etc.). Let’s put it this way: Is there any real reason why an Incident Management process should look in one company completely different than in other ones? Not really. The only reason I could think of is to get as a company a competitive advantage out of it (you differentiate yourself in the market). As this is most probably not the case, you therefore just could buy a tool with predefined templates and build some KPI’s and resolver groups around it?  Let’s have a deeper look at this:

The bottom-up approach

Bottom-up has become very popular in the last years: Usually promoted by tool vendors, it promises efficient IT Service Management implementations by reusing out-of-the box processes (proven by thousands of customer implementations), already built into the tool. These process templates are then bottom-up customized, depending on the organizational structure (role model). Some kind of governance layer is added by using a predefined set of reports including KPI’s, which – if needed – can be adapted. Looking at the graph above it goes exactly the opposite way compared to the top-down approach. Starting with existing tools, that are reused, you get to the bigger picture. Although this approach is very inviting because it’s cost-efficiency, it has several challenges. First of all, it puts the focus too much on the tool (because that’s the point where it starts) and the organizational and governance parts come much later or easily get forgotten – factors that are very critical for a successful ITSM implementation. Secondly, people tend to become “tool-blind” when following this approach: Instead of starting with the requirements (you remember: What are the services I provide? What are the processes and the controls around it?) the further path is already given by the tool which can result in restrictions.

Combining the top-down and bottom-up approaches wisely

Now as you know advantages and disadvantages of both approaches, it is more than obvious that both of them should be combined to get the best result. Before giving some concrete steps, one question to be answered is how much you should focus either on top-down or bottom-up. This depends on a couple of factors:

• Money: If in your specific environment cost is an issue, then the bottom-up approach is usually more cost-efficient
• Time: The same applies if time is an issue
• How much ‘Service Management’?: This question sounds a little bit odd, but you need to be aware if you just want to have a ticketing tool (then bottom-up is perfect) or if you want to build a holistic Controlled Service Environment (->then you need to bring more top-down elements into the design process).
• ‘Uniqueness’ of your IT processes: If your IT services and processes are very likely to look standardized, this is an argument to focus more on a bottom-up approach, simply because it is more likely you can reuse the processes that come with the tool. On the other hand, it is wise to prefer a top-down approach if your processes and IT services are very specific, what is typically the case if they are directly linked to a service which gives your company a competitive advantage in the market.

Generally speaking, it always makes sense to start with a top-down approach. It implies that at least you should have a picture of what business processes you support, what your IT Services are, which IT processes and controls are in scope of your IT Service Management project and which tool might fit these requirements best. In the next step the bottom-up approach should come into play: have a look at the detailed pre-defined processes in the tool. Where they fit your requirements – keep them, where not – change them according to your requirements. If you want to change something, always ask yourself: Do I really need this? Does it add any value? This point where top-down and bottom-up meet each other is also called ‘Fit/Gap Analysis’, from my point of view you get here the most synergies. It brings the best of both worlds together, but it is also challenging because at this point the process consultant and the tool vendor have to talk to each other. Last but not least consider to use a holistic framework for implementing IT Service Management, for example the Controlled Service Environment approach by Glenfis.