500. Project management

In internal element 200 of this guide, we talk about the need for ‘continuous improvement’ as a necessary condition for an organization to adapt to new and ever-changing environments in order to guarantee its survival over time. Continuous improvement is directly related to the capacity of an organization to undertake projects where elements of improvement are introduced. In the following scheme of the WITORG guide, we can observe internal element 500. Project management.

In a ‘good’ organization, and in part of its people, comfort states can be reached, where execute the management processes are designed and implemented, which may seem enough to ensure its smooth running. This happens even when there is a management process of continuous improvement, or continuous improvement routines, within each main management processes or support processes. The reason is not well known, but an organization settles in.

Someone may ask: why change if the organization works? Some people in an organization may feel a certain comfort and affirm: we have reached a moment of well-being or comfort where everything seems to flow without introducing changes. However, in any organization there are daily situations where you must fix, modify or create something new. ‘Project management’ after all. Some examples of cases where there is a need to change something:

• Strategic approaches.
• New alliances with entities external to the organization (partners, customers, suppliers, competitors…).
• A client’s claim or non-conformity.
• Delays in deliveries.
• Launch of a new product to the market.
• Implementation of a new manufacturing process.
• Launch of new services.
• Request by a client of new requirements.
• Rejection of products delivered by suppliers.
• Changes in the suppliers’ conditions.
• Suppliers or customers’ bankruptcy.
• Detection of non-conforming products within the organization itself.
• Detection of internal errors within the organization.
• Cases not included in the management processes.
• Others.

Despite having a good design of the management processes in an organization, when an event like the ones mentioned above appears, normally the person in charge of a management process can solve it with the management team within the operative routines of the same management process. However, there will be cases in which the issue to be addressed, and to be fixed, may require evolving management subprocesses, evolve a management process or even a process map. The goal of project management is to deal with all the projects of an organization with a common jargon, regardless of their origin.

Defined projects and indefinite projects

No organization can foresee in the design of its management processes or subprocesses all the casuistry of problems and possible situations to deal with. In the reality of any organization there are problems or situations in which it is not clear which management process or subprocess  to apply. Not even who person responsible for leading the solution is.

In addition, if they are organizations of clear Taylorist essence, where the distribution of power is established by departments, we find problems or situations where the responsibility of who assumes them as their own and manages them is not clear. How does an organization act in these cases? These are called INDEFINITE PROJECTS.

Within an organization there are formally management processes and subprocesses designed to launch new products, processes or services. These are the defined projects.

Matches between the defined projects and the indefinite projects:

• In many cases, they appear unexpectedly.
• They require the partial or complete participation of people who work in operational management processes or subprocesses of the organizational system, whose load-capacity relationship in the processes or projects is high. Do they have time to meet the new workload?
• Depending on the nature of the project (especially if it is an indefinite project) it is not clear who has to report/document/collect it, who must manage it or what should be the team of people who would participate in the development of the solution. In the defined projects, although the management process may be clear, what people should form the project team may not be so, due to each individual’s load/capacity reasons or other.
• Within an organization, it is possible to live with several undealt cases with projects that are both indefinite and defined which are not undertaken or suffer constant delays. All of them create a sense of lack of control due to recurrent problems, prolonged in time and without a definitive solution. People learn to live with problems.

Not all defined and indefinite projects can be treated at the same time. A common reason for different organizations is the apparent work overload in relation to the people’s load/capacity in it. The cancellation of projects for which a significant amount of resources had been allocated is also usually unexpected. How is the load/capacity relation of the people involved in an organization, regarding the projects’ entry or cancellation?

The organizational capacity’s disposition to undertake both indefinite and defined projects is the way to adapt to increasingly changing environments, as discussed in internal element 200 of this guide. Therefore, it is essential to be aware of the importance of managing the whole of defined and indefinite projects within an organization. After all, the evolution of organizations has a lot to do with their ability to manage projects.

A series of points are exposed in this internal element to describe the minimum conditions necessary to be able to visualize the whole of defined and indefinite projects and how they make an organization evolve.

Need for common jargon for the management of defined and indefinite projects

There are both defined and indefinite projects within the following list of situations (some are already named):

• A client’s return.
• Delays in deliveries.
• Launch of a new product to the market.
• Launching of a new manufacturing process.
• Launch of new services.
• Request by a client of new requirements.
• Rejects of products delivered with suppliers.
• Changes in the suppliers’ conditions.
• Suppliers or customers’ bankruptcy.
• Offers to new customers.
• Establishment in a new market or country.
• Detection of non-conforming products within the organization itself.
• Detection of internal errors within the organization.
• Cases not included in the management processes.
• Evolution of a management process.
• Evolution of the management process map.
• Increase of the KPIs belligerence.
• New administrative, environmental, security regulations…
• Many other cases.

Some of these situations are dealt with through the management processes, departments in some cases, of the organizational system. Others are not considered within the organizational system, either by its magnitude, or by the fact that an organizational system cannot collect all possible cases.

Any new defined or indefinite project is produced by a non-conformity derived from the events mentioned above. WITORG considers that a nonconformity does not have to be a negative fact, on the contrary, when it is intended to evolve it is due to not being satisfied with something. Nonconformism is part of the essence of continuous improvement. Conceptual cases of a non-conformity are:

• Something has not worked within the organization, it is detected and finally solved. It is usually an indefinite project. It is clearly a nonconformity internal to the organization.
• An organization launches a new product, a new process or a new service on its own initiative, a defined project. In this case, something new is created that also responds to an internal nonconformity.
• A client requests an offer of new products, services, processes, etc. In this case, the client’s non-conformity requires something new or evolved. If that client is in the organization’s strategy, his new need will also become an internal nonconformity.

Therefore, from now on, we will call INC (internal nonconformity) both defined and indefinite projects managed within an organization. As the term INC can lead to confusion or have a negative connotation, WITORG Guide invites each organization to invent a term to name the two types of projects. In this way, an organization will visualize through its INC an important part of the projects oriented to point 200 of the guide.

The connection of participation of people in INC with the continuous improvement of any organization is one of the most important events that occur in it. Hence the need for a common jargon.

Each organization has its own jargon. Generally, neither the starting point nor the circumstances are usually the same when organizations are compared. Each one must find its way, considering several aspects:

• Should all the people in an organization participate?
• Should all groups of interest participate?
• Can the implementation project be considered by phases or stages?
• Is it advisable to reward participation and involvement in improvement?
• Are the organization’s current values adequate to drive the improvement?
• Any other the reader wants to add.

In any case, as continuous improvement is the ability of an organization to adapt to the environment and continue to survive, the important thing is to be aware of its need and start the journey from that same awareness.

The term INC could have a negative connotation. Due to the concept’s importance and to give it a positive meaning, an INC could be called an opportunity for improvement, action for improvement, evolutionary action or other proposals. Whenever this helps to generate a common jargon and to evolve an organization, the name is secondary.

Detecting or locating new INCs in an organization

When an INC is detected, whether it can be regarded as a defined or indefinite project, it is not always treated or acted upon immediately. Trying to collect all the existing INCS and documenting them would be practically impossible in most organizations.

When we talk about INC, an organization can ask itself what should be the minimum importance of an event that affects it to be considered as INC. Defining this is impossible and we would fall into grey areas where eternal discussions would be generated. Each organization must establish a minimum, without forgetting the most important issue: if the INC is the vehicle of continuous improvement. This goes for the people in the organization: the more people who are in contact with INC, the more awareness there will be that they are working on continuous improvement.

Once it is relatively clear when we are before an INC, where does the responsibility to collect and document it lie? In some management processes or subprocesses it is known, in those that it is not, it is convenient to assign the responsibility of collecting INC to people who are referents in the organization and are involved in continuous improvement. This indicates the need to give responsibilities in the INC collection when it is not clear at first sight who should lead.

In a Taylorist organizational system it is relatively easy to detect an INC, however, documenting and registering it may mean interfering in matters outside the department or function of the person who detected the INC. In relation to this fact, the following points are raised:

• Can anyone detect and present INC even if they are not from their area of responsibility?
• Are the values of transparency and trust important for a person to present an INC?
• Are there resources to attack all INC?
• What commitments do the CEO and the shareholders acquire regarding continuous improvement and with the people who carry it out?
• What are the objectives, mission and vision of an organization?

Obviously, it is not a simple topic. Each organization must make decisions in this regard. A common jargon to deal with any defined and indefinite projects and that the people of an organization know how they participate in the evolution of an organization greatly simplifies continuous improvement. Therefore, defining a name for the INCS described so far by each organization is considered to be core with respect to the organizational system.

The management of the INC, minimum to establish

This section aims to establish a series of key points to support a minimum INC management (in defined and indefinite projects):

• A simple documentary base, where each INC is numbered, described, targets are indicated and a team is assigned to it.
• The trust and organizational transparency necessary for part or all the organization to detect and collect INC.
• People with the role or responsibility to analyse the INC outside and within the management processes and subprocesses and be able to assign teams to them in case the management processes do not clearly determine it.
• INC load/capacity analysis system and reallocation of resources.

From WITORG’s experience, it is considered important to begin the INC definition in the simplest way possible. Reasons for this:

• When organizations work on major or significant projects (generally defined projects) they use management methodologies and associated software where the true management of the project will take place. In these cases, the INC should only be considered to associate a project’s number, a statement and some relevant data. However, within a defined project, INC can also be detected as an opportunity for improvement within the same project.
• In continuous or serial manufacturing INC of different nature appear due to the different functions or departments and the casuistry present within each of them. If complex or very detailed formats are presented to collect all the possible INCs, writing one will be complex, demotivating and will be avoided as much as possible.
• In routine works of organizations dedicated to services that do not have to do with manufacturing also appear INC of different nature, due to the different functions or departments and the casuistry present within each one of them. Therefore, this point would require an INC design like the concept shown in the previous point.

With the good intention of implementing a continuous improvement system, organizations of all kinds have launched several initiatives that have failed and passed into oblivion. In an improvement system the INC format is a point of little importance compared to the bases on which to build the improvement itself. In any case, it is recommended not to forget that simplicity makes possible the understanding, in the case of defining work tools such as the INC format.

The profitability of the INC

When asked if all the INC must have associated or calculated a minimum return of some kind, the following points are indicated:

• An improvement system aims at the organization evolving and surviving in a medium-term environment. If you think about the short term, you may not need an improvement system. There are organizations that are created for a project bounded in time. Once finalized, these organizations will be dissolved or sold. Is a formal improvement system necessary while developing this type of project?
• Even if an organization is designed to survive over time, if the focus on results is short-term, does an improvement system make sense? This does not mean that the short-term results are not important. Consolidating an improvement system and evolving it is a medium-term job. Therefore, if short-term results are required, short-term improvements will also be required, especially if there are unexpected deviations.
• How do you want to share the results of the improvement with the people who participate in it?
• When an organization carries out improvement activities, both in defined and indefinite projects, it is known from experience that a percentage of them do not report any economic benefit, at least in the short term. Some even abundant losses. And all this even having calculated a positive return for a specific project or INC. A calculation of positive profitability is not a guarantee. Not forgetting that the fact of trying improvements is a value in itself that will bring benefits in the future.
• Of the INCs released, at what percentage would it be desirable to obtain a positive return? 60 %, a 70 %, 80 %, a 100 %? Should the whole of the INC’s profitability be calculated?
• What kind of profitability results from doing improvement activities, fail, learn and try again within an organization?
• What profitability results in recognizing at least part of an organization as within a system of continuous improvement when it is connected to an INC?

The relation load capacity in the INC, the eternal problem

When an organization executes its management processes, it is normal for people to feel a burden with respect to their capacity, or at least that is usually the feeling in many organizations. There are times when, in addition to the workload of people associated with the routines of a management process, new INCs appear or urgent matters to be urgently dealt with due to the damage they may be causing, because they represent a great opportunity or for various reasons.

When a large amount of INC suddenly appears, an organization seems to collapse, feeling, in addition to stress, a sense of generalized lack of control.

The more Taylorist or departmental the organizations are, the poorer the designs of the management processes tend to be and with a greater feeling of lack of control. There are even cases where one department is affected while others seem to continue with a normal life.

Is it possible to treat all the INCs that appear spontaneously at the same time?

Evidently, no. But the fact of monitoring the INC allows:

• Detect them and visualize the new workload introduced to the system.
• Perform an INC prioritization and assign or reassign resources trying to optimize the possibilities of the organization.
• Centre people on what is decided as a priority and momentarily put on hold other tasks.
• To have a system where the review of the capacity load of the INC is frequent and also helps in situations of organizational ‘collapses’.
• Impregnate in the organization the idea of continuous improvement through a more or less organized form of INC management, with the aim of its survival over time.

Each organization has its more Taylorist or more holacratic organizational structure. Assessing whether an organization can manage all its INCs in a centralized or decentralized manner depends on factors such as:

• Level of knowledge needed.
• Size of the organization.
• Specialties within the organization.
• Level of transparency and organizational trust.
• Teamwork culture
• Many others.

Therefore, it is complex to generalize how the INC set should be managed within an organization. Each one should look for a balanced way so that their own INC management does not pose a problem in itself. In addition, this implies that evolving the INC management system may be necessary due to the change over time in the factors mentioned in the previous paragraph. The way to build an INC management system is explained in the next point.

The people and conditions for balancing the INC’s load/capacity

It is complex in an organization to appoint a single person as responsible for allocating financial and human resources to the INC. This is mainly due to the impossibility for a person to master all the necessary specialties. (Internal element 600 explains how the teams work). Below are some points for consideration when performing load/capacity balancing for INCs:

• Create multifunctional committees where the necessary knowledge is represented.
• Assign people a working time for continuous improvement, whether they are participating in INC or not.
• Design a language where people communicate their situation regarding the load/capacity relation, considering the load of operational routines over the INC in which they participate. People should check on an established frequency if they are overloaded or not. This must be communicated with a certain frequency and for a future delimited period. This way, people can volunteer to help and, in other cases, as in need for collaboration. The impossibility of being able to help everyone in everything due to the different specialties and different knowledge required in each INC is clear. However, there are always tasks in which you can collaborate, and it can also be a way to detect training and education needs. The development of this way of working can take an organization to a true collaborative world.

Designing, implementing and evolving a management system for the INC is the task of each organization. Surely, several approaches are valid as to how to introduce this management into the organizational system. This will depend on the size of the organization, the maturity in process management and many other variables. In any case, being aware of the need is the first step.

The INC management, ‘B. quality systems’ and ‘C. systems’

The origin of the INC to be dealt with in an organizational system is very diverse, as mentioned in this chapter. What this guide proposes is to define the collection of any INC in a simple manner, with a statement, description of the problem, objective and, subsequently, the person responsible and the team. This is a core part of the organization to be able to establish a common jargon for the management of continuous improvement, through project management. The collection of the INC is convenient to perform it in a formal and, above all, simple system. Another issue will be to determine which tools and methodologies of project management are necessary for projects of a certain size that were detected and collected within an INC.

The reason for designing a simple INC collection system is due to the following points:

• All or at least part of the anomalies detected through the management processes are collected the same way.
• All indefinite projects are collected the same way.
• All defined projects are collected the same way.

For the management of the three previous points, methodologies or tools from points B and C of the WITORG Guide are used. The organization incorporates these systems as help, guidance or tool for the design of its organizational system. However, the elements from points B and C are incorporated elements, therefore external. If an organization is not satisfied with the philosophies, methodologies and tools incorporated from these points, they can be redesigned or even eliminated and new ones incorporated.

Today, ICTs, with their methodologies and tools, allow simple, powerful ways of information collection and bilateral communication. Many of B’s elements have their origin in the last century. And without detracting from everything that has helped the organizational improvement, they originated in circumstances different from the current ones. Reviewing the systems from points B and C of the WITORG Guide currently implemented in an organization is necessary as part of the organizational system improvement. And taking advantage of the benefits of the new technologies from external element C of the guide is quite an opportunity.

There are methodologies and tools of different nature within B and C such as ISO 9000 and family, EFQM, TQM, QMS, ERP, MES, CRM, lean manufacturing, Toyota system, industry 4.0, PDM, PLM, project management, analysis methodologies problems and a quite long etcetera. These systems relate to INC in some way, but make it difficult for an organization’s continuous improvement common language. And even more, the more departmental it is.

In addition, a simple INC collection system could be nowadays related to all the systems mentioned in the previous paragraph, and easily, as technology allows it so.

Continuous improvement as a management process and project management

The INC, or any other way the reader wants to call them, and the aspects related to them, generate the core element of continuous improvement. Therefore, WITORG concludes that continuous improvement should be understood as a main management process. This is taken from the concept of the main management process described in section 300.

The previous paragraph can generate certain contradictions with what has been explained so far on the structure of internal elements 200, 300 and 500. To clarify, the following points are given:

• Section ‘200. Continuous improvement’, talks about the need to evolve in order to survive. Without entering process management or project management.
• The importance of continuous improvement as a whole leads to question whether to include it as a main n management process of an organization in internal element ‘300. Process management’. Even if, then, it could derive in all management process to include continuous improvement within them.
• Section ‘500. Project management’ should contemplate project management methodologies derived from opportunities for improvement of an organization’s defined and undefined projects:
  • • • First, it would be necessary an exercise to define what are considered an organization’s defined and indefinite projects.
      • Second, the ways to define and collect INCs.
      • Third, the methodologies/tools necessary to manage INCs.
      • Forth, the method to analyze the load-capacity produced by the INC, and the resources management to manage INCs. All this could be considered within a continuous improvement management process.
      • Even if these four routines could be included next within each process management in a process map, each step will require an own focus.