I was asked this question in a break during one of my last trainings. Sadly, I could not find the time, nor a proper situation to answer it in class, so I am going to use this post to do so now.

When a person or a company needs to design a process from scratch, there are always two general approaches:

  • Bottom up – Use the current roles and responsibilities, improve them and build the process outputs around those roles
  • Top down – Start from the process itself, fit it in your enterprise architecture and then think about the fulfilling roles

Now I know that stating the two approaches in that way most probably led you to the conclusion that the second one is a little bit better, closer to best practices, etc. Well, as all consultants like to say, it depends.

Bottom up

When you read the ITIL 9 guiding principles, for example, there is one saying: Start where you are. What does this mean? It means that you should always try to start by checking what works well from the current set up and only improve what is not. In short, don’t throw everything and start from scratch, but build on your current strengths.

The most important advice here is to build in controls. If you reached a point where you need to define a process, instead of just do the things as usual, then you are probably not performing well and both your employees and customers are complaining. So, think about what must be produced, then how this output can be controlled, based on what can and should be measured, and from then on define your process. Sounds easy, right?

Well, as with all bottom up approaches, you might reach a point where the roles are defined properly, the output is more or less OK, but somehow the situation is not improving. This is because processes are connected with each other and they are also a base for delivery of the services, so you will have to step up and see the big picture.

The biggest advantage of this approach is speed. If you start with a clear goal and work hard, you can have your process designed and running within days.

The biggest disadvantage is that in the long run you have to step up and see the big picture and if the picture isn’t right, you might have to change your processes again and again until it fits.

Top Down

When you start from the top you will look at the process from the perspective of all other processes and services, which provide inputs or make use of its outputs. This is a great approach, especially if you want to define and maintain a good value chain. In the end, you will drill down in the process itself and define the roles and responsibilities which are needed to deliver the promised output.

The biggest advantage of this approach is the integration with all other processes and services and the ability to follow the value creation from beginning to end.

The biggest disadvantage is speed. It will take you several rounds to integrate and then several more to define the proper roles and responsibilities.

Practical Guidance

Keep in mind that not all processes are equally important for the value creation and realization. As in the services, you can make a Business Impact Analysis (BIA) and define which processes are critical for your service delivery. You can do this for the existing processes, but also in advance of processes, which are about to be designed. So, why bother?

 Well, I think at this point it is obvious that for less critical processes your preferred option would be bottom up, and for critical ones – top down. Of course, preferred does not mean that you will always do it this way, but simply that you will have a standard approach. As we all know best practice comes from standardization. The more you do it, the better your service delivery will be.

I hope that with this short article I managed to show you what are the two general approaches when you are about to design a process. Keep in mind that designing a process is not an easy task, as processes involve people, tools, resources, other processes and services. So, define your vision, why you are implementing this process, the process itself must not be the goal, then see where you are, make a baseline, set SMART (Specific, Measurable, Achievable, Relevant and Time-bound) targets, make a plan and follow it until you reach your measurable goal. In the end don’t forget to set a process owner, because only he/she will make sure that the achieved level will be embedded in the organization and momentum will not be lost.



Tell me your thoughts in the comments and let’s open a dialog. I would be excited to hear other opinions on this topic.

Consider joining our LinkedIn Group to continue this conversation as well - CLICK HERE
We hope you will consider joining our Facebook Community as well.  Click on the image to your left to visit and join, or you can CLICK HERE


Reading this article qualifies you to submit a request for PDU's from PMI.

This Article qualifies as follows:



For more information on registering your PDU's with PMI - CLICK HERE


At Project Management for Today, we encourage conversation; agree with us or disagree with us, it’s all still knowledge, and we are here to share knowledge. Take a moment to add to the conversation by leaving a comment. It’s an opportunity to engage in the conversation!

If you believe in what we are doing, take a minute to share our articles on your social networks such as LinkedIn and other sites. Use the buttons on the left side of the page.

This article features content from a “Contributing Author” to the Project Management for Today Community. This content is published on this site with the author’s explicit permission. As with all articles on this site, this article is protected by copyright. If you are interested in becoming a Contributing Author to this site, you can learn more by reading the information HERE


You may republish this article in whole or in part with attribution to the author and a direct link back to the full article on this site. Attributions MUST include a hyperlink to the original article, as well as a "Canonical Link" reference embedded in the <head> section of the page.
#pmfortoday / #projectmanagement / #pdu / #pmi / #pmo / #pmbok / #pmblog / #pmoblog / #pmp / #pmi-acp / #pgmp


Nikola Gaydarov

Nikola Gaydarov

Contributing Author

Nikola has been in the IT sector for almost 10 years. He started his career in HP Global Delivery Center back in 2007 and since then has been involved in many different roles: technical consultant, operational manager, transition manager and ITSM implementation consultant. During these years he has worked both domestically and in Western Europe.

Designing and improving processes is his passion. Working with the stakeholders to define all roles and responsibilities is where he finds most of the challenges. Proposing solutions and solving those challenges is his biggest reward.

He has started teaching ITIL® since the beginning of 2015 after successfully becoming an ITIL® Expert. Courses that he has successfully delivered are: ITIL® Foundation, ITIL® OSA, ITIL® RCV, ITIL® PPO, ITIL® SOA and ITIL® MALC.

As a consultant Nikola has gained also a lot of practical experience in Project Management. He used this experience to successfully acquire PRINCE2® Practitioner certification.


LinkedIn Profile – CLICK HERE
LinkedIn Group – CLICK HERE
Download My Resume - CLICK HERE

Articles by Nikola Gaydarov – CLICK HERE

Advertisements B