30 Aug 2005

Create your methodology based on a standard framework (Part2)

by Lucas Rodriguez Cervera of Nevant

This article, the second of a series of three, gives some tips on adapting and
documenting a methodology based on a standard framework such as ITIL or PMBoK.

In the previous article I explained why it is a good idea to create a methodology based on a standard framework
and highlighted the criteria to choose the most convenient one. In this article I will give some tips for the
adaptation and documentation of the methodology.

Understand the framework

Once a framework has been chosen it is time to start building the methodology. The first step is to acquire a
general understanding of the framework, a holistic view of its components. You must have a clear idea of its
scope and boundaries. It might be useful (if you already have some formal processes in place) to carry out a
mapping of your processes to the standard and perform a gap analysis. This is not necessary if you approach the
project as a reengineering project, building the new processes from the ground up.

Build a roadmap

Once you have a clear vision of the standard framework's scope and your current situation, you have to define
where you want to get (the scope of your methodology). This means that you must have a clear vision of your
organization once the new methodology is in operation. You might find that some processes do not apply to your
organization or are too sophisticated for your needs.

Be realistic. Take into consideration the resources you have available for the project and the timeframe. Be sure
that this strategic vision is known by all people involved in the project and understood and shared by the initiative
sponsor.

Now you know where you want to get and the objectives of the project have been defined, it is time to plan how
you are going to get there. You can face the project in two ways:

– Once-off delivery. The methodology is only only deployed once the full scope has been achieved.
– Incremental delivery. The methodology is deployed in several iterations, each of which releases a set of
processes.

Although the once-off approach can make sense when the scope of the change is limited, I believe an iterative
approach increases the probability of success of the project. Try to get some quick-wins by choosing for the first
iterations those processes that add visible value or solve a known problems. You will learn with each release and
apply that knowledge in subsequent iterations.

Nevant – The link between processes and results Pag 1

 30 Aug 2005

Adapt and detail the processes

Standard frameworks are general purpose. In order to be useful to a wide and heterogeneous set of
organizations they provide best practices expressed in general terms. It is your task to convert that into
actionable pieces of work. After understanding the process as described in the framework, you will have to
determine how you want it to be carried out in your organization's context, determine the roles that will be
responsible of executing it, the tools that will be used to facilitate it and the documents, information, objects, etc...
that it must deliver.

Document the processes

Once the new processes are clear, they must be documented in order to facilitate their communication to the
people that will be executing them. The objective now is that the process is executed in the real world according
to the new process definition. This can only be achieved through process understanding and buy in of the people
who carry out the process, and good process documentation is key for this.

Process can be documented in a wide variety of formats with several tools (from MS word to metoCube, a
process documentation tool developed by us at Nevant). Whatever format and structure you choose for your
process documentation, always try to keep the following in mind:
– Process documents must be easily accessible. If they're not, people won't spend time searching for them.
– Process documentation must be easily navigable. If people don't find the concrete piece of information they
are looking quickly, they will probably desist or waste valuable time.
– The tools and templates needed to carry out the work described must be easily accessible from the
documentation.
– Complement textual process descriptions with diagrams.

Lucas Rodríguez Cervera is founder of Nevant – Process documentation software a company specialized in
delivering process solutions to knowledge based companies. They pioneered this concept with metoCube.

Nevant – The link between processes and results Pag 2