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.

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.