names, product names, and trademarks are owned by their ... · pdf filefast start® in...

© 2006 by Systemation. ALL RIGHTS RESERVED.

No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical,

including photocopying or recording, or by any information storage or retrieval system, or otherwise, without written

permission from Systemation. For permission or more information, please send requests to Systemation. All brand

names, product names, and trademarks are owned by their respective companies and referred to herein for identification

purposes only.

For general information on other Systemation products and services, please contact us at 1-800-747-9783, or visit our

website at www.systemation.com.

2095 South Pontiac Way

Denver, CO 80224-2411

USA Telephone: 1-800-747-9783,

[email protected]

www.systemation.com

| �

Fast Start® in Business AnalysisFSIBA_V2

Table of Contents

Module 1 Introduction ........................................................................................................................... 1

Defining Business Analysis .....................................................................................................................3

What is Business Analysis? ..............................................................................................................5

What is a Business Analyst? .............................................................................................................6

International Institute of Business Analysis (IIBA) Business Analysis Body of Knowledge (BABOK) ..........................................................................7

Today’s Approach to Business Analysis ..................................................................................................9

The Systems Development Life Cycle ..................................................................................................12

Approvals ........................................................................................................................................14

Workshop Agenda .................................................................................................................................16

Initiation ..........................................................................................................................................16

Analysis ..........................................................................................................................................16

Conceptual Design ..........................................................................................................................16

Workshop Objectives ......................................................................................................................17

Getting the Most from This Workshop ..................................................................................................18

Workshop Logistics ...............................................................................................................................19

�� |

Table of Contents


Your Role This Week ......................................................................................................................19

Workshop Materials ........................................................................................................................20

Module 2 Enterprise Analysis .............................................................................................................. 21

What is Enterprise Analysis? .................................................................................................................23

Enterprise Analysis Activities .........................................................................................................24

What Has Changed? ........................................................................................................................25

What Information Should We Gather for Enterprise Analysis? ............................................................26

How Should We Collect This Information? ....................................................................................26

Types of Information to Collect ............................................................................................................27

Sources of Information ..........................................................................................................................29

How Does Enterprise Analysis Help the Project? .................................................................................30

Real-World Application .........................................................................................................................31

Module 3 Defining the Project Scope .................................................................................................. 33

An Approach to Project Definition ........................................................................................................35

Step One—Identify Issues .....................................................................................................................36

Uses for Issues ................................................................................................................................36

Step Two — Recognize Future Benefits ...............................................................................................37

Step Three—Identify the Functional Areas/Stakeholders and Sponsor ................................................38

Stakeholder .....................................................................................................................................38

The Project Sponsor ........................................................................................................................39

Step Four—Diagram the Functional Flow ............................................................................................40

Step Five—Define the Project Scope and Objectives ...........................................................................41

Scope Exclusions ............................................................................................................................42

Objectives .......................................................................................................................................42


Module 4 Procedure Analysis .............................................................................................................. 45

Preparing for Analysis ...........................................................................................................................47

What Information Should We Gather to Analyze? .........................................................................47

| ��

Table of Contents


Why Perform Procedure Analysis? .................................................................................................48

Definitions .............................................................................................................................................48

Performing Procedure Analysis ............................................................................................................49

Process Flow Modeling .........................................................................................................................50

Why Create Models? ......................................................................................................................51

Symbols Used in Process Flow Models ..........................................................................................52

Swim Lane Diagram ..............................................................................................................................53

Guidelines for Creating Swim Lane Diagrams ...............................................................................54

Process Scripts .......................................................................................................................................55

Old Procedure .................................................................................................................................56

Process Script Procedure ................................................................................................................56


Module 5 Interviewing ......................................................................................................................... 59

Why Interview? .....................................................................................................................................61

Preparing for the Interview ....................................................................................................................62

Interview Structure ................................................................................................................................63

Questioning and Listening Techniques .................................................................................................65

Listening for Requirements ...................................................................................................................66

Holding the Interview ............................................................................................................................67


Module 6 Requirements, Assumptions, and Constraints .................................................................... 71

Effective Requirements Practices ..........................................................................................................73

Requirements ..................................................................................................................................73

Types of Requirements ...................................................................................................................74

SMART Requirements ....................................................................................................................75

Identifying User Requirements .............................................................................................................76

Functional Requirements ................................................................................................................78

Quality of Service Requirements ..........................................................................................................79

�v |

Table of Contents


Quality of Service Requirements ....................................................................................................79

Assumptions ..........................................................................................................................................81

Constraints .............................................................................................................................................82


Module 7 Defining a Solution .............................................................................................................. 85

Solution Definition ................................................................................................................................87

System Improvement ......................................................................................................................87

System Redesign .............................................................................................................................87

Review Project Scope ............................................................................................................................88

Conceptual Design Creates Change ......................................................................................................89

Process Improvement ......................................................................................................................90

Systems Development .....................................................................................................................91

Organizational Change....................................................................................................................92

Impact Analysis ....................................................................................................................................93

Process Improvement impact ..........................................................................................................93

Systems Development impact .........................................................................................................94

Organizational Change impact ........................................................................................................94


Module 8 Solution Implementation Planning ..................................................................................... 97

Systems Development Life Cycle Review ............................................................................................99

Phases for Implementation Planning .....................................................................................................99

Planning to Implement the Future Changes ........................................................................................100

Visualizing the Project Schedule for Implementing the Solution ......................................................100

Step 1 — Break the Project down into Tasks ...............................................................................101

Step 2 — Assign Resources ..........................................................................................................101

Step 3 — Estimate Time ...............................................................................................................102

Step 4 — Sequence the Tasks .......................................................................................................103

Step 5 — Chart the Plan ...............................................................................................................103

| v

Table of Contents


Real-World Application .......................................................................................................................104

Module 9 Management Presentation ................................................................................................. 107

Business Case Decision Package ........................................................................................................109

What’s in this Management Presentation? .......................................................................................... 111

Presentations ........................................................................................................................................112

Rehearsal and Practice Run .................................................................................................................113

Real-World Application ......................................................................................................................114

Appendix A Recommended Reading ..................................................................................................... 117

Appendix B Glossary .............................................................................................................................. 123

Appendix C Index ................................................................................................................................... 127

Exercises ............................................................................................................................................ 131

Exercise 1 — Getting Acquainted .......................................................................................................131

Exercise 2 — Enterprise Analysis Of Akmee Communications .........................................................133

Exercise 3 — Defining the Scope ........................................................................................................147

Exercise 4 — Procedure Analysis .......................................................................................................159

Exercise 5 — Interviewing for user Requirements .............................................................................175

Exercise 6 — Requirements, Assumptions, and Constraints ..............................................................179

Exercise 7 — Define the Solution .......................................................................................................183

Exercise 8 — Implementation Planning ..............................................................................................189

Exercise 9 — Management Presentation .............................................................................................193

v�

Blank Page / Notes


jdjdjdjdjdjdjd

Introduction

Module 1 Introduct�on

Module 1 | 1


� | Module 1

Introduct�on


In this module, you will:

Define Business Analysis and what it means in today’s environment

Recognize the System Development Life Cycle and various approaches

Discover the objectives and topics covered in the workshop

Discuss the workshop logistics and agree on classroom norms

Welcome to Fast Start® in Business Analysis. This course has been designed to cover a wide range of topics and activities important to Business Analysts. Obviously in three days we can’t address the immense breadth and depth of capabilities, tasks, and skills that a Business Analyst would gain from years of experience. But in three days we can develop a strong foundation of knowledge, offer structure to the sometimes chaotic Analyst’s workload, identify useful tools and techniques, and discuss various methods to improve performance and create efficiency in our own work environments.

This section of the Participant Guide will give you information on the course objectives and topics of discussion, the logistics for this specific workshop, and some guidelines for obtaining the maximum benefit from the workshop.

•

•

•

•

Module 1 | �

Introduct�on


Defining Business Analysis

Before we get going, we need to define Business Analysis and describe the role of a Business Analyst in today’s work environment. Since we’re here for three days to talk about this, it’s important that we all recognize what the terms mean and why this job role is critical to the organization. To develop a working definition, a few related questions will generate critical thinking and active discussion.

What is the role of the Business Analyst within your organization?

What tools and techniques are used by your Business Analysts?

1.

2.

� | Module 1

Introduct�on


What skills and capabilities are important for a successful Business Analyst?

What are the biggest challenges you encounter as a Business Analyst?

3.

4.

Module 1 | �

Introduct�on


What is Business Analysis?

Based on all the previous answers just discussed, Business Analysis is a complex set of skills and capabilities, tools and techniques, and challenges and rewards that creates a defined job role vital to organizations today. The International Institute of Business Analysis (IIBA) defines it as follows:

Business analysis is the set of tasks, knowledge, and techniques required to identify business needs and determine solutions to business problems.�

Solutions often include the following components:

Systems Development – Analysis work performed to review the current automated components used by an organization, identify issues, define requirements for system functionality and quality of service (non-functional requirements), and suggest the best possible system solutions to fill the business needs.

Process Improvement – Analysis work to review the current manual or automated workflow activities and tasks performed by people, departments, and systems which are designed to achieve a specific and successful business outcome. This analysis would include the relationships, exchange of information, and interactions/handoffs between areas. It would also include a detailed investigation of procedures, policies, and observations of the work being performed.

Organizational Change – Analysis work to review the organization as a whole and consider the strategic vision, corporate objectives, financial position, and major changes in company’s product, customer base, market, or environment. Projects initiated on an enterprise level are often reserved for senior analysts, managers, directors, and executives. Business analysts are often asked to provide detailed information used in the organizational change decision-making process.

� International Institute of Business Analysis (IIBA), Business Analysis Body of Knowledge (BABOK) version �.6 © 2006

•

•

•

� | Module 1

Introduct�on


What �s a Business Analyst?

This is another important question which will result in various answers depending upon how your organization defines the roles, responsibilities, and job title. The IIBA’s definition is as follows:

A business analyst works as a liaison among stakeholders in order to elicit, analyze, communicate and validate requirements for changes to business processes, policies and information systems.

The business analyst understands business problems and opportunities in the context of the requirements and recommends solutions that enable the organization to achieve its goals.2

The role or job description of business analysis work has various titles in different organizations, such as Business Analyst, Business Systems Analyst, Systems Analyst, and Process Improvement Specialist. In addition, Business Analysis work may be part of other job titles within the Information Technology department, such as Programmer Analyst, Database, Web, or Applications Developer, and Systems Administrator. As another option, specific functional areas within an organization may have their own analysts which would have a title relevant to the area in which they work. We will be using the title of Business Analyst in this workshop to cover this broad range of job descriptions.

A Business Analyst often performs any or all of the following:

Recognize business goals and objectives, as well as background of organization/department being analyzed, market, products, competition, customer, financials, stakeholders, what has changed, etc.

Focus on business processes and procedures

Identify cost saving opportunities, increase efficiencies, decrease errors/issues

Identify and interact with business users at various levels to gather and validate information and determine requirements

Identify impact on other areas both internally as well as outside the organization

Recognize exposure or potential risks associated with process changes

Understand available and applicable technologies (while not necessarily being technical)

Act as a liaison between the business unit customer/users and the technology department

Document and management requirements from a “what is needed” perspective

2 International Institute of Business Analysis (IIBA), Business Analysis Body of Knowledge (BABOK) version �.6 © 2006

•

•

•

•

•

•

•

•

•

Module 1 | �

Introduct�on


International Institute of Business Analysis (IIBA) Business Analysis Body of Knowledge (BABOK)

All definitions and processes included in this workshop are consistent with the International Institute of Business Analysis, A Guide to the Business Analysis Body of Knowledge (BABOK®). This workshop will also help you understand six Business Analysis Knowledge Areas:

Enterprise Analysis

Determining project scope

Preparing the business case

Requirements Planning and Management

Understanding team roles for the project

Planning considerations

Activities selection

Scope management

Requirements Elicitation

Requirements gathering using various techniques

•

•

•

•

•

•

•

� | Module 1

Introduct�on


Requirements Analysis and Documentation

Requirements package structure

Creating a business domain model

User requirements analysis

Functional requirements analysis

Quality of service requirements analysis

Assumptions and constraints

Requirements documentation

Various modeling techniques

Requirements Communication

Requirements package creation

Solution Assessment and Validation

Alternate solutions development

Solution selection

Solution implementation

Solution impact communication

•

•

•

•

•

•

•

•

•

•

•

•

•

Module 1 | �

Introduct�on


Today’s Approach to Business Analysis

A new business opportunity, need for improvement, or a specific problem will initiate analysis work which eventually may be approved as a project to implement suggested solutions. The diagram below shows a typical sequence of tasks that an analyst would follow during analysis work.

Business Analysis Diagram

Notice that the arrows rotate full circle which indicates that there is iteration/repetition in business analysis work. Rarely is a single pass adequate to fully understand the area being analyzed. Several iterations may need to be performed for a complete and accurate requirements document. In fact, using an Agile/Iterative System Development Life Cycle process, this work is performed in small, manageable segments or modules and is repeated over and over until all modules are complete.

10 | Module 1

Introduct�on


Elicit Information – Analysts collect both written and verbal information. Written materials might include such things as company profiles, organization charts, processes and procedure documents, job descriptions, forms, reports, interfaces, system information, and anything else that the analyst finds important to understand the area being analyzed. Verbal information is also gathered from stakeholders, users, and project team members. Verbal information can be gathered during interviews, facilitated sessions (workshops), or observing the job being performed.

Analyze – Reviewing all the collected information for the details to better understand the current state of the organization, and its processes and systems. This discovery process helps the analyst better understand the issues or needs. A good analyst will patiently work through this phase and not jump to fixing problems or defining a solution too quickly.

Document – Various tools, techniques, and models are available to help the analyst depict the details of processes and systems in graphical and word-based formats. Models can be used to document and explain complex components in a more user-friendly way.

Communicate – The exchange of information with analysts, users, stakeholders, subject matter experts, and the project team is vital to the successful outcome of the project. On going communication is used to collect information, validate the current system/process, assess needs, gather and validate requirements, and seek/gain approval throughout the project.

Requirements – The focus of most analysis projects and one of the major deliverables is the requirements documentation. Initial requirements may be offered when the project is initiated. Those requirements will be developed and additional requirements discovered throughout the entire business analysis process. Organizations have their own names and definitions for the requirements specifications or documents which contain requirements. Regardless of the name or format, the quality of the requirements statements is the key to a successful project.

•

•

•

•

•

Module 1 | 11

Introduct�on


Business Analysis work is:

Interactive – Requiring collaboration with other analyst team members, stakeholders, users, customers, project managers, project sponsors, developers, designers, programmers, testers, vendors, and support personnel.

Top-Down – Necessitating that an analyst is capable of seeing the big picture from a high level, as well as recognizing a deeper level of detail within a specific process and its use of information.

Iterative – Demanding that the analyst will patiently work through the process of discovering the as-is process and its use of information to better determine the requirements and best solution. As the Business Analysis Diagram illustrates, Business Analyst work is iterative. By that we mean that the analyst is continuously collecting information about requirements, analyzing it, communicating, and validating with the user community. The analyst may often go through several cycles until the requirements document is signed off.

Methodology-and Model-Dependent – Offering the analyst a wide range of tools and techniques to elicit information, document the business, processes, and data elements, as well as define solutions.

Requirements-Driven – Defining one of the most important capabilities for the analyst to master: the ability to define, document, and communicate requirements.

•

•

•

•

•

1� | Module 1

Introduct�on


The Systems Development Life Cycle

In any project, we should go about our work using some kind of structured approach or methodology. In many organizations, the Systems department (Information Systems or Information Technology) uses an approach called a Systems Development Life Cycle (SDLC). The purpose of the SDLC is to provide a framework in which a systems project occurs. Each phase usually requires some level of review and approval to proceed to the next phase of work. From a graphical perspective, each component of the SDLC provides specific information and completes activities necessary to begin the next phase of work.

There are several variations on the SDLC. Various organizations and consulting companies have built their own methods based on internal requirements and previous project experience. In addition, different project types might demand a different methodology based on criteria like complexity, size, visibility, user involvement, timeframe, and management decision. However, the main phases in the SDLC and the ultimate objectives of any methodology are the same: initiate, analyze, design, develop, test, and implement a project.

Approaches

There are two different approaches to the industry-recognized SDLC. They are as follows:

Waterfall – Moving from project initiation through implementation and its related components. Waterfall dictates that all requirements are gathered before design work is started.

Spiral or Iterative – This approach focuses on smaller “chunks” of analysis, requirements development, and design work. It aims to produce individual modules of a system that will eventually interoperate as a whole. This approach dictates that only the requirements for any given component need to be identified at that time. Then the process is repeated for each additional phase of work.

•

•

Module 1 | 1�

Introduct�on


1� | Module 1

Introduct�on


Approvals

There are at least three points at which a Business Analyst commonly would seek approval to proceed. Each organization will have their own formal or informal process to document the project status and get the go-ahead to move forward or stop the project as appropriate. These approval checkpoints (often called approval gates) are used by management and the organization to make sure that the project work being undertaken is feasible, necessary, in line with the business objectives, prioritized, and that the project has expected value.

Approvals happen at the following levels:

Project Charter Approval – This approval happens at the completion of the initiation phase of the SDLC. It specifies information about the project objectives, scope, stakeholders, timeframes for analysis work, financial background, and a wide range of other components like feasibility, risk, and strategic fit. Approval is requested from the project sponsor, project manager (if assigned at this stage), and upper-level decision makers. If approved, work can begin in detailed analysis.

Requirements Approval – This approval happens upon completion of the analysis phase of the SDLC. The Analyst will review, validate, and verify all documents, models, requirements, assumptions, and constraints that were discovered during the analysis work. Validation is requested from the users, stakeholders, and subject matter experts. The requirements documentation will be updated (possibly numerous times) to reflect suggested changes, additions, and/or deletions to the requirements. Once the document is finalized, approval is requested from the project sponsor, project manager (if assigned at this stage), and upper-level decision makers. If approved, work can begin on the conceptual design.

Conceptual Design Approval – This approval happens at the conclusion of the conceptual design work, allowing the technical design work to commence. Approval of the technical design would also be necessary to move into the development and implementation phases of the project. This approval process may simply cover the suggested solution, or it may be a more all-encompassing decision package with input components and deliverables from all phases of initiation, analysis, and design work. Once the document is finalized, approval is requested from the project sponsor, project manager (if assigned at this stage), and upper-level decision makers.

•

•

•

Module 1 | 1�

Introduct�on


-

1� | Module 1

Introduct�on


Workshop Agenda

This workshop uses a case study to help you explore the topic of business analysis. The following topics are covered:

Introduction – Understand the objectives, topics, and logistics for the workshop.

In�t�at�on

Enterprise Analysis – Perform an overview to learn about the case study company.

Defining the Scope – Examine issues, identify stakeholders that are impacted, and use this information to define the scope and objectives of the project.

Analysis

Procedure Analysis – Analyze an existing business process and any supporting forms and reports. Document the process using a modeling tool.

Stakeholder Interviews – Interview key stakeholders and subject matter experts to get answers to questions about the existing procedure, as well as suggestions and requirements for improvement.

Requirements, Assumptions, and Constraints – Define the business and user requirements needed to create a successful future solution. Describe the assumptions and constraints associated with the solution.

Conceptual Design

Defining a Solution – Design a high-level solution to improve the business process.

Solution Implementation Planning – Review an implementation plan for the project.

Management Presentation – Prepare and present the results of the project decision package to key stakeholders and gain approval to go ahead with implementation.

Note: As previously stated, approval is an important part of any project. A go/no go decision will take place at the end of initiation, at the end of the analysis work, and after conceptual design. This workshop will focus on those approval gates and will culminate in a management presentation to get final approval to proceed with the project. All activities leading up to Module 9 will be used to some extent in the management presentation of the decision package.

�.

2.

�.

4.

5.

6.

7.

8.

9.

Module 1 | 1�

Introduct�on


Workshop Objectives

Fast Start® in Business Analysis has been specifically designed to help you accomplish a great deal in a short period of time.

In this workshop, you will:

Collect and analyze information about a specific case study company

Perform a high-level, preliminary investigation of a business process/system in need of improvement

Identify issues and the stakeholders/functional areas affected by the issues

Determine the scope for a business analysis project

Understand the business process by investigating how it currently works

Perform procedure analysis on the business process and document the results

Identify and interview key stakeholders and subject matter experts to validate knowledge of the current system, gain user involvement, and gather user requirements

Write requirements, assumptions, and constraints necessary in the future system

Use information gathered in analysis to create a high-level solution to the business problem

Recognize the potential impacts of the defined solution

Consider and document key activities required to implement the solution

Present the project decision package and gain approval to proceed with implementation

•

•

•

•

•

•

•

•

•

•

•

•

1� | Module 1

Introduct�on


Getting the Most from This Workshop

Generally, what people get from any workshop is directly related to what they put in. To help maximize the value you derive from Fast Start® in Business Analysis, you should consider doing the following:

Set your pagers on “stun” and your cell phone on “quiet” (or turn it off)

Respect agreed-upon class start, end, and break times

Keep an open mind

Participate at your comfort level

Think about and apply workshop information

Ask questions at any time

Share your relevant stories

Respect others’ views and keep them private

Put aside other work and problems, and avoid outside interruptions

Dress comfortably

Have fun!

•

•

•

•

•

•

•

•

•

•

•

Module 1 | 1�

Introduct�on


Workshop Logistics

Use the table below to record the logistics for your particular workshop.

Instructor’s name

Instructor’s email

Start/end times

Lunch (approximate)

Breaks

Your Role Th�s Week

For the next three days you will be working for a different company (if only you could get two paychecks?). Note the characteristics of our case study company below, along with your role in the company:

Employed by

Consultant or employee?

Job responsibility

Department

Your manager is

�0 | Module 1

Introduct�on


Workshop Materials

The materials used in this workshop include:

Participant Guide, including:

Class discussion material, worksheets, and templates

Case study exercises and background material

Appendices, including:

Blank and lined paper

Blank worksheets

Suggested reading list

Glossary

Index

Handouts for case study

Suggested solutions for exercises

Exercise � — Turn to the exercise in the back of the book and follow the facilitator’s instructions.

�.

•

•

2.

•

•

•

•

•

�.

•

jdjdjdjdjdjdjd

En

terprise A

naly

sis

Module � | �1


Module 2 Enterprise Analysis

�� | Module �

Enterprise Analysis



Define Enterprise Analysis and state its purpose

Identify the types and sources of information useful in this level of analysis

Perform a high-level enterprise analysis to “size up” the organization so that you can operate most effectively during further analysis work

Gain insights into the case study company involved in the workshop

Before we get started on our project, we should take some time to get oriented. The first project we work on as an employee or consultant requires us to consider the big picture and review the entire organization. We have to establish our bearings quickly and accurately to be effective in detailed analysis work. As our experience with the organization or department increases, it is equally important to revisit this enterprise analysis work at a high level to gain an understanding of what has changed.

Some analysts are asked to perform or assist in identifying business opportunities, strategic planning, and feasibility studies. It is not practical to be involved in this type of enterprise-altering work without a solid foundation of knowledge about the organization as a whole and how it relates to its customers, competition, the environment, market trends, financial factors, and a wide range of other components. Without understanding the important nature of enterprise analysis, a Business Analyst may get too caught up in the details to recognize the impact a process or system change could have on the organization and vice versa. Therefore, this step is critical to begin each and every project

•

•

•

•

Module � | ��

Enterprise Analysis


What is Enterprise Analysis?

Enterprise Analysis is the pre-project work that offers analysts insights into the past, present, and future of the organization and its working environment. New information only means something when we consider it as part of a familiar context.

Enterprise Analysis

Business Analysis activities that take place for organizations to (�) identify business opportunities, (2) build their business architecture framework and (3) determine the optimum project investment path for the enterprise, including implementation of new business and technical system solutions.3

We perform Enterprise Analysis for the following reasons:

To learn about the organization and its relation to the outside world

To relate our project to some context within the organization

To understand how past events led up to the situation as it stands right now

To provide a foundation for strategic planning, feasibility decisions, and risk assessment

To identify business’ requirements, goals, and objectives

To prepare the business case and the decision package for the project

� International Institute of Business Analysis (IIBA), Business Analysis Body of Knowledge (BABOK) version �.6

•

•

•

•

•

•

�� | Module �

Enterprise Analysis


Enterprise Analysis Activities

The following list highlights the various tasks and activities that Managers, Executives, Directors, Business Analysts, and Project Managers will be involved with. Business Analysts perform current state analysis and offer the foundational information necessary to make informed decisions at this level.

Enterprise Analysis activities are as follows:

Strategic plan development

Strategic goal development

Business architecture development and maintenance

Conducting feasibility studies

Conducting the initial risk assessment

Business case development and presentation

Determining project scope

New project proposals

Selecting and prioritizing new business opportunities

Launching new projects

Managing projects for value

Tracking project benefits

Preparing the decision package

The activities highlighted in bold will be discussed in this workshop.

•

•

•

•

•

•

•

•

•

•

•

•

•

Module � | ��

Enterprise Analysis


What Has Changed?

Enterprise Analysis is centered on fact finding. It is not decision/solution-driven in its own right, but the information uncovered may be helpful in initiating further investigation. One of the most important questions to ask when performing Enterprise Analysis is: what has changed?

Considering that all organizations experience internal and external changes, this question is relevant and may uncover new information on a day-to-day basis, and sometimes even minute-by-minute. When the investigation of the organization may be too high-level given a particular change, analysis of the department or functional area of work may be more appropriate. But don’t allow a narrow mindset to prevent you from seeing the bigger picture. Everything is related back to the greater whole and focusing too heavily on only one segment of the enterprise may create problems down the line.

This question is also relevant to help uncover why additional analysis work may be needed. Consider that business objectives, processes, and systems work to fulfill a certain need at a specific point in time. By asking “what has changed?” we may be able to identify the time and reason that changes took place, which impact the business, process, or system, causing it to no longer work in the same expected way. Projects have three main origins:

Changes in the outside world. New regulations and laws, changes to the economic climate, new competitive challenges, globalization opportunities, and customer demands create projects.

Changes in management thinking. Executives and top managers may reevaluate company objectives, philosophies, or activities, or a corporate restructure may necessitate projects to address the changes.

Changes in major systems or operations. Functional systems may suffer a significant breakdown or a series of small but troublesome problems that can no longer be ignored or corrected through Band-Aid” fixes. Newly installed systems and processes may have an impact on existing systems/processes that were not updated at the same time.

�.

2.

�.

�� | Module �

Enterprise Analysis


What Information Should We Gather for Enterprise Analysis?

What kinds of information can help us learn about the organization as a whole? Where would we look to get this information? Use the space below to record types and sources of information.

How Should We Collect This Information?

Here are a few guidelines for collecting information:

Start by learning the organization’s mission/vision statement, then get more detailed.

Keep an open mind and fact-finding perspective. Don’t jump to solution mode.

Watch out for over-collecting. This is meant to be high-level.

Write down key information for future reference.

Work from the general to the specific.

Don’t just gather material. Study it.

Most importantly, after gathering all the information, consider the question “what has changed?”

•

•

•

•

•

•

Module � | ��

Enterprise Analysis


Types of Information to Collect

As a first step, working from the general to the specific, we need a short, working definition of the main purpose of the organization. We want to state clearly what the organization does. This specific statement identifies the general industry and tells us what the company does within that environment. Extra information about the customers and markets it serves adds useful detail.

Beyond this, our individual lists will vary depending on the needs of the project and the characteristics of the analyst. For starters, here are some things we can look at:

Organization and size

Company size and location of subsidiaries

Recent organizational changes

Organizational charts

Global or local

General history

When did they get into the business they are in today?

Other businesses in the past?

Is it an “old” or a “new” company?

Products and services

Contributions to income for each product line or service offered

Any new products/services in the pipeline?

Any products or services dropped recently or in the past?

How do our products/services compare in the marketplace?

�.

•

•

•

•

2.

•

•

•

�.

•

•

•

•

�� | Module �

Enterprise Analysis


Functional areas or division of work

Main departments or divisions

The functional relationship between these areas

Industry practices

Changes and trends in industry practices

Known major industry problems

Niche products or services, differentiation

Sales and earnings

Trends and actual figures from annual report

Type and location of customers

Main competitors and products

How customers regard the company

Internal information

Accounting and auditing practices

Current patterns of management thinking, philosophies

Known major systems problems

Union or non-union

Level of technology in use

Culture of organization

Regulatory or legal compliance requirements

Willingness or adaptability to change

4.

•

•

5.

•

•

•

6.

•

•

•

•

7.

•

•

•

•

•

•

•

•

Module � | ��

Enterprise Analysis


Sources of Information

Information can be found in many various locations. Some of it will be documented and others may be word of mouth. Both are an important part of fully understanding the organization. Consider the following sources of information when performing Enterprise Analysis:

Intranet – The organization’s internal viewpoints and information source.

Internet – The worldwide view the organization would like to project from its own web-site. Also search other web-sites which have information posted about the organization. They may have more general and less biased viewpoints.

Financial Institutions – These may reference and rank the organization position and viability based on industry-recognized financial measurements.

External Documents – Profiles and prospectuses, organizational literature, marketing and media promotions, press releases, news and magazine reports, and customer-focused information.

Internal Documents – Human resources policies and procedures, organizational charts, functional area definitions, manuals, training materials.

Verbal Communications – The opportunity to speak with key individuals within the organization who have been around and know the history and possibly the strategic vision of the organization. In addition, discussions with people involved in day-to-day operations will offer insights into the culture, morale, work styles, cross-functional activities, etc.

Keep in mind that although this is analysis and a fact-finding mission, it is meant to be at a very high level. We sometimes refer to this as the 30,000-foot overview. We are trying to gain perspective and without a formal project scope, we don’t want to get too involved in the details and interviewing process just yet. There will be time for that once we have some direction and focus.

•

•

•

•

•

•

�0 | Module �

Enterprise Analysis


How Does Enterprise Analysis Help the Project?

Examining this information about the organization helps us in these areas of the business analysis process:

Project Definition. We concentrate on learning about issues and opportunities for improvement in the context of a larger framework; to see what they mean. Enterprise Analysis gives us that framework.

Planning the Analysis. The perspective we gain in our Enterprise Analysis helps identify additional information needs, where to collect that information, and define analysis work.

Project Charter and Scope Definition. We use background information to build our business case and justify the project. Our knowledge of some historical background gives credibility to our proposal. Knowledge of what has changed allows us to focus on where and when problems began or a new business requirement surfaced.

Procedure Analysis. Using a top-down approach allows the analyst to gain perspective and directs the work of digging for details within departments, processes, and systems.

Stakeholder Interviews. We are better able to recognize the general culture, values, and interactions of people both internal and external to the organization.

System Design. Our investigation allows us to understand the strategic plan and business objectives. It guides the analysis work to identify the best possible solution to fulfill the business needs, and helps steer clear of jumping directly to a technology-based solution.

Management Presentation. Our overall knowledge of the organization makes us look credible and well-grounded when we propose the decision package for approval. We also know which management interests to highlight in the presentation.

As you can easily see from this list, Enterprise Analysis is critical to every step in the process. It’s the right place to start any project even if just a small amount of time is allocated to this task.

Exercise 2 — Turn to the exercise in the back of the book and follow the facilitator’s instructions.

1.

2.

3.

4.

5.

6.

7.

Module � | �1

Enterprise Analysis


Real-World Application

To make Enterprise Analysis work for each and every project in the real world, try these suggestions:

Consider what has changed. Change prompts more change. Internal changes to processes or systems will have an impact on other processes or systems and will always have an impact on the employees. External changes can have a dramatic impact on the business, demanding change to adapt or else go out of business.

The big picture. Before digging for details, it is helpful to understand the big picture and have a broad perspective of the organization as a whole. It can also help position the project within the business for greater success.

Spend adequate time. Don’t feel like you’re backtracking in performing this work after a project has been initiated. It’s necessary to have a foundation of knowledge before proceeding to the details. It doesn’t have to take long to perform enterprise analysis if you are familiar with the organization and stay focused on the task.

Don’t skip Enterprise Analysis. Skipping enterprise analysis could create too narrow a focus even for a seasoned analyst who has been with the organization for a number of years.

Start documenting. Document your findings during enterprise analysis and reference them throughout analysis work. Also, start a glossary of terms that can be updated and used throughout the analysis work.

Don’t be surprised if your knowledge of the enterprise gets you involved in bigger initiatives, like providing information for strategic planning, feasibility studies, and risk analysis. It will also help further your career as someone who is capable of seeing the big picture and can recognize the corporate vision.

How can you apply these concepts in the real world?

•

•

•

•

•

��

Notes


jdjdjdjdjdjdjd

Interv

iewing

Module � | ��


Module 5 Interviewing

�0 | Module �

Interviewing



Recognize the importance of stakeholder involvement

Understand the best techniques for preparing and holding an interview

Discuss various questioning and listening techniques

Learn how to recognize and capture stakeholder requirements

Experience interviewing key stakeholders and users

The Standish Group first published its Chaos report on IT project outcomes in 1994. At that time, it reported that 53% of projects are challenged and 31% failed. More current statistics from 2004 indicate that 53% of projects are still challenged, but the failed projects have decreased to 18%.4

The Chaos report also indicates that year after year, one of the top three reasons for low project success is lack of user involvement. The next most important challenge/failure factor is missing or improper requirements. This can be attributed to the fact that without user involvement, the analyst will base its findings on inaccurate information, will misinterpret the user’s needs, will have to make assumptions about key project factors, and will write poor requirements or miss them all together. Therefore, interviewing users is a critical part of increasing the chances for project success. Maybe with a little extra user involvement, we can get the percentage of challenged projects to decrease over the next 10 years.

4 The Standish Group Chaos University report �994-2006, www.standishgroup.com

•

•

•

•

•

Module � | �1

Interviewing


Why Interview?

Interviewing can be a very powerful tool when we keep in mind the place it has in systems work. Business analysis depends on interviewing for the following reasons:

To get the right people involved and therefore create positive opportunities for change.

To learn how the process and systems really work.

To get answers to questions that were uncovered during the procedure analysis.

To identify needs and gather user requirements.

1.

2.

3.

4.

�� | Module �

Interviewing


Preparing for the Interview

We have to get ourselves ready before we can perform an interview. We have to think about our role as an interviewer. Only then can we think about why we want to see this person and how we will explain the purpose of the interview.

Most analysts, technical and non-technical, forget that in the analysis phase they must maintain a questioning, learning, investigative attitude instead of jumping to a solution. We want to learn more about the actual system and about the people who make it work in the real world. We are fact finding.

Here are some things to think about in advance of the interview. Answering these questions will make the interview more successful.

Determine in advance how you will handle:

Getting in and establishing rapport

Following leads and clues

Anticipating and countering problems

Using the right level of detail

Dealing with interruptions

Gaining cooperation and involvement, avoiding threats

Getting out and leaving the door open to future visits

•

•

•

•

•

•

•

Module � | ��

Interviewing


Interview Structure

Prepare your introductions

Practice how you will introduce yourself.

Identify the people you will be interviewing if there is more than one person and if you have never met them before.

Use a firm handshake.

Make eye contact and smile.

Thank them for their time.

Tell them how important their participation is.

Make them feel at ease and comfortable.

Describe the project background

Avoid an acronym or project nickname unless the person is familiar with the project.

Provide a status of the work being performed.

Let them know where they fit into the project.

Let them know why this project is important so they will want to get involved.

State the purpose of your visit

Consider using an agenda and email it in advance.

Consider sending your questions in advance or a list of items you need from them.

Do not tell them you are here to “fix” their problems, as they may not feel like there are problems to be fixed.

Do not tell them someone sent you to do the interview. You are there because they are an important part of the process and have information that can help improve things.

1.

•

•

•

•

•

•

•

2.

•

•

•

•

3.

•

•

•

•

�� | Module �

Interviewing


Discuss prepared questions and listen to their answers

Use active listening and avoid thinking about what to say next or what to ask next.

Do not interrupt or finish their thoughts, even if you can predict what they will say.

Rephrase their answers in your own words for validation.

Do not make any promises. You are fact-finding not solving at this stage.

Make sure you have a note-taking format prepared in advance

Write down anything you think is important.

Capturing their thoughts and ideas can be flattering. If you do not write things down, they may assume you will forget it and it will never get done.

Bring someone else along if you feel you ca not take effective notes and hold the interview.

Fill out your notes and write down additional information after the interview is over.

Email notes to the interviewee so that you are both on the same page about what was discussed.

Know how to end the interview when your time is up

Again, thank them for their time.

Summarize the key points as reminders.

Discuss any action items and timeframes for delivery.

Get names of other employees that might be helpful to your work.

Ask to speak with subordinates if interviewing a manager.

Ask if they would like any follow-up communications and how they would like them (i.e., in person, email, phone call).

Set up a future meeting time if everything was not discussed in this meeting.

4.

•

•

•

•

5.

•

•

•

•

•

6.

•

•

•

•

•

•

•

Module � | ��

Interviewing


Questioning and Listening Techniques

Open and closed questions. Prepare a variety of questions of both types. Open-ended questions get people talking and provide more information. Closed-ended questions are helpful for specific answers and validation.

Factual and emotional questions. Factual questions gain specific data and information components. Emotional questions uncover pain points, concerns, and impact. Both types of questions are necessary to gain a full understanding of what is going on.

Do not talk too much. During the interview, ask a question and then listen to the answer.

Ask only one question at a time. The interviewee may forget what was asked or have a hard time formulating an answer if too much is asked all at once.

Listen and observe. Learn to listen “completely.” Listen without judgment or criticism. Do not interrupt. Watch for nonverbal clues like facial expressions and body language. Try to go on a walkthrough or tour if you can.

Be interactive. Show that you are listening by using eye contact, body language, and nodding your head in agreement or disagreement. Stay interested, and do not get distracted.

•

•

•

•

•

•

�� | Module �

Interviewing


Listening for Requirements

Obviously one of the main reasons for holding an interview is to capture stakeholder requirements. But many times the entire interview goes by and we feel that nothing has been defined. We expect the user to be able to list out their requirements for the new system, but we are dissatisfied with what they have to offer. For now, let us keep it simple. We want to capture anything the stakeholder says that could possibly lead to a requirement which will be addressed in the next module. To listen for requirements, take note any time you hear the following:

“I need…” “I want…”

“It would be nice if…” “Can you make…”

“Can the future system …” “I have to keep…”

“I don’t like…” “It doesn’t work…”

“It needs to be improved…” “It’s broken…”

“I’d like to see…” “It would be helpful to have…”

“I suggest…” “As an idea…”

“Just a thought…” “I don’t want to lose the ability to…”

A good analyst can listen for requests, needs, concerns, comments, suggestions, ideas, thoughts, guidelines, issues, rules, and metrics to develop a list of potential requirements. They should be captured immediately and validated to get a better understanding of what is important and why it is necessary.

Module � | ��

Interviewing


Holding the Interview

When we get into the interview itself, we naturally want to give our attention to the list of questions we have prepared. At the same time, we want our interview to be effective and professional. The guidelines listed below cover different aspects that influence the success of the interview.

Follow an agenda. Send the agenda prior to the interview and ask them to respond with anything they would like to add (if time permits). Verify the meeting date, time, and place.

Start the interview right. Give the person you are interviewing a firm handshake and a smile. First impressions can make or break a successful interview.

Be aware of the interviewee as a person. Create a comfortable, supportive interaction with the person. Avoid stereotyping and unfounded expectations. Be sensitive to cultural differences, disabilities, and so forth. Also, be personable yourself.

Small talk. Small talk is helpful to open the doors to communication and establish rapport, but some interviewees may want to get right down to work. Keep small talk within reason.

Be appreciative. Thank the person for their time and for the knowledge that they are willing to share with you. A person who feels like they are appreciated will be more cooperative.

Control the interview. The interviewer is supposed to be in control of the interview. Watch your time, and do not let your interviewee talk you into making any promises.

•

•

•

•

•

•

�� | Module �

Interviewing


Watch for resistance and hostility. It is possible the interviewee may feel uncomfortable with the questions or concerned about their job or your perception of them. Try to determine what the hostility is about. Make them feel like they are an important part of the process.

Take notes. Ask for permission to take notes so that you can better capture all the important facts of the interview. Do not try to write an entire transcript, but do try to capture a fair amount of detail. If you detect an issue with taking notes, put away your pen and pad and just listen. Try to record the details as soon as the interview is over. If possible, interview with a team member who can take notes for you; two sets of ears are better than one.

Validate procedures and look for exceptions. Sometimes the interviewee will describe alternatives or exceptions to the process you previously analyzed. Listen for these and pursue them in detail to gain a better understanding of how the process really works.

Summarize and review. At the end of the interview, go over the main points and review any action items you may have. Set dates for the next meeting or for when you will pick up or drop off something you promised.

Gather your thoughts after the interview. Clean up your notes and write down anything else you were not able to capture during the interview. Consider summarizing the interview, with action items, and send a copy to the interviewee so everyone has the same information. Note any open issues or gaps and make plans to follow up on them.

Exercise 5 — Turn to the exercise in the back of the book and follow the facilitator’s instructions

•

•

•

•

•

Module � | ��

Interviewing



Do not try to play the ideal analyst. Don’t try to play some imaginary role of how an Analyst should look or appear. Just be yourself and try to act as naturally as you can.

Avoid trigger words and technical jargon. Some words can send the wrong signal to the interviewee and can produce an unwanted response. Also, unless the person is technical, discussing the technical details of a system will probably make them feel uncomfortable. Find a different way to get the point across and explain terms that might be confusing.

Be natural, comfortable, and confident. The more interactions and interviews you perform, the more comfortable you will be. Even though you may feel intimidated by a Vice President, for example, remember that he or she puts on socks the same way you do.

What is in it for me? Throughout the interview, remember the interviewee’s point of view. They need to know how they will benefit from your project, and from this interview specifically.

Be patient and versatile. Learn what “pushes your button,” then do what you need to control it. Remember that when someone is abrupt or rude, it is usually not personal. Do what you have to do to get the information you need from them, and adapt to their communication style.

Always summarize. Summarize periodically during the interview. Then summarize again at the conclusion with what was discussed, what was agreed upon, commitments they have made, and commitments you have made (next steps).

Do not rely on memory. Even the best analyst needs a little assistance remembering the key points. Either take notes during the interview or as soon after the interview as possible.


•

•

•

•

•

•

•

�0

Notes


jdjdjdjdjdjdjd

Solution

Implementation

Planning

Module � | ��


Module 8 Solution Implementation Plann�ng

�� | Module �

Solution Implementation Planning



Recognize the tasks that must be done to implement the proposed solution

Estimate time and resources for the implementation

Projects can fail for any number of reasons, but you can trace many failures to poorly thought-out approaches to implementation planning and scheduling. The techniques involved do not present much of a problem. Most people find them sensible and easy to understand.

Project Managers will often play a major role in defining the final implementation schedule. But, they often ask the Business Analyst for information or even to build the preliminary plan. In addition, before making a presentation to management, the Project Manager will want to know how long it will take to deliver a solution. While this is not a course in project management, we should consider the work that must be done to prepare for this step.

•

•

Module � | ��



Systems Development Life Cycle Review

The first three phases of the traditional SDLC are now almost complete. Once management approves the decision package, it will be time to move forward. After approval, the analysts may still spend time eliciting, refining, and documenting requirements until they feel they have the most accurate and completely detailed requirements specification that can be turned over to technical designers and/or developers.

InitiationApproval of project scope and agreement to proceed with analysis work

•Completed

Analysis Development and approval of requirements document

• Completed

Conceptual Design Pending approval for project decision package

• Pending Approval

Phases for Implementation Planning

The phases below should be the focus for implementation planning. Once approval of the decision package is granted to continue the project, and the final requirements specifciation is deliverd, then technical design can begin. At this point, the analyst may still be involved, or the project may be taken over by the developers and designers, with the analyst providing assistance as needed. In addition, it is common that a Project Manager may be assigned at this stage to fully plan, budget, and oversee the implementation of the proposed system. For now, we want to offer a high-level implementation plan that considers the key tasks to move the project forward.

Techn�cal Des�gn

Detailed system/program specificationsBuild vs. Buy decisionVendor selection

•

••

RFP - Requests for proposals, detailed technical specifications and data models

Development

Developing the application code Installing and configuring a purchased solution

•

•

Modules of code, configuration parameters, technical documentation

Test�ng Testing functionality, user acceptance, quality, etc.

• Test scripts and results

Implementation

Application rollout to a select group of users (pilot)Deployment to production environment

•

•

Installed applications, system documentation, training, and user reference materials

100 | Module �



Planning to Implement the Future Changes

Most projects can be handled with basic techniques. The process of planning and scheduling for a project uses these main steps. Each step has more than one technique or tool associated with it, each with its own name.

Break the project down into component tasks within each phase.

Assign resources to the people or departments that can best perform the task.

Estimate the time each task will take to complete.

Sequence the tasks in general order from the start to the end of the project.

Chart the plan, showing general sequence, to get a visual picture of the whole project with its dependencies and durations.

Visualizing the Project Schedule for Implementing the Solution

Earlier we planned the work that we needed to perform as the Business Analyst to get from initiation to the conceptual design. We have made it through all of those tasks but still have a little more planning to do. The goal of implementation planning is to define how much time it will take for the proposed solution to get to the production environment.

In the management presentation, we are likely to get asked:

How long will the project take to implement?

Who needs to be involved?

So that we can answer those questions, we must do a little brainstorming to formulate a reasonable plan. Once approved, the Project Manager will more than likely create a more thorough and detailed implementation plan. Until then, let us give it our best effort.

�.

2.

3.

4.

5.

•

•

Module � | 101



Step 1 — Break the Project down into Tasks

Think about ALL of the work that needs to be performed to get the solution implemented. It is helpful to consider implementation activities from the perspective of the three types of changes we have identified in the conceptual design: systems development, process improvement, and organizational change. For example:

Systems Development – Send RFPs to vendors, review vendors, select products, buy hardware, install and configure software, build the interfaces, test applications, roll out pilot, etc.

Process Improvement – Automate manual entry process, develop change communication plan, move employee offices, buy necessary equipment, perform inventory count, train employees, etc.

Organizational Changes – Reorganize departments, revise job descriptions, build cross- functional communication plan, present changes to all employees, release new product, verify building readiness for move, etc.

Too often, the focus is centered on just creating the automated system, and all other human and corporate tasks are forgotten. Also, do not forget about management communication and approval, as it is a critical component which will happen at various intervals throughout the implementation process.

Step 2 — Assign Resources

When you have listed all of the tasks, you can allocate resources to those tasks. You may assign the task to a team member, or indicate what skills are necessary if a team member does not have them. This way, our manager can help identify the people we need. Do not forget to assign material resources as well, such as tools, hardware, software, etc.

If the resource is not available in house, we may have to assign consulting resources or other external expertise.

•

•

•

10� | Module �



Step 3 — Estimate Time

This may be the most challenging part of the process, since it is easy to underestimate the time it will take to perform a particular task. There is often a lot of hidden time that goes into the particular task that is difficult to identify. Estimating is a skill which often requires previous experience, and domain knowledge, as well as knowledge of the system or component architecture and interfaces.

Consider, for example, facilitating a one-hour meeting. The one-hour timeframe can be deceiving when you consider: 30 minutes to build the agenda, 15 minutes to write an email inviting the participants, three hours to prepare the meeting materials and presentation, one hour to hold the meeting, 20 minutes of discussion with coworker after the meeting ends, 10 minutes to clean up meeting room, 45 minutes to write up notes and action items, and 15 minutes for follow-up email to participants. The one-hour meeting from start to finish is now 6 hours and 15 minutes. Amazing, isn’t it? No wonder we can never get anything done.

There are various methods that can be used to estimate time, but none of them are without flaws, and that is why it is called an estimate. Unfortunately, management will often hold you to the estimate as the actual timeframe required, and are disappointed if the project does not proceed as planned. Try the following methods for making your estimates:

SWAG – Your best guess may be good enough at this stage. Let the project manager handle the specifics.

Experience – Provide your insightful knowledge to define the most appropriate amount of time.

Ask around – Ask the people who perform the work how long they think it will take to complete.

Other estimates – Use the amount of time that was allocated to performing a similar task from another project.

Actual timeframes – Better yet, use the time that it actually took to perform the task based on a project plan already completed.

Industry experience – When accuracy becomes critical, there are web sites, texts, project management techniques, and consulting firms that offer best practices for defining tasks, timeframes, and methodologies for implementation planning.

Some project managers will add a “float” value to their estimates. This is additional time in hours or a percentage to make sure that all factors that could impede completion are accounted for, even if not individually listed. For instance, determining the time it will take and then adding 20%, or figuring a best guess and then doubling the number just for safe measure.

•

•

•

•

•

•

Module � | 10�



Step 4 — Sequence the Tasks

To make the implementation successful, all tasks need to be identified and then woven together in the proper sequence to create a quality implementation plan. Tasks that are dependent on other tasks being completed should be arranged accordingly. From previous experience and team consensus, logically order the tasks so they make sense from start to finish, and work together as a cohesive plan.

Step 5 — Chart the Plan

One tool we can use to visualize a project is called a Gantt chart. This chart is most often prepared using project management software as shown in the diagram below.

The tasks are shown to the left, usually followed by the resource assigned (not shown), start and end dates, duration, calendar indicators across the top, and graphical duration of the task shown as bars or block lines. Arrows used in the software help indicate dependencies or relationships between tasks.

ID Task Name Start Finish Duration

Sep 2006 Oct 2006 Nov 2006

9/10 9/17 9/24 10/1 10/8 10/15 10/22 10/29 11/5 11/12 11/19 11/26 12/3

1 10d9/20/20069/7/2006Planning

2 10d9/20/20069/7/2006Evaluate current systems

3 19d10/17/20069/21/2006Analysis

4 10d10/4/20069/21/2006Define user requirements

5 5d9/27/20069/21/2006Define web content

6 5d10/11/200610/5/2006Define technical requirements

7 3d10/16/200610/12/2006Define network requirements

8 1d10/17/200610/17/2006Get user sign off

9 15d11/6/200610/17/2006Design

10 10d10/30/200610/17/2006Design user interface

11 5d10/23/200610/17/2006Design data model

12 5d11/6/200610/31/2006Design system architecture

13 20d12/4/200611/7/2006Develop

14 15d12/25/200612/5/2006Test

15 10d1/8/200712/26/2006Implement

Before there were personal computers, Gantt charts were hand-drawn on graph paper. These work just as well and will provide all the details we need. Today, Gantt charts can be produced in project management software, as well as popular spreadsheets and drawing tools.

To chart the implementation plan, write the timeframe delineation across the top of the chart and the tasks that have been sequenced in the left column. In the next column list the resources assigned. Draw a bar or block to indicate duration of each task. When the chart is finished, look at the last task to determine the total amount of time needed for implementation.

10� | Module �




Use sticky notes, one for each task. Write the task in the middle, the timeframe in the left-hand corner, and the resource assigned in the right-hand corner. Then arrange the sticky notes on a wall, white board, or cling sheets. It is a fast and easy way to create the chart interactively.

Divide and Conquer. Brainstorm the task list, time, and resources, then discuss various ideas. A good way to assign timeframes is to take an average of each person’s estimated time. Some will be high, some will be low, and the average may be just right.


Exercise 8—Turn to the exercise in the back of the book and follow the facilitator’s Instructions.

•

•

10�

Notes
