In this study, we present the M-PDCA governance model that is constructed and deployed within the scope of Engineering Performance Enhancement (EPE) Project conducted at FNSS Savunma Sistemleri A.Ş. Having experienced a rapid growth in the number of concurrent projects and business volume, the major aim of the firm in undertaking the EPE project was to avoid schedule and cost overruns. In this respect, our governance model enables the R&D division to use a standard yet flexible platform for planning and executing the engineering content of projects, review performance at a pre-determined frequency and forecast the success or failure in achieving business plans and objectives, and take actions accordingly. For this purpose, we designed the model with its four "must have" elements: Plan, Do, Check and Act for all levels of the division through brainstorming sessions and workshops. The model is currently being executed at all levels of the organization and compliance to the model is being monitored through regular audits. Daily M-PDCA meetings are being held by the engineering teams and these meetings are supported by automatic KPI reports provided to the team leaders/meeting moderators. Apart from the daily meetings of engineering teams, bi-weekly meetings are held where work package level issues are being handled with the participation of department managers and division director. The M-PDCA model made it easier for us to foresee the risks and opportunities related to the projects, and manage the engineering effort more effectively. The model is in use for over 60 weeks and weekly audits are performed to measure adherence to the M-PDCA model. Last weeks' audit results indicate adherence levels around 85% which represents a satisfactory level of acceptance of the model. The user feedback that we receive regularly is also in alignment with these observations.
1
FNSS Savunma Sistemleri A.Ş. (FNSS), a joint venture company owned by Nurol Holding Inc. and BAE Systems Inc., is a leading manufacturer and supplier of tracked and wheeled armored vehicles and weapon systems for the Turkish and Allied Armed Forces. Starting off by manufacturing Armored Combat Vehicles in 1988, FNSS has today become a world class company capable of designing and manufacturing a broad range of land systems, modernizing existing vehicles, and providing the necessary training and integrated logistic support for these systems.
FNSS develops its wide range of indigenously-designed tracked and wheeled vehicles and weapon systems at its own R&D Division, and using its own engineering experience. Over the last few years, the company went through a significant growth in terms of both business scope and volume. In the last six years, the number of concurrent programs tripled and the size of the R&D division increased by 400%. To handle such a massive change in the business environment, the company launched a restructuring effort. As part of this effort, we started the “Engineering Performance Enhancement (EPE)” project to enable a better and more effective management of the R&D division in consultation with Truenord Management Consultancy.
In this study, we present the M-PDCA governance model that is constructed and deployed within the scope of EPE Project. PDCA is a well-known and applied methodology as a continuous process improvement approach by business excellence specialists. However, within the scope of the EPE project, the same concept was proposed as a process and project governance model by Truenord, therefore the definition of MPDCA and the approach may differ from other applications for that matter. As explained in this document M-PDCA is an iterative four-step management discipline of constantly reviewing the Key Performance Indicators (KPIs) at pre-determined frequency and taking actions accordingly. It provides a roadmap for achieving business targets and a framework for risk and failure management. The model provides frequent past performance data to the responsible parties and provides a predictive picture for the future. With that respect, we believe it complements traditional gate-based product development planning by focusing on KPIs at task owner and engineering team levels. Furthermore, the model enables the R&D division to use a standard yet flexible platform in planning and executing the engineering content of the projects. 2
PDCA cycle, also called Deming Cycle, is a four step management method for
continuous improvement of processes, products and services and also for problem solving
purposes. It is a widely used tool in the industry today, and highly recommended by the
quality assurance standards ISO9001, ISO/TS 16949 etc. [
During the literature survey, we found out that different applications of PDCA
method are being performed by a wide range of industries. Global IT companies are
one of these examples where PDCA approach is used to come up with a high level
quality product that meets or even exceeds customer expectations.
K.A.Chandrakanth Tektronix Engineering Development, India suggests series of
practices/tools in accordance with PDCA model that can be implemented in an IT
company. As he suggests, “Plan” is the part where all customer requirements are analyzed,
understood and prioritized and schedule and budget/resource estimates are done.
Following the “Plan” in the “Do” is the step where they start working on these
requirements. Verification of the results is done in the “Check” part by simply comparing the
plan and do phases. Differences between expected and actual output are identified at
this step and related corrective actions are determined and performed in the “Act” step.
These actions will be an input to the next cycle where you re-plan to meet the
requirements [
In addition to the IT companies, there are examples of aluminum foundries
performing PDCA practices. These companies define and plan tasks on annual basis to achieve
overall goals. For check, metrics are defined and on daily/weekly basis teams present
their current status. On a quarterly basis these metrics are reviewed and deviations are
analyzed in details. Taking these analyses into account, plans are updated or changed
to meet yearly goals [
Examples mentioned above show that, regardless of the industry, PDCA method enables an effective management, control and improvement of business activities/processes. Although the specific practices they have been performing for each PDCA element differ, an effective governance method is being implemented for both cases using PDCA approach. Keeping the main purpose of each “PDCA” step in mind, several different practices can be used in accordance with the company’s culture and industry profile. 3
As a result of the significant growth in the business volume, number of engineers in the R&D division increased by 80% just in the last two years. During the same period, number of concurrent programs has increased from 2 to 6. Previously, there was not any specific model for the management of engineering activities. Instead, engineers were finding their own ways to manage their tasks, e.g., they were listing and managing their tasks either at their notebooks, spreadsheets or on their minds and hence, their activities were not visible to them, to their managers or to technical leaders. Control, review and approval mechanisms were not clearly defined on unit/team level either. Engineers had the authority to release their documents without getting the approval from related supervisors and even sometimes they did not know who should approve which type of document etc.
Apart from activity management on unit/team level, there was no control mechanism evaluating the progress of all programs together which are running simultaneously. Under these circumstances, it was impossible to manage all of functional and project based efforts growing with increasing number of projects, in an effective and controlled way to prevent schedule and cost overruns and quality problems.
To better understand the improvement opportunities in the engineering management practices, we decided to construct the M-PDCA model and we started by listing our current engineering management methods for Plan, Do, Check and Act elements separately, which resulted in the “as is” M-PDCA model presented in Fig. 1. “Plan” element consists of annual resource plan showing man-power required on department basis in order to develop programs and total ERD budget including infrastructure, facility, hardware and software investments and consumables. “Do” element includes Design and Development Processes defined in the previous years, that should be re-evaluated and updated according to the current organizational structure. For the “Check” element, we were using program schedules supplied by program managers, since the R&D division did not have any design plan/schedule and performance reporting structure (KPI definition, monitoring and reporting). “Check” element consists of 3 different standalone meetings which were not integrated within themselves or to other “Plan” or “Do” tools. Unfortunately there was no structured method being used for the “Act” element of the “as is” model. At the beginning of EPE project, we examined our “as is” situation and discussed our “to be” situation. Based on that, several workshops were organized through which project objectives, performance indicators, milestones and work packages were specified.
After identifying improvement opportunities in the current methods, we determined “to be” M-PDCA cycle elements (Please see Fig. 2). In the subsequent sections, we discuss each cycle element in more detail. Plan is the statement of how activities will be performed in alignment with the resource budget (man-power, time, material, tools etc.) in order to meet the business objectives. M-PDCA includes two sorts of plan; Management Master Plan (includes 5 years’ resource & schedule plans, reviewed & updated in longer intervals) and Unit/Team Activity List (reviewed & updated in shorter intervals).
Management Master Plan was already in use in the “as is” model, whereas Unit/Team activity plans are newly introduced with M-PDCA model. Unit/Team activity plans are derived from high level project schedules. Work packages and engineering hours required in order to complete them are defined and work packages are assigned to related engineering units/teams. Based on the high level project schedules, detailed level tasks are planned by setting the inputs, outputs and interfaces required to complete the work package. Each task must have an owner, assignee and due date. “Do” element of the model assists the execution of engineering design and development plans by providing process maps, standards and procedures. This element is highly important since process mapping is crucial for business excellence: it identifies wastes and areas of improvement, makes work visible in order to improve and orients new employees and clarify roles, responsibilities & organizational interfaces.
Within the context of “Do” element, firstly we revisited the Design and Development Process and updated it according to the current needs, added review and approval process steps and defined inputs and outputs for each process step. After that, we clarified 1 n o itc n u F 2 n o itc n u F 3 n o itc n u F 4 n o itc n u
F C A A R A A
I I R R R R
I C R C I C C
A C A
R 5 n o itc n u F
C I A R 6 n o itc n u F
I 7 n o itc n u F xxxx document xxx report xxx plan
C A 1. 3.1 3.2 3.3 3.4
roles and responsibilities for each process step by using RACI (Responsible, Accountable, to be Consulted, to be Informed) matrix through workshops with team/unit and department managers (See Fig 3).
xxx plan R
“Check” is the part of the governance model which provides a snapshot of the essential information required to review the current status by making use of KPI charts, meetings, reports and feedbacks. It triggers the “Act” part if necessary. Daily M-PDCA meetings, designed to capture the ‘pulse’ of the work area, the previous day’s performance and issues and current day’s targets, are being held by the engineering teams. These meetings are supported by automatic KPI reports provided to the team leaders/meeting moderators via our Enterprise Resource Planning (ERP) and PLM (Product Lifecycle Management) systems.
Three different KPIs are defined and these KPIs are being reported with different frequencies depending on the organizational levels (definition of the KPIs can be seen in Table 1.). Employee based KPIs are reported daily to the team leaders/unit managers, unit/team based KPIs are reported weekly to the department managers and department based KPIs are reported monthly to the R&D division director. Each KPI shows the performance in the previous period i.e. previous day for daily reported KPIs, previous week for weekly reported etc.
Essentially, M-PDCA established a bottom up, performance-driven governance of projects by engaging R&D engineers who traditionally treated overall project performance as the responsibility of executive project management. Bi-weekly meetings are held with the participation of department managers, division director and technical leaders. In these meetings, we evaluate and discuss all programs together and prioritize tasks/projects if necessary and handle work package level issues. Heat map is the M-PDCA element that enables us to follow the project progress, review schedule and cost (engineering hour) status at the work package level in bi-weekly meetings. It basically includes project name, work package name and owner, due date, engineering hours budget, engineering hours spent on the work package so far, and work package task completion percentage. By making use of the data provided by our ERP and PLM systems, heat map displays the current status of a work package with respect to schedule and cost using a color scale. It also helps us to foresee the risks/opportunities related with the schedule and cost of the work package and take actions accordingly (please see Table 2).
Task
Estimated Estimated
Plan % HEAT MAP REPTOaRbTle 2. Heat Map
Eng Hours Eng Hours Eng Hrs Actual % Schedule Eng Hrs Complete
Budget
Spent
Complete
Status
Status Project Space 3.4
Act Problem solving processes, corrective & preventive actions plan revisions, action plans and escalations form the “Act” element. As its name suggests, this element covers the actions required in order to solve the problems that might emerge at the “Check” stage.
Within the scope of “Act”, escalation reports are generated and sent. KPI3, which is the performance indicator showing number of late tasks, is an important measure that helps us avoid schedule overruns. Therefore, KPI3 values exceeding predefined limits are escalated to the department managers and division director regularly. If any task is late more than 15 days, department manager receives an escalation report regarding this situation. If the task is late more than 30 days, then the escalation report is sent to the R&D division director. The report includes number of late tasks together with the related task explanation. Managers and director are expected to examine these reports and intervene in the situation.
Another venue for the “Act” element is the bi-weekly meetings where R&D managers and Technical Leaders come together to discuss project related issues and escalate risks and opportunities where necessary. 3.5
Execution and Adherence Audit The model is currently being executed at all levels of the R&D division and compliance to the model is being monitored through regular audits. M-PDCA audit is designed to evaluate adherence to the M-PDCA practices and elements. Audits are performed weekly by the R&D Planning and Process Development unit members.
An M-PDCA audit consists of four sections: Plan, Do, Check and Act. For “Plan” and “Check” unit managers/team leaders, for “Do” technical leaders and unit managers/team leaders, for “Act” department managers are audited. Respondents answer standard set of questions with predefined weights (different set of questions & weights are used for each element, please see Fig. 4) and an adherence score is calculated for each part. Previously discussed reports and KPIs are also taken into consideration during evaluation. Input collection is taken into consideration and required steps are individually planned.
Output delivery is taken into consideration and required steps are individually planned.
Review and approval mechanisms are taken into consideration and required steps are individually planned.
Task dates support the project plans and objectives.
Tasks are self explanatory. Weights Start dates and end dates of tasks are defined and reasonable.
Owners and assignees of tasks are defined.
Tasks are at least in active state.
Required dependencies are set in the plan.
Variation of task durations is reasonable.
Tasks are planned with considering the resource loading. To calculate an overall score, different weights are defined for the M-PDCA elements and M-PDCA adherence score for each element and an overall adherence score is calculated for different hierarchical levels in the organization (R&D Division Overall, Department based and Unit/Team Based) and dashboards are designed to show weekly progress (Fig. 5). 5
The M-PDCA model has been in place since March 2016. We started with the pilot runs with selected units for the first couple of weeks. The model has been deployed to the entire R&D division (23 units) in 4 months and we have been auditing all units every week since May, 2016. Our target was to achieve 90% adherence to the model. By August 2017, we reached our target at some units & departments and at the division level we reached 85% adherence which indicates that we are on the right track.
Currently we have - an engineering plan for each project, on a single and shared platform, - fixed interval progress reviews at 2 different hierarchical levels; daily & biweekly and - project & performance KPI management to match schedule and engineering hour constraints.
During the execution period, we continuously received feedbacks from the users, the two examples are: “Tasks are visible to the team members and internal communication has improved” and “PDCA deployment enabled effective planning of daily tasks, prioritization, and highlighted critical issues”
We also observed improvements in the KPIs as a result of the implementation of the M-PDCA model: - KPI1; utilization rate increased by 4%. - KPI2; task completion rate increased by 9% - KPI3; number of late activities decreased by 15%
Furthermore, from a project management perspective, it has become easier for us to foresee and track the risks and opportunities related to the projects, manage our schedule/cost/design quality status and hence manage the engineering effort more effectively. 6
The development and implementation of the M-PDCA model provided us with very valuable experiences about engineering management practices. First of all, we learned the importance of behavioral change in order to fully benefit from these development efforts. Secondly, we experienced that communication of these development efforts through all media and taking feedbacks into consideration are two critical success factors. With M-PDCA, R&D functional units’ awareness on schedule & budget non-conformances increased, a high level of transparency regarding performance achieved. However, we had to work on the correct feedback behaviors of individuals, specifically functional managers, when faced with non-conformances. Therefore, we have established the bottom up, performance-driven governance of projects where quantitative progress reporting infrastructure was available, but we had to put more effort on the human capital in order to make the framework produce the expected outcomes.
We learned the effect of each M-PDCA element on the whole efficiency, i.e., how plan element will affect the end result or how important it is to define weights for each element. In addition, we found out that it is very critical to set baselines and scope at the beginning and then manage changes in a systematical way. Apart from those, we practiced the importance of audit on the teams/units, i.e., how important to align audit intervals according to the maturity level on the deployment.
In order to increase benefits of the M-PDCA model, we plan to centralize engineering project planning in one unit/team, and expect other units/teams to execute their development efforts according to the plan generated by the engineering project planning team.