STRATEGIC PLANNING PROCESS: STEPS IN DEVELOPING

STRATEGIC PLANS
I. Strategic Planning Process Defined
Successful RBA efforts involve strategic planning, implementation, monitoring, and
evaluation (which will ultimately provide data that will be used in future planning and
implementation efforts). Strategic planning, an essential first step in the development of a
results-based accountability system, is defined as the process of addressing the following
questions:

Where are we?

What do we have to work with?

Where do we want to be?

How do we get there?

This process is undertaken by states, organizations, programs, and sub-programs.

The steps involved in developing a strategic plan are described below. Although this process
appears systematic and rational, it is often iterative and evolves substantially over time.
Further, it is subject to political pressure and will be modified accordingly. Some strategic
planning efforts may not include all the steps described. The elements and process described
in the next section should be modified depending on context.
II. Components of a Strategic Planning Process
The first step in the strategic planning process is to address the questions Where are we?
and What do we have to work with? Examination of recent history and changing contexts
(both internal and external) of the state, organization, program, or sub-program allows
participants to assess current positions. Answering the question of what we have to work with
involves consideration of strengths and weaknesses and determination of how to capitalize on
strengths.
The next step in the process is answering Where do we want to be? As the articulated
vision stems from the values of those involved in the process, it is essential that this step
involve all of those who will have a stake in the achieving the vision. For agencies and
programs, the vision is then translated into a mission statement: a broad, comprehensive
statement of the purpose of the agency or program. States and communities may not have
UNIT I
1

INFORMATION SYSTEM AND ORGANIZATION

mission statements, as they may have multiple purposes. If unable to design mission
statements that can encompass multiple divergent goals, planners should articulate several
separate mission statements reflecting different goals.
The next step in the planning process is the articulation of goals. Desired long-range
conditions of well-being for the state, community, agency, or program, goals indicate the
intended future direction of the state, agency, or program. An example of a state goal is that
all children and families be healthy by the year 2010.
After articulating the vision and determining goals, planners must address means of
reaching their goals. This step involves articulating strategies for achieving results. Strategies
should reflect the strengths and weaknesses of the entity engaged in the planning. For
example, a very small office should recognize that its size could be both a weakness and
strength. The size would limit it to strategies that do not require large human resource
commitments, but would allow it to use strategies requiring rapid dissemination of
information throughout the organization. Recognition of relative strengths and weaknesses is
helpful in identifying promising strategies.
RBA system development must include consideration of methods of goal
measurement. Some strategic planning processes include this step; others leave this question
to be addressed by a separate process. Addressing goal measurement involves articulation of
objectives, indicators, and benchmarks. Objectives are the short-term conditions needed to
achieve desired conditions of well-being for children, families, or communities in the long
term. Indicators are quantifiable measures of progress; they provide numeric assessment of
the desired conditions of well-being Benchmarks are target levels of performance expressed
in measurable terms and specified time frames, against which actual achievement is
measured.
III. State Experiences with Strategic Planning: Lessons Learned
Many states have developed strategic plans to guide results-based accountability systems.
Examination of numerous planning processes yielded the following lessons:

Successful efforts involve stakeholders and gain their support. Strategic plan
development requires consideration and articulation of values and priorities; the plan
should reflect views expressed by all those involved in the process. States that have
successfully designed and adopted plans included all those interested in the strategic
planning process. For example, processes have been developed to involve program

UNIT I
2

INFORMATION SYSTEM AND ORGANIZATION

managers, providers, legislators, and the public in the articulation of visions. Some
states have held public meetings; others have coupled meetings of policymakers with
public opinion polls asking about the core values of citizens. Inclusion of key
stakeholders can take many months and requires that resources be devoted to the
activity. However, it is essential to the success and sustainability of the effort.

Prioritizing goals is an essential step in developing a strategic plan for a RBA system.
Strategic plans are not merely laundry lists of goals, but rather reflect the priorities of
those participating in the planning process. The most useful plans are succinct and
easily translated into useful measures. Inclusion of too many goals causes states,
agencies, and programs to become overwhelmed with the details of data collection
and reporting. Friedman (1996) recommends choosing a limited number of broad
goals that reflect multiple objectives.

Successful public strategic planning processes address conflicting mandates and

goals. State officials and managers of public programs are often faced with the need
to negotiate between conflicting mandates and goals when articulating strategic plans.
For example, job training legislation may include a program goal of placement of all
trainees within one month of program completion. Another goal in the same
legislation may be that trainees retain employment for at least one year. These goals
may conflict: employment that is obtained quickly may not be the best match for the
trainees, so they may be more likely to leave these jobs. In such cases, legislation may
have been drafted with input from numerous representatives with conflicting views.
As public managers develop strategic plans, they should recognize that programs may
have conflicting mandates and be explicit about what the agency can and cannot do in
light of the mandates.

KEY OBJECTIVES FOR THE ORGANIZATION

Organizations

must

achieve

certain

objectives

in

order

for

Leadership

Development programs to be successful. Some of these objectives are:

Identifying pockets of talent throughout an organization and directing them through

career development and succession planning programs.

UNIT I
3

Grooming individuals that show high potential

INFORMATION SYSTEM AND ORGANIZATION

Assist employees in developing and increasing their self-awareness so that they have
a better understanding of their own strengths and weaknesses.

Create leaders and encourage individual autonomy at increasingly lower levels within
the company.

Train managers to be highly successful and creative mentors and coaches.

Integrate the overall approaches to management development with other human

resource strategies such as performance management, career development, and
recruitment strategies.

The Organizational Process

Organizing, like planning, must be a carefully worked out and applied process. This process
involves determining what work is needed to accomplish the goal, assigning those tasks to
individuals, and arranging those individuals in a decision-making framework (organizational
structure). The end result of the organizing process is an organization a whole consisting
of unified parts acting in harmony to execute tasks to achieve goals, both effectively and
efficiently.
A properly implemented organizing process should result in a work environment where all
team members are aware of their responsibilities. If the organizing process is not conducted
well, the results may yield confusion, frustration, loss of efficiency, and limited effectiveness.
In general, the organizational process consists of five steps (a flowchart of these steps is
shown in Figure 1 ):

Figure 1The organizational process.

UNIT I
4

INFORMATION SYSTEM AND ORGANIZATION

1. Review plans and objectives: Objectives are the specific activities that must be
completed to achieve goals. Plans shape the activities needed to reach those goals.
Managers must examine plans initially and continue to do so as plans change and new
goals are developed.
2. Determine the work activities necessary to accomplish objectives: Although this
task may seem overwhelming to some managers, it doesn't need to be. Managers
simply list and analyze all the tasks that need to be accomplished in order to reach
organizational goals.
3. Classify and group the necessary work activities into manageable units: A
manager can group activities based on four models of departmentalization: functional,
geographical, product, and customer.
4. Assign activities and delegate authority: Managers assign the defined work
activities to specific individuals. Also, they give each individual the authority (right)
to carry out the assigned tasks.
5. Design a hierarchy of relationships:A manager should determine the vertical
(decision-making) and horizontal (coordinating) relationships of the organization as a
whole. Next, using the organizational chart, a manager should diagram the
relationships.
DEVELOPING AN INFORMATION SYSTEM:
The steps involved in developing an Information System are:

Analysis

Feasibility Study

System Design

Testing

Implementation

Documentation

ANALYSIS:

UNIT I
5

INFORMATION SYSTEM AND ORGANIZATION

This is a very important part in the development of an Information System and involves
looking at an organization or system (such as a nursery school) and finding out how
information is being handled at the moment.

UNIT I
6

INFORMATION SYSTEM AND ORGANIZATION

If there is no computer system then the first task will be to look at existing manual systems.
It is possible to find out about existing systems in a number of ways:

Talking to the people who work with the system.

Questionnaires to existing users.

Observing how people use the system.

Reading existing manuals.

If the aim is to improve an existing computer system the methods of analysis

previously mentioned are still important.

The analysis phase often includes a feasibility study.

At the end of this phase a decision needs to be made as to what software to use.

FEASIBILITYSTUDY:
The aim of a feasibility study is to see whether it is possible to develop a system at a
reasonable cost. At the end of the feasibility study a decision is taken whether to proceed or
not.
A feasibility study contains the general requirements of the proposed system.
Let us consider the task of setting up an Information System for a nursery and seeing how
Information Technology can help it run more efficiently.
The study might identify the following general requirements for the system:

To be simple and easy to use.

To store all relevant details of the members.

To produce membership lists, membership cards and mailing labels.

To produce posters, flyers and similar material advertising the nursery.

DESIGN:
The areas that need to be considered in the design process are listed below:
UNIT I
7

INFORMATION SYSTEM AND ORGANIZATION

1. Outputs
2. Inputs
3. File Design
4. Hardware
5. Software
OUTPUTS:
Some of the outputs for a system for a nursery might be:
a) Details of the children looked after within the nursery.
Name

Address

Telephone No.

Membership No.

Smith, Tony

12 Fields Rd

0543 3445545

001342

Jackson, Jake

9 Man Gdns

0563 9545752

001234

Timms, Tony

87 Colly Row

0543 8653653

001789

Fogett, Carol

9 Shaw St

0563 9657564

001455

b) Address labels for parents of the children.

Mrs Jackson Mr Timms

Mrs Fogett

Mr Smith

9 Man Gdns 87 Colly Row 9 Shaw Street 12 Fields Road

Todthope

Todthope

Todthope

Todthope

TD3 5TT

TD3 8DE

TD3 3HG

TD3 7HJ

DESIGN-INPUTS:
To work out the inputs required for a system several questions need to be addressed:

What data needs to be entered into the computer system?

How much data needs to be input, and how often?

Where does the data come from?

How will the data be entered into the system?

DESIGN - FILE DESIGN:

How many files are needed and what will their structure be? A nursery membership file might
have the following structure:

UNIT I
8

INFORMATION SYSTEM AND ORGANIZATION

UNIT I
9

INFORMATION SYSTEM AND ORGANIZATION

DESIGN HARDWARE:
This section covers the types of computers and printers thought suitable for the system
being analysed.
If the system needs to be on a network, details would be specified here.
DESIGN SOFTWARE:
A decision will have to be made as to what software to use.
The most common software packages are databases, spreadsheets and word processing
packages.
TESTING:
Any new system needs to be thoroughly tested before being
introduced.
First of all the system should be tested with normal data to see if it
works

correctly.

Secondly, the system is tested with data containing known errors to

try

and

make

it

fail

('crash').

Thirdly, the system is tested with very large amounts of data to see
how it can cope.
It is important that processing time and response rates remain
acceptable with varying amounts of data.
A test plan should be designed before testing commences.
Part of
system

Purpose

Expected result

Actual result

Add new

New member on members New member

member

list

appeared

Remove a

Member not on

Member deleted

member

membership list

from list

tested
Members File

Members File

UNIT I
10

INFORMATION SYSTEM AND ORGANIZATION

IMPLEMENTATION:
Implementing or introducing a new system can be done in two
ways:
Direct Implementation
Parallel Running
DIRECT IMPLEMENTATION

With this method of implementation the users stop using the manual
system and start using the computer system from a given date.
The advantage of this method is that it is less costly in effort and time
than any other method of implementation. The disadvantage of this
method is that if problems occur the users do not have any alternative
apart from returning to a manual system which may prove difficult if it
has been discontinued.
PARALLEL RUNNING
With parallel running, the new system is introduced alongside the
existing system. With parallel running both systems (manual and
computer, or old computer and new computer system) will be in
operation at the same time. This has the advantage that the results
from the new system can be compared with those of the old system.
However, it has the major disadvantage that each job is done twice
and therefore it means a lot of extra work for the users.
DOCUMENTATION:
A number of documents are produced during the development of a
new computer application.
Essentially there are two types:

UNIT I
11

User Guides

Technical Documentation

INFORMATION SYSTEM AND ORGANIZATION

USER GUIDES:
User guides are written in plain English rather than technical language.
The guide should cover how to run the system, how to enter data, how to
modify data and how to save and print reports.
The guide should include a list of error messages and advice on what to
do if something goes wrong.
TECHNICAL DOCUMENTATION:
Technical documentation is used to explain a system to a specialist i.e. an
analyst/programmer.
This document will be used if any changes have to be made to the
system.
It is a very important document which needs to be fully up-to-date.
MAINTIANABILITY AND RECOVERABILTY

UNIT I
12

INFORMATION SYSTEM AND ORGANIZATION

UNIT I
13

INFORMATION SYSTEM AND ORGANIZATION

DESIGN FOR MAINTAINABILITY DESIGN CONSIDERATIONS

Factors that should be considered when designing for maintainability are provided below.
A. Non-Interference of Preventive Maintenance - Preventive maintenance should be
minimized and require as little crew time as feasible.
B. Flexible Preventive Maintenance Schedule - Preventive maintenance schedules
should be sufficiently flexible to accommodate changes in the schedule of other
mission activities.
C. Redundancy - If maintenance is necessary and system operations will be interrupted,
redundant installations should be considered in order to permit maintenance without
interrupting system operation.
D. Goals of Designing for Maintainability - The following are goals for optimizing
crew involvement in both preventive and corrective maintenance.
1. Reduce training requirements of crew.
2. Reduce certain skill requirements of crew.
3. Reduce time spent on preventive and corrective maintenance.
4. Increase maintenance capabilities during mission (especially corrective

maintenance).
E. Corrective Maintenance - The following factors should be considered when
designing for corrective maintenance tasks.
1. The benefit gained from repair should be worth the time and effort expended
on repair.
2. The time and effort involved in corrective maintenance should be weighed
against the cost and feasibility of carrying replacement units.
3. Required calibration, alignment, or adjustment should be easily and accurately
accomplished.
4. Automate fault detection and isolation tasks whenever possible.

UNIT I
14

INFORMATION SYSTEM AND ORGANIZATION

DESIGNS FOR MAINTAINABILITY DESIGN REQUIREMENTS

Equipment Design Requirements
All flight hardware and software shall be designed to facilitate on-orbit maintenance, checkout and shall be compatible with ground maintenance capabilities.
Equipment design shall minimize both complexity and time requirements for maintenance.
Equipment design for maintenance shall consider IVA as the prime resource; maintenance by
EVA shall be contingency only.
General Maintainability Design Requirements
General requirements to be followed when designing for maintainability are presented below.
a. Growth and Update - Facilities, equipment, and software design shall allow
reconfiguration and growth during the mission.
b. Independence - Systems and subsystems shall be as functionally, mechanically,
electrically, and electronically independent as practical to facilitate maintenance.
c. Maintenance Support Services - Maintenance support services ( e.g., electrical outlets)
shall be accessible at potential problem locations or at a designated maintenance location.
d. Reliability - Equipment design shall reduce to a minimum the incidence of preventive
and corrective maintenance.
e. Simplicity - Equipment design shall minimize maintenance complexity.
f. Time Requirements - Equipment design shall minimize the time requirements for
maintenance.
g. Equipment - Maintenance equipment and tools shall be kept to a minimum.
h. Hazardous Conditions - System design shall preclude the introduction of hazardous
conditions during maintenance procedures.
USER ROLE IN SYSTEM DEVELOPMENT:
FUNCTIONAL ANALYST
A functional analyst career is one of the most critical ones. The job duties prove crucial
among the overall organizational operations due to their dependency roles.

UNIT I
15

INFORMATION SYSTEM AND ORGANIZATION

The common job responsibilities include

Conducting series of meetings with the client

Probing the client regarding the system requirements through various means

Documenting the received information regarding the requirements

Analyzing the complete requirements and forwarding it to the designers in a specified

format

The functional analyst role is involved not only during the early stage of the system, but
throughout the whole development process.
Example:
Objective: To join a highly reputed and dynamic organization as a functional analyst and to
take my career to better heights through extra ordinary performances with a great consistency.
Summary of Qualifications:

A great deal of experience as a functional analyst at reputed corporations

Tremendous and exact knowledge of the job profile and its supporting processes such
as UML, algorithms, etc.

Ability to work under large work pressures and deadlines

Great innovative attitude in applying new and effective analyzing procedures

Absolute command at various development software and the web platform

Excellent spoken English abilities and high level of convincing powers

Extra ordinary tendency of approaching the solution through the most efficient
pathway

Professional Experience:
ABC Co Ltd., Los Angeles, CA (2007-Present)
Senior analyst

Conducting meetings with the client regarding requirement analysis

Following standard analysis procedures to understand the primary format and scope
of the system requirements

UNIT I
16

INFORMATION SYSTEM AND ORGANIZATION

Instructing subordinate about the points to be documented and the common

documenting conventions

Analyzing the documented information and converting it into assertive forms

Preparing the standard reports and forwarding them to the concerned authorities

SOLUTIONS ARCHITECT
A Solutions Architect in Information Technology Enterprise Architecture is a practitioner in
the field of Solution Architecture
The role title has a wider meaning in relation to solving problems, but is more often used in
the narrower domain of Technical architecture - the context for the remainder of this
definition. In this context, the Solutions Architect is a very experienced architect with crossdomain, cross-functional and cross-industry expertise. He/she outlines solution architecture
descriptions, then monitors and governs their implementation.
Overview
The role of "Solutions Architect" requires knowledge and skills that are both broad
and deep. To be effective the Solutions Architect must have experience on multiple Hardware
and Software Environments and be comfortable with complex heterogeneous systems
environments. The Solutions Architect is often a highly seasoned senior technocrat who has
led multiple projects through the Software development process or Systems Development
Life Cycle (SDLC), and has usually performed in a variety of different roles in that life cycle.
The person needs an ability to share and communicate ideas verbally, both orally and in
writing, to executive staff, business sponsors, and technical resources in clear concise
language that is the parlance of each group.
A practitioner of Solution Architecture, Systems engineering and Software engineering
processes, the Solutions Architect is the person who organizes the development effort of a
systems solution. The Solutions Architect is responsible for the development of the overall
vision that underlies the projected solution and transforms that vision through execution into
the solution. The Solutions Architect becomes involved with a project at the time of inception
and is involved in the Functional analysis (FA) of developing the initial requirements. They
then remain involved throughout the balance of the project.

UNIT I
17

INFORMATION SYSTEM AND ORGANIZATION

The Solutions Architect is an expert in many categories. They should have hands-on
experience in multiple industries and across several disciplines. They can master a variety of
hardware platforms including mainframes, distributed platforms, desktops, and mobile
devices. Akin to that they should also possess skill and understanding of a variety of
Operating Systems. A broad and deep understanding of Databases is also required.
Solutions Architects decide which technologies to use. They work very closely with
developers to ensure proper implementation. They are the link between the needs of the
organization and the developers.
Solution Architects in large organizations act as the bridge between the Enterprise Architect
and the Application Architect.
The Solutions Architect has several essential duties and responsibilities, which include all or
some combination of the following:

Solutions Architect topics

Business Planning and General Management

Take ownership of a particular solution offering

Develop and execute a solution strategy and business plan that support product growth

Shape, design, and plan specific service lines in product area

Spearhead product marketing

Subject Matter Expertise

Act as visionary and strategist for solution product area

Survey market landscape for solution insights, direction, vendors, and methods

Provides expertise to identify and translate system requirements into software design
documentation,

Work with technical writers to ensure quality internal and external client-oriented
documentation

Speak at trade conferences and seek authorship opportunities in trade publications

UNIT I
18

INFORMATION SYSTEM AND ORGANIZATION

Business Development

Help marketing departments develop marketing materials and position strategies for
product area, in conjunction with overall marketing message framework

Help business development life cycle by serving as a product SME to help identify and
qualify business development opportunities

Manages sales and marketing activities for the service offering

With Channel Development team, develop and maintain vendor relationships within the
product

Methodology and Quality Assurance

Lead development of formalized solution methodologies

Build and maintain repository for deliverables, methodologies, and business development
documents

Interface and coordinate tasks with internal and external technical resources. Collaborates
with Project Managers and technical directors to provision estimates, develop overall
implementation solution plan, and serve lead as required, to implement installation,
customization, and integration efforts

Oversee aspects of project life cycle, from initial kickoff through requirements analysis,
design and implementation phases for projects within solution area

Provide quality assurance for services within solution area

Write, or direct the writing of white papers that further insight and thought in the solution
area

Work Force Management, Supervision and Mentoring

Manages a team of direct reports who drive service lines in the solution area

Assists staffing coordinators who define project team requirements for projects in
solution area

Work with Delivery Services Director to define overall recruiting needs and expertise in
solution area

Work with Director of Delivery Services to establish professional development needs for
practitioners in solution area

Mentor and guide more junior technical resources

UNIT I
19

INFORMATION SYSTEM AND ORGANIZATION

DEVELOPMENT LEAD
A lead programmer or development lead is a software engineer in charge of one or more
software projects. Alternative titles include Development Lead, Technical Lead, Senior
Software Engineer, Software Design Engineer Lead (SDE Lead), Software Manager, or
Senior Applications Developer. When primarily contributing in a high-level enterprise
software design role, the title Software Architect (or similar) is often used. All of these titles
can have different meanings depending on the context.

Responsibilities
A lead programmer's exact responsibilities vary from company to company, but in general he
or she is responsible for the underlying architecture for the software program, as well as for
overseeing the work being done by any other software engineers working on the project. A
lead programmer will typically also act as a mentor for new or lower-level software
developers or programmers, as well as for all the members on the development team.
Although the responsibilities are primarily technical, lead programmers also generally serve
as an interface between the programmers and management and have supervisorial
responsibilities in delegating work and ensuring that software projects come in on time and
under budget. Lead programmers also serve as technical advisers to management and provide
programming perspective on requirements. Typically a lead programmer will oversee a
development team of between two and ten programmers, with three to five often considered
the ideal size. Teams larger than ten programmers tend to become unmanageable without
additional structure. A lead programmer normally reports to a manager with overall project or
section responsibility, such as a director or product unit manager (PUM).
Responsibilities

Design system developments to e5 in conjunction with the e5 Change Team, Projects

and users. Agree viable system solutions to solve business problems.

Accountable for appropriate and consistent use e5 QEDs, Softpaint and other tools.

Ensure that e5 changes are documented using agreed standards, methods and tools.

Apply risk management techniques to system change and controls to satisfy internal
and external audit and financial control requirements.

UNIT I
20

INFORMATION SYSTEM AND ORGANIZATION

Actively co-ordinate sign-off by all parties of clear requirements in a timely manner to

avoid waste.

Help to resolve live (production) technical problems, liaising with internal partners
and third party suppliers as necessary. Advise on preventative maintenance as it
affects e5.

Build and maintain relationships with other teams in Finance Systems, internal
customers, internal and third party suppliers.

Ensure due preparation to support e5 fixes, changes and implementations prior to go

live.

Provide leadership and engagement of staff, deliver effective performance

management in line with Friends Life policy and processes. Ensure that all staff are
effectively allocated to satisfy current and planned demand.

Deliver accountabilities within the allocated cost base

Systems developer:
Systems developers work on the internal operations of computers. They work within
organizations to solve computer problems using existing systems or incorporating new
technologies to meet particular needs. They test both hard and software systems, and
diagnose and resolve system faults.
The role also covers writing diagnostic programs and designing and writing code for
operating systems and software to ensure that they function more efficiently. When required,
they make recommendations for future developments to software or operating systems.
Systems developers may also create systems in response to technical specifications supplied
by an IT analyst. This may require integrating off-the-shelf software packages into the
existing systems.

Typical work activities

Tasks vary according to the type of organization and size of employer that you are working
for, but will typically involve:

consulting with colleagues or clients with a view to writing or modifying current

operating systems;

evaluating and implementing ways to incorporate existing or new technologies;

UNIT I
21

INFORMATION SYSTEM AND ORGANIZATION

observing, testing, diagnosing and resolving faults in the software;

writing and testing code and then refining and rewriting as necessary;

writing systems to control the scheduling of jobs on a mainframe computer or to control

the access allowed to users or remote systems;

providing written documentation for users, perhaps in conjunction with a technical

author;

working with other IT specialists both internally and externally;

Undertaking short and longer-term project work.

WHAT'S THE QUALITY ASSURANCE ROLE?

The quality assurance (QA) role is one that is focused on creating a quality deliverable. In
other words, it is the responsibility of the QA role to make sure that the software
development process doesn't sacrifice quality in the name of completed objectives.

The QA role works with the Functional Analyst (FA) and the Solutions Architect (SA) to
convert the requirements and design documents into a set of testing cases and scripts,
which can be used to verify that the system meets the client needs. This collection of test
cases and scripts are collectively referred to as a test plan. The test plan document itself is
often simple providing an overview of each of the test cases. The testing cases and scripts
are also used to validate that there are no unexplained errors in the system.

The test plan is approved by the Subject Matter Experts (SMEs) and represents the
criteria to reach a project closing. If the test cases and scripts in the test plan are the
agreed upon acceptance criteria for a project then all that is necessary is for project
closure is to demonstrate that all of the testing cases and scripts have been executed
successfully with passing results.

A test case is a general-purpose statement that maps to one or more requirements and
design points. It is the overall item being tested. It may be a specific usability feature, or a
technical feature that was supposed to be implemented as a part of the project.

Test scripts fit into the test cases by validating that case. Test scripts are step-by-step
instructions on what to do, what to look for, and what should happen. While the test cases
can be created with nearly no input from the architecture or design, the test scripts are
specific to how the problem was solved by the software development team and therefore

UNIT I
22

INFORMATION SYSTEM AND ORGANIZATION

they require an understanding of not only the requirements, but also the architecture,
design, and detailed design.
FUNCTION DEPLOYMENT
Quality function deployment (QFD) is a method to transform user demands into design
quality, to deploy the functions forming quality, and to deploy methods for achieving the
design quality into subsystems and component parts, and ultimately to specific elements of
the manufacturing process.as described by Dr. Yoji Akao, who originally developed QFD in
Japan in 1966, when the author combined his work in quality assurance and quality control
points with function deployment used in value engineering.
QFD is designed to help planners focus on characteristics of a new or existing product or
service from the viewpoints of market segments, company, or technology-development
needs. The technique yields graphs and matrices.
QFD helps transform customer needs (the voice of the customer [VOC]) into engineering
characteristics (and appropriate test methods) for a product or service, prioritizing each
product or service characteristic while simultaneously setting development targets for product
or service.
EXAMPLE: Areas of application
QFD House of Quality for Enterprise Product Development Processes
QFD is applied in a wide variety of services, consumer products, military needs F-35 Joint
Strike Fighter[2], and emerging technology products. The technique is also used to identify
and document competitive marketing strategies and tactics (see example QFD House of
Quality for Enterprise Product Development, at right). QFD is considered a key practice of
Design for Six Sigma (DFSS - as seen in the referenced roadmap).[3] It is also implicated in
the new ISO 9000:2000 standard which focuses on customer satisfaction.
Results of QFD have been applied in Japan and elsewhere into deploying the high-impact
controllable factors in Strategic planning and Strategic management (also known as Hoshin
Kanri, Hoshin Planning,[4] Acquiring market needs by listening to the Voice of Customer
(VOC), sorting the needs, and numerically prioritizing them (using techniques such as the
Analytic Hierarchy Process) are the early tasks in QFD. Traditionally, going to the Gemba
(the "real place" where value is created for the customer) is where these customer needs are
evidenced and compiled.
UNIT I
23

INFORMATION SYSTEM AND ORGANIZATION

While many books and articles on "how to do QFD" are available, there is a relative paucity
of example matrices available. QFD matrices become highly proprietary due to the high
density of product or service information found therein.
ROLE OF TRAINER

Project managers
A project manager is a professional in the field of project management. Project managers can
have the responsibility of the planning, execution, and closing of any project, typically
relating

to

construction

industry,

engineering,

architecture,

computing,

and

telecommunications. Many other fields in the production engineering and design engineering
and heavy industrial have project managers.
UNIT I
24

INFORMATION SYSTEM AND ORGANIZATION

A project manager is the person accountable for accomplishing the stated project objectives.
Key project management responsibilities include creating clear and attainable project
objectives, building the project requirements, and managing the triple constraint for projects,
which is cost, time, and scope.
A project manager is often a client representative and has to determine and implement the
exact needs of the client, based on knowledge of the firm they are representing. The ability to
adapt to the various internal procedures of the contracting party, and to form close links with
the nominated representatives, is essential in ensuring that the key issues of cost, time, quality
and above all, client satisfaction, can be realized.

Project management triangle

The project management triangle

Like any human undertaking, projects need to be performed and delivered under certain
constraints. Traditionally, these constraints have been listed as "scope," "time," and "cost".[1]
These are also referred to as the "project management triangle", where each side represents a
constraint. One side of the triangle cannot be changed without affecting the others. A further
refinement of the constraints separates product "quality" or "performance" from scope, and
turns quality into a fourth constraint.
The time constraint refers to the amount of time available to complete a project. The cost
constraint refers to the budgeted amount available for the project. The scope constraint refers
to what must be done to produce the project's end result. These three constraints are often
competing constraints: increased scope typically means increased time and increased cost, a
tight time constraint could mean increased costs and reduced scope, and a tight budget could
mean increased time and reduced scope.

UNIT I
25

INFORMATION SYSTEM AND ORGANIZATION

The discipline of project management is about providing the tools and techniques that enable
the project team (not just the project manager) to organize their work to meet these
constraints.

Project management framework

The Program (Investment) life cycle integrates the project management and system
development life cycles with the activities directly associated with system deployment and
operation. By design, system operation management and related activities occur after the
project is complete.

International standards
There have been several attempts to develop project management standards, such as:

Capability Maturity Model from the Software Engineering Institute.

GAPPS, Global Alliance for Project Performance Standards an open source standard
describing COMPETENCIES for project and program managers.

A Guide to the Project Management Body of Knowledge

HERMES method, Swiss general project management method, selected for use in
Luxembourg and international organizations.

The ISO standards ISO 9000, a family of standards for quality management systems, and
the ISO 10006:2003, for Quality management systems and guidelines for quality
management in projects.

PRINCE2, PRojects IN Controlled Environments.

Association for Project Management Body of Knowledge[29]

Team Software Process (TSP) from the Software Engineering Institute.

Total Cost Management Framework, AACE International's Methodology for Integrated

Portfolio, Program and Project Management.

V-Model, an original systems development method.

The Logical framework approach, which is popular in international development

organizations.

IAPPM, The International Association of Project & Program Management, guide to

project auditing and rescuing troubled projects.

Project portfolio management

UNIT I
26

INFORMATION SYSTEM AND ORGANIZATION

An increasing number of organizations are using, what is referred to as, project portfolio
management (PPM) as a means of selecting the right projects and then using project
management techniques as the means for delivering the outcomes in the form of benefits to
the performing private or not-for-profit organization.

UNIT I
27

INFORMATION SYSTEM AND ORGANIZATION