This chapter comprises five short descriptions. It will go into what constitutes success factors in change processes and cooperation with different types of customer. It will also show how we dealt with different tasks in capability development and also some of the difficult situations we found ourselves in. What is important is to find a way of ensuring acceptance in change processes.
Change processes in operations often come about just at the time when its employees find themselves in situations of great stress. Changes required in order to ensure long-term efficient working practices. Communicating and raising understanding of the necessity of adding even more stress to a tense situation which will also only likely show some return several years down the line is a delicate issue.
Capabilities are developed over time. Work has always been conducted with capability development at Saab in one way or the other. During the past 15 years however, there has been a focused and strategically based initiative to develop all capabilities so as to keep the company and its operations in balance.
Several questions regarding the standpoint to be adopted during change processes need to be answered:
What can be rectified in a short time and how is enthusiasm for making changes established in an organisation? What will take a long time to change and how are needs balanced against the available resources? In a complex organisation, capabilities must be developed with a long-term approach and with consideration to what is realistic to achieve!
The working procedure regarding capability development was changed at the beginning of the 2000s. It would involve a long-term, continued control of the content, economic follow-up and introduction of business cases which would result in increased focus on monitoring economic value.
The author recommends the following texts that relate to this story: In chapter Ensuring long-term operations capabilities under the heading Capability Development in an International Environment, under the heading Management & control of capability development and under the heading Planning and implementing capability development.
The text refers to the highlighted areas in the journey of change in the aircraft industry
When, at the beginning of the 2000s, the decision was made to change financial resources management, the development of methods and tools and product development within all 14 technical areas, the entire technical organisation was informed of the new routines and that new people had assumed responsibility for them. The information provided on the change also explained the importance of good feedback. The incoming suggestions would be looked at in detail and the decisions would be made within a month. This was to be the beginning of a long-term, constant capability development.
In order to ensure success in capability development in a large organisation, it is important to look at past and current conditions but above all how the company should look in the future in order to achieve all of the business and company goals that have been defined in the organisation.
A great deal of effort was made to develop a project management handbook which would form the basis for a working procedure that takes a learning approach in order to systematically transfer experience and methods from past product development projects to future ones.
When embarking upon a change project with great ambitions regarding capability development, there is a series of important factors which help get it off to a good start. This is why it is so important to ensure a proper project kick-off at all levels.
The development methodology to be used in the project must already be specified so that the different development teams can start their work practically without having to discuss first how they going to do things.
Are their success factors in the change process for the capability development working procedure? This section will go a little further into this subject.
When, at the beginning of the 2000s, the decision was made to change financial resources management, the development of methods and tools and product development within all 14 technical areas, the entire technical organisation was informed of the new routines and that new people had assumed responsibility for them. The information provided on the change also explained the importance of good feedback. The incoming suggestions would be looked at in detail and the decisions would be made within a month.
Over 2 months, over 400 suggestions involving different types of needs for developing methods, tools, software, development environments, etc. as part of product development came in. The suggestions covered all of the 14 different technical fields. Going through all of the different suggestions was a painstaking task.
Thanks to the excellent descriptions of the strategic direction the business areas should take over the next 10 years, we had a good basis on which to make different decisions with long-term consequences. The documentation to be relied on related to the business plan, the strategic objectives described in different operational plans and the various technical planning in force at the time.
We had also come up with suggestions for guidelines regarding which technical areas and types of technology should be developed in order to increase capabilities within the company.
Before changes in working procedures and the capability development, we had also introduced a new process for preparation and decision-making. This new process was a model which weighted and evaluated decisions based on technical complexity, effectiveness for the company and improved technical and product development.
These evaluations consisted of criteria which were both achievable and workable both short-term and long-term. Particularly important for these evaluations was also whether the technical solution new working procedure, etc., had the right timing to be introduced and implemented. It was particularly important to ensure acceptance in the company for new working procedures and methods which should be seen to have a positive effect on both increased capabilities and value streams across multiple technical disciplines. It was, of course, essential that the changes resulted in long-term improved capabilities of the current technical areas.
At all times there was an economic framework which had to be adhered to. This was one of the criteria upon which decisions were made. Nowadays this seems obvious, but at that time there was not such a great understanding of why such limitations were required. Everyone thought that “technology is so much greater than the economy” back then.
A small number of individuals, who were the change leaders, did the work. We involved different specialists and managers from product architecture and the most experienced, proactive people from the technological areas in order to help evaluate the suggestions.
It became clear early on that most of the suggestions could not be implemented due to various reasons. Many of the suggestions were too comprehensive or had a bad or no business case at all. It was not always possible to find acceptance to introduce new working procedures either. Sometimes the technical optimism was too high or there was a lack of maturity in the technology, etc.
Many of the suggestions could be used by putting them together with other suggestions already underway in the value streams. In other cases, it was possible to take certain parts of different suggestions and put them together, e.g. 25% of the content from one suggestion, 40% from another and 35% from a third proposal. This resulted in good value streams and a specific, good business case.
As a result it was possible to achieve good cooperation between different technical areas, contribute positively towards the value stream in development work and even solve difficult technical challenges.
For a certain period of time, the process resulted in the exchange of harsh words. People questioned everything including the decisions themselves, the content and the new working procedures. In some cases things even approached the ridiculous such as using business cases when selecting projects within technical development.
Would it be possible to cooperate beyond the boundaries of the separate technical areas? In a way, there was a certain reticence to work beyond one’s own technical area which meant that many people did not want to work in areas they were not fully comfortable with.
A large number of suggestions involving technical development were packaged as a limited number of capability development project. The people who had made the suggestions and their line managers were informed that if they wanted to fulfil their part of the technical development, they would be required to cooperate with other operations and technical areas. The expectation was that those involved would also agree on a new project specification with the requirements for the implementation of the capability development and would describe in particular how the implementation and development should take place and could develop over time when viewed as part of the value stream.
Once it became clear that the new working procedure would no longer be discarded, we noticed a very creative and good ‘working process’ between those involved. The result was that practically all of the suggestions that had been repackaged were implemented with excellent results.
In order not to lose control of the new working procedure and control of the capability development project, it was essential for some of the change managers to be responsible for the change Project steering group.
One conclusion that can be drawn from this section is that it is important to think through how change processes should be implemented and how decisions should be made, but most of all it is important to be consistent and resistant in the face of difficulties.
Of course it is also essential that those involved have enough knowledge to make the decisions required and what consequences they may have in the company in the short-term and long-term. Pedagogical, proactive cooperation will take you far.
This section will summarise the factors required in order to be successful in capability development in a large organisation. It is important to look at past and current conditions but above all how the company should look in the future in order to achieve all of the business and company goals that have been defined in the organisation.
In order to be able to organise a change process in a realistic manner, you have to know which people and operations have been leading or supportive of the collective competence and which have been a driving force.
There are many different ways of organising change processes in large, complex organisations which can have varying rates of success. When product life cycles are extremely long and the products are very complex, the requirements for well thought-out value streams and the comprehensive management of product life cycles also need to be added. Developing capabilities for time frames between 1–25 years demands specific requirements, not least the people meant to work with this type of operation.
The people who will drive long-term change processes must have certain personal characteristics such as being supportive and flexible and should be prepared to give advice. They should be able to provide solutions thanks to the way they work. These people should also have a certain authority and mandate so that the organisation will accept their methods, decisions and aims as part of the capability development work.
One further requirements is that there is a clearly-established and implemented decision in the management function for the allocation of financial means for capability development for several years ahead, and at least a decade.
Management in capability development also requires certain capabilities in people who need to manage the following:
This section will give a couple of examples of how to transfer experience and methodology from former product development projects to future projects.
A great deal of effort was made to develop a project management handbook which would form the basis for a working procedure in order to systematically transfer experience and methods from past product development projects to future ones.
The handbook was designed so as to show how to work in a practical manner with project management. It could be described as a sort of “experience cookbook”. Training was linked to the project leadership handbook which covered several training steps. All project managers were expected to go to training to learn how to work on a product development project.
This, however, is not enough, and project managers must also make time to find experience people for recurring guidance. Training is always carried out in real-life situations, something which is as important as ensuring a good network of experienced people available to ask for advice.
In conjunction with the follow-up and development of core value work in step two, the task was oriented towards driving and working as part of a product development project. In connection with this, we also produced practical guidelines for how to solve different tasks and how as a project manager you should deal with different situations you can find yourself in.
The following summary offers practical advice which has been developed over the years as part of product development projects. It can be seen as a checklist for different success factors which will make sure the project is effective and which have been built into ordinary working procedures.
To ensure clear start-up meetings at the calculation and project launch stage, a number of basic preparations and choices must be made.
Convey the customer’s (internal and/or external) expectations so that all project participants get the information.
This entails employees knowing what is to be delivered to them, by whom and when. In addition, it is essential to clarify what an employee should deliver, when and to whom. It is especially important to clarify what can be done to prevent unclear content in deliveries, delivery schedules, etc. and unclear feedback.
Before project kick-off, it is important to clarify how the requirements, partial goals and goals should be implemented and how this should be communicated both internally and with the supplier. This includes specifying the consequences if the agreed obligations are not complied with.
In order to remove difficulties in communication and cooperation, it is essential to identify and capture common problems before they arise.
The conditions which have enabled us to develop new working procedures are built on the continuous work on maturity development which are updated according to the current requirements in different ways. The work with CMMI is an example of working on a broad front within the entire organisation.
Before the implementation of lean and value stream analysis, a number of lead times and systems/project planning analysis were carried out.
After that, comprehensive, rational project planning called "Grönsaksbladet" was introduced which would feedback experience in all development projects from the middle of the 2000s onwards meaning that value stream analyses were built into the working procedure.
"Grönsaksbladet" was introduced which would
After this initiative, lean principles and certain lean tools were introduced which made effectiveness in the value streams primary and at the centre of focus.
In order to fulfil requirements from the armed forces, a learning-based working procedure at all levels needed to be found. This was needed to be able to fulfil the requirements and deliver “overall capabilities”.
Success can happen in many different ways. One way is to be perceptive, prepared to cooperate and make use of other peoples’ experience. The description below is a note on cooperation with customers (both internal and external).
Some examples of good questions in this context are:
Once you have and understanding of the overall concept, developed a close relationship with the customer regarding requirements and needs, and understood the restrictions and constraints affecting the situation, it is now time to translate the needs and requirements into different capabilities and realistic technical solutions. Concept work and different types of operational analysis that need to be carried out require both the customer and supplier to cooperate in different ways so that understanding and insight can grow gradually and finally be turned into practical solutions.
The type of cooperation has an important bearing on the levels of learning. One form of cooperation which is very effective for joint learning is the integrated product team. This type of team may be made up of a customer in the form of a requester or user together with different supplier skills, e.g. analysts for operations analysis or technical specialists.
This working procedure – learning through participation – should carry on during the entire process from the concept through to delivery and subsequent follow-up. Naturally the customer/supplier roles will change over time. This in itself can also be a good working procedure for learning, with successive refinement of the product in a value stream followed up by continuous “lessons learned”.
Some of the most important moments during the early stages of cooperation which promote joint learning are when the participants try out different concepts within planned scenarios. This could, for example, concern how combat commands could be implemented in different threat/geographical scenarios the product will be operating in, what the operational performance required for the entire weapons system is and which characteristics and performance the system needs to have in order to survive in different threat scenarios.
The types of cooperation can be very varied, but different types of simulation exercises which play out sequences in different planned scenarios provide both understanding and a drive to learn.
A learning-based working procedure means communication between people, and socialising with other employees, customers and suppliers gives perspective and experience. Reflection also helps with learning as it gives you the perspective and opportunity to modify how you do things if you ask yourself lots of questions during your working day. Were the technical solutions sufficiently accurate? Will we stick to the budget if we continue to work in this way? Will the customer accept it if we don’t manage to finish in time?
One method to deal with this type of issue might be to carry out value stream analyses to check we are working in the right way. This might be the introduction of lean thinking in how we make use of resources. This might be continuous work with “lessons learned”. It might also be the exchange of experiences on different levels in one’s own project and from drives and reports from customers and suppliers, etc.
It can be seen that the following questions can form the basis for a number of success factors if we just make sure we concentrate on them.
This section describes different types of success factor which provide an advantage and effect when running change projects with the aim of creating lasting capability development.
At the start of the 2000s, a small yet well-formed group was put together with the full support of the business area management group which would steer capability development long-term. This group has an important influence and large scope skills-wise and also has authority and great discipline skills in operations. This has been one of the basic conditions which has meant Saab has enjoyed great success in capability development. The initiatives for both the operations and technical development were unified in a way which benefited the business area as a whole. There was a definite will to change operations but at a reasonable cost.
When embarking upon a change project with great ambitions regarding capability development, there is a series of important factors which help get it off to a good start.
This was why it was so important to ensure a proper project kick-off at all levels. The development methodology to be used in the project must already be specified so that the different development teams can start their work practically without having to discuss first how they going to do things.
It is essential to put together a good development team, both regarding skills and questions on core values. A project needs to be managed in the spirit of good collaborative capabilities so that the team feels and has clarity on the mandate required for success.
To do this, it is important to have clear strategies and objectives for the project and to have a well thought-out plan for how the implementation and imposition of the results should happen.
It is also essential to agree on the results and deliveries to be carried out as part of the project in regard to the person setting the requirements and the recipients of the results of the change project.
Informal leaders must be sought early on in the project work; these can then act as mentors when implementing any new working procedures or information systems. Leveraging the network of personal contacts within a project can often be key in enduring that the project is successful. It is also essential to make sure that the collaborative forms have short decision paths in the value stream that the project is a part of.
In order to work in a sound way with regard to engineering, it is essential that all participants have the necessary knowledge and training in systems engineering. This is required to understand the overall picture in the product development work itself.
For a change project to be successful, it is crucial to make sure that the capability development project is well-rooted in the operations. A good way of doing this is organising visits to other companies and operations and see how they experience this new working environment and modified working procedure. In change processes, it is also important to make employees understand that there needs to be a balance between technology and operations development with the benefits and economic funding.
Anyone joining operations should be given the time to find out more and be told about the changes underway and the entire operations they represent. The area with the new working procedure and information systems must participate actively in the change process.
It has been proven many times that ‘getting in’ project leaders for a capability development project from the other company involved to use and manage the results of the project increases the possibility of the project becoming a success considerably when compared with getting in someone from outside.
In order to manage the project results correctly, all of the working procedures which have been developed and which improve work in all of the value streams must be accepted by the managing PM&T organisation. It is important to ensure that there is a comprehensive responsibility for managing and developing processes, methodology, tools, information and information systems.
It has been shown that if you introduce operation principles with lean thinking as a basis early on, this has steered decision-makers at all levels. It results in very large positive effects for both short lead times and economic rationalisation. We introduced a meeting culture with short, structured meetings which show the required tasks and any deviations early on.
Working in close conjunction with partners and suppliers is an everyday, important task. It is all about finding ways to come up with agreements and contracts in order to have access to the right subcontractor skills over the entire delivery life-cycle. It is also important to review the methodology, calculations and production methods used by the subcontractor before signing any agreement.