=Paper=
{{Paper
|id=Vol-1985/BPM17industry09
|storemode=property
|title=Engineering Management through M-PDCA in Defense Industry: The Case of FNSS
|pdfUrl=https://ceur-ws.org/Vol-1985/BPM17industry09.pdf
|volume=Vol-1985
|authors=Pinar Bakal,Zeynep Ozturk,Ari Bostan
|dblpUrl=https://dblp.org/rec/conf/bpm/BakalOB17
}}
==Engineering Management through M-PDCA in Defense Industry: The Case of FNSS==
https://ceur-ws.org/Vol-1985/BPM17industry09.pdf
Engineering Management through M-PDCA in Defense
Industry: The Case of FNSS
Pınar Bakal1, Zeynep Öztürk1 and Ari Bostan2
1FNSS Savunma Sistemleri A.Ş., Oğulbey Mahallesi Kumludere Caddesi No: 11, 06830
Gölbaşı, ANKARA, TURKEY
pinar.bakal@fnss.com.tr
zeynep.ozturk@fnss.com.tr
2TrueNord Management Consulting, Beybi Giz Plaza, Maslak Meydanı Sokak No:1/55 Sarıyer,
ISTANBUL, TURKEY
ari.bostan@truenord.com
Abstract. In this study, we present the M-PDCA governance model that is con-
structed and deployed within the scope of Engineering Performance Enhance-
ment (EPE) Project conducted at FNSS Savunma Sistemleri A.Ş. Having experi-
enced 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 divi-
sion to use a standard yet flexible platform for planning and executing the engi-
neering 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 ex-
ecuted at all levels of the organization and compliance to the model is being mon-
itored through regular audits. Daily M-PDCA meetings are being held by the en-
gineering teams and these meetings are supported by automatic KPI reports pro-
vided 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 op-
portunities related to the projects, and manage the engineering effort more effec-
tively. 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 ad-
herence 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.
Keywords: PDCA, Plan-Do-Check-Act, Process Governance, Engineering
Management, Process Adherence Audit, KPI Management, Defense Industry
M. Brambilla, T. Hildebrandt (Eds.): BPMN 2017 Industrial Track Proceedings,
CEUR-WS.org, 2017. Copyright © 2017 for the individual papers by the papers' au-
thors. Copying permitted for private and academic purposes. This volume is published
and copyrighted by its editors.
Pınar Bakal, Zeynep Öztürk, Ari Bostan
1 Introduction
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 vehi-
cles and weapon systems at its own R&D Division, and using its own engineering ex-
perience. 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 meth-
odology as a continuous process improvement approach by business excellence spe-
cialists. 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 M-
PDCA and the approach may differ from other applications for that matter. As ex-
plained in this document M-PDCA is an iterative four-step management discipline of
constantly reviewing the Key Performance Indicators (KPIs) at pre-determined fre-
quency 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 plat-
form in planning and executing the engineering content of the projects.
2 Related Work
PDCA cycle, also called Deming Cycle, is a four step management method for contin-
uous 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. [1], [2], [3]
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.
Engineering Management through M-PDCA in Defense Industry: The Case of FNSS
K.A.Chandrakanth Tektronix Engineering Development, India suggests series of
practices/tools in accordance with PDCA model that can be implemented in an IT com-
pany. As he suggests, “Plan” is the part where all customer requirements are analyzed,
understood and prioritized and schedule and budget/resource estimates are done. Fol-
lowing the “Plan” in the “Do” is the step where they start working on these require-
ments. 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 require-
ments [4].
In addition to the IT companies, there are examples of aluminum foundries perform-
ing 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 [5].
Examples mentioned above show that, regardless of the industry, PDCA method en-
ables an effective management, control and improvement of business activities/pro-
cesses. Although the specific practices they have been performing for each PDCA ele-
ment 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 Problem Definition
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. Un-
der 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
Pınar Bakal, Zeynep Öztürk, Ari Bostan
current engineering management methods for Plan, Do, Check and Act elements sepa-
rately, 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, hard-
ware 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 defi-
nition, 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.
Fig. 1. “As is” M-PDCA Model
4 Method and Approaches Used
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 pro-
ject 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.
Engineering Management through M-PDCA in Defense Industry: The Case of FNSS
Fig. 2. “To be” M-PDCA Model
3.1 Plan
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’ re-
source & schedule plans, reviewed & updated in longer intervals) and Unit/Team Ac-
tivity 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 activ-
ity 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.
3.2 Do
“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 im-
portant 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 pro-
cess steps and defined inputs and outputs for each process step. After that, we clarified
Pınar Bakal, Zeynep Öztürk, Ari Bostan
roles and responsibilities for each process step by using RACI (Responsible, Account-
able, to be Consulted, to be Informed) matrix through workshops with team/unit and
department managers (See Fig 3).
Function 1
Function 2
Function 3
Function 4
Function 5
Function 6
Function 7
Task # Task Input Output Notes
1. Process Step 1
1.1 Task/activity 1.1 xxxx document C A I R I
1.2 Task/activity 1.2 xxx report A R I C
1.3 Task/activity 1.3 R C A I
2. Process Step 2 Interface with 1.2
2.1 Task/activity 2.1 C R A
2.2 Task/activity 2.2 C A R
3. Process Step 3
3.1 Task/activity 3.1 I A R R I SF dependency with 2.1
3.2 Task/activity 3.2 xxx plan C C A R
3.3 Task/activity 3.3 xxx plan C A I R I Interface with 2.2
3.4 Task/activity 3.4 xxx drawing R C A I
Fig. 3. Design and Development Process RACI matrix example
3.3 Check
“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, meet-
ings, 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 perfor-
mance 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 lead-
ers/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 perfor-
mance as the responsibility of executive project management.
Engineering Management through M-PDCA in Defense Industry: The Case of FNSS
Table 1. KPI Definitions and Reporting Structure
Automatic Dept. Technical
Unit Mngr Director Report Content
Reports Mngr Leader
KPI1 : Utilisation rate (%)
Daily PDCA •Time allocation by work package
X
Reports & KPIs •Missing reported hrs
Weekly PDCA KPI2: Task completion rate (%)
X X % of tasks completed on time in the previous period
Reports & KPIs
KPI3: # of late activities
Monthly PDCA # and list of late activities
X X
Reports & KPIs
Work package schedule and engineering hrs status
Heat Map X X X
review
Escalation
X X List of late activities (≥15 days & ≥ 30 days)
Reports
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/op-
portunities related with the schedule and cost of the work package and take actions
accordingly (please see Table 2).
Report Date : 10-Jul-17
HEAT MAP REPORT
Table 2. Heat Map Heat Map Report for All Active Projects
Project Task Estimated Estimated Plan % Eng Hours Eng Hours Eng Hrs Actual % Schedule Eng Hrs
Owner
Space Name Start Date End Date Complete Budget Spent % Complete Status Status
Project 1 WP 1 24.10.2016 30.01.2017 100% 200 197 99% 100% 1,00 1,02 Engineer 4
Project 1 WP 4 24.10.2016 30.01.2017 100% 80 138 173% 100% 1,00 0,58 Engineer 5
Project 6 WP 5 24.10.2016 30.01.2017 100% 24 58 240% 100% 1,00 0,42 Engineer 2
Project 1 WP 6 24.10.2016 30.01.2017 100% 32 44 138% 100% 1,00 0,73 Engineer 3
Project 1 WP 7 9.03.2018 9.03.2018 0% 788 12 2% 0% N/A 0,00 Engineer 4
Project 1 WP 8 27.10.2016 2.11.2016 100% 20 61 305% 100% 1,00 0,33 Engineer 5
Project 2 WP 9 24.10.2016 31.12.2018 32% 70 99 141% 100% 3,09 0,71 Engineer 6
Project 1 WP 10 24.10.2016 30.01.2017 100% 200 395 198% 100% 1,00 0,51 Engineer 7
Project 1 WP 11 24.10.2016 30.01.2017 100% 24 20 81% 100% 1,00 1,24 Engineer 8
Project 6 WP 13 24.10.2016 30.01.2017 100% 120 139 116% 100% 1,00 0,87 Engineer 10
Project 1 WP 14 2.03.2017 15.03.2017 100% 200 49 25% 100% 1,00 4,09 Engineer 11
Project 1 WP 16 4.12.2015 20.03.2018 70% 800 442 55% 45% 0,65 0,81 Engineer 13
Project 1 WP 17 11.10.2016 9.03.2018 53% 480 1000 208% 0% 0,00 0,00 Engineer 14
Project 2 WP 1 24.10.2016 30.01.2017 100% 24 18 73% 100% 1,00 1,38 Engineer 3
Project 4 WP 4 24.10.2016 30.01.2017 100% 100 322 322% 100% 1,00 0,32 Engineer 3
Project 2 WP 5 24.10.2016 30.01.2017 100% 24 17 69% 100% 1,00 1,46 Engineer 4
Project 2 WP 6 24.10.2016 30.01.2017 100% 45 221 491% 100% 1,00 0,21 Engineer 5
Project 2 WP 12 24.10.2016 30.01.2017 100% 120 285 238% 100% 1,00 0,43 Engineer 26
Project 2 WP 13 24.10.2016 31.12.2018 32% 100 109 109% 100% 3,09 0,93 Engineer 27
Project 1 WP 14 24.10.2016 30.01.2017 100% 24 67 279% 100% 1,00 0,36 Engineer 28
Pınar Bakal, Zeynep Öztürk, Ari Bostan
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 re-
lated 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 manag-
ers 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 manag-
ers/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 dur-
ing evaluation.
Engineering Management through M-PDCA in Defense Industry: The Case of FNSS
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.
Fig. 4. M-PDCA Adherence Audit Sheets
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 cal-
culated 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).
Fig. 5. M-PDCA Adherence Audit Dashboards
Pınar Bakal, Zeynep Öztürk, Ari Bostan
5 Results Achieved
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 & bi-
weekly 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, pri-
oritization, 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 sched-
ule/cost/design quality status and hence manage the engineering effort more effectively.
6 General Lessons Learned and Conclusion
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 fac-
tors. With M-PDCA, R&D functional units’ awareness on schedule & budget non-con-
formances 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 estab-
lished 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
Engineering Management through M-PDCA in Defense Industry: The Case of FNSS
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 engineer-
ing project planning in one unit/team, and expect other units/teams to execute their de-
velopment efforts according to the plan generated by the engineering project planning
team.
References
1. Eirin Lodgaard, Knut Einar Aasland, An Examination of the Application of Plan-Do-Check-
Act Cycle in Product Development, International Conference on Engineering Design,
ICED11 (2011).
2. The Plan-Do-Check-Act and PMBOK® Guide Process Groups,
http://blog.sukad.com/20130124/plan-do-check-act-pmbok-guide-process-groups/
3. PDCA Cycle, http://en.q-bpm.org/mediawiki/index.php/PDCA_Cycle
4. K.A.Chandrakanth, Plan Do Check Act (PDCA) Improving Quality Through Agile Ac-
countability, TEKTRONIX Engineering Development India Private Limited.
5. Jeremy Weinstein, Steve Vasovski, The PDCA Continuous Improvement Cycle Module 6.4,
ESD.60 Lean/Six Sigma Systems MIT Leaders for Manufacturing Program (2004).