1 Unit An Introduction To Project Management
1 Unit An Introduction To Project Management
1 Unit An Introduction To Project Management
Project management in the modern sense began in the early 1960s, although it has its roots much further back in the latter years of the 19th century. The need for project management was driven by businesses that realised the benefits of organising work around projects and the critical need to communicate and co-ordinate work across departments and professions. One of the first major uses of project management as we know it today was to manage the United States space programme. The government, military and corporate world have now adopted this practice. Here is the main definition of what project management is: 1. Project management is no small task. 2. Project management has a definite beginning and end. It is not a continuous process. 3. Project management uses various tools to measure accomplishments and track project tasks. These include Work Breakdown Structures, Gantt charts and PERT charts. 4. Projects frequently need resources on an ad-hoc basis as opposed to organisations that have only dedicated full-time positions. 5. Project management reduces risk and increases the chance of success. Project management is often summarised in a triangle. The three most important factors are time, cost and scope, commonly called the triple constraint. These form the vertices with quality as a central theme.
1. 2. 3. 4.
Projects must be delivered on time. Projects must be within cost. Projects must be within scope. Projects must meet customer quality requirements
More recently, this has given way to a project management diamond, with time, cost, scope and quality the four vertices and customer expectations as a central theme. No two customers' expectations are the same so you must ask what their expectations are. A project goes through six phases during its life: 1. Project Definition: Defining the goals, objectives and critical success factors for the project. 2. Project Initiation: Everything that is needed to set-up the project before work can start. 3. Project Planning: Detailed plans of how the work will be carried out including time, cost and resource estimates. 4. Project Execution: Doing the work to deliver the product, service or desired outcome. 5. Project Monitoring & Control: Ensuring that a project stays on track and taking corrective action to ensure it does. 6. Project Closure: Formal acceptance of the deliverables and disbanding of all the elements that were required to run the project.
The role of the project manager is one of great responsibility. It is the project manager's job to direct, supervise and control the project from beginning to end. Project managers should not carryout project work, managing the project is enough? Here are some of the activities that must be undertaken: 1. The project manager must define the project, reduce it to a set of manageable tasks, obtain appropriate resources and build a team to perform the work. 2. The project manager must set the final goal for the project and motivate his/her team to complete the project on time. 3. The project manager must inform all stakeholders of progress on a regular basis. 4. The project manager must assess and monitor risks to the project and mitigate them. 5. No project ever goes exactly as planned, so project managers must learn to adapt to and manage change. A project manager must have a range of skills including:
Leadership People management (customers, suppliers, functional managers and project team) Effective Communication (verbal and written) Influencing Estimating Negotiation Problem solving Conflict Management Creative thinking Planning Time Management Contract management
"Project managers bear ultimate responsibility for making things happen. Traditionally, they have carried out this role as mere implementers. To do their jobs they needed to have basic administrative and technical competencies. Today they play a far broader role. In addition to the traditional skills, they need to have business skills, customer relations skills, and political skills. Psychologically, they must be results-oriented self-starters with a high tolerance for ambiguity, because little is clear-cut in today's tumultuous business environment. Shortcomings in any of these areas can lead to project failure." - J. Davidson Frame Many things can go wrong in project management. These things are often called barriers. Here are some possible barriers:
1. 2. 3. 4.
5. Union strikes 6. Personality conflicts 7. Poor management 8. Poorly defined goals and objectives.
A good project management discipline will not eliminate all risks, issues and surprises, but will provide standard processes and procedures to deal with them and help prevent the following: 1. Projects finishing late, exceeding budget or not meeting customer expectations. 2. Inconsistency between the processes and procedures used by projects managers, leading to some being favoured more than others. 3. Successful projects, despite a lack of planning, achieved through high stress levels, goodwill and significant amounts of overtime.
4. Project management seen as not adding value and as a waste of time and money. 5. Unforeseen internal and/or external events impacting the project. Project management is about creating an environment and conditions in which a defined goal or objective can be achieved in a controlled manner by a team of people.
Defining the Project In this stage the project manager defines what the project is and what the users hope to achieve by undertaking the project. This phase also includes a list of project deliverables, the outcome of a specific set of activities. The project manager works with the business sponsor or manager who wants to have the project implemented and other stakeholders -- those who have a vested interest in the outcome of the project. Planning the Project Define all project activities. In this stage, the project manager lists all activities or tasks, how the tasks are related, how long each task will take, and how each tasks is tied to a specific deadline. This phase also allows the project manager to define relationships between tasks, so that, for example, if one task is x number of days late, the project tasks related to it will also reflect a comparable delay. Likewise, the project manager can set milestones, dates by which important aspects of the project need to be met. Define requirements for completing the project. In this stage, the project manager identifies how many people (often referred to as "resources") and how much expense ("cost") is involved in the project, as well as any other requirements that are necessary for completing the project. The project manager will also need to manage assumptions and risks related to the project. The project manager will also want to identify project constraints. Constraints typically relate to schedule, resources, budget, and scope. A change in one constraint will typically affect the other constraints. For example, a budget constraint may affect the number of people who can work on the project, thereby imposing a resource constraint. Likewise, if
additional features are added as part of project scope, that could affect scheduling, resources, and budget. Executing the Project Build the project team. In this phase, the project manager knows how many resources and how much budget he or she has to work with for the project. The project manager then assigns those resources and allocates budget to various tasks in the project. Now the work of the project begins. Controlling the Project The project manager is in charge of updating the project plans to reflect actual time elapsed for each task. By keeping up with the details of progress, the project manager is able to understand how well the project is progressing overall. A product such as Microsoft Project facilitates the administrative aspects of project management. Closure of the Project In this stage, the project manager and business owner pull together the project team and those who have an interest in the outcome of the project (stakeholders) to analyze the final outcome of the project. Time, Money, Scope Frequently, people refer to project management as having three components: time, money, and scope. Reducing or increasing any one of the three will probably have an impact on the other two. If a company reduces the amount of time it can spend on a project, that will affect the scope (what can be included in the project) as well as the cost (since additional people or resources may be required to meet the abbreviated schedule). Project Portfolio Management Recent trends in project management include project portfolio management (PPM). PPM is a move by organizations to get control over numerous projects by evaluating how well each project aligns with strategic goals and quantifying its value. An organization will typically be working on multiple projects, each resulting in potentially differing amounts of return or value. The company or agency may decide to eliminate those projects with a lower return in order to dedicate greater resources to the remaining projects or in order to preserve the projects with the highest return or value.
you will learn how to initiate projects by developing a business case, undertaking a feasibility study, establishing the terms of reference, appointing the team and setting up a project office. "Every step required to build a comprehensive suite of project plans is provided in Chapter 3. This includes the activities required to create a project plan, resource plan, financial plan, quality plan, risk plan, acceptance plan, communications plan and procurement plan. The entire tender process is also defined, allowing you to create a suite of tender documentation to help you select a preferred supplier and create a supplier contract. The four phases of the project life cycle3 "The most complex phase in the project life cycle (project execution) is made simple in Chapter 4 with a step by step guide to the nine critical management processes: time management, cost management, quality management, change management, risk management, issue management, procurement management, acceptance management and communications management. "Finally in Chapter 5, you will be shown how to formally close a project by creating a project closure report and undertaking a post implementation review. So sit back, relax and discover the vital steps needed to manage a project through the four critical phases of the project life cycle: initiation, planning, execution and closure." Project Initiation "The first phase of a project is the initiation phase. During this phase a business problem or opportunity is identified and a business case providing various solution options is defined. Next, a feasibility study is conducted to investigate whether each option addresses the business problem and a final recommended solution is then put forward. Once the recommended solution is approved, a project is initiated to deliver the approved solution. Terms of reference are completed outlining the objectives, scope and structure of the new project and a project manager is appointed. The project manager begins recruiting a project team and establishes a project office environment. Approval is then sought to move into the detailed planning phase." 5 "Within the initiation phase, the business problem or opportunity is identified, a solution is defined, a project is formed and a project team is appointed to build and deliver the solution to the customer. Figure 1.3 shows the activities undertaken during the initiation phase:
Figure 2: Project initiation activities "Develop a business case: The trigger to initiating a project is identifying a business problem or opportunity to be addressed. A business case is created to define the problem or
opportunity in detail and identify a preferred solution for implementation. The business case includes: A detailed description of the problem or opportunity; A list of the alternative solutions available; An analysis of the business benefits, costs, risks and issues; A description of the preferred solution; A summarized plan for implementation. "An identified project sponsor then approves the business case and the required funding is allocated to proceed with a feasibility study. "Undertake a feasibility study: At any stage during or after the creation of a business case, a formal feasibility study may be commissioned. The purpose of a feasibility study is to assess the likelihood of each alternative solution option achieving the benefits outlined in the business case. The feasibility study will also investigate whether the forecast costs are reasonable, the solution is achievable, the risks are acceptable and the identified issues are avoidable. "Establish the terms of reference: After the business case and feasibility study have been approved, a new project is formed. At this point, terms of reference are created. The terms of reference define the vision, objectives, scope and deliverables for the new project. They also describe the organization structure; and activities, resources and funding required undertaking the project. Any risks, issues, planning assumptions and constraints are also identified. "Appoint the project team: The project team are now ready to be appointed. Although a project manager may be appointed at any stage during the life of the project, the manager will ideally be appointed prior to recruiting the project team. The project manager creates a detailed job description for each role in the project team, and recruits people into each role based on their relevant skills and experience "Set up a project office: The project office is the physical environment within which the team is based. Although it is usual to have one central project office, it is possible to have a virtual project office with project team members located around the world. A project office environment should include: Equipment, such as office furniture, computer equipment, stationery and materials; Communications infrastructure, such as telephones, computer network, e mail, Internet access, files storage, database storage and backup facilities; Documentation, such as a project methodology, standards, processes, forms and registers; Tools, such as accounting, project planning and risk modelling software. "Perform a phase review: At the end of the initiation phase, perform a phase review. This is basically a checkpoint to ensure that the project has achieved its objectives as planned." Project Planning "Once the scope of the project has been defined in the terms of reference, the project enters the planning phase. This involves creating a: Project plan outlining the activities, tasks, dependencies and timeframes; Resource plan listing the labour, equipment and materials required; Financial plan identifying the labour, equipment and materials costs; Quality plan providing quality targets, assurance and control measures; Risk plan highlighting potential risks and actions to be taken to mitigate those risks; Acceptance plan listing the criteria to be met to gain customer acceptance; Communications plan describing the information needed to inform stakeholders; Procurement plan identifying products to be sourced from external suppliers.
"At this point the project will have been planned in some detail and is ready to he executed."
7
"By now, the project costs and benefits have been documented, the objectives and scope have been defined, the project team has been appointed and a formal project office environment established. It is now time to undertake detailed planning to ensure that the activities performed during the execution phase of the project are properly sequenced, resourced, executed and controlled. The activities shown in Figure 3 are undertaken.
Figure 3: Project planning activities "Create a project plan: The first step in the project planning phase is to document the project plan. A 'work breakdown structure' (WBS) is identified which includes a hierarchical set of phases, activities and tasks to be undertaken to complete the project. After the WBS has been agreed, an assessment of the level of effort required to undertake each activity and task is made. The activities and tasks are then sequenced, resources are allocated and a detailed project schedule is formed. This project plan is the key tool used by the project manager to assess the progress of the project throughout the project life cycle. "Create a resource plan: Immediately after the project plan is formed, the level of resource required undertaking each of the activities and tasks listed within the project plan will need to be allocated. Although generic resource may have already been allocated in the project plan, a detailed resource plan is required to identify the: Type of resource required, such as labour, equipment and materials; Quantity of each type of resource required; Roles, responsibilities and skill sets of all human resource required; Specifications of all equipment resource required; Items and quantities of material resource required. "A schedule is assembled for each type of resource so that the project manager can review the resource allocation at each stage in the project. "Create a financial plan: A financial plan is created to identify the total quantity of money required to undertake each phase in the project (in other words, the budget). The total cost of labour, equipment and materials is calculated and an expense schedule is defined which enables the project manager to measure the forecast spend versus the actual spend throughout the project. Detailed financial planning is an extremely important activity within the project, as the customer will expect the final solution to have been delivered within the allocated budget. "Create a quality plan: Meeting the quality expectations of the customer can be a challenging task. To ensure that the quality expectations are clearly defined and can reasonably be achieved, a quality plan is documented. The quality plan: Defines the term 'quality' for the project. Lists clear and unambiguous quality targets for each deliverable. Each quality target provides a set of criteria and standards to be achieved to meet the expectations of the customer. Provides a plan of activities to assure the customer that the quality targets will be met (in other words, a quality assurance plan).
Identifies the techniques used to control the actual quality level of each deliverable as it is built (in other words, a quality control plan). "Not only is it important to review the quality of the deliverables produced by the project, it is also important to review the quality of the management processes that produced them. A quality plan will summarize each of the management processes undertaken during the project, including time, cost, quality, change, risk, issue, procurement, and acceptance and communications management. "Create a risk plan: The next step is to document all foreseeable project risks within a risk plan. This plan also identifies the actions required to prevent each risk from occurring, as well as reduce the impact of the risk should it eventuate. Developing a clear risk plan is an important activity within the planning phase, as it is necessary to mitigate all critical project risks prior to entering the execution phase of the project. "Create an acceptance plan: To deliver the project successfully, you will need to gain full acceptance from the customer that the deliverables produced by the project meet or exceed requirements. An acceptance plan is created to help achieve this, by clarifying the completion criteria for each deliverable and providing a schedule of acceptance reviews. These reviews provide the customer with the opportunity to assess each deliverable and provide formal acceptance that it meets the requirements as originally stated. "Create a communications plan: Prior to the execution phase, it is also necessary to identify how each of the stakeholders will be kept informed of the progress of the project. The communications plan identifies the types of information to be distributed to stakeholders, the methods of distributing the information, the frequency of distribution, and responsibilities of each person in the project team for distributing the information. "Create a procurement plan: The last planning activity within the planning phase is to identify the elements of the project to be acquired from external suppliers. The procurement plan provides a detailed description of the products (that is, goods and services) to be acquired from suppliers, the justification for acquiring each product externally as opposed to from within the business, and the schedule for product delivery. It also describes the process for the selection of a preferred supplier (the tender process), and the ordering and delivery of the products (the procurement process). "Contract the suppliers: Although external suppliers may be appointed at any stage of the project, it is usual to appoint suppliers after the project plans have been documented but prior to the execution phase of the project. Only at this point will the project manager have a clear idea of the role of suppliers and the expectations for their delivery. A formal tender process is undertaken to identify a short list of capable suppliers and select a preferred supplier to initiate contractual discussions with. The tender process involves creating a statement of work, a request for information and request for proposal document to obtain sufficient information from each potential supplier and select the preferred supplier. Once a preferred supplier has been chosen, a contract is agreed between the project team and the supplier for the delivery of the requisite products. "Perform a phase review: At the end of the planning phase, a phase review is performed. This is a checkpoint to ensure that the project has achieved its objectives as planned." Project Execution In much of the literature, and in training programs, project management is all about project planning while project execution gets short shrift. This is not the case in Jason's book. As Jason explains: "This phase involves implementing the plans created during the project planning phase. While each plan is being executed, a series of management processes are undertaken to monitor and control the deliverables being output by the project. This includes identifying
change, risks and issues, reviewing deliverable quality and measuring each deliverable produced against the acceptance criteria. Once all of the deliverables have been produced and the customer has accepted the final solution, the project is ready for closure. The activities of this phase are shown in Figure. Project management execution activities "The execution phase is typically the longest phase of the project in terms of duration. It is the phase within which the deliverables are physically constructed and presented to the customer for acceptance. To ensure that the customer's requirements are met, the project manager monitors and controls the activities, resources and expenditure required to build each deliverable. A number of management processes as shown are undertaken to ensure that the project proceeds as planned. "Build the deliverables: This phase involves physically constructing each deliverable for acceptance by the customer. The activities undertaken to construct each deliverable will vary depending on the type of project being undertaken. Activities may be undertaken In a 'waterfall' fashion, where each activity is completed in sequence until the final deliverable is produced, or in an 'iterative' fashion, where iterations of each deliverable are constructed until the deliverable meets the requirements of the customer. Regardless of the method used to construct each deliverable, careful monitoring and control processes should be employed to ensure that the quality of the final deliverable meets the acceptance criteria set by the customer. "Monitor and control: While the project team are physically producing each deliverable, the project manager implements a series of management processes to monitor and control the activities being undertaken by the project team. An overview of each management process follows. "Time Management: Time management is the process of recording and controlling time spent by staff on the project. As time is a scarce resource within projects, each team member should record time spent undertaking project activities on a timesheet form. This will enable the project manager to control the amount of time spent undertaking each activity within the project. A timesheet register is also completed, providing a summary of the time spent on the project in total so that the project plan can always be kept fully up to date. "Cost management: Cost management is the process by which costs/expenses incurred on the project are formally identified, approved and paid. Expense forms are completed for each set of related project expenses such as labour, equipment and materials costs. Expense forms are approved by the project manager and recorded within an expense register for auditing purposes.
"Quality management: Quality is defined as the extent to which the final deliverable conforms to the customer requirements. Quality management is the process by which quality is assured and controlled for the project, using quality assurance and quality control techniques. Quality reviews are undertaken frequently and the results recorded on a quality review form. "Change management: Change management is the process by which changes to the project scope, deliverables, timescales or resources are formally requested, evaluated and approved prior to implementation. A core aspect of the project manager's role is to manage change within the project. This is achieved by understanding the business and system drivers requiring the change, identifying the costs and benefits of adopting the change, and formulating a structured plan for implementing the change. To formally request a change to the project, a change form is completed. The status of all active change forms should he recorded within a change register. "Risk management: Risk management is the process by which risks to the project are formally identified, quantified and managed. A project risk may be identified at any stage of the project by completing a risk form and recording the relevant risk details within the risk register. "Issue management: Issue management is the method by which issues currently affecting the ability of the project to produce the required deliverable are formally managed. After an issue form has been completed and the details logged in the issue register, each issue is evaluated by the project manager and A set of actions undertaken to resolve the issue identified. "Procurement management: Procurement management is the process of sourcing products from an external supplier. Purchase orders are used to purchase products from suppliers, and a procurement register is maintained to track each purchase request through to its completion. "Acceptance management: Acceptance management is the process of gaining customer acceptance for deliverables produced by the project. Acceptance forms are used to enable project staff to request acceptance for a deliverable, once complete. Each acceptance form identifies the acceptance criteria, review methods and results of the acceptance reviews undertaken. "Communications management: Communications management is the process by which formal communications messages are identified, created, reviewed and communicated within a project. The most common method of communicating the status of the project is via a project status report. Each communications message released is captured in a communications register. "Perform a phase review: At the end of the execution phase, a phase review is performed. This is a checkpoint to ensure that the project has achieved its objectives as planned." Project Closure "Project closure involves releasing the final deliverables to the customer, handing over project documentation to the business, terminating supplier contracts, releasing project resources and communicating the closure of the project to all stakeholders. The last remaining step is to undertake a post implementation review to quantify the level of project success and identify any lessons learnt for future projects."11 "Following the acceptance of all project deliverables by the customer, the project will have met its objectives and be ready for closure. Project closure is the last phase in the project life cycle, and must be conducted formally so that the business benefits delivered by the project
are fully realized by the customer. The activities outlined in Figure 5 are undertaken.
Figure 5: Project closure activities "Perform project closure: Project closure, or 'close out', essentially involves winding up the project. This includes: Determining whether all of the project completion criteria have been met; Identifying any outstanding project activities, risks or issues; Handing over all project deliverables and documentation to the customer; Cancelling supplier contracts and releasing project resources to the business; Communicating the closure of the project to all stakeholders and interested parties. "A project closure report is documented and submitted to the customer and/or project sponsor for approval. The project manager is responsible for undertaking each of the activities identified in the project closure report, and the project is closed only when all the activities listed in the project closure report have been completed. "Review project completion: The final activity within a project is the review of its success by an independent party. Success is determined by how well it performed against the defined objectives and conformed to the management processes outlined in the planning phase. To determine how well it performed, the following types of questions are answered: Did it result in the benefits defined in the business case? Did it achieve the objectives outlined in the terms of reference? Did it operate within the scope of the terms of reference? 0 Did the deliverables meet the criteria defined in the quality plan? Was it delivered within the schedule outlined in the project plan? Was it delivered within the budget outlined in the financial plan? "To determine how well the project conformed, an assessment is made of the level of conformity to the management processes outlined in the quality plan. These results, as well as a list of the key achievements and lessons learnt, are documented within a postimplementation review and presented to the customer and/or project sponsor for approval."
ORGANIZATION STRATEGY
Organizational strategy is concerned with envisioning a future for your family business, creating value in the eyes of your customers, and building and sustaining a strong position in the marketplace. "As a result of the current market conditions, continued success for many family businesses will be determined by how they can adapt to change - and to be able to do it quickly," according to family business expert Don Schwerzler. Schwerzler has been studying and advising family business entrepreneurs for more than 40 years and he is the founder of the Family Business Institute headquartered in Atlanta GA.
As we work with our family business clients, assessing their organizational strategy is an important part of our succession management strategy - we consider organizational strategy in terms of four key components, each with critical elements.
Focused Purpose o Clearly defining short-term purpose o Ensuring mission is realistic o Serving the best interests of all stakeholders o Defining a point of differentiation Future Perspective o Clearly defining long-term outlook o Appealing to the long-term interests of the company's stakeholders o Providing a foundation for decision-making Strategic Advantage o Competitive advantage is a key driver to forming an organizational strategy o Competitive advantage is clearly understood by all stakeholders o Employees clearly understand how their role supports the company's organizational strategy
Customer Profile o Clearly defining reasons why customers buy products or services o Clearly defining benefits that customers seek o Clearly defining reasons why customers would not buy products or services o Assessing customer bargaining power o Knowing customer preferred choice of distribution channel Industry and Competitive Analysis Is Essential Component of Organizational Strategy o Identifying primary competitors o Identifying potential and indirect competitors o Clearly defining strengths, weaknesses and strategies of competitors o Assessing the threat of substitute products or services or new entrants into the marketplace o Understanding what it takes to be successful in a given market o Comparing customer growth rate with industry standards o Ongoing market evaluation process Environmental Assessment o Defining and clarifying regulatory requirements
Assessing vulnerability to adverse business cycles Summarizing opportunities and threats due to: Economic conditions New technology Demographic structure Legal or political events The natural environment Socio-cultural norms Key Success Factors Are Identified With a Critical Thinking Process o Implementing a critical thinking process o Clearly measuring competitive intensity o Clearly defining product or service demand within your market o Clearly defining drivers to success within your industry o Consistently monitoring key influences within your industry
o o
Finance o Adequate funding of key initiatives o Utilizing a comprehensive pricing model o Consistently performing within a range of financial goals o Having a targeted long-range financial plan o Employing a "Cost / Benefit" approach to resource allocation o Financial plan allowing for economic or environmental disruption o Financial plan allows for flexibility o Employing the "If / Then" model when forming organizational strategy Research and Development o Fully integrating all appropriate departments with R&D o Maintaining a creative and innovative process o Ensuring R&D has all required resources to successfully fulfil its function Production o Fully integrating all departments to support production o Strategic partners consistently fulfil production commitments o Production process is cost-effective o Production process is flexible, fast and responsive Marketing o Coordinating all departments to support marketing o Having a clearly defined marketing plan o Branding plays a critical role o Utilizing a marketing system or database to track customer and market information o Employing an effective product / service management process o "Competitive advantage" is a key driver for all marketing decisions
Employees take pride in the ability to promote products and services Monitoring the ROI of all marketing campaigns Sales / Distribution o Consistently achieving sales goals o Ensuring that sales teams / channels possess required skills to achieve plan o Ensuring that sales teams / channels are provided with the necessary information to achieve their goals o Employing a well-defined sales management process o Coordinating all departments to support our sales process o Tracking sales activity from lead generation through close Does Your Organizational Strategy Emphasize Customer Service? o Clearly defining customer service standards o Meeting or exceeding customer expectations o Measuring customer satisfaction o Managers and employees share a high commitment to achieving customer loyalty o Maintaining a customer relationship management system that provides critical service information to make the best decision o Maintaining a high rate of repeat business, customer loyalty and referrals
o o
Organization Strategy Needs Vital Direction o Identifying key strategic objectives o Prioritizing action items by their importance to strategic intent o Ensuring objectives are quantifiable and measurable o Those responsible for implementation participate in the strategic planning process o Plans must specify how each area will contribute to achieving strategic plan Resource Alignment o Allocating sufficient resources to achieve strategic intent o Clearly defining resources necessary for each objective o Evaluating individual or group capacity prior to assigning workload Organization Accountabilities o Ensuring that employees understand how their roles and responsibilities relate to strategic objectives o Holding individuals accountable for their work o Employee goals reflect accountabilities and timeliness o Employing an internal system to routinely review the status of key objectives o Measuring key financial indicators o Utilizing a uniform format to measure and report performance.
ORGANIZATIONAL STRUCTURE
Organizational structure depends on the product to be developed. Wheelwright and Clark define a continuum of organizational structures between two extremes, functional organizations and project organizations. Functional organizations are organized according to technological disciplines. Senior functional managers are responsible for allocating resources. The responsibility for the total product is not allocated to a single person. Coordination occurs through rules and procedures, detailed specifications, shared traditions among engineers and meetings (ad hoc and structured). Products that need a high level of specialized knowledge require a functionally organized structure. A light-weighted matrix organization remains functional and the level of specialization is comparable to that found in the functional mode. What is different is the addition of a product manager who coordinates the product creation activities through liaison representatives from each function. Their main tasks are: to collect information, to solve conflicts and to facilitate achievement of overall project objectives. Their status and influence are less as compared to functional managers, because they have no direct access to working-level people. A heavy-weighted matrix organization exists of a matrix with dominant the project structure and underlying the functional departments. The product manager has a broader responsibility. Manufacturing, marketing and concept development are included. The status and influence of the product manager, who is usually a senior, is the same or higher as compared to the functional manager. Compared to functional managers, because they have no direct access to working-level people. A project organization exists of product oriented flows: project and teams. The project members leave their functional department and devote all their time to the project. They share the same location. The professionals are less specialized and have broader tasks, skills and responsibilities. The functional manager is responsible for the personnel development and the more detailed technology research in the functional groups. Companies can be classified to their organizational structures. Another variable company can be classified to be the nature of the projects undertaken. We characterize projects by the number of employees needed to perform the tasks, or workload, and the number of tasks that are fundamentally different in nature. An example of the latter aspect is PCB development and structural design. Another way to classify organization structure is by one of the following four categories: I. The product to be developed is comprehensible for one person. One person is likely to have all the knowledge needed to develop Manufacturing and Assembly. The development department in companies that undertake these kinds of projects are usually very small. If a company consists of more than one department, it is usually structured as a functional organization. II. The product to be developed has a fairly low complexity, but total work is high. These kinds of products are likely to be developed within one functional department. A research department may also be an example of a department in which type II projects are undertaken. Are more departments involved, and then the light weighted matrix structure is preferable.
Employees are involved on a full-time basis. Tasks may be performed concurrently. The sequence can be determined using the Design Structure Matrix. III. The product to be developed consists of a lot of different elements, such as software, PCB, power supply and mechanical structure. The product is however in the engineering phase, i.e. it is clear what needs to be done to get the product into production. Various disciplines perform their own tasks. These tasks have mostly a low workload. Employees cannot work full-time on one project. This creates a complex situation that may be compared to a job shop situation in production logistics. Though the comparison between manufacturing and product development is not accepted by all product development managers, it may yield good results. Studying each step in the Product Development Process and fluctuations in workloads reveals ways to reduce variation and eliminate bottlenecks. It is necessary to view the Product Development Process as a process and not as a list of projects. Three important findings regarding this are:
1. Projects get done faster if the organization takes on fewer at a time. 2. Investments to relieve bottlenecks yield disproportionately large time-to-market benefits. 3. Eliminating unnecessary variation in workloads and work processes eliminates distractions and delays, thereby freeing up the organization to focus on the creative parts of the task.
Creating cross-functional concurrent engineering teams is the right way to develop products. However, the pitfall is too many projects at the same time, so that key people from engineering, marketing and manufacturing work at five or more projects at once. This results in congestion. Striving to work at 100% of the product development capacity lengthens product development lead times enormously. A more realistic percentage is 80%. Attention must be focused on bottlenecks, these days most commonly found at the software development side of the project. IV. The product is complex. Total work is high. Employees can thus participate on a full-time basis. A project organization is the most appropriate organizational structure for these kinds of products.
Corporate culture can be looked at as a system. Inputs include feedback from, e.g., society, professions, laws, stories, heroes, values on competition or service, etc. The process is based on our assumptions, values and norms, e.g., our values on money, time, facilities, space and people. Outputs or effects of our culture are, e.g., organizational behaviours, technologies, strategies, image, products, services, appearance, etc.
The concept of culture is particularly important when attempting to manage organizationwide change. Practitioners are coming to realize that, despite the best-laid plans, organizational change must include not only changing structures and processes, but also changing the corporate culture as well. There's been a great deal of literature generated over the past decade about the concept of organizational culture -- particularly in regard to learning how to change organizational culture. Organizational change efforts are rumoured to fail the vast majority of the time. Usually, this failure is credited to lack of understanding about the strong role of culture and the role it plays in organizations. That's one of the reasons that many strategic planners now place as much emphasis on identifying strategic values as they do mission and vision.
Stakeholder Management
Stakeholder management is the process of managing the expectation of anyone that has an interest in a project or will be effected by its deliverables or outputs. Helpful Suggestions for Managing Difficult Clients Every consultant has had to deal with a difficult client. The nice thing about being a consultant - you just need to get through the project and you will be able to move on - you don't necessarily have to work with that client ever again. But really, that's not what you want, is it? Ideally you develop a strong working relationship with a client so that when another project comes up, the client thinks of you first. You become a partner with the client, not just a one-time deal.
Stake Your Project Claim After recent conversations with a friend about waffling company policies on projects, my head was whirling. I wondered how you manage a project without the stakeholders' approval or buy-in. In my friend's company, the sales representatives sometimes create quotes based in large part on what the customers want, and not always on what their products can do. The next step in the process is a layer of approval from several colleagues, and in many cases, the sales representative in question has to go back to the customer and renegotiate. You can imagine how the customer feels. Stakeholder Commitment: Why Is It Important? If that carrot-at-the-end-of-the-stick tactic seems useless to get commitment from your stakeholders, try these how-to's shared by experts. Commitment is important in any relationship. It is the value that galvanises diverse entities so that all can work together unilaterally and seamlessly. Without it, there is no bond and no common purpose. Romantic, family or even business-wise, commitment is the force that drives the relationship forward, toward a mutually desirable goal that usually points to growth and/or profitability. How to Sell Function, Feature and Benefit to Stakeholders Top executives and stakeholders are often "sold" certain projects from within the organisation. This normally happens, where a sales team first handles a project and then later assigns it to a project manager who "inherits" it. The concept here is that the selling to the stakeholders actually continues once the project manager takes over. Because of this reality, the project manager must to some extent use sales skills and continue to build (and even sometimes repair!) the relationships with the stakeholders. Building Relationships in Project Management Building relationships is just as important within the project team as it is outside. Good relationships can be the difference between outstanding success and dismal failure because it's all about getting people to like and trust you so that they will deliver what you need them to deliver at the right time in the right way. We have talked previously about managing stakeholders, finding out about and managing their needs and expectations, however this is much easier if you have developed good relationships with stakeholders in the first place. Project Management: Stakeholder Risk Management Is it really true that on time, on budget, and fulfilling all requirements means project success? Whose requirements are we really trying to meet anyway? And who decides if the original due date can be changed when the scope grows? In this article we'll address the people swirling around your project, stakeholders. You'll find some useful tips and other resources for optimising stakeholder involvement in your project. Avoiding the "Dark Twisty Turn-filled Tunnel Syndrome" Many a well conceived project ends up in the scrap heap because of inadequate expectation setting, or sponsors and key stakeholders that become disinterested or impatient with projects
that don't produce deliverables quickly enough. These projects, after creating an initial buzz, appear to enter "a dark twisty tunnel" where the light from the tunnel entrance is no longer seen, the tunnel exit is nowhere in sight, and inadequate milestones exist to indicate forward progress. Avoiding this trap is no trivial matter, as it is more than just defining milestones for your project. Persuasion and Perception Every year, between forty and seventy percent of all corporations and public sector bodies attempt to make strategic change. Overwhelmingly, formal projects are the preferred structure used to organise such effort, regardless of whether the underlying goals are defined in terms of business process re-engineering (BPR), technology upgrades, mergers and acquisitions, due diligence or similar concepts. What is Stakeholder Management? Running a successful project requires a high degree of stakeholder management. So who are stakeholders? A stakeholder is anyone who has an interest in your project or will be affected by its deliverables or output. It is important to understand the values and issues that stakeholders have in order to address them and keep everyone on board for the duration of the project. Creating and Sustaining a PM Culture In the rush to implement project management, some organizations are implementing largescale training programs, hiring project management consultants, and setting up project offices. Still, they are not seeing the results they had expected. The reason is simple-they have not created the environment necessary for project management to grow and flourish. What is a project environment and how can you create one? It's not easy, but it can be done. Here's how. Most organizations are vertical bureaucracies. Project management cuts across this vertical structure, placing authority and accountability for project results in the hands of a project manager. This can be a painful process! Just try wresting power away from functional managers. Obviously, shifting power from a vertical hierarchy to a cross-functional, temporary organization takes a little foresight and preparation nothing less than an organizational culture change. In the project management context, this entails establishing a whole set of new behaviours, starting at the top. In a project culture, functional managers provide resources to project teams. The project managers themselves must be empowered, via a written project charter, to make decisions, secure resources, and deal directly with the customer. Management must create a project management methodology that defines the project life cycle and process, right down to what is required, when it is required, and how it is done. A complete set of instructions, forms, templates, and tools is necessary to ensure consistent, repeatable performance across the organization. A training program, tailored to the new methodology, is necessary to teach and reinforce use of the methodology. Outside consultants may be required to diagnose and correct existing problems while future project managers are in training. And, most importantly, senior management must require consistent application of the methodology and reward successful project behaviours. Guidance on Creating a Project Culture in Your Organization
In Creating a Climate and Culture for Sustainable Organizational Change (Organizational Dynamics, Spring 1996), Schneider, Brief, and Guzzo list six steps to implementing total organizational change. It is useful guidance to those who are involved in creating a project management culture. 1. Ensure the organization is prepared to handle a major organizational change. If the organization's management is not trusted, any attempt to change will be treated with scepticism. If you have ever heard the following statements where you work, you are facing an uphill battle: This is just the flavour of the day; this too shall pass; this will last about a year then we'll be into something else; this is just like TQM- here today, gone tomorrow. These statements reflect distrust in the organization's leadership. Change will be difficult in this organization. Ask the following questions before implementing widespread change: a) Is employee morale high? b) Does the leadership have a history of successfully implementing major changes? c) Is management known for tackling tough decisions and doing the right thing? If the answer to these questions is yes, change will be embraced. If the answer is no, management must be consistent and plan for resistance. Constancy of purpose will overcome scepticism in the long run. 2. Is the proposed change consistent with the existing organizational culture? If decision making is centralized, if the organization is a traditional vertical hierarchy, if communication is primarily up the chain, and if conflict is escalated rather than resolved locally, the change will require significantly more time, effort, and attention. If, on the other hand, the organization has already spent a lot of time and effort establishing a team-based culture, the change will be accepted much more readily. 3. Plan the change in as much detail as possible. This is where creation and deployment of a project man - agreement methodology, and establishment of a project management office, come into play. Specify why the change is necessary-what is threatening the current organization and why the proposed change will defeat the threat. Spend time and money developing the methodology, processes, and policies. Make it clear to people that they will receive training, will be expected to implement the new practices, and will be rewarded for doing so. Communicate, communicate, and communicate. Going half way with this step will lead to disaster. 4. Ensure that the reward system is structured to motivate employees to focus on implementing the project management methodology. People are smart. They figure out what the organization rewards and that's what they do. Management must reward good project behaviour and discourage ad-hoc approaches. For example, if the new project methodology requires risk plans, and management never asks to see a risk plan or even asks about the top risks and associated response strategies, people will stop addressing risk. They will return to their old ways, with predictable results. This implies that senior management knows what a valid assumption is in the methodology-not always. This can be cured with a one day PM for Executives course. 5. Allocate resources to maintain the new system. As with any system, maintenance of a project man - agreement system is part of the total system life cycle cost. Sometime during the change to a project culture, a project office should be set up to help implement the change and to actually carry out many project duties. The scope of the project office can vary between informal groups of passionate individuals to a collocated, permanent organization. Either way, the project office is responsible for updating the methodology, providing expert
help to project teams, tracking and reporting project status, even man - aging projects for the more formalized project office. This takes resources-and it's not really optional if you want the change to last. 6. Monitor the progress and effectiveness of the change to the organization. Adjust as necessary. This step is fundamental project management practice. Performance must be monitored and variance eliminated to bring about lasting change. Periodically check to make sure the change is taking effect, that you are getting the desired behaviours and project results. If so, pat yourself on the back for a job well done. If not, check to see where the resistance is or lack of support exists and take action to get back on track. Project management will improve cost, schedule, and technical performance. It will lead to satisfied customers. But it does fail in some organizations due to the lack of a project management culture. When we speak of changing the culture, we are talking about changing the set of shared beliefs, values, and expectations that exist within the organization. A change as basic as this must be undertaken methodically. Follow the six-step plan described here to dramatically improve your chances of success.
Setting objectives (these should be measurable) Identifying deliverables Planning the schedule Making supporting plans
Supporting plans may include those related to: human resources, communication methods, and risk management. Computer hardware and software project planning within an enterprise is often done using a project planning guide that describes the process that the enterprise feels has been successful in the past. Project planning is part of project management, which relates to the use of schedules such as Gantt charts to plan and subsequently report progress within the project environment. Initially, the project scope is defined and the appropriate methods for completing the project are determined. Following this step, the durations for the various tasks necessary to complete the work are listed and grouped into a work breakdown structure. The logical dependencies between tasks are defined using an activity network diagram that enables identification of the critical path. Float or slack time in the schedule can be calculated using project management software. Then the necessary resources can be estimated and costs for each activity can be allocated to each resource, giving the total project cost. At this stage, the project plan may be optimized to achieve the appropriate balance between resource usage and project duration to comply with the project objectives. Once established and agreed, the plan becomes what is known as the baseline. Progress will be measured against the baseline throughout the life of
the project. Analyzing progress compared to the baseline is known as earned value management. The inputs of the project planning phase include Project Charter and the Concept Proposal. The outputs of the Project Planning phase include the Project Requirements, the Project Schedule, and the Project Management Plan.
Step 1: Create a Project Plan Firstly, you need to create a comprehensive Project Plan, which is critical to the success of the project. The Project Plan identifies the Work Breakdown Structure (WBS) of the phases, activities and tasks to be undertaken. It defines the sequencing, duration and dependencies of each task, as well as the generic resources and financial expenditure required to complete your project. Step 2: Create a Resource Plan Following the creation of a Project Plan, a detailed assessment of the resources required to undertake the project should be made. The required labour, equipment and materials should be listed and the amount of each resource quantified. Finally, the resource consumption should be scheduled to provide the Project Manager with a complete view of the total amount of resource needed for each stage of the project. Step 3: Create a Financial Plan The Financial Plan describes the total quantity of financial resources required during each stage of the project. The total cost of each item of labour, equipment and materials is calculated, as well as the total cost of undertaking each activity within the Project Plan. Step 4: Create a Quality Plan To ensure that the project deliverables meet customer requirements, a Quality Plan is developed. This plan explicitly lists the quality targets to be achieved, and a suite of Quality Assurance and Quality Control activities are scheduled to ensure that the required level of quality is achieved throughout the project. Step 5: Create a Risk Plan Managing Project Risk is a critical process within the Project Lifecycle. To mitigate risk effectively, all foreseeable project risks are identified and rated in terms of their likelihood of occurrence and potential impact on the project. The risks are prioritized and a set of actions identified to reduce the likelihood of each risk and its impact on the project should it occur.
10 Steps to Planning a Project Did you know that one of the most common causes of project delay, overspend and customer dissatisfaction is the lack of proper project planning? The Project Planning phase is one of the most critical phases within a project. Within this phase, the people, resources, finances, suppliers and tasks must be correctly scheduled, in order for the Project Manager to be able to monitor and control the project delivery effectively. To help you to plan projects better than before, weve described here the 10 steps to planning a project. If you want to plan projects quickly and efficiently, then take the following 10 steps: A description of each step follows:
Step 6: Create an Acceptance Plan The key to customer satisfaction is in gaining approval from the customer that the deliverables meet the quality criteria stated in the Quality Plan. To ensure that customer acceptance is sought for each deliverable produced by the project, an Acceptance Plan is created. The Acceptance Plan provides a schedule of Acceptance Reviews which are undertaken to gain customer acceptance for the completion of each deliverable within the project. Step 7: Create a Communications Plan A Communications Plan is a document which describes the information to be provided to project stakeholders to keep them informed of the progress of the project. Each stakeholder is listed and their requirements for information clearly identified. A schedule of communication events and activities are laid out to ensure that the right information is communicated to the right people at the right time. Step 8: Create a Procurement Plan Projects often need to acquire procurement items (such as products, services and specific results) from external suppliers. The Procurement Plan describes which items will be sourced from external suppliers and the timeframes and methods for delivery. Step 9: Contract the Suppliers With a clear view of the procurement items to be acquired, the project team will set out to select and contract one or a small number of preferred suppliers to the project. Step 10: Perform Phase Review With a detailed understanding of the activities, resources, finances and supplier relationships required to undertake the project, the team is ready to enter the Execution phase. A Phase Review is undertaken to ensure that all of the required Planning activities have been completed and to provide formal approval to proceed to the Project Execution phase. There you have it. By completing these 10 steps, you will create a comprehensive suite of Project Plans which enable you to properly control people, resources, finances, suppliers and tasks throughout the entire Project Lifecycle.
Large, complex projects are organized and comprehended by breaking them into progressively smaller pieces until they are a collection of defined "work packages" that may include a number of tasks. A $1,000,000,000 project is simply a lot of $50,000 projects joined together. The Work Breakdown Structure (WBS) is used to provide the framework for organizing and managing the work. In planning a project, it is normal to find oneself momentarily overwhelmed and confused, when one begins to grasp the details and scope of even a modest size project. This results from one person trying to understand the details of work that will be performed by a number of people over a period of time. The way to get beyond being overwhelmed and confused is to break the project into pieces, organize the pieces in a logical way using a WBS, and then get help from the rest of your project team. The psychologists say our brains can normally comprehend around 7-9 items simultaneously. A project with thousands or even dozens of tasks goes way over our ability to grasp all at once. The solution is to divide and conquer. The WBS helps break thousands of tasks into chunks that we can understand and assimilate. Preparing and understanding a WBS for your project is a big step towards managing and mastering its inherent complexity. The WBS is commonly used at the beginning of a project for defining project scope, organizing Gantt schedules and estimating costs. It lives on, throughout the project, in the project schedule and often is the main path for reporting project costs. On larger projects, the WBS may be used throughout the project to identify and track work packages, to organize data for Earned Value Management (EVM) reporting, for tracking deliverables, etc.
facilities .... [It] displays and defines the product(s) to be developed and/or produced and relates the elements of work to be accomplished to each other and to the end product(s)." It requires some mental discipline to develop a product-oriented or deliverable-oriented grouping of project elements adding up to comprise the entire project scope. Intuitively, we tend to start out with a task-oriented approach. This is OK for very small projects where extensive project management controls will not be used. The task-oriented approach is easy to understand, because we can easily think of projects as collection of tasks. A task-oriented WBS can be developed by beginning with a simple "to-do" list and then clustering the items in a logical way. The logical theme could be project phases, functional areas, or major endproducts. If your organization will be collecting historical data to form a cost database, you should try to select a standard approach consistent with the organizations long term data collection needs. A sample WBS is shown in the figure below:
Additional level 2 elements not shown here might include development environment support, logistics and training, and installation and start-up. This next link will take you to a skeleton sample WBS for a software and hardware system development project, and you can also download a zipped version of the corresponding MS-Project 2002 (.mpp) file. A WBS for a large project will have multiple levels of detail, and the lowest WBS element will be linked to functional area cost accounts that are made up of individual work packages. Whether you need three levels or seven, work packages should add up through each WBS level to form the project total.
oriented. Your WBS can be built on nouns or verbs. If the results of your project are primarily verbs, then a verb based or process based WBS may make more sense. If your WBS is to be product or deliverable oriented, then you can start by thinking of the WBS as a parts list for the ultimate end-items of your project. This link will give a simple illustration of a product or process based WBS orientation. These differences are not shown to tell you what the right way for your project are, but just to familiarize you with the distinctions, so you can think about them and choose what's best for your project.
WBS Numbering
WBS elements are usually numbered, and the numbering system may be arranged any way you choose. The conventional numbering system is shown in the figure. The shaded box shown in the above slide could be numbered 1.2.2.3, which would tell you it was in the second box in level 2, the second box in level 3, and the third box in level 4.
WBS Dictionary
If a WBS is extensive and if the category content is not obvious to the project team members, it may be useful to write a WBS dictionary. The WBS dictionary describes what is in each WBS element, and it may also say what is not in an element, if that is unclear. Here is a sample of a WBS dictionary description: WBS Element 1.5.4.5. - Systems Integration Test Equipment Planning - This element includes the effort to identify requirements and specify types and quantities of test equipment needed to support the System Integration and Test process. It does not include the design or procurement of such equipment, which is covered in Element 1.5.4.6.
a product-oriented WBS, functional categories of work may form "cost accounts" within a WBS element. Cost account managers are responsible for a functional areas contribution to a WBS element. Cost accounts from several departments or functions may combine into one WBS element. Internal department planning for a cost account will be made up of individual work packages. A work package will typically have its own budget and schedule. Work packages should be small enough to be executed by individuals or small groups in a single department, and they should be of relatively short schedule duration. A small project might define a maximum work package size as two weeks of effort. Larger projects will assemble larger work packages that can be appropriately managed and controlled. The project manager will have to decide to what degree employment of various details of WBS implementation will benefit the efficient management of the project. On a very small project, a formal WBS may serve no useful purpose, but it can become valuable if project size or complexity start to increase. As an organizations project management environment matures, or as larger size and complexity are encountered, application of the WBS concept can evolve from an ad hoc list of tasks, to time-phased activity lists, task lists clustered by project deliverables and services, or an end-product focused WBS fed by cost accounts and work packages.
If you are using MS-Project or a similar project management software application, you may encounter the WBS as a vertical list with indents to show structure. This will be compatible with the Gantt View data entry screens. While some software packages provide a separate WBS view, you could prepare your WBS in the vertical format using a word processor, and then cut and paste your WBS into your project management software package.
Organizational Standards
Your organization may want to decide on a standard WBS format or group of formats, use these across all projects, and communicate definitions widely so everyone will be speaking the same language. This can save re-learning project lessons and can lay the groundwork for successful data gathering to aid future cost estimates.
WBS Implementation
When you set up a project WBS, think about how you will be using it later in the project. Try to consider how you will organize the WBS, schedule format, manager assignments, and charge numbers, in your early project planning. These days, the WBS in smaller projects ends up automatically being the indent structure in your Gantt schedule, so pay attention to those indents, and make sure that is the WBS you want for rolling up costs in your project, especially if you will be using EVM. It will be helpful if you can map the charge numbers, managers, and task groups to each other. This will help you track costs and progress for each manager. If your project schedule will on MS-Project, you may want to insert "text" columns into your schedule (Gantt View) for project charge numbers and manager names.
If your project charge numbers cannot be linked to groups of tasks assigned to specific managers, you will have no way to provide performance measurement feedback to managers. Some project management environments have definite conventions for grouping items in a WBS. The best method is to have a WBS that works for your particular project environment. The WBS should be designed with consideration for its eventual uses. Your WBS design should try to achieve certain goals:
Be compatible with how the work will be done and how costs and schedules will be managed, Give visibility to important or risky work efforts, Allow mapping of requirements, plans, testing, and deliverables, Foster clear ownership by managers and task leaders, Provide data for performance measurement and historical databases, and Make sense to the workers and accountants.
There are usually many ways to design a WBS for a particular project, and there are sometimes as many views as people in the process. Experience teaches that everyone takes a slightly different slice of the apple, so make sure WBS arguments seeking metaphysical certainty are quickly brought to closure. Simple practicality combined with enlightened trial and error usually is the best approach.
done in parallel. Some tasks require the skill of a single individual; other jobs in the project require that everyone chip in and lighten the load. A project, technically, is a temporary endeavour to create a unique product or service. Projects are an undertaking outside of the normal operations of an entity. For example, you might roll out a new application, install new monitors, create a new portion of a web site, or establish a new call centre for application support. In some organizations, such as ones comprised of application developers or consultants, or IT integration companies, everything they do is a project because they complete projects for other organizations. Consider a company that creates custom applications for other organizations. Their operation is an ongoing series of projects. The organization that completes the project work is called the performing organization. IT project management is the ability to balance the love and implementation of technology while leading and inspiring your team members. Of course, the goal of project management is not technology for technologys sake, but rather a movement toward things like improved customer service, enhanced product quality, and increased profitability. As you can see in Figure 1-1, project management is a high-wire balancing act. Establishing the Project Requirements Before the actual project work can begin, the project manager must establish the project requirements with the project stakeholders. Stakeholders are any individuals, groups, or communities that have a vested interest in the outcome of the project. On some projects, the stakeholders may be just one department. On others, when projects may affect every department, the stakeholders may be throughout the entire organization. Identifying stakeholders is important because their input to the project requirements early in the project initiation can ensure the projects success. Of course, on most projects there will be key stakeholders who influence the projects outcome: department managers, customers, directors, end users, and other folks who have direct power over the project work. With the input of these key stakeholders, specifically their requirements for the project, constraints on the project, and time and cost objectives for the project, the project manager will be able to gather the project requirements to begin building a project plan to create the project deliverables. Clarity is paramount. When the decision has been handed down that your company will be implementing some new technology, and youll be leading the way, you need a clear, thorough understanding of the projects purpose. Ambiguous projects are a waste of time, talent, and money. Before the project begins, you need to know what exact results signal the projects end. A project truly begins when you know exactly what the project will produce.
Once the project is defined, you need a clearly stated start and end date. The role of a project manager is not permanent but temporary. You, the project manager, are responsible for seeing the goal, developing the steps to get there, and then leading the way for your team to follow. How will you know what the end result of the project is to be? Ask! Who do you ask? People like the project sponsor can answer these kinds of questions. More about that later! You must have a clear vision of the end result, or the project will drone on and on forever and youll never finish. Too often IT projects can roll into project after project stemming from an original, indecisive, half-baked wish list. Whether you are a full-time employee within an organization or a contract-based project manager, you must have a clear understanding of what the end results of the project will be. Imagine your favourite archaeologist manoeuvring through a labyrinth of pitfalls, poison darts, and teetering bridges to retrieve a golden statue. In the movies, theres always some fool who charges past the hero straight for the booty and gets promptly beheaded. Dont be that guy. Before you can rush off toward the goal of any given project, youve got to create a clear, concise path to get there. To create this path, youll have to interview the decision makers, the users the change will affect, and any principals involved in the development of the technology. These are the stakeholdersthe people who will use the project deliverables on a daily basis or will manage the people who will use the project deliverables. You must have a clear vision of what the project takes to create it or youre doomed. Often projects start from a wish list and evolve into a catalog of complaints about the current technology. One of your jobs in the early stages of the project will be to discern valid input from useless gripes. As you begin your project, consider these questions: Does the Project Have an Exact Result? Projects that are as indecisive as a six-year-old at an ice cream stand rarely are successful. As a project manager, you must ensure the project has a definable, obtainable end result. At the creation of the project, every project manager, project sponsor (the initiator of the project), and team member should know and recognize the end result of the project. Beware of projects that begin without a clearly defined objective. While you should be looking for exact requirements that a project is to include, you must also look for requirements that are excluded from a project (for example, a project that requires all mail servers to be upgraded in the operating system, but not the physical hardware). As the project takes form, the requirements to be excluded will become obvious based on management, the time allotted for the projects completion, and the given budget. Is There Industry or Government Sanctions to Consider? Within your industry there may be governmental or self-regulating sanctions you will have to take into account for your project. For example, in a banking environment there are regulations dealing with the security of the technology, the backup and recovery procedures, and the fault tolerance for the hardware implemented. Government regulations vary by
industry, and if your company is a government contractor, there are additional considerations for the project deliverables. Within your industry there may be standards and regulations. Regulations are must-haves that are required by law. Of course, pharmaceuticals, utility companies, and food packaging companies have regulations that dictate their practices. If companies break regulations, fines and lawsuits may follow. Standards, however, are generally accepted guidelines and practices within an industry. Standards are heuristics, rules of thumb, which are not laws but are usually followed. The project manager must be aware of regulations and standards that affect the projects work and deliverables. Defining project goals and objectives Goals and Objectives Goals and objectives are statements that describe what the project will accomplish, or the business value the project will achieve. Goals are high level statements that provide overall context for what the project is trying to achieve, and should align to business goals. Objectives are lower level statements that describe the specific, tangible products and deliverables that the project will deliver. The definition of goals and objectives is more of an art than a science, and it can be difficult to define them and align them correctly. Goals Goals are high-level statements that provide the overall context for what the project is trying to accomplish. Let's look at an example and some of the characteristics of a goal statement. One of the goals of a project might be to "increase the overall satisfaction levels for clients calling to the company helpdesk with support needs". Because the goal is at a high-level, it may take more than one project to achieve. In the above example, for instance, there may be a technology component to increasing client satisfaction. There may also be new procedures, new training classes, reorganization of the helpdesk department and modification of the company rewards system. It may take many projects over a long period of time to achieve the goal. The goal should reference the business benefit in terms of cost, speed and / or quality. In this example, the focus is on quality of service. Even if the project is not directly in support of the business, there should be an indirect tie. For instance, an IT infrastructure project to install new web servers may ultimately allow faster client response, better price performance, or other business benefit. If there is no business value to the project, the project should not be started. Generally, non-measurable: If you can measure the achievement of your goal, it is probably at too low a level and is probably more of an objective. If your goal is not achievable through any combination of projects, it is probably written at too high a level. In the above example, you could envision one or more projects that could end up achieving a higher level of client satisfaction. A goal statement that says you are trying to achieve a perfect client experience is not possible with any combination of projects. It may instead be a vision statement, which is a
higher level statement showing direction and aspiration, but which may never actually be achieved. It is important to understand business and project goal statements, even though goals are not a part of the Ten Step Project Definition. Goals are most important from a business perspective. The project manager needs to understand the business goals that the project is trying to contribute to. However, you do not need to define specific project goals. On the other hand, objectives definitely are important. Objectives Objectives are concrete statements describing what the project is trying to achieve. The objective should be written at a lower level, so that it can be evaluated at the conclusion of a project to see whether it was achieved or not. Goal statements are designed to be vague. Objectives should not be vague. A well-worded objective will be Specific, Measurable, Attainable/Achievable, Realistic and Time-bound (SMART). An example of an objective statement might be to "upgrade the helpdesk telephone system by December 31 to achieve average client wait times of no more than two minutes".
Note that the objective is much more concrete and specific than the goal statement. The objective is measurable in terms of the average client wait times the new phone system is trying to achieve. We must assume that the objective is achievable and realistic. The objective is time-bound, and should be completed by December 31.
Objectives should refer to the deliverables of the project. In this case, it refers to the upgrade of the telephone system. If you cannot determine what deliverables are being created to achieve the objective, then the objective may be written at too high a level. On the other hand, if an objective describes the characteristics of the deliverables, they are written at too low a level. If they describe the features and functions, they are requirements, not objectives.
Identify Find, list and characterise elements of Risk. Analyse Prioritise identified Risks against agreed criteria. Plan Select and implement Risk Handling Options. Manage Implement, monitor, report and review Risk Management actions against objectives.
In order to obtain the maximum benefit from Risk Management, it needs to be implemented in a systematic and disciplined manner and as an iterative process as shown in this illustration. Risk Management (RM) covers all those measures which have to be implemented in order to determine a reasonable and acceptable level of risk (Risk Appetite) and to manage a project so as to avoid exceeding that level. For an overview of project Risk Management the provides further guidance.
Opportunity or Threat?
The definition of a Risk includes both positive and negative consequences. The Iterative Process described above is equally applicable whether addressing the Opportunity (positive) or Threat (negative) side of Risk Management.
In some organisations 'Risk Analysis' (rather than RM) is often encountered, and is divided into Identification, Assessment and Management; 'Risk Analysis and Management' is also sometimes equated with RM. 'Handling' is used by United States organisations instead of Management for the fourth stage. To avoid confusion and to aid a common understanding, a Risk Language has been developed for use within MOD projects and programmes.
A Project budget
Defining a budget for development projects is frequently referred to as an art form. As seems to be true with all business ventures, your cost projection can easily be the subject of -fuzzy math," with little bearing on reality. Hourly rates for development time, escalation costs for rapid development, and pricing of tools and other resources can fluctuate based on little more than what the client can afford. To ensure an accurate projection of the amount of money required to deliver a solution, follow the guidelines below to help you create a consistent and justifiable budget that is realistic. Basics of budgeting A budget is one of those pivotal tools that are used across many departments within a company. For the developers, it dictates how much time to spend on specific areas of the application. For the project manager, it's a baseline used to determine whether the project is on track. For sales or the client, it correlates directly to the success of the effort. It's no surprise that one of the biggest issues in creating a budget is interpretation. Regardless of circumstance, a number of basic philosophies can help your budgeting immensely by protecting it from subjective review. By understanding concepts, and making sure that everyone involved understands them, you'll be on the right track to an accurate projection:
Project costs and project budgets are two different things. Always start by identifying project costs. Project costs are not defined solely in monetary amounts. Include actual amounts, with shipping and taxes, for software or hardware purchases that must be made. If you're pro-rating the costs of using pre-existing hardware and software tools, include it in number of hours. Likewise, developer effort costs are recorded in hours, not dollars. Once you've laid out your costs, identify your risks and assign a percentage reflecting how much each risk factor may affect the project as a whole, or a portion of the project. Each development team should have a risk value assigned to it, to cover reasonable costs such as hiring the occasional contractor to get a timeline under control, unforeseen overtime, and so on. Your budget, then, is the total of the costs, as transcribed into a monetary figure, plus the total risk percentage of that cost. Define conversion values that you use to represent equipment pro-rating and development times. Your budget is not an invoice. Once you've determined the hard figures involved, leave it up to your company's business representatives to make adjustments for profits. Make sure they understand your figures reflect actual costs.
A budget should always be labelled as an estimate, until it is finalised and approved. This helps to manage expectations and prevent miscommunications from being written in stone. A single person does not create a budget. At the very least, all of the following should be consulted: lead developer, project manager, and a business-side driver.
Identifying project costs When you're identifying the costs of development is as close to reality as possible. Look at performance of the team members on past projects to get a feel for how long it will take to program a set amount of code. Consult with your lead developer. That's worth saying twice "consult with your lead developer! Watch out for boastful estimates, but save hourpadding for your risk assessment stage. Don't forget to include costs of integration and deployment. Meetings, security certificates, license fees, quality assurance hours, debugging, documentation hours and material costs, and planning time are all areas that are frequently overlooked. Whether your company will be billing the client for these items or not, they are all valid and substantial expenses of a project. Including them will help you accurately measure the profitability of the solution down the road. Next, itemise estimates for features that weren't included in the specification, but that you suspect will be asked for later, or that would be beneficial to the final product. List these separately as options. Another good thing to up-sell is developer support time for about 60 days after launch. Often when a project is rolled out, support groups aren't in place or may defer a lot of questions to the developers. Once you've got your costs outlined, it's time to look at the probability of exactly hitting those costs. Risk assessment Risk assessment and assignment is very important to a successful budget. Without it, the crises that happen regularly and are an inherent part of any project will affect your bottom line. Values in your estimate should have this padding built in, and it should not be considered a part of sales mark-up. Risk represents actual costs incurred over the course of development. Risk line items should include things like development team experience, obscurity (supportability) of the technology used, planning time shortages, number of development teams, location of development teams, number of modular components, proximity and availability of the project driver, product dependencies such as databases or third-party software, and any unknowns. Once you've determined your risk items, assign a scope and percentage to each item. For example, if one part of your application is to be built in Java and another in C, and your team consists mostly of C programmers, the Java component may have a higher risk assignment under the -developer experience" line item. The percent assigned should be applied only to the relevant portion of the project. All projects have a certain amount of risk involved that can be attributed to human existence. People get sick and take vacation. No one is an expert in everything. I always assign a
percentage to this area, beyond other considerations. An average 10-developer, 6-month project justifies a risk assessment of 5 percent of the total project costs. For longer projects and smaller teams, it will be higher; for shorter projects and larger teams, it will be lower. It is normal for your overall risk assessment to be between 20 and 30 percent of the total project cost. Does this seem high? Low? Your actual total risk percentage will depend on your experience in evaluating the team and the pending effort. If, after calculating an estimate, your numbers are coming out too high, look at other projects by your company. Did they actually fall within their budget? If not, your numbers may be justified. If so, you may be giving your team too little credit. Rectify project-to-project discrepancies before presenting your estimate to the project driver. Conclusion Regardless of how close you come to reality, a client will be much happier if your project comes in below budget than over it; however, too high a risk value can create sticker shock, revealing inexperience and creating misgivings about your management abilities. By following the guidelines we've suggested and applying some common sense, you can be assured that your team, project drivers, and client will enjoy the benefits of a well-estimated project.
shared belief in the value and achievability of the team's goals, awareness of the value of the individual's own role and contribution, recognition of the value of other team members (whether they are key specialists or just non-specialist, junior assistants), desire to work collaboratively, sharing thoughts, ideas, concerns, etc, friendship - enjoying working together with a common purpose, supporting each other in recognition that the team's success requires all members to be successful, coaching junior members rather than bossing them, listening to ideas and advice from other team members, making time to communicate with other team members, celebrating successes, Rewarding good team behaviour in financial and non-financial ways.
To achieve this collaborative team style, the Project Manager usually needs to behave as one of the team - collaborative, supportive, friendly, etc. The Project Manager should be the best
of friends with each team member to the extent that each participant would go to great lengths to help the project succeed. It is interesting to compare this project management style with the traditional view of the Project Manager. Often the best recognised Project Managers are those who make a lot of noise, bang the table, make snap judgements, are tough with their people, "crack the whip" and generally drive people to perform through the exercise of power. These behaviours are very visible and it is common to find managers with this personal style do get recognised and promoted. A regime of terror can only succeed so far and for so long. There comes a point where the participants give up trying and no amount of pressure can persuade them to increase their contribution. Beyond that point, people will leave and the project will fail. Conversely, in a collaborative team the participants feel that the team's success is their own personal mission. They will respond ever more determinedly as the pressure rises. The Project Manager who has created an excellent team will find the team performing optimally with very little intervention. Herein lays the dilemma for a career-minded Project Manager. In good projects the Project Manager does not need to (and should not) exhibit dramatic, powerful, personal characteristics, but the organisation's leadership may be more likely to recognise the talents of a manager who creates a lot of noise. Planning for a first-class team: You might be able to build a good, effective team based on your own instinct and personality. If, however, you apply your wisdom you will realise you need to plan your approach in advance of building the team. Team-building considerations will impact your decisions on such things as:
budget, team structure, reward mechanisms (bonuses, payments, other incentives) assignments and usage of specific individuals, mobilisation of resources, communications strategy, Planned activities - events and regular meetings.
The project's sponsors should also understand the importance of building a good team. Make sure they support the measures and approaches you plan. For example, if you feel it would help to allow the team to wear jeans, work from home and have free drinks every Friday you could get in a lot of trouble unless the senior leadership understand and agree. Routine activities and special events should be included in the overall high-level planning for the project and in the detailed plan for each phase
Take care to choose the right people. Pick them for their skills and abilities as they apply to your particular project. You don't necessarily need the person most qualified in absolute terms, but you need the person most qualified for your specific project. Concentrate on the skills you need for the job in hand. Don't be seduced by reams of paper qualifications that you will never need. You almost certainly need a mixture of team members each with a different set of skills and abilities, rather than a series of clones all with identical skills. Ensure that taken as a group they together represent all the skills you need in the proportions that you need them. Don't overlook the need to choose people who can all get along with each other and work together as a team. A group of prima donnas is the last thing you want. Set the Tone and the Ground Rules:
Do this at your very first team meeting. Make sure that you call this at the very start of your project and that everyone in your team comes to the meeting. Don't be late yourself and don't allow lateness in others.
This is the meeting where you have to make it clear who is in charge and what you expect from your team. This is where the team hierarchies and reporting structures are restated. This is the time to remove any ambiguities or potential conflicts. Make sure everyone is clear about his role and responsibilities. Delegate tasks as appropriate and make it clear who hold the delegated authority. Setting Clear Goals:
You must set clear achievable goals. You must set them for your team as a whole and you must set them for the individuals within your team. They must be unambiguous and they must be mutually attainable. That is to say, no one individual's goal should in any way conflict with that of another individual. In fact you want it to be in everybody's interest that each individual achieves his own goal. Design the goals accordingly. You must try to build a team that works together with common aims, all working towards the same final goal.
Communication:
It is almost impossible to exaggerate the importance of communication within any organisation, and in particular within a project team. Make it your duty to ensure that everyone within your team knows what is going on. Make sure that everyone knows of outside events that will affect the team. Make sure that everyone knows their own goals and objectives and those of the team as a whole. Make sure they know the objectives of those interfacing to them and of any potential conflicts. Make sure that a problem or a delay in one area is immediately communicated to those whom it may affect.
Encourage and foster co-operation, not competition. Make sure it is in no-one's interest to keep information to them. Communication will come naturally if it is in everyone's own interest - and this will be the case if you have earlier ensured that you all have common mutually interdependent goals. These guidelines on their own are certainly not enough to guarantee a fully functional and successful team, but following them will go a long way towards creating one. On the other hand, if you don't follow them your chances of success will be minimal.
Members of an effective project team should have positive influence over their peers. They should be able to persuade community members who could be helpful to the project as well as their superiors and subordinates. Team members who are influential will not only be able to convince key people to become involved but also inspire others to take action.
4. They Are Motivational
Along the same vein, effective project team members are motivational by nature. While of course it is important the the project manager is able to inspire the team to perform the necessary tasks, it is just as imperative that the project team members are able to inspire and encourage one another as well as themselves. A motivated team will have clear project goals in sight and have the endurance to carry through to completion.
5. They Have Skills and Experience
Another of the key characteristics of an effective project team is that the team members have the talent, knowledge and familiarity necessary to accomplish the undertakings assigned to them. You are likely to have an assortment of skills and personalities making up your team, as you should. Think of it as all the parts of the body. The brain does the thinking but the feet do the walking - one does not function without the other, even though they are unique and
separate. Understanding and determining the necessary project management skills will help you select the best candidates.
6. They Are Dependable
The members of an effective project team are reliable, responsible and accountable to one another as well as to themselves. They create a plausible schedule that incorporates timeliness with accuracy and detail, leaving some room for unexpected snags. They adhere to that schedule because they don't want to let down their teammates - or themselves.
7. They Can Communicate Well
Effective project team members know how to express themselves in a way that gets their point across without offending others. They also know how to effectively listen when others are expressing thoughts, opinions and ideas. They will be able to communicate well with other team members as well as management, other employees and those with whom they must come in contact to complete the assigned tasks for the project. This characteristic reduces the chances of misunderstandings and misinformation, as well.
8. They Are Committed
Team members who are committed to the company or organization as well as the project in general are highly effective, as they are much more likely to give 100% at every step of the project and go above and beyond when necessary. Committed team members believe in what they are doing and therefore take great satisfaction in a job well done. These are the team members who tend to set up weekly meetings in order to make sure everyone is on track and that there are no foreseeable problems.
9. They Can Think Creatively
One of the often overlooked yet highly valuable characteristics of an effective project team is that they are able to think imaginatively. They are resourceful by nature and look for ways to make the best of the tools and materials that are available. Creative thinkers are especially helpful during project planning, as they can often put thoughts and ideas into other perspectives, turning out inventive and innovative concepts.
10. They Are Supportive
Last but certainly not least, effective project team members should be supportive of the project, the company and one another. When your project team stands behind what your organization and project represents, you can rest assured that they will perform the best job possible. A supportive team will check in with one another to learn the project status and learn whether any of their teammates need help. They will work together to ensure that the project is completed in a timely and successful manner.
Virtual Team:
A virtual team (also known as a geographically dispersed team or GDT) is a group of individuals who work across time, space and organizational boundaries with links strengthened by webs of communication technology. Members of virtual teams communicate
electronically and may never meet face-to-face. Virtual teams are made possible by a proliferation of fibre optic technology that has significantly increased the scope of off-site communication. Virtual teams allow companies to procure the best talent without geographical restrictions. According to Hambley, ONeil, & Kline (2007), "virtual teams require new ways of working across boundaries through systems, processes, technology, and people, which require effective leadership...despite the widespread increase in virtual teamwork, there has been relatively little focus on the role of virtual team leaders."
Networked teams
Generally, networked teams are geographically distributed and not necessarily from the same organization. These teams are frequently created and just as frequently dissolved; they are usually formed to discuss specific topics where members from the area of expertise, possibly from different organizations, pitch their ideas in the same discussion. Depending on the complexity of the issue, additional members to the team may be added at any time. The duration these teams last may vary significantly depending on how fast or slow the issue is resolved. Parallel teams Parallel teams are highly task oriented teams that usually consist of specialized professionals. While they are generally only required for very short span of time, unlike networked teams, they are not dissolved after completion of the tasks. The team may be either internal or external to the organization. Project development teams Similar to parallel teams, these teams are geographically distributed and may operate from different time zones. Project development teams are mainly focused on creating new products, information systems or organizational processes for users and/or customers. These teams exist longer than parallel teams and have the added ability to make decisions rather than just make recommendations. Similar to networked teams, project development teams may also add or remove members of their team at any given of time, as needed for their area of expertise. Work, production or functional teams
These teams are totally functioning specific where they only work on a particular area within an organization (i.e. finance, training, research, and etcetera). Operating virtually from different geographical locations, these teams exist to perform regular or ongoing tasks. Service teams Service teams are geographically located in different time zones and are assigned to a particular service such as customer support, network upgrades, data maintenance, etc. Each team works on providing the particular service in their daylight hours and at the end of day, work is delegated to the next team which operates in a different time zone so that there is someone handling the service 24 hours a day. Offshore ISD teams Offshore ISD outsourcing teams are independent service provider teams that a company can subcontract portions of work to. These teams usually work in conjunction with an onshore team. Offshore ISD is commonly used for software development as well as international R&D projects
results. This means processes (phases of work) must be defined in terms of standard deliverables and review points to substantiate completeness, and standard techniques and tools to be used in the development process. Such standardisation eliminates confusion and materially assists the project team in communicating on a common level, regardless of where they are geographically located. 3. Establish standard and routine project reporting cycles. Here, a good Project Management system can be invaluable. At minimum, project status should be reported on a weekly basis. If it is not possible to hold an on-site project review meeting in person, try holding an on-line meeting instead. Internet chat sessions and video conferencing have become very effective in this regards. The only problem though knows whether the participants are truly paying attention. A private project blog or discussion group can also be helpful for reporting problems and project status, as well as establishing punch lists and providing a clearinghouse for solutions. When you think about it, there is actually nothing here that shouldn't be done under normal operating conditions where all participants are on-site and present. Electronic communications simply begs the issue. It also means standard methodologies, like "PRIDE," are just as important today as they were yesterday, perhaps more so. Consider this, without such standardisation; offshore programming is not truly feasible. Collaborative software, the Internet, and all of our other communications vehicles are nice, but without an organised and standardised development environment, chaos will inevitably ensue.
obstacles due to restrictions of the Internet which in turn may lead to incorrect assumptions if a message is not laid out clearly. Failure to properly communicate and clearly address messages or emails could to lead to frustration and eventually failure. Poor leadership and management: Poor leadership can result in the failure of any team, whether virtual or not; however, it becomes a much more prominent problem in virtual teams. Messages must be sent across accurately and clearly. Inability to effectively communicate to members of the team can all greatly affect a project. Incompetent team members: Virtual teams should only consist of competent and experienced team members due to the distance factor which can overtly affect the timing and completion date of a project. Projects are more likely to fail if the team consists of individuals who are lazy or lack sufficient knowledge to complete their assigned tasks. It only takes one incompetent team member to have a negative effect on the rest of the team
Conflict management
It refers to the long-term management of intractable conflicts. It is the label for the variety of ways by which people handle grievancesstanding up for what they consider to be right and against what they consider to be wrong. Those ways include such diverse phenomena as gossip, ridicule, lynching, terrorism, warfare, feuding, genocide, law, mediation, and avoidance. Which forms of conflict management will be used in any given situation can be somewhat predicted and explained by the social structureor social geometryof the case. Conflict management is often considered to be distinct from conflict resolution. In order for actual conflict to occur, there should be an expression of exclusive patterns, and tell why the conflict was expressed the way it was. Conflict is not just about simple inaptness, but is often connected to a previous issue. The latter refers to resolving the dispute to the approval of one or both parties, whereas the former concerns an ongoing process that may never have a resolution. Neither is it considered the same as conflict transformation, which seeks to reframe the positions of the conflict parties.
Counselling
When personal conflict leads to frustration and loss of efficiency, counselling may prove to be a helpful antidote. Although few organizations can afford the luxury of having professional counsellors on the staff, given some training, managers may be able to perform this function. Nondirective counselling, or "listening with understanding", is little more than being a good listenersomething every manager should be. Sometimes the simple process of being able to vent one's feelingsthat is, to express them to a concerned and understanding listener, is enough to relieve frustration and make it possible for the frustrated individual to advance to a problem-solving frame of mind, better able to cope with a personal difficulty that is affecting his work adversely. The nondirective approach is one effective way for managers to deal with frustrated subordinates and coworkers. There is other more direct and more diagnostic ways that might be used in appropriate circumstances. The great strength of the nondirective approach (nondirective counselling is based on the client-cantered therapy of Carl Rogers), however, lies in its simplicity, its
effectiveness, and the fact that it deliberately avoids the manager-counsellors diagnosing and interpreting emotional problems, which would call for special psychological training. No one has ever been harmed by being listened to sympathetically and understandingly. On the contrary, this approach has helped many people to cope with problems that were interfering with their effectiveness on the job.
Conflicts in an organization:
Organizational conflict is a state of discord caused by the actual or perceived opposition of needs, values and interests between people working together. Conflict takes many forms in organizations. There is the inevitable clash between formal authority and power and those individuals and groups affected. There are disputes over how revenues should be divided, how the work should be done and how long and hard people should work. There are jurisdictional disagreements among individuals, departments, and between unions and management. There are subtler forms of conflict involving rivalries, jealousies, personality clashes, role definitions, and struggles for power and favour. There is also conflict within individuals between competing needs and demands to which individuals respond in different ways.
Role Conflict:
Another facet of personal conflict has to do with the multiple roles people play in organizations. Behavioural scientists sometimes describe an organization as a system of position roles. Each member of the organization belongs to a role set, which is an association of individuals who share interdependent tasks and thus perform formally defined roles, which are further influenced both by the expectations of others in the role set and by one's own personality and expectations. For example, in a common form of classroom organization, students are expected to learn from the instructor by listening to him, following his directions for study, taking exams, and maintaining appropriate standards of conduct. The instructor is expected to bring students high-quality learning materials, give lectures, write and conduct tests, and set a scholarly example. Another in this role set would be the dean of the school, who sets standards, hires and supervises faculty, maintains a service staff, readers and graders, and so on. The system of roles to which an individual belongs extends outside the organization as well, and influences his functioning within it. As an example, a man's roles as husband, father, son, and church member are all intertwined with each other and with his set of organizational roles. As a consequence, there exist opportunities for role conflict as the various roles interact with one another. Other types of role conflict occur when an individual receives inconsistent demands from another person; for example, he is asked' to serve on several time-consuming committees at the same time that he is urged to get out more production in his work unit. Another kind of role strain takes place when the individual finds that he is expected to meet the opposing demands of two or more separate members of the organization. Such a case would be that of a worker who finds himself pressured by his boss to improve the quality of his work while his work group wants more production in order to receive a higher bonus share.
These and other varieties of role conflict tend to increase an individual's anxiety and frustration. Sometimes they motivate him to do more and better work. Other times they can lead to frustration and reduced efficiency.
Avoidance - a management strategy which includes no attention or creating a total separation of the combatants or a partial separation that allows limited interaction Smoothing - technique which stresses the achievement of harmony between disputants Dominance or Power Intervention - the imposition of a solution by higher management, other than the level at which the conflict exists Compromise - strategy that seeks a resolution which satisfies at least part of the each party's position Confrontation - strategy featuring a thorough and frank discussion of the sources and types of conflict and achieving a resolution that is in the best interest of the group, but that may be at the expense of one or all of the conflicting parties
A trained conflict resolver can begin with an economical intervention, such as getting group members to clarify and reaffirm shared goals. If necessary, he or she moves through a systematic series of interventions, such as testing the members' ability and willingness to compromise; resorting to confrontation, enforced counselling, and/or termination as last resorts.
Personality change
In many contexts, the manager appears to be asking an employee to change his personality to conform to new requirements. This was the challenge that faced Freud as he used psychoanalysis in treating his patients, who had varying degrees of neurosis. The relationship between the psychoanalyst and his patient is one in which the individual seeking help is asked over a period of time to reach into his memory, and through free associations to
communicate with the psychoanalyst about past incidents and events. The patient is peeling off layer after layer of experience stretching over a lifetime, with the support, understanding, and guidance of the psychoanalyst. As the patient unfolds his life story, he may reach a particular incident or event that may be a root cause of his problem in living a "normal" life. If such an event in his past took place in preverbal infancy or before, he may never be able to recall it. Nevertheless, the psychoanalytic relationship itself, because it involves a high degree of trust and confidence and an opportunity to admit to a sympathetic and understanding listener hidden anxieties and fears, may provide the therapeutic experience that is needed for the patient to decide that he has solved his problem. Though there are various theories of psychotherapy in addition to traditional Freudian psychoanalysis, the processes of therapy are often quite similar. In any case, changing an individual's personality is rarely possible in the short run. After all, it presumes changing the meaning that an individual has assigned to his life experiences. The Neo-Freudian point of view, however, assumes that an individual is amenable to personality change until he dies, though any change must become increasingly difficult as the individual adds layer upon layer of experience as he moves along life's path. Changing the core of an individual's personality within a "reasonable" time may offer little hope of success.
Negotiation
It is a dialogue intended to resolve disputes, to produce an agreement upon courses of action, to bargain for individual or collective advantage, or to craft outcomes to satisfy various interests. It is the primary method of alternative dispute resolution. Negotiation occurs in business, non-profit organizations, and government branches, legal proceedings, among nations and in personal situations such as marriage, divorce, parenting, and everyday life. The study of the subject is called negotiation theory. Professional negotiators are often specialized, such as union negotiators, leverage buyout negotiators, peace negotiators, hostage negotiators, or may work under other titles, such as diplomats, legislators or brokers.
Approaches to negotiation
Negotiation typically manifests itself with a trained negotiator acting on behalf of a particular organization or position. It can be compared to mediation where a neutral third party listens to each side's arguments and attempts to help craft an agreement between the parties. It is also related to arbitration which, as with a legal proceeding, both sides make an argument as to the merits of their "case" and then the arbitrator decides the outcome for both parties. There are many different ways to segment negotiation to gain a greater understanding of the essential parts. One view of negotiation involves three basic elements: process, behaviour and substance. The process refers to how the parties negotiate: the context of the negotiations, the parties to the negotiations, the tactics used by the parties, and the sequence and stages in which all of these play out. Behaviour refers to the relationships among these
parties, the communication between them and the styles they adopt. The substance refers to what the parties negotiate over: the agenda, the issues (positions and - more helpfully interests), the options, and the agreement(s) reached at the end. Another view of negotiation comprises 4 elements: strategy, process and tools, and tactics. Strategy comprises the top level goals - typically including relationship and the final outcome. Processes and tools include the steps that will be followed and the roles taken in both preparing for and negotiating with the other parties. Tactics include more detailed statements and actions and responses to others' statements and actions. Some add to this persuasion and influence, asserting that these have become integral to modern day negotiation success, and so should not be omitted. Skilled negotiators may use a variety of tactics ranging from negotiation hypnosis, to a straight forward presentation of demands or setting of preconditions to more deceptive approaches such as cherry picking. Intimidation and salami tactics may also play a part in swaying the outcome of negotiations. Another negotiation tactic is bad guy/good guy. Bad guy/good guy tactic is when one negotiator acts as a bad guy by using anger and threats. The other negotiator acts as a good guy by being considerate and understanding. The good guy blames the bad guy for all the difficulties while trying to get concessions and agreement from the opponent.
9. Doing this process over several sessions allows both sides to feel that progress is being made, and actually generates better and more polished ideas that both sides can invest in. 10.It is the process of creating something together, rather than the specific proposals, which creates bonding around a shared task and establishes new ways of working together. Each side feels honoured and all can feel that something is being accomplished.
2.
3.
4.
5.
preserving personal relationships. Accommodators are sensitive to the emotional states, body language, and verbal signals of the other parties. They can, however, feel taken advantage of in situations when the other party places little emphasis on the relationship. Avoiding: Individuals who do not like to negotiate and dont do it unless warranted. When negotiating, avoiders tend to defer and dodge the confrontational aspects of negotiating; however, they may be perceived as tactful and diplomatic. Collaborating: Individuals who enjoy negotiations that involve solving tough problems in creative ways. Collaborators are good at using negotiations to understand the concerns and interests of the other parties. They can, however, create problems by transforming simple situations into more complex ones. Competing: Individuals who enjoy negotiations because they present an opportunity to win something. Competitive negotiators have strong instincts for all aspects of negotiating and are often strategic. Because their style can dominate the bargaining process, competitive negotiators often neglect the importance of relationships. Compromising: Individuals who are eager to close the deal by doing what is fair and equal for all parties involved in the negotiation. Compromisers can be useful when there is limited time to complete the deal; however, compromisers often unnecessarily rush the negotiation process and make concessions too quickly.
Emotion in negotiation
Emotions play an important part in the negotiation process, although it is only in recent years that their effect is being studied. Emotions have the potential to play either a positive or negative role in negotiation. During negotiations, the decision as to whether or not to settle rests in part on emotional factors. Negative emotions can cause intense and even irrational behaviour, and can cause conflicts to escalate and negotiations to break down, but may be instrumental in attaining concessions. On the other hand, positive emotions often facilitate reaching an agreement and help to maximize joint gains, but can also be instrumental in attaining concessions. Positive and negative discrete emotions can be strategically displayed to influence task and relational outcomes and may play out differently across cultural boundaries. Affect effect: Dispositional affects affect the various stages of the negotiation process: which strategies are planned to be used, which strategies are actually chosen, the way the other party and his or her intentions are perceived, their willingness to reach an agreement and the final
negotiated outcomes. Positive affectivity (PA) and negative affectivity (NA) of one or more of the negotiating sides can lead to very different outcomes.
Positive affect in negotiation
Even before the negotiation process starts, people in a positive mood have more confidence, and higher tendencies to plan to use a cooperative strategy. During the negotiation, negotiators who are in a positive mood tend to enjoy the interaction more, show less contentious behaviour, use less aggressive tactics and more cooperative strategies. This in turn increases the likelihood that parties will reach their instrumental goals, and enhance the ability to find integrative gains. Indeed, compared with negotiators with negative or natural affectivity, negotiators with positive affectivity reached more agreements and tended to honour those agreements more.[ Those favourable outcomes are due to better decision making processes, such as flexible thinking, creative problem solving, respect for others' perspectives, willingness to take risks and higher confidence. Post negotiation positive affect has beneficial consequences as well. It increases satisfaction with achieved outcome and influences ones desire for future interactions. The PA aroused by reaching an agreement facilitates the dyadic relationship, which result in affective commitment that sets the stage for subsequent interactions. PA also has its drawbacks: it distorts perception of self performance, such that performance is judged to be relatively better than it actually is. Thus, studies involving self reports on achieved outcomes might be biased.
1. Day-to-day / Managerial Negotiations Such types of negotiations are done within the organization and are related to the internal problems in the organization. It is in regards to the working relationship between the groups of employees. Usually, the manager needs to interact with the members at different levels in the organization structure. For conducting the day-to-day business, internally, the superior needs to allot job responsibilities, maintain a flow of information, direct the record keeping and many more activities for smooth functioning. All this requires entering into negotiations with the parties internal to the organization. 2. Commercial Negotiations Such types of negotiations are conducted with external parties. The driving forces behind such negotiations are usually financial gains. They are based on a give-and-take relationship. Commercial negotiations successfully end up into contracts. It relates to foregoing of one resource to get the other. 3. Legal Negotiations These negotiations are usually formal and legally binding. Disputes over precedents can become as significant as the main issue. They are also contractual in nature and relate to gaining legal ground.