Annex 3

Unique ID: 001

Date of submission: 05.05.2016

Request For Change

Change Owner:
Initiator of the RFC:
Proposed Change priority: Normal
Reference to Change Proposal: Confluence page link

I.

Description of the Change being applied for

1. Summary description

The workflow followed in

for product documentation currently is lacking

procedures that are established and followed by all the participants in this process. Due
to a number of external and internal triggers a quality standard needs to be
implemented that addresses all the aspects of a product documentation management
process. The ISO/IEC 26511:2011 international standard defines the documentation
process from the manager's standpoint. It assists those who provide input to, perform,
and evaluate product documentation management. The new practices that the standard
imposes require new tools to be used and some to be upgraded. This is the case of
start using Google Docs as a review tool and upgrading the Jira version for having
better reporting mechanisms.
2. Business case

The specific business need behind this request for change is that according to the
majority of the staff involved in the process of product documentation (a research had
been conducted) the process is needing improvements mainly in the review from a
competent software developer part where proper tools are missing and a lot of time is
wasted. Also a proper mechanism for providing input must be set with clear quality
gates, meaning that it should be clearly stated: who should provide what and when. Last
but not least the management should have a feedback for the status of the
documentation issues and the progress when comes to new product version release.
3. Reason for the Change to be implemented
Competition
Big names such as Eclipse, Oracle, IBM are developing their own IoT solutions. They
have implemented all kinds of quality standards and are constantly addressing the
improvement of product documentation process. By having a better product
documentation the competition is gaining advantage on the market of the open source
IoT solutions.
Customers
customers/partners demand new better product (version) with more features
as soon as possible. The stuffed process of product documentation is able to slow
down the release of the product itself.
Acquisition of
by
The acquisition is putting new standards and requirements. Moreover the workload for
the Software Development Department is increased and the workers struggle to put
extra efforts in the review process of the product documentation.
Inefficient procedures, Practices and Processes
With the growth of the company and the recent acquisition of
it became urgent
to implement standardized processes and procedures in the company. While the
recent certification in ISO 20000 satisfies the requirement of adequate Service
Management System there are still several other deficiencies like the lack of
established project and documentation management cycles cause performance gaps
and issues.
Turnover of human resources

Old experienced people leave the company. Newcomers are replacing them. These
means that people used to the procedures and processes in the company are lost and
time and resources have to be spent for training the new employees. Therefore
established procedures have to be in place in order to be easy for the newcomers to
adapt to the organizational culture.

4. Costs
A rough estimation of the costs from this normal change project execution had been
made based on the total man hours needed for the change to be planned, executed and
evaluated. The total figure is 515 men hours.
The Change manager invested:
5 months, roughly each day 2 hours, equals to 200 mh
The CAB invested:
5 sessions (2 hours each) that include 4 employees, equals to 40mh
The Change Authority invested:
10 work hours in total for the whole project (self reported)
The Release Analyst invested:
10 work hours in total for the whole project (self reported)
The stakeholders:
95 employees, involved in a 1 hour presentation for the new standard and practices
implemented, equals to 95 mh.
4 stakeholders, involved in a pilot project for 5 wd, equals to 160 mh.

5. Benefits
Reduced time for providing the complete product documentation
Reduced time of engagement of the Software department in the process of
producing product documentation

 A clear workflow when comes to reporting and fixing bugs in the product
documentation (saving time to the involved parties)
Avoiding personal issues to influence the product quality (because of the defined
procedures that must be followed)
Implemented international standard for quality

6. Consequences if the Change is not implemented

Most importantly the satisfaction of the work done (amongst the employees
involved in the current process) is very low. This is what the research have
shown. More and more personal issues are expected to rise and complicate the
process of documentation.
If the new workflow is not implemented, the company will continue to waste
resources in terms of time and potential.

7. References (e.g. to a Problem Record triggering this RFC)

Several times the problem for lack of standardized process for documentation had been
risen from different participants. Unfortunately the indignation was not put into a format
issue or documented for the Change Manager to be able to use it as a reference and
justification for the change.
8. Business areas on the client-side affected by the Change
During the process of Change there is no expectation that a business area on the
client-side to be affected.

9. Services affected by the Change

The product documentation is one of the key tools used by the Support department in
the services they provide. This service would be affected in a positive way after the

change is implemented, since it would benefit from the improved product

documentation.

10. IT infrastructure components (CIs) affected by the Change

The change envisions that a new version of the software development management
tool (Jira) must be implemented. This will result in a potential loss of information, need
of additional training, need of re-writing of the customized features of the product.

11. Technology aspects

No new technologies are planned to be introduced with the current change.

II.

Risks

Risks during the implementation of the Change

1. Identified risks
The new Jira version implementation could take a relatively big period for
implementation because it requires re-writing of the customized features.
Consequently the people resources that would be engaged in the implementation
would not be available for working on other projects.
The change could not be well-accepted amongst the Software Development
department staff. There would be some resistance to change ranging from not
following the new practices (e.g. not writing the user doc section in Confluence)
to actively object to the new workflow or methods used.
The change is scheduled for a period when there will be no big pressure over the
teams for releasing new version but still some people could not take their time to
get know the new procedures and this may cause conflicts or confusion.
2. Counter-measures

 The new Jira version implementation would be carefully planned and discussed
with the management and the people who had made the customization of the
older version features. A feasibility study could be conducted.
The contra-measures for dealing with the resistance for change are described in
the Sponsorship Roadmap, the Communication Plan and the Resistance
Management Plan.
The conflicts triggered by stuffs being unaware of the change could be managed
by pointing out the officially established procedures - the ISO/IEC 26511:2011
implementation.
3. Back-out strategy for the case of a failed Change implementation
The planned change does not requires specific back-out strategy, since it does not
affect directly some company service. It could only improve the company's product but
it does not threaten IT infrastructure or normal stuff functioning.
However some measures should be taken when the new Jira version is to be
implemented and go-life. It is recommended that the old version continues to operate
until a full migration is performed to the new version. If some technical issues occur with
the new version, the old one is to be available and operating.

III.

Time schedule
Predicted/suggested time schedule for the implementation

Change Description

Implementation Date

Responsible Officer

New ISO/IEC 26511:2011

standard procedures
available on the dedicated
web-resource

Mid of May 2016

ISO Expert

Review Process
document to be
communicated to the

Mid of May 2016

Change Manager

stakeholders
Designing Jira custom
plugins

Start end of April 2016

Subject Experts

New Jira version

implementation

Mid of May 2016

System Administrator

Formal Presentation for

the new procedures and
tools

Beginning of June 2016

Change Manager, Change

Owner

Evaluation of the Change

End of June 2016

Test Managers

IV.

Estimate of resources for the implementation

1. Required personnel resources

Change Management team includes: the

Change

Manager

(Documentation

Department Manager), the Change Owner (in this case the R&D manager as an
authority of the business processes in

two

Test

Managers

(head

managers form the Software Development department that would evaluate formally
the implemented change).
Release Analyst s ISO Expert since she has the administration rights
over
s ISO implementation.
System Administrator - The old Jira version (v.3.13) should be migrated to the one
chosen (v.7.0).
Subject Experts on
s custom plugins for Jira - some custom plugins for
Jira currently used by
must be re-written.

2. Estimated work effort for the required personnel resources

For implementing the new ISO/IEC 26511:2011 standard, the ISO Expert would
need 10 men days.
For communicating the new Review Process, the Change Manager would need
1 men day.

 For designing the new custom plugins of the software development management
tool, rough estimation is 100 men days.
For migrating the software development management tool to the required
version, the system administrator would need about 5 to 7 men days.
For the Formal Presentation the Change Manager would need 1 men day.
For Change Evaluation, the Test Managers would need about 10 to 30 men
days.

3. Cost estimate
The most considerable expense is the time that the software developers would need to
re-write the custom plugins for the new version of Jira. It is estimated to about 100 men
days and could be approximated to

V.

euro.

Budget

The new Jira version costs: for 101-250 Users US $

The other costs are covered by the monthly salary of the engaged staff.

VI.

Additional supporting documents

1. Sponsorship Roadmap
2. Communication Plan
3. Resistance Management Plan

VII.

Approval or rejection

Approval or Rejection
(approved/rejected dd/mm/yy)

Person/ body in charge of the

approval

(Change Authority)

Change Reviewers
(Change Manager)

(Change Owner)

(Test Manager)

(Test Manager)
Priority Assigned by Change

Normal

Management
Reasons for Rejecting the RFC

(To be filled in if applicable)