Within this session, Mr. Nen will bring us his sharing on the scope of work of a BrSE and some notes for a BrSE for Japanese market – opportunities and challenges for BrSE.

1. FJP-Offshore Working model
Project Management Sharing
Tokyo, Dec 2016
1

2. 2
Working Scope for BrSE Team

3. BrSE Main PIC:
- Requirement Investigation
- Scope Definition
- Make Specification and Basic
Design (Optional)
- Evaluate quality of Input,
Dependencies to help reduce
risk
Offshore Main PIC:
- Communication support (Report,
Q&A…)
- Product Review (Directly or
Understanding then explain)
- Pre Acceptance Test
- Support on Honban Environment
testing
- Bug Fixing follow (Reproceduce,
bug content explain)
Working Scope for BrSE team (V-Model Base)
①Assure Input Quality
② PIC of Upper Stream
③ Assure Product
Progress
④ Communication
Support
⑤ Product Inspection
⑥ Verification Support
BrSE Working Scope
Implementation
test
Integration
test
Integration
test
Unit test
Implementation
Verify
Verify
Verify
Verify
Requirement
analysis
Basic design
Program
design
Detailed design
Quality embedding process
Quality confirmation/
verification process

4. Basic tasks of an onsiter Customer
Onsiter’s responsibility
FSOFT offshore
1. Spec
understanding
Transfer to offshore
0. Planning (scope, cost,
process, delivery deadline)
1. Design explanation
QnA
1. QnA
0. Project planning:
development plan/quality plan
0. Resource management:
task assignment
1. Spec understanding
Spec QnA
1. Planning &
Preparation
Time
2. Meeting:
progress report,
issue report
2. Progress management
Quality management
Issue management
Cost management
2. Progress management
Quality management
Issue management
Cost management
2. Development
2. Implementation
& management
3. Spec modification
3. Support for
problem solving
3. Request to modify spec3. Adjust and manage
spec modification
3. Problems &
Changes
4. Pre-release check,
pre-review request
4. Pre-review
Pre-test
4. Deliverables
review
Delivery inspection
4. Q-UP4. Test/Review/Correct
An onsiter has to take care of lots of things.
5. FPT deliverables review
Acceptance test
5. Release:
Release, Review/test request,
Bug fixing, Final release
5. Release
Everything for the success of the Final release

5. Customer’s requirements
Communication/Requirements understanding (for final good release)
・Always take notes when the customer explain details about the specification.
・Always ask about what you don’t understand.
・Issues should be solved as early as possible. If you continue to work without understanding the requirement,
there may be lots of things to rework, and the deadline for Final release may not be kept.
・If you are not sure about the answer to a question, “I will confirm and answer by xx”.
1. Planning & Preparation

6. Communication/Requirements understanding (for final good release)
・If you cannot make decision immediately, “I will confirm and answer by xx”.
Self time management
・Mandatory things should be prioritized. For unecessary/low-priority tasks, discuss with the
customer and ignore if possible.
2. Implementation &
management

7. Issue management (for final good release)
・Always report on time.
* FPT to always submit report before being told.
・Issues/Progress delay/Quality defects, you can’t solve everything at the same time. Start from the
most critical thing (what affects the final release the most).
3. Issues and Changes

8. Change Request management (for final good release)
・When being asked by the customer: “Could you do ~~ as well?”, if you are not sure about that: “I think it’s
difficult. I will look into this carefully and get back later”.
・You must first get the customer’s agreement regarding the schedule and cost. Only after that the spec
change request should be implemented.
・Keep evidence of the customer’s request.
・Initial plan achievement is top priority. If the initial release plan cannot be kept after the spec change is
implemented, discuss with the customer to adjust the plan.
When being asked “Can you do
this?”, many people reply “Yes I can”
but in fact they can’t do it.
The effort required to implement the
change is excessive. Over-budget.
4. Test/Review/Correct

9. ・The project is not released according
to the initially agreed release plan
(do not leave it until a day before the
release date to check the release items)
・Items not included in the release
plan are released without prior notice.
Part of the submitted
documents has not been
translated.
There were lots of spec
changes, therefore the
release was delayed.
Releasing more items than
planned, fixing bugs found,
which should not be done?
I don’t understand.
Release management/control (for final good release)
・Once the release is accepted, if any bug is found, FPT may charge to fix it (if FPT does the bug
fixing free of charge, the customer may request to do further review or test. It may degrade the project).
・Request customer’s pre-review before actual release (should discuss with the customer to
understand to what extent the quality should be improved).
・Before releasing the project to the customer, bridge SE should spend time to check the release items
if required.
5. Release

10. Summary 1:
All are for final release, for Customer’s final satisfaction, and for our final satisfaction
Communication/Requirements understanding (for final good release)
・Always take notes when the customer explain details about the specification. Always ask about what you don’t understand.
・If you cannot make decision immediately, or if you are not sure about the answer to a question: “I will confirm and answer by xx”.
・Issues should be solved as early as possible. If you continue to work without understanding the requirement, there may be lots of things
to rework, and the deadline for Final release may not be kept.
Issue management (for final good release)
・Always report on time. * FPT to always submit report before being told.
・Issues/Progress delay/Quality defects, you can’t solve everything at the same time. Start from the most critical thing (what affects
the final release the most).
Change Request management (for final good release)
・When being asked by the customer: “Could you do ~~?”, if you think that it is impossible: “I’m sorry but I don’t think I can do it”.
・You must first get the customer’s agreement regarding the schedule and cost. Only after that the spec change request should be
implemented.
・Keep evidence of the customer’s request.
・Initial plan achievement is top priority. If the initial release plan cannot be kept after the spec change is implemented, discuss with the
customer to adjust the plan.
Release management/control (for final good release)
・Once the release is accepted, if any bug is found, FPT may charge to fix it.
・Request the customer to do pre-review before actual release. Discuss with the customer to understand to what extent the quality should
be improved.

11. 2. Schedule your essential/main tasks every day/every week, make it open, and be responsible
for them
Everyday, every week, do your main tasks first and do it perfectly. You may then do other
tasks if you have time.
1. Measure your own productivity (of your main/essential tasks)
Measure your productivity of the main tasks (* pages/hour, * queries/day, * steps/day)
requirement understanding (**pages/hour),
offshore-progress-understanding (*minutes/day),
release-check (**pages/hour, **steps/hour, *modules/day)
3. With remaining time, handle your other tasks and help other people temporally
Try to omit unnecessary tasks.
For the remaining time, you can do other tasks or support others.
・For unecessary tasks, discuss with the customer to see if you are allowed to ignore.
Summary 2:
To rescue yourself from being busy, simply:

12. Career path
At the earliest, excellent onsiter reaches Delivery Head within 5 years or so

13. Thank you!
13