Methodology:: Planning

This page represents my collection of the Planning related diagrams and slides. You may download whole page in HTML format: planning_html.zip (405 KB) and / or slides in Visio 5 format: planning_vizio.zip (246 KB) .

Navigation: If you click on thumbnail picture, it will zoom in. To zoom it out, click on picture again.

Update 18-May-2003

Planning at Startup

Figure 1.

Fig.1 shows processes which should be started at the startup of the project. Roles should be defined and documented as well.

Steering committee meetings are used as a forum for creating a common understanding of the project progress. This in turn lays the foundation for coordinating the work within development and across the different functional areas.

Only two roles (persons) are working on the Product Requirements refining and clarification cycle: Customer (or Customer Proxy) and Project Manager. All the team working to produce the Schedule.

 

Expectations of Information Systems

Figure 2.

Fig.2 shows Expectations of Information Systems.

 

 

 

Information Systems Group: Responsibilities Overview

Figure 3.

List of IS Group Responsibilities is shown on Fig.3. It is important that all activities of IS Group are coordinated centrally. This will ensure avoiding of "Not enough control" situation, which may cause significant problems for the project. See Change Control chapter for more details.

 

 

Information Systems Planning: IS Employee Skill Set

Figure 4.

Diagram Fig.4 shows IS Employee Skill Set which is necessary to bear in mind when a new project is planning.

The combination of Leadership, Business and Technical knowledge is quite important to properly assign responsibilities to a person.

 

Information Systems Planning: Project Communication

Figure 5.

Diagram Fig.5 shows communications of the Project Team with Management, Customers, Consultants, Vendors and so on.

The diagram represent a list of communication channels.

 

Information Systems Planning: Iterative Strategic Planning Network

Figure 4.

Diagram Fig.4 shows relationship between Strategy, Funding, Resource Allocation, and Execution of the project.

During the Project Execution you have to bear in mind that all there Processes are linked together and influent each to others as it shown on the diagram.

As you may see the Diagram is not only marketing tool, but also a reminder about the Planning Processes relations.

Information Systems Planning: Business Drivers and Boundaries

Figure 5.

Fig.5. shows Drivers and Boundaries of the Information Systems Planning.

Business drivers identify what to do. Boundary conditions may limit what can be done. The resulting plan describes how to do what can be done.

Information Systems Planning: Drivers of Information Systems Plan

Figure 6.

Diagram Fig. 6 shows Drivers of Information Systems Plan, their relations, and processes which cause effect to the  resulting Information Systems Plan.

 

 

Information Systems Planning: Plan Components

Figure 7.

Fig.7. shows Plan components and their relationship.

As a first step, Situation Analysis - Description of where we are today, internal, and external, business, and IS should be done. Secondly, you have to create Strategy Foundation - Description of where we want to be, business, and IS.

After the Gap Analysis you will will be able to create Strategy Implementation: plans how we are going to get there from an IS standpoint.

Information Systems Planning: Phases of the Planning Process

Figure 8.

Fig. 8 shows relations between phases for the Business and Information Systems groups of the Planning Process for the Information Systems.

 

 

Information Systems Planning: Business Process Map

Figure 9.

Business Process Map is shown on Fig.9. Starting from Leadership at the strategic level, it employs and supports Administration, Planning, Design & Development, Produce & Deliver, and Resource Development processes, to build Customer Satisfaction Management at the end.

 

Information Systems Planning: Computing Architecture Determined by Business Objectives

Figure 10.

Computing Architecture is solidly determined by Business Objectives. On the diagram Fig.10 Business Objectives are shown on the left, and caused Computing Architecture requirements on the right.

This matrix could be used as a solution generator tool. You ask question on the left and depending on the answer you put requirement line on the right side.

 

Page updated: 26 Aug 2003 23:02 +0400