Every organisation has problems at some point in its lifetime. The evolution of  an organisation involves changes and challenges that need to be addressed in order to improve the structure, procedures, and even the culture depending on the actual circumstances. Tackling a project, creating a project office and carrying out organisational transformation projects are all very important and significant challenges that require collective resolve, the support of management and exceptional communication.

These processes of transformation cannot be undertaken in an individual effort. The simple will of one person does not change an organisation, but it is necessary to combine the willpower, interests and attitudes of everyone so that the desired outcome can be achieved. When facing a process of organisational change, it is helpful to have as a guide, a series of steps that have proven to be effective in the case of such a  process. A good reference is the  8 steps model proposed by  Jonh Kotter in his book “Leading Change", we can briefly summarise the points:

1. Create a sense of urgency: For the most successful changes, it is helpful if the entire company wants it. To ensure this kind of backing and the necessary motivation, it is imperative that a sense of urgency is felt about the need for change.
2. Form a powerful coalition: Work toward gaining the necessary support by creating a coalition of people who, motivated by your ideas and proposals, help to persuade others that there is a need for change.
3. Create a vision for change: Outline a clear and extensive vision that explains the required effort and strategic initiatives that will contribute to achieving this vision. This will support the change.
4. Communicate the vision: Spread the vision and surround yourself with people who support the change and understand the criticality of implementing it. Talk about your vision frequently and set the example as one who wholly believes in the change.
5. Remove obstacles: Reduce hindrances by revising procedures, structures and beliefs that limit or jeopardize the desired change. Reward those who embrace and implement the change speedily and with conviction.
6. Create short-term wins: Produce, evaluate and celebrate achievements and look at how they complement the final results. Nothing motivates like success, especially at the beginning of a project.
7. Build on the Change: Many projects relating to change fail because victory is declared too quickly. It is important to do evaluations throughout the process, and only consider it a success when the change has become a new habit in the organisation.
8. Anchor the Changes in Corporate Culture: To sustain a change in the organisation, it must be incorporated into the core of the organisation and should be reflected in its strategic principles, operational procedures and in its culture.

Remember: Never try to make an organisational change on your own. Look for support, create an optimal environment and work steadfastly.

When considering a poor quality product, with several design or aesthetic problems, and difficulties in determining how it was constructed to begin with, it is quite likely that it is the product of a project which suffered significant complications. This pattern is true for all kinds of products. Ones in engineering, construction, software and creativity. When pressed for time and costs increase, or scope is reduced, the quality is sacrificed.

When planning becomes overwhelming the first element that is sacrificed is always quality. There is a tendency to not do things well, to take shortcuts that will supposedly work with one’s deadlines more easily. The thing is that sometimes when these measures are used, both consciously and unconsciously by the team, they do not effectively solve the issues with time when we encounter them, but makes them more difficult to prevent overall.

When a team is under extreme pressure, there is a tendency to hide the flaws and other weaknesses with product.

The problems appear later, in the implementation and maintenance stages. The rush has now passed, but the problems in the product are there, waiting for someone to notice and address them. As soon as it is time to make some sort of adjustment or do a simple routine maintenance exercise, the problems emerge and the product works poorly or stops working altogether. But this problem is ‘normally’ one for the maintenance team.

Planning complications are unfortunately more common than we would like to acknowledge and they cannot always be avoided. When the product contains ‘invisible problems’ we must be quick to document these problems and not wait for them to arise in later production phases. If aware of a problem deal with it. We must think about those dealing with the implementation and maintenance of the product and not only of finishing the project at any cost.

Always remember: “More haste, less speed!”

Project governance is the framework encompassing all guidelines, processes, decision-making models and tools when undertaking a project.

Each organisation should adjust this general framework to the policies and governance method it has in place. Projects are undertaken within an organisation and should be aligned to the way in which decisions are taken and the corporate culture in which it will be developed.

The project governance framework should be revised during the course of its life-cycle by the project leader and project team; with adjustments sometimes being necessary to suit certain circumstances, developments or experiences.

This is an especially critical issue for major or complex projects as it provides a coherent method that provides definition, documents, tools and the communication of reliable and repeatable practices within the project. It also defines roles and tests the effectiveness of the project manager, while always leaving a framework for decision-making.

Project governance involves the interested parties, policies, procedures, tools, standards, responsibilities and documented authorities. Despite the fact that the framework in which a project is developed aids governance, the team continues to be responsible for planning, implementation, control and closure.

A few aspects of the project governance framework are defined in the PMBoK:

Organizations have a set of assets that are key to project management and which must be looked after and treasured as items of great value within the company. Organizations are sometimes unaware of how important these assets are, even though they form the basis of many of their competitive advantages.

They basically consist of the plans, processes, policies, procedures and specific knowledge bases that are used by the organization during the course of its projects. They include any object, practice or knowledge of the organization, as well as knowledge bases, that can be used when implementing or managing a project.

The assets comprising the processes in place at an organization can be divided into two main areas:

Processes and procedures

In other words, the practices applied within the company for the various project phases.

• Processes and procedures during the start-up and planning: these consist of all the standards applied by the organization and the guidelines and criteria to be adopted by all standard processes and procedures within the organization. They will include the organization’s policies regarding project and product life-cycles, planning models, etc

• Processes and procedures during the implementation, monitoring and control: these consist of the change control procedures; the financial control procedures; the incident and defect management procedures defined by said controls, as well as the identification and monitoring actions to be performed; the communication requirements within the organization; procedures for prioritizing, approving and issuing work authorizations; risk control procedures; and guidelines and criteria for evaluating proposals and measuring standardized performance.

• Processes and procedures during the closing: these are the guidelines and requirements for closing the project, e.g. final assessments and audits, release of resources from the project, closure of contracts, etc.

Corporate knowledge

In other words, storing and collecting information on what happened during the projects:

• Configuration management: versions and baseline of the performing organization procedures, standards and policies.

• Financial data, budgets or man hours for each activity.

• Historical information and knowledge base from lessons learned, registers and documents or historical archives from previous projects.

• Incidents and defects, including their status, control and resolution.

• Data for measuring completed processes.

• Archives and documents on previous projects.

All these assets are key to the organization and should not be left scattered between different files, documents and computers. The organization should ensure they are clearly and accessibly collected for those people responsible for project management in a centralized computer system such as ITM Platform.