| Software fails
to meet the needs and requirements of the business. |
Ability to
accept and deploy the new systems. |
Poor
requirements do not reflect true needs. Users do not buy into the need for
the new systems. System changes are of poor quality making the the system
unreliable. |
Requirements
analysts. Developers, who misunderstand requirements and produce poor
quality software. |
Medium
|
High
|
Perform more
rigorous review of requirements. Encourage developers to undertake better
testing and to engage end users in the test design. Conduct reviews of
developer test activity. |
Consider
increasing resource in acceptance test teams. Recruit external consultants
to assist with test design and management. |
Business
Analyst, IT UK |
Open |
| UK users
demand too many changes to the new system. |
Ability to
make changes quickly and go live. Customisation increases the risk of poor
quality software and unreliability. Also affects the business case: costs
may exceed the savings. |
Human nature
to be over cautious and demanding. |
UK users
|
High
|
High
|
Manage
requirements change carefully. Ask users to justify all changes on the
basis of economics. Grade changes as mandatory, high, medium and low
|
Incorporate
the need to limit software changes (cost, risk and time) in the
transformation plan and communications to the user community. Put
responsible senior users in charge of requirements gathering and review.
|
Business
analysts. User managers must control requirements change. |
Open |
| New hardware
and software infrastructure is unreliable. |
Ability to
implement and rely on the new systems. |
Poor design
and/or under specification of the new infrastructure. |
IT Support
fail to install and configure infrastructure properly. Infrastructure is
under sized. |
Low
|
High
|
Perform review
of infrastructure design. Compare planned infrastructure with existing
Italian set up. Involve Italian IT people in the review. |
Assess
viability of running performance/reliability tests on the infrastructure,
prior to deployment. |
IT UK
|
Open |
| The process of
converting, cleansing and reformating data in the old system to populate
the new system is more difficult than planned. |
Ability to go
live with the new system. |
Several
causes: poor quality or missing data in legacy system; implicit rules in
the legacy data; lack of knowledgeable resource in the data
audit/conversion team. |
Legacy system
data, underestimation of the effort required. |
Medium
|
High
|
Perform early
data audit; perform pilot conversions to understand the task better;
refine plan based on pilot experience. |
Review whether
current data is salvageable. Investigate potential costs of outsourcing
data capture from hardcopy documentatin to an agency. |
Project
Manager |
Open |
| The
Cost-Benefit analysis might turn out to be negative or neutral. The cost
of separation might outweigh the benefits of implementing the changes.
|
The business
case |
Underestimation of the benefits. Over estimation of the
savings. |
Poor analysis
of the cost/benefits for the business case. Poor selection of staff for
separation. |
Low
|
High
|
Model the
best, worst and expected scenarios in the business case. Select the staff
for separation more carefully. Define favourable criteria for the
separation selection process. |
Remind
business analyst to prepare business case realistically. |
Head Office
|
Open |
| Effort
required to manage store reporting and analysis is unchanged, or worsened.
|
Business case
(to make cost savings through staff separation). |
Overestimate
of potential savings in the business case; non-cooperation of HQ staff in
the efficient use of the new system |
Business Case,
HQ Staff |
Low
|
High
|
Review
business case. Engage HQ staff in the transformation process. Monitor
staff performance in their use of the new process and systems. |
- |
HQ Management
|
Open |
| Management
reports do not highlight the best and worst performing lines and stores.
|
Affects
ability to rationalise lines and suppliers and improve our competitive
advantage. |
Poor
definition of the management reports. Poor quality data received from
stores. |
System
requirements. Poor data. |
Low
|
High
|
Perform
careful review of the requirements, paying particular attention to the
management reporting. Ask data audit team to compare data produced by
stores with stock distribution to the store, to ensure sales data is
accurate. |
Perform manual
reconciliation of store sales for selected stores with stock data received
in the existing systems. Be wary of manual adjustments made by the stores,
not reflected in the EPOS data we use for current HQ reporting. |
HQ Management.
Data Audit team. |
Open |
| Best and worst
performing product lines and suppliers do not exist or cannot be
identified from the store reporting. |
Ability to
rationalise the products and suppliers and improve competitive advantage.
|
Poor business
case: assumed there was significant variation in the performance of lines
and suppleirs. Poor quality reporting (poor data or poor reports). |
Business case,
reporting facilities. |
Low
|
High
|
Review a
selection of stores to ensure there is significant variation in line and
supplier performance. Conduct more stringent tests of the management
reporting to ensure these variations are revealed. |
Perform manual
reconciliation of store sales for selected stores with stock data received
in the existing systems. Be wary of manual adjustments made by the stores,
not reflected in the EPOS data we use for current HQ reporting. |
Business
Analyst, IT UK |
Open |
| Customers do
not increase spending on the new range |
Reduced or
unchanged revenues. |
Poor selection
of winning and losing product lines and stores. |
Inaccuract
management reporting from the new system. |
Low
|
High
|
Ensure
reporting is accurate. Focus attention on acceptance testing and the
accuracy of reports. |
Verify
acceptance test plans cover reporting accuracy. Consider performing a
customer surveys on current and planned products to guage the mood of the
market. |
Acceptance
Test Team |
Open |
| The cost of
separation might be too high for selected staff. |
The business
case |
Poor selection
of staff. Need to focus on staff who can be reassigned, rather than made
redundant and compensated for. OR staff who are close to retirement.
|
Poor staff
selection |
medium
|
High
|
Model the
costs of separation, prior to updating the COBA. Select the staff for
separation carefully. Define favourable criteria for the separation
selection process. |
Obtain full
staff profiles including service record, age and current remuneration to
ensure accuracy in the separation costs. |
Head Office
|
Open |
| Software fails
to meet the needs and requirements of the business. |
Ability to
accept and deploy the new systems. |
Poor
requirements do not reflect true needs. Users do not buy into the need for
the new systems. System changes are of poor quality making the the system
unreliable. |
Requirements
analysts. Developers, who misunderstand requirements and produce poor
quality software. |
Medium
|
High
|
Perform more
rigorous review of requirements. Encourage developers to undertake better
testing and to engage end users in the test design. Conduct reviews of
developer test activity. |
Consider
increasing resource in acceptance test teams. Recruit external consultants
to assist with test design and management. |
Business
Analyst, IT UK |
Open |
| Software fails
to meet the needs and requirements of the business. |
Ability to
accept and deploy the new systems. |
Poor
requirements do not reflect true needs. Users do not buy into the need for
the new systems. System changes are of poor quality making the the system
unreliable. |
Requirements
analysts. Developers, who misunderstand requirements and produce poor
quality software. |
Medium
|
High
|
Perform more
rigorous review of requirements. Encourage developers to undertake better
testing and to engage end users in the test design. Conduct reviews of
developer test activity. |
Consider
increasing resource in acceptance test teams. Recruit external consultants
to assist with test design and management. |
Business
Analyst, IT UK |
Open |
| Software fails
to meet the needs and requirements of the business. |
Ability to
accept and deploy the new systems. |
Poor
requirements do not reflect true needs. Users do not buy into the need for
the new systems. System changes are of poor quality making the the system
unreliable. |
Requirements
analysts. Developers, who misunderstand requirements and produce poor
quality software. |
Medium
|
High
|
Perform more
rigorous review of requirements. Encourage developers to undertake better
testing and to engage end users in the test design. Conduct reviews of
developer test activity. |
Consider
increasing resource in acceptance test teams. Recruit external consultants
to assist with test design and management. |
Business
Analyst, IT UK |
Open |
| Users refuse
to accept systems for political or personal reasons. |
Cannot
implement systems with confidence that the users will actually use the
software. |
Personal
agendas, insecurity |
End users in
the test team |
medium
|
high
|
Engage with
users, communicate better, involve the users in the transformation
planning. |
Select users
that are influential in the business and support the overall project
objectives. |
User managers
|
Open |