Roadmap planning approach

13
July 30, 2008 Global Infrastructure Planning Kickoff

Transcript of Roadmap planning approach

Page 1: Roadmap planning approach

July 30, 2008

Global Infrastructure PlanningKickoff

Page 2: Roadmap planning approach

Agenda

Objectives

Roles and Responsibilities

Definitions

A Sample process

Deliverables

2

Page 3: Roadmap planning approach

Today’s to do list

Develop a common understanding of the elements of the process

Assign ownership to the process steps

Develop a set of deliverables

Define a timeline for delivery

3

Page 4: Roadmap planning approach

IT Ops Manager Roles and Responsibilities

SLA compliance Queue management Escalation management Maintenance contracts Vendor ops relationships Staff management Staff and peer communication management Staff training plans: existing technologies Cost control Customer relations / IT advocate with the business Standards compliance System monitoring Transition from engineering

4

Page 5: Roadmap planning approach

IT Engineering Manager Roles and Responsibilities

Architecture Standards Design Vendor relationships: “forward looking” Staff management Staff and peer communication management Vision and roadmap Develop management tools Staff training plans: new and future technologies Cost forecasting Customer requirement forecasting Transition to operations

5

Page 6: Roadmap planning approach

Architecture Philosophy

An plan for implementing a set of technologies within the Sybase environment.

It is a high level document that does not contain time commitments, vendor or model decisions, or implementation specifics.

It is meant to be a lasting document that can be used to cover a technology in the broadest manner.

It is meant to be used by engineers and engineering managers to ensure that designs are consistent and to guide the roadmap.

Information in the document is sensitive, and should only be shared with vendors in the pre-sales phase in the most general terms. It may be shared with vendors that are engaged based on a need to know in order to successfully execute. The engineering manager determines the need to know.

6

Page 7: Roadmap planning approach

Architecture Composition

Scope of the Architecture – What the architecture covers and where it applies

Business drivers – Functional, Legacy support, External standards, Legal / Regulatory requirements, Others

Requirements – Describes the characteristics of the system encompassed by the architecture.

Functions– Describes functions without detailing model, version numbers, or manufacturers.

Support requirements – Processes and metrics that must be in place to assess the implementation of the architecture requirements.

Interaction – How this architecture is linked to other functional areas.

7

Page 8: Roadmap planning approach

Design Philosophy

A blueprint for implementing a particular technology within the Sybase environment.

It is an intermediate level document that contains vendor and model decisions, implementation specifics, and support requirements.

It is meant to be a repeatable model to be used for implementation projects.

It is meant to be a means for documenting technology decisions. It is meant to be used by engineers, implementation personnel and

managers to ensure that implementations are consistent and to document technology selection.

It supports project scope statements and serves as the basis for the technical work done during a project.

Information in the document is sensitive, and should only be shared with vendors in the pre-sales phase in the most general terms. It may be shared with vendors that are engaged.

8

Page 9: Roadmap planning approach

Roadmap Philosophy

An time-based plan for implementing a set of technologies within the Sybase environment (a program).

It is an intermediate level document that contains time commitments for specific projects or activities that will support the ongoing architecture.

It is meant to be a continually updated document that can be used to drive work-effort and budgetary planning in the near term and guide project selection in the longer term.

It is meant to be used by engineering managers to estimate work effort, develop a capital budget, and schedule projects for the next 3 to 5 years.

Visibility is by quarter, with lower fidelity being used after the first 4 to 6 quarters.

Information in the document is very sensitive, and should not be shared with vendors except in the most general terms. It should be shared outside of the organization only in an interactive conversation.

9

Page 10: Roadmap planning approach

Expectation setting

Architecture = word document With supporting Visio / Excel

Design = word document With supporting Visio / Excel

Roadmap = Project with Description paragraphs

10

Page 11: Roadmap planning approach

A Roadmap exercise

11

Microsoft Project Document

Page 12: Roadmap planning approach

Roadmap description

Request inputs from your customers Plan based on skill set and level (i.e., architect, engineer,

implementer, operations) Costs should be in $1K increments, nothing smaller Plan for the unforeseen

12

Page 13: Roadmap planning approach

Your deliverables

Draft due 8/20 MS Project roadmap with at least 4 quarters of planning Resource plan for 2009 Capital plan for 2009

Final due 9/10 MS Project roadmap with at least 4 quarters of planning

A first cut at years 2 and 3 without costs Resource plan for 2009 Capital plan for 2009

13