The processes are those that allow us to have a “template” that works as a guide for the people involved in the project and, in addition, are the ones that maintain each of the contributions consistent with the project; all this so that once they are done, the management team - and also the field or "operational" team - understand what they did and how they did it.
This is a very important element to develop progress reports and to generate the wealth of lessons learned, without counting that it helps for the morale of the group because its members not only know what is expected of each team, but understand how it is that all Deliverables and tasks interact with each other to achieve an end and how other teams do their part of the job.
It is worth mentioning that the processes used by a team are not only limited to the areas of knowledge used in project management; They can include anything from accessibility issues, to creating documents dealing with business cases or system codes, updating the project schedule, to testing system functionality, and many other tasks that must be done. develop during the realization of a project, even when they are not directly linked to the specific deliverables of the project. Of course, there will also be organizations where a formal process is established to create new processes… but that could be somewhat bureaucratic or exaggerated -and perhaps even pathological-; however, each organization is a world that operates under its own rules.
Regardless of how many and what processes are used in a project, what is most important is to constantly evaluate them. If the goals set are not being met, even if only very little, the processes need to be reviewed and this responsibility falls on the project management team. We have to make sure that the process is refined so that it benefits both the current project and future projects. Initially, we must always be thorough and objective with the processes we are using. If it is required to make a change in a project and especially in one that is already in the execution phase, we have to take the necessary measures and understand that it must be carried (or carried,if it involves several changes), proceed with great caution because we are in unfamiliar terrain - it does not matter how well learned we have the process or how many times we have carried it out… the changes can turn it into something completely new.
But, to minimize both the possible risks and the work that would have to be done, we suggest that you consider these five steps that will help you be sure that you are evaluating your processes very carefully and correcting what is necessary efficiently, without neglecting caution at any time. In this way, the project team can adopt them and move forward because they now have an improved process.
Step 1: Evaluate
What is wrong with the process? Looked at carefully and paying attention to details that at first glance are out of place, the first thing we should do is record where we notice things that do not work or hinder the process. Now, one should not be exhaustive or rediscover the black thread, much less discard any document that refers to it… because this is not the right time to do so. If the project is running, chances are there is not enough time or resources - and most likely there is neither - to completely redesign the process. So in order not to get overly fatigued, the evaluation should focus on the element or elements that are causing problems, those that are "damaged" within the process as it has been carried out up to now. Of course,it may well take much more serious research and discussion among team members to expose this specific part of the process; But once we have identified the item that is not working, then the project leader can determine why it is not. We think that carrying out a review of the history of the process will be of interest and utility during the development of our evaluation; Knowing why it was instituted the way it was made can help us understand why it appears to be not working 100%. Although it is true that the part that is not working, perhaps it is a small portion of the whole process, it is logical to suppose that there will be more steps -both before and after- that would be affected by the changes to be made and, for this reason,we also have to take them into account during the evaluation.
Step 2: Receive feedback and record it
Well, now that we have evaluated the process and have identified the steps of the process that we need to change, as project leaders we should request feedback and suggestions from the project team and some subject matter experts about what could be done to solve the problem.. If a process is being changed, people using it should give their opinion on what might work best, as they are the best source of information to confirm what might work and what would not work at all. These ideas are important for reviewing the process, although on many occasions the people who carry it out may not be able to see the whole picture - especially if some parts of the process intersect with other resources or teams within the project and,from then on, the members of the "generator" team lose track of him. So the project leader should collect this feedback and examine it very carefully so that they can create a validatable review.
Step 3: Sketch
This is the moment in which we put the pencils to work and begin to devise the scenarios of change. We have to pay special attention to consider each and every one of the impacts that the planned change could generate. It is also very important to keep a complete record of all the changes that have been made, so that the people who carry out the process can easily see them. It may be necessary to make a “reference table” or “quick guide” as it is an excellent tool to communicate these changes and help others to use them and to be able to stay within the process as stipulated by the Management Office. of Projects (PMO). However, we have to warn you: sketching cannot be done in isolation and tightly.In the same way that opinions and ideas were received about what could be changed, it is necessary to receive specific feedback about the documents generated in this step and, in addition, the opinions should be from both direct users and those who could be seen involved in the process in one way or another.
Step 4: Communicate
Once the sketch has become the final draft - since we have polished it to the maximum - then the project leader should communicate to his team that there is a revised process. This should be done before effective implementation, but we suggest that it not be done too early. Why? Well, our reasoning is that if we do it well in advance, we run the risk of the team forgetting the important information that we are trying to communicate to them. This communication should be direct and should only contain the necessary information about the change in the process. There is nothing more to add since, at best, the team already knows the reasons why and how the changes were made, as well as everything related to the general process they carry out and their objective; because of all this,In accomplished they only need to understand what is changing within the work or task that they carry out. In addition, you also need to communicate with stakeholders and executives, as it is essential to bring them up to date on the improvements being made and how they will benefit the entire project.
Step 5: Implement
The last step is to launch the revised process. However, it should be noted that it is very possible that an “official approval” is required before starting it, so it must be obtained as soon as possible so that the work on the project is not seen delayed, hindered or detained. Ideally, by this point, all the details have been covered and the resources are ready, and to carry out the implementation of the revised process, only an action as simple as sending an email or calling is required. to a board where all relevant resources are informed that they can begin to use it.
Once all this is done, the project leader can take a moment to relax with the assurance that the project is progressing as well as possible… until someone else points out that there is another part of one of the processes that is not working.
Perhaps what we mentioned at the beginning about the existence of a process to evaluate processes no longer sounds so far-fetched, doesn't it?
