Anda di halaman 1dari 22

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 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
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.
Grooming individuals that show high potential

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 1
The organizational process.
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 (decisionmaking) 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:

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.

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:
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
Smith, Tony
Jackson, Jake
Timms, Tony
Fogett, Carol

Address
12 Fields Rd
9 Man Gdns
87 Colly Row
9 Shaw St

Telephone No.
0543 3445545
0563 9545752
0543 8653653
0563 9657564

Membership No.
001342
001234
001789
001455

b) Address labels for parents of the children.


Mrs Jackson
9 Man Gdns
Todthope
TD3 5TT

Mr Timms
87 Colly Row
Todthope
TD3 8DE

Mrs Fogett
9 Shaw Street
Todthope
TD3 3HG

Mr Smith
12 Fields Road
Todthope
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:
Field

Type

Length

Example

Membership
Numeric
No.

352600

Surname

Text

20

McSweeney

First Name

Text

15

Jane

Address line
1

Text

25

3 Longlane

Address line
2

Text

25

London

Post Code

Alpha
numeric

10

N1 1TH

Telephone
No.

Alpha
numeric

10

0181-3661234

Fees Paid

Text

Fee Date

Date

22/04/97

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
tested

Purpose

Expected result

Members File

Add new
member

New member on members New member


list
appeared

Members File

Remove a
member

Member not on
membership list

Actual result

Member deleted from


list

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:
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

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.
DESIGNS FOR MAINTAINABILITY DESIGN REQUIREMENTS
Equipment Design Requirements
All flight hardware and software shall be designed to facilitate on-orbit maintenance, check-out
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.
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
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 cross-domain, crossfunctional 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.
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

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

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.
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;
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
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.

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.
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.
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


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.

Anda mungkin juga menyukai