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 1The 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 6 20 15 25 25 10 10 1 8 Example 352600 McSweeney Jane 3 Longlane London N1 1TH 0181-3661234 Y 22/04/97

Membership Numeric No. Surname First Name Text Text

Address line Text 1 Address line Text 2 Post Code Telephone No. Fees Paid Fee Date Alpha numeric Alpha numeric Text Date

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 Members File Members File Purpose Add new member Remove a member Expected result New member on members list Member not on membership list Actual result New member appeared 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.