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:
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
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.
must
achieve
certain
objectives
in
order
for
Leadership
UNIT I
3
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.
UNIT I
4
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
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
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:
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:
DESIGN:
The areas that need to be considered in the design process are listed below:
UNIT I
7
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
Mrs Fogett
Mr Smith
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:
UNIT I
8
UNIT I
9
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.
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
member
list
appeared
Remove a
Member not on
Member deleted
member
membership list
from list
tested
Members File
Members File
UNIT I
10
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
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
UNIT I
13
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
UNIT I
15
Probing the client regarding the system requirements through various means
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:
Tremendous and exact knowledge of the job profile and its supporting processes such
as UML, algorithms, etc.
Extra ordinary tendency of approaching the solution through the most efficient
pathway
Professional Experience:
ABC Co Ltd., Los Angeles, CA (2007-Present)
Senior analyst
Following standard analysis procedures to understand the primary format and scope
of the system requirements
UNIT I
16
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
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:
Develop and execute a solution strategy and business plan that support product growth
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
UNIT I
18
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
With Channel Development team, develop and maintain vendor relationships within the
product
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
Write, or direct the writing of white papers that further insight and thought in the solution
area
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
UNIT I
19
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
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
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.
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.
UNIT I
21
writing and testing code and then refining and rewriting as necessary;
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
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
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
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.
UNIT I
25
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.
International standards
There have been several attempts to develop project management standards, such as:
GAPPS, Global Alliance for Project Performance Standards an open source standard
describing COMPETENCIES for project and program managers.
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.
UNIT I
26
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