The Cisco Ppdioo Lifecycle Approach

Published Date: 02 Nov 2017

Using a network lifecycle approach provides several key benefits. These benefits include:

Speeding access to applications and services. Critical to a productive environment is accessibility to network applications and services and by using the following actions we can accelerate access to these:

Keeping software current, and managing and resolving problems affecting your system.

Increasing availability, resource capacity, and performance to improve service-delivery efficiency and effectiveness.

Supporting current and planned network technologies and services by Assessing and improving operational preparedness.

Improving the availability, reliability, and stability of the network and the applications running on it.

Another benefit is Improving business agility. Enterprises must react in good time to changes in the economy. Enterprises that achieve this gain a competitive edge over their competitors. The following actions will encourage this:

Continual enhancement of performance.

Establishing technology strategies and business requirements.

Expertly integrating, configuring, and installing system components.

Integrating business sgoals and technical requirements into a detailed design and demonstrating that the network is functioning as specified.

Preparing the site or sites to support the system that is to be implemented.

Increasing network availability is another key benefit. For most enterprises this is a top priority and the brief for this project also states that this is a key requirement. Network downtime can cause all sorts of problems and at times can be critical. To improve this availability we use the network lifecycle and the following actions:

Improving staff skills

Before deployment, stage and test the proposed system.

Assess the network’s security state and its capability to support the proposed design.

Validate network operations and produce a sound operations design.

Specify the right set of hardware and software, and keeping them current and operational.

Monitoring the system and assessing availability trends and alerts, proactively.

Defining remediation plans and identifying security breaches, proactively.

Perhaps the most critical to most enterprises is the cost. This is actually another key benefit that the PPDIOO lifecycle approach gives. Lowering the total cost of network ownership. Many enterprise executives aggressively assess the costs associated with IT expense, and with the following actions we can work towards this:

Accelerating successful implementation.

Align business goals and technical requirements with a sound network design.

Plan for changes, such as resource requirements and infrastructure changes.

Validating and Identifying technology requirements.

Improving the efficiency of operational processes and tolls to reduce operating expenses.

Improving the efficiency of the network and the supporting staff.

Prepare

Plan

Design

Plan for Implementation is undertaken during this phase.

Implement

Operate

Optimize

Risk

Risk Identification

Business Risk

BR1: Supplier does not deliver on time – This would cause the project to fall behind schedule as the installation team waits for the equipment to be delivered.

BR2: Supplier supply’s wrong item/s – Again this would cause the project schedule to be delayed and probably by more time then a late delivery, as the item has still to be dispatched.

BR3: Supplier is out of stock – This could cause a delay in the project schedule while an item is sought from the manufacturer.

BR4: Project gets cancelled – This risk would mean that SMCC Tech has lost a lot of income from the project.

Technical Risk

TR1: Hardware failure – Can cause delays again while a working item is supplied.

TR2: Hardware components not compatible – This risk means that adequate planning has not been done and this will cause the schedule to be delayed.

TR3: Cabling infrastructure inadequate – If this risk comes true then, a major delay will happen, while new cabling is installed.

TR4: Network failure – This could cause a small delay to schedule while configurations are checked or a major delay if the fault cannot be found.

Organizational Risk

OR1: Key team member leaves – This would place extra burden upon those who are still working on the project.

OR2: Key team member performance poor -

OR3: Theft of Hardware – The police may have to be involved and the culprit punished.

OR4: IT staff cannot support new equipment – This would require training of the IT staff to a level where they are confident to be able to utilise the new equipment to a high standard.

Project Management Risk

PR1: Project runs over budget – One of the reasons why a project would be called a failure.

PR2: Project runs over Schedule – Another reason to call a project failed.

PR3: Project scope not met – Again a project would be called a failure if the scope is not met.

PR4: Requirements misunderstood – The results of this could mean the project has to be started again.

Risk Analysis

Risk matrix

High

OR2

Medium

OR3

BR1, TR1, OR1, PR1, PR2, PR3

TR4, PR4

Low

BR3, OR4

BR2

BR4, TR2, TR3

Probability/Impact

Low

Medium

High

As seen in the above table, some risks have a greater impact and probability than others. This report will focus on those risks which have the highest. These risks are shown in orange and red.

Risk Planning

Risk Avoidance

OR1 – To avoid this risk, SMCC Tech must keep its employee’s happy and healthy. Decent wages would be a good place to start, and perhaps offering bonuses for performance and possibly a health plan.

PR4 – Avoiding a misunderstanding can sounds simple in theory and it is a matter of discussing with the client his needs and wants, preparing a proposal and talking him through the parts he does not understand.

Risk Acceptance

TR1 – This risk again will have to be accepted but it must be found out before installation. Otherwise the impact will be far greater.

TR4 – Accepting that there may be some failures in the configuration is the proper solution because there may be many devices need configuration and something may just be input wrong. This is acceptable and all systems must be testing before going live.

Risk Transference

BR1 – This risk will have to be accepted, however there are measures that can be taken to soften the blow. Such as insurance.

PR2 – Running over schedule can also prove to be a large problem for the customer, in fact incurring costs due to lack of business. Insurance should be in place to cover for this.

Risk Mitigation

PR1 – If the project runs over budget it could prove to be a very large problem for both SMCC Tech and their customer. To mitigate this, the proper planning and cost estimation’s must be put in place before work is started.

PR3 – If the scope of the project is not met, then it will most probably have to continue with more work incurring costs and time. The customer’s requirements must be analysed and discussed fully before proceeding.

Risk Monitoring

Risk monitoring should be an ongoing process throughout the life of the project. The key to this process is communication between team members and people who are working on the project. New risks may arise and must be dealt with the same way as initial risks were. That is to identify them, put them into a risk matrix and then to plan for when or if they happen.

Quality

Quality Planning

Quality Assurance

Quality Control

Legislation

Computer Misuse Act 1990

Regulation of Investigatory powers Act 2000

Telecommunications Regulations 2000

Health and Safety at Work Act (Moving and Handling Regulations)

Data Protection Act 1994

Waste Electrical and Electronic Equipment Directive 2006

Consumer Protection Act 1987

Human Rights Act

Plan for Implementation

The exact steps necessary to complete the implementation phase should be included in a detailed implementation plan. The more detailed the implementation plan is, the more likely the implementation will be a success.

5.1. Edinburgh (Head Office) Implementation

5.2. Glasgow Implementation

Ref. No.

Task

Equipment

Team

Result

G1

Disconnect Hubs

G2

Dispose of Hubs

G3

Install Rack’s

G4

Install Firewall

G5

Install Router

G6

Install DL Switch’s

G7

Install AL Switch’s

G8

Configure Firewall

G9

Test Firewall

G10

Interconnect New components

G11

Verify cabling

G12

Verify links

G13

Configure Router

G14

Configure Layer 3

G15

Configure Layer 2

G16

Verify Connectivity

G17

Connect Hosts

G18

Verify Connectivity across WAN

5.3. Dundee Implementation

Ref. No.

Task

Equipment

Team

Result

D1

Disconnect Hubs

D2

Dispose of Hubs

D3

Install Rack’s

D4

Install Firewall

D5

Install Router

D6

Install DL Switch’s

D7

Install AL Switch’s

D8

Configure Firewall

D9

Test Firewall

D10

Interconnect New components

D11

Verify cabling

D12

Verify links

D13

Configure Router

D14

Configure Layer 3

D15

Configure Layer 2

D16

Verify Connectivity

D17

Connect Hosts

D18

Verify Connectivity across WAN

5.4. London Implementation

Ref. No.

Task

Equipment

Team

Result

L1

Disconnect Hubs

L2

Dispose of Hubs

L3

Install Rack’s

L4

Install Firewall

L5

Install Router

L6

Install DL Switch’s

L7

Install AL Switch’s

L8

Configure Firewall

L9

Test Firewall

L10

Interconnect New components

L11

Verify cabling

L12

Verify links

L13

Configure Router

L14

Configure Layer 3

L15

Configure Layer 2

L16

Verify Connectivity

L17

Connect Hosts

L18

Verify Connectivity across WAN

5.5. Cambridge Implementation

Ref. No.

Task

Equipment

Team

Result

C1

Disconnect Hubs

C2

Dispose of Hubs

C3

Install Rack’s

C4

Install Firewall

C5

Install Router

C6

Install DL Switch’s

C7

Install AL Switch’s

C8

Configure Firewall

C9

Test Firewall

C10

Interconnect New components

C11

Verify cabling

C12

Verify links

C13

Configure Router

C14

Configure Layer 3

C15

Configure Layer 2

C16

Verify Connectivity

C17

Connect Hosts

C18

Verify Connectivity across WAN

Plan for Testing

A major factor to consider is the possibility of failure no matter how robust the design or how well a prototype works, so there should be a well-defined process test after each step taken.

6.1. Edinburgh (Head Office) Testing Strategy

Hardware Testing: Visual Inspection, Power check, PAT

Network Testing: Connectivity Check, Integration Check, Stress Test

Security Testing: Port scan, Network Scan, Vulnerability Scan, Penetration Test

6.2. Glasgow Testing Strategy

6.3. Dundee Testing Strategy

6.4. London Testing Strategy

6.5. Cambridge Testing Strategy

6.6. Integration Testing Strategy

References

Implementing Cisco IP Switched Networks (SWITCH) ISBN: 1-58705-884-7

http://www.sqa.org.uk/e-learning