text:
Assignment: Project Management Q.1 A). Define a Project and bring out its main characteristics. In your opinion why a project is required ? Ans: A project is an organized program of activities out to reach a defined goal. It is of a non recurring nature with a specified terminal point. It is a package of time bound, scheduled and assembled activities dedicated to the attainment of a specific objective of successful completion of work on time and within the allocated budget. The concept of 'project' means different things to different users, or reflects different frames of reference. Project usually involve a certain degree of innovation and are in contract with 'routine' activities. They are characterized by a beginning (start), and end and usually involve a specific team called the project team. Projects involve risk and are typically constrained by limited resources. Typical projects includes (but are not limited to): - Engineering projects when the objective is to build a new engineered device - Industrial projects when the purpose is to create a new production unit or factory - Construction projects when buildings or civil work is involved - Economic projects also called development projects where land is usually involved - IT projects, often software development projects, but also establishment of a data room - Start-up projects or new ventures involve creation of a new company to exploit an invention or a unique know-how in some field.... Projects have been in existence for centuries, and although they may be in quite different fields, they have numerous methodologies in common that are independent of the field they are dealing with. These methodologies called 'project management' have to do primarily with organization, scheduling, teamwork, communication and management. A broader definition of a Project is as follows. 1. A project involves a single definable purpose, end time or result, usually specified in terms of cost, schedule, and performance requirements. 2. Every project is a unique in that it requires doing something different than was done previously. Even in routine projects such as home construction, variables such as terrain, access, zoning laws, labor market, public services, and local utilities make each project different. A project a one time activity never to be exactly repeated again. 3. Projects are temporary activities. An ad hoc organization of personal, material, and facilities is assembled to accomplish a goal, usually within a scheduled time frame, once the goal is achieved the organization is disbanded or reconfigured to begin work on a new goal. 4. Projects cuts across organizational lines because they need the skills and talents from multiple professions and organizations. Project complexity often arises from the 1 complexity of advanced technology, which creates task inter dependencies that may introduce a new and unique problems. 5. Given that a project differs from what was previously done, it also involves unfamiliarity. It encompasses new technology and for the organization under taking the project, posses significant elements of uncertainty and risk. 6. The organization usually has something at stake when doing a project. The activity may call for special scrutiny or effort because failure would jeopardize the organization or its goals. 7. Finally a project is the process of working to achieve a goal during the process, a project passes through several distinct phases, called the project life cycle. The tasks, people, organizations and other resources expenditure slowly build with each succeeding phase peak and then decline as the project nears completion. The most obvious characteristics of a project is that it has to achieve a particular purpose and this is normally indicated in the projects name. Mumbai-Pune express highway project, Reliance petroleum refinery project, Bharti telecom project, The Hindustan lever compensation survey project, Nagarjuna fertilizers project, The chinnaswamy stadium project, The national sports complex project, The hinduja hospital projects, etc. This distinguishes it form routine activities which are part of an organization's normal business, such as running a payroll, editing a daily news paper or producing another ten thousand of beans, or cars, or motors or bicycles. A project is a job that is done one time. Cooking a meal is one project. A heart surgery is a project. Its most useful to think a project as an instrument of change. When the project is successfully completed, it will have an impact on people's lives by changing their working patterns or by changing their environment. Managing change is clearly different and at times much harder than managing the status quo, and it is for this reason that projects are established to effect such change in a controlled manner. Projects can vary huge both in their subject and in their size. A project can range from putting a man on the moon, to selecting a new coffee making machine. Projects exists in all sorts of different types of business, such as information systems, event management, construction, finance, marketing, industrial research and the local municipal corporation. Or even as personal as building your own house. More ever no two projects are the same. A project to stage this year's filmafare awards contest may look similar ton last year's, but its objective will be different, the circumstances will have changed and it will involve different people. The main characteristics of a project that: 1. Its an instrument of change 2. It has clearly identifiable start and finish 3. It has a specific aim 4. It results in something being delivered. 5. It is unique 6. It is the responsibility of a single person or body 7. It involves cost, resources and time 8. It uses a wide variety of resources and skills 2 Another way ok looking at a project is that 1. It has a start and finish 2. It has a time frame for completion 3. It has a unique one – timeness 4. It has an involvement of several people on a ad-hoc basics 5. It has a limited set of resources 6. It has sequencing of activities and phases. Project could be a national or international, industrial or non industrial, R&D, high technology, conventional technology or low technology projects. In a finer categorization, projects could be further classified as major, medium or mini projects. Again they could be grass – root, expansion or modification projects. Depending on the speed needed for execution, the projects could be categorized as - Normal projects (where adequate time is allowed) - Cash projects (where additional costs are concerned to gain time) - Disaster projects (anything needed to gain allowed) A project could be under taken for one of these needs To acquire balancing resources to correct imbalances in capacity\ To upgrade the technology To replace the used up or worn out assets To expand projections of existing activities To diversify into allied and new lines Projects are two types Defensive projects: These are aimed to strengthen the present position e.g. Product line, technical service, product or process improvement etc. Aggressive projects: These are concerned with giving new ways of service or entering new commercial lines or fields, development of an innovative project or process, or a long range, research oriented program. Examples of projects are: 1. Developing a new product or service 2. Making a change in structure, reorganization of staff in an organization 3. Designing a new vehicle 4. Developing a new or modified information system 5. Launching a new product. Project based management has become the new philosophy through which organization respond to change effectively to develop and exploit markets ahead of their competitors and hence project management is the skill that all managers need in their portfolio, along side more traditional disciplines. 3 Project touch all lives, in working and social environments. Earlier bureaucracies (also known as traditional methods) have been viewed as providing an efficient, stable and certain environment in which to conduct businesses. Change was mistrusted. Managing change was limited to specialist, usually technical functions in an organization, and its introduction was carefully controlled. That has now changed. Change is endemic, brought about by an explosion in the development of technology and communication. Rather than being the preferred style of management, bureaucracies are viewed as restricting an organizations ability to respond to change and thereby to maintain a competitive edge. Product development times and market windows are shrinking, requiring, new products to be introduced quickly and effectively. Organizations must adopt flexible structure to respond to the changing environment *********************************** *********************************** Q.1B). What is the "Project management"? Enumerate the activity levels during various phases of project in an organization. Ans: Project Management is the discipline of planning, organizing, and managing resources to bring about the successful completion of specific project goals and 4 objectives. A project is a finite endeavor—having specific start and completion dates— undertaken to create a unique product or service which brings about beneficial change or added value. This finite characteristic of projects stands in sharp contrast to processes, or operations, which are permanent or semi-permanent functional work to repetitively produce the same product or service. In practice, the management of these two systems is often found to be quite different, and as such requires the development of distinct technical skills and the adoption of separate management philosophy, which is the subject of this article. The primary challenge of project management is to achieve all of the project goals and objectives while adhering to classic project constraints—usually scope, quality, time and budget. The secondary—and more ambitious—challenge is to optimize the allocation and integration of inputs necessary to meet pre-defined objectives. A project is a carefully defined set of activities that use resources (money, people, materials, energy, space, provisions, communication, motivation, etc.) to achieve the project goals and objectives It's the application of skills, knowledge, tools & techniques to meet or exceed stake holder requirement from a project. The tools are to means to an end. The desired end is a successful project that contributes to the business success of the organization as well. Project management is too often thought in terms of discrete tools such as schedules and status reports with a concomitant lack of understanding of its value and corresponding lack of commitment to effective implementation. As a discipline, project management developed from different fields of application including construction, engineering, and defense. In the United States, the forefather of project management is Henry Gantt, called the father of planning and control techniques, who is famously known for his use of the Gantt chart as a project management tool, for being an associate of Frederick Winslow Taylor's theories of scientific management, and for his study of the work and management of Navy ship building. His work is the forerunner to many modern project management tools including the work breakdown structure (WBS) and resource allocation. The 1950s marked the beginning of the modern project management era. Again, in the United States, prior to the 1950s, projects were managed on an ad hoc basis using mostly Gantt Charts, and informal techniques and tools. At that time, two mathematical project scheduling models were developed: (1) the "Program Evaluation and Review Technique" or PERT, developed by Booz-Allen & Hamilton as part of the United States Navy's (in conjunction with the Lockheed Corporation) Polaris missile submarine program and (2) the "Critical Path Method" (CPM) developed in a joint venture by both DuPont Corporation and Remington Rand Corporation for managing plant maintenance projects. These mathematical techniques quickly spread into many private enterprises In 1969, the Project Management Institute (PMI) was formed to serve the interest of the project management industry. The premise of PMI is that the tools and techniques of project management are common even among the widespread application of projects 5 from the software industry to the construction industry. In 1981, the PMI Board of Directors authorized the development of what has become A Guide to the Project Management Body of Knowledge (PMBOK Guide), containing the standards and guidelines of practice that are widely used throughout the profession. The International Project Management Association (IPMA), founded in Europe in 1967, has undergone a similar development and instituted the IPMA Competence Baseline (ICB). The focus of the ICB also begins with knowledge as a foundation, and adds considerations about relevant experience, interpersonal skills, and competence. Both organizations are now participating in the development of an ISO project management standard. Project management has developed quite remarkably over the last 20 years from a systems oriented methodology, through ‗goal-orientation' to project bases management. From a topic in which computers were pre – eminent, to one in which people, interpersonal and inter group relationship predominate. Project management focuses on a project. A project is undertaking that has a beginning and an end is carried out to meet established goals within cost, schedule, and objectives. Project management brings together an optimizes the resources necessary to successfully complete the project. The resources include the skills, talent, and co operative effort of a team of people, facilities, tools, and equipment information, systems, and techniques and money. Project management is composed of several different types of activities such as: 1. Analysis & design of objectives and events 2. Planning the work according to the objectives 3. Assessing and controlling risk (or Risk Management) 4. Estimating resources 5. Allocation of resources 6. Organizing the work 7. Acquiring human and material resources 8. Assigning tasks 9. Directing activities 10. Controlling project execution 11. Tracking and reporting progress (Management information system) 12. Analyzing the results based on the facts achieved 13. Defining the products of the project 14. Forecasting future trends in the project 15. Quality Management 16. Issues management 17. Issue solving 18. Defect prevention 19. Identifying, managing & controlling changes 20. Project closure (and project debrief) 21. Communicating to stakeholders 22. Increasing/ decreasing a company's workers 6 Project objectives define target status at the end of the project, reaching of which is considered necessary for the achievement of planned benefits. They can be formulated as S.M.A.R.T. Specific, Measurable (or at least evaluable) achievement, Achievable (recently Acceptable is used regularly as well), Relevant and Time terminated (bounded). The evaluation (measurement) occurs at the project closure. However a continuous guard on the project progress should be kept by monitoring and evaluating. Project management differs in two significant ways. First, it focuses on a project with infinite life span, whereas departments or other organizational units expect to exist indefinitely. Second, projects frequently need resources on a part time basis, whereas permanent organizations try to utilize resources full time. The sharing of resources frequently leads to conflict and requires skilful negotiation to see that projects get the necessary resources to meet objectives throughout their project life. All projects have some basic underlying structure. What ever be the project, it will develop over four distinct phases. 1. The conceptual and Definition Phase. 2. The planning phase. 3. The implementation or Execution phase. 4. The completion and review phase. Project management means management of all four phases of a projects life cycle to meet the established goals of time, cost and quality. Typical Activity Levels During the Phases of a Project"s Life Defining the Project Planning the Project Implementing the Plan Completing the project 7 A c t v i t y l e v e l Time Keenly observe fro the graph that the time (that should be )taken in conceptualizing defining the project and in planning the project is (and should be) high – this is important to understand for it lays the foundation for the implementation phase and the project will get completed smoothly. The primary reason why many projects have time and cost over runs resulting in poor quality. Unfinished tasks and leave a feeling of being short – changed, disgusted, cheated, leading to litigation and unpleasantness is because they are ill – convinced. The nature of these phases will, of course vary, depending on the type of project. So too will the time taken to go through them, from minutes to years. Typically a project will begin as the result of a report of feasibility study. (The work to undertake the feasibility study may well itself have been run as an individual project). The feasibility study will have defined the problem which is being addressed (e.g. It takes too long to travel from Mumbai to Pune) It may have investigated what the real requirements are (e.g. we need to be able to travel from Mumbai to Pune in less then two hours ). It will have evaluated alternative solutions and recommended a course of action. 1. The conceptual Phase: It includes identifying needs, establishing feasibility, searching for alternatives, preparing proposals, developing basic budgets and naming the starting project team. The conceptual phase of the Project life cycle defines the project, so management can decide to pursue or not. The purpose is to yield the tools, so someone can make an informed decision and envision the project's intent, scope, benefits and costs. There are several tools that can be used to paint the picture for executive management. One of the first items that needs to be completed is to determine what is required, needed, and or desired. This is done with simplified use case modeling. Discover the actors, their 8 functions, and goals. Detail these use cases in simple paragraphs to capture the essence of the case As you are discovering the intended usage of the system, it is a good idea to start a risk list, and how you intend to manage each risk. It's best to identify and start working on risks in the beginning instead of the end. Since no one really refers to the same term in the same manner, another item to ha ve is a glossary. This will help to define terms. In healthcare there are several ways to refer to the same thing. For example the unique number for a patients visit can be either serial number, patient case number, encounter number, account number, and so on. After establishing the use cases at a high level, it is time to create the vision document. This document has many components to capture the intent of the new system. One part details the problem that is at hand in terms of the root cause. Normally for technology business cases, the problem is a business processing problem for which a technology solution can help or eliminate. Another part of the document details the stake holders. This defines who will be affected by the proposed project and how they will be affected. The document also includes a portion which covers the functional requirements of the system. If you think the vision statement just isn't clear enough, sometimes a prototype can help to illustrate the solution. This isn't a defined deliverable, but if you believe it will help to illustrate the point. It may be worth the time to invest. Another deliverable is the implementation plan or software development plan. At this point, it is high level, but it does capture the needed resources, and time for tasks within the project. It's a work breakdown structure with people assigned to the tasks. After there is a clear understanding of the vision of the system is going to be, the next document that emerges is the executive summary. This document provides a high level overview of the key findings and recommendations. It is also summarizes the current situation and the future if enhancements go as planned. Finally the business case takes all of these components, and analyzes them in conjuncture with the total cost of ownership, including both one-time and recurring operational costs. The business case includes the executive summary overview, the risk list, functional requirements, the resource costs, and the vision of the new system. It is probably ideal to have this in a format that can be used for multiple projects so they can be compared to one another. The business case should be the comprehensive document that allows executive management to decide the feasibility of the project. The basic processes of the Project Initiation Phase are: Creation of a Product / Project Description Document. This is an informal, high- level statement describing the characteristics of the product / project / process to be created. Development of Project Feasibility Document. This identifies project constraints, alternatives and related assumptions applied to the end product to be developed. Project feasibility is characterized by four basic components: o Business Problem Description. 9 o Approach Overview to be used to develop. o Potential Solutions of the problem. o Preliminary Recommendations. Development of Project Concept Document. It determines What is to be done? How will it be done? and Why is it to be done? Thus determining the business value achieved after project completion. Creation of Project Charter. Project Charter formally communicates the initiation of the project. It consists of Project Scope, Project Authority and Critical Success Factors. During this phase, Project Team is responsible for the following activities: Conducting Interviews and yellow pad sessions with customers and stakeholders. Conduct research and brainstorming sessions for generating more necessary information. Preparation of Project Feasibility Document, Project Concept Statement and Project Charter. Preparation of other ancillary documents as defined in the organization standards. Some common barriers and problems are faced by Project Managers during the Initiation Phase which hamper the project to get started. Let us have a summarized look at some of the common problems: Project Team Frustration builds up as the project does not seem to get started. There is a Lack of Commitment from the Management and Key Stakeholders. Customer Indecision may arise due to non-visibility of the end product by the customer. Locating the right people can be difficult while assembling the Project Initiation Team. Lack of consensus on Project Objectives can kill the project before it starts. 2. The planning phase: It involves creating schedules, conducting studies and analysis, designing systems, building and testing prototypes, analyzing results, and obtaining approval for production. The effort spent in planning can save countless hours of confusion and rework in the subsequent phases. The purpose of the Project Planning Phase is: Establish Business Requirements. Establish Cost, Schedule, List of Deliverables and Delivery Dates. Establish Resource Plan. Get Management Approval and proceed to next phases. The basic processes of the Project Planning Phase are: 10 Scope Planning. This specifies the in-scope requirements for the project. Preparing the Work Breakdown Structure. This specifies the breakdown of the project into tasks and sub-tasks. Organizational Breakdown Structure. This specifies who all in the organization need to be involved and referred for Project Completion. Resource Planning. This specifies who will do what work at which time of the project. Project Schedule Development. This specifies the entire schedule of the activities detailing their sequence of execution. Budget Planning. This specifies the budgeted cost to be incurred in the completion of the Project. Project Initiation Phase defines a few facilitating processes as well that are required for successful Project Completion. These can be: Procurement Planning. Planning for procurement of all resources (staff and non- staff). Communication Planning. Planning on the communication strategy with all project stakeholders. Quality Planning. Planning for Quality Assurance to be applied to the Project. Risk Management Planning. Charting the risks, contingency plan and mitigation strategies. Configuration Management Planning. Defines how the various project artifacts will get stored. Both the basic processes and facilitating processes produces a Project Plan. During this phase, Project Team is responsible for the following activities: Project Managers are responsible for developing the Project Plan thus ensuring that all the project planning requirements are fulfilled. Functional / Management personnel are responsible ensures that adequate resources are available for the project. Key Stakeholders should approve the Project Plan before moving to the next phase. Project Planning is essential for a project's success. Project Planning helps team members to understand their responsibilities and expectations from them. Project Planning Phase identifies scope, tasks, schedules, risks, quality and staffing needs. 3.The implementation / Execution Phase: It encompasses procuring and implementing systems, verifying performance and modifying systems as required. Project Execution Phase follows the Project Planning Phase and ideally starts once the Project Plan has been approved and base lined. Project Execution is characterized by the actual work on the tasks planned and project Control involves the comparison of the actual performance with the planned performance and taking appropriate corrective action to get the desired output. During this phase, Project Team is responsible for the following activities: Team Members execute the tasks as planned by the Project Manager. 11 Project Manager is responsible for performance measurement which includes finding variances between planned and actual work, cost and schedule. Project manager is responsible for providing Project Status Report to all key stakeholders to provide visibility. All Project Key stakeholders are responsible for the review of the metrics and variances. All Project Key stakeholders are responsible for taking necessary action of the variances thus determined so as to complete the project within time and budget. The basic processes of the Project Execution and Control can be: Project Plan Execution. Review of Metrics and Status Reports. Change Control Process. This defines the procedures to handle the changes that are introduced during Project Execution and Control. The facilitating processes during Project Execution can be: Quality Assurance and Quality Control. Performance Monitoring. Information Distribution or Status Reporting. Project Administration. Risk Monitoring and Control. Scope Control. Schedule and Cost Control. Contract Administration. Project Execution and Control Phase has a direct correlation to project progress and stakeholder's expectations. Even the minor issues, if unnoticed, can cause major impact on cost, schedule and risk and deviate the project from the Project Plan, thus emphasizing the importance for the Project Execution and Control Phase. 4. The completion phase: It includes training operational personal, transferring materials transferring responsibility, releasing resources and reassigning project team members. Project completion Phase is the last phase of the Project Life Cycle. The commencement of the Project Completion Phase is determined by the completion of all Project Objectives and acceptance of the end product by the customer. 12 Project Closure includes the following tasks: Release of the resources, both staff and non-staff, and their redistribution and reallocation to other projects, if needed. Closure of any financial issues like labour, contract etc. Collection and Completion of All Project Records. Archiving of All Project Records. Documenting the Issues faced in the Project and their resolution. This helps other projects to plan for such type of issues in the Project Initiation Phase itself. Recording Lessons Learned and conducting a session with the Project Team on the same. This helps in the productivity improvement of the team and helps identify the dos and donts of the Project. Celebrate the Project Completion. Its party time folks!!! The basic process of the Project Closure Phase involves: Administrative Closure. This is the process of preparation of closure documents and process deliverables. This includes the release and redistribution of the Project Resources. Development of Project Post Implementation Evaluation Report. It includes o Project Sign-Off o Staffing and Skills o Project Organizational Structure o Schedule Management o Cost Management o Quality Management o Configuration Management o Customer Expectations Management o Lessons Learned Lessons Learned form an integral part of the Project Closure Phase. It helps answer the following typical question during Project Closure. Did the delivered product / solution meet the project requirements and objectives? Was the customer satisfied? Was Project Schedule Met? Was the Project completed within Budgeted Cost? Were the risks identified and mitigated? 13 What could be done to improve the process? The outputs from Project Closure Phase provides as a stepping stone to execute the next projects with much more efficiency and control. ********************************* ************************************** Q.5 A). Define the planning in a project? Describe various steps in planning Ans: Planning means listing in detail what is required to successfully complete the project along the critical parameters of quality, time & cost. A key activity for any project process is making decisions. The managers of successful project processes specify the format for how the team will make decisions and who will make them. Such a format sets down guidelines for meetings, for resolving issues, and for communication among team members. Project planning 14 Once the project has been defined and the project process organized, the team must formulate a plan that identifies the specific tasks to be accomplished and a schedule for their completion. Planning projects involves five steps: 1. defining the work breakdown structure 2. diagramming the network 3. developing the schedule 4. analyzing cost-time trade-offs, and 5. Assessing risks. Having ensured to a great degree of confidence in the conceptual phase that the project is feasible we shall now proceed to turn the concepts into reality. Hence you will appreciate that the planning of project execution. This term ―project execution ― includes planning monitoring and control. The monitoring and control activities will be taken up in the implementation phase of the project. All too often when people think of project planning, they perceive the use of only techniques and concepts such as PERT & CPM. These techniques are important to use in the development of a project schedule How ever project planning includes a wider scope of activity. Project planning also deals with the organizational design to support the project as well as the information systems and control systems which are used to model, evaluate and reallocate resources as will be required during the execution of the project. The basis for planning is the clarity in the scope, time, cost and quality, goals/parameters which have been established in the conceptual phase. Project planning begins with the end result – the three goals – and works backward to ensure that the goals are achieved. Planning steps: Establish the project objective Choose the basic strategy for achieving the objective Break the project down into sub units or steps Determine the performance standard for each sub units Determine how much time is required to complete each sub unit Determine the proper sequence for completing the sub units and aggregate this information's in to a schedule for the total project Design the cost of each sub units and aggregate cost in to the project budget Design the necessary staff organization, including number and kind of positions, and the duties and responsibilities of each Determine what training, if any, is required for project team members. Develop the necessary policies and procedures The key to a successful project is in the planning. Creating a project plan is the first thing you should do when undertaking any kind of project. 15 Often project planning is ignored in favour of getting on with the work. However, many people fail to realize the value of a project plan in saving time, money and many problems Project Goals: A project is successful when the needs of the stakeholders have been met. A stakeholder is anybody directly or indirectly impacted by the project. As a first step it is important to identify the stakeholders in your project. It is not always easy to identify the stakeholders of a project, particularly those impacted indirectly. Examples of stakeholders are: The project sponsor The customer who receives the deliverables The users of the project outputs The project manager and project team Once you understand who the stakeholders are, the next step is to establish their needs. The best way to do this is by conducting stakeholder interviews. Take time during the interviews to draw out the true needs that create real benefits. Often stakeholders will talk about needs that aren't relevant and don't deliver benefits. These can be recorded and set as a low priority. The next step once you have conducted all the interviews and have a comprehensive list of needs is to prioritise them. From the prioritised list create a set of goals that can be easily measured. A technique for doing this is to review them against the SMART principle. This way it will be easy to know when a goal has been achieved. Once you have established a clear set of goals they should be recorded in the project plan. It can be useful to also include the needs and expectations of your stakeholders. This is the most difficult part of the planning process completed. It's time to move on and look at the project deliverables Project deliverables: Using the goals you have defined in step 1, create a list of things the project needs to deliver in order to meet those goals. Specify when and how each item must be delivered. Add the deliverables to the project plan with an estimated delivery date. More accurate delivery dates will be established during the scheduling phase, which is next. Project Schedule: Create a list of tasks that need to be carried out for each deliverable For each task identify the following: The amount of effort (hours or days) required to complete the task The resource who will carryout the task 16 Once you have established the amount of effort for each task, you can workout the effort required for each deliverable and an accurate delivery date. Update your deliverables section with the more accurate delivery dates. At this point in the planning you could choose to use a software package such as Microsoft Project to create your project schedule. Alternatively use one of the many free templates available. Input all of the deliverables, tasks, durations and the resources who will complete each task. A common problem discovered at this point is when a project has an imposed delivery deadline from the sponsor that is not realistic based on your estimates. If you discover that this is the case you must contact the sponsor immediately. The options you have in this situation are: Renegotiate the deadline (project delay) Employ additional resources (increased cost) Reduce the scope of the project (less delivered) Use the project schedule to justify pursuing one of these options. Supporting plans: This section deals with plans you should create as part of the planning process. These can be included directly in the plan. Human resources:Identify by name the individuals and organisations with a leading role in the project. For each describe their roles and responsibilities on the project. Next, describe the number and type of people needed to carryout the project. For each resource detail start dates, estimated duration and the method you will use for obtaining them. Communication Plan: Create a document showing who needs to be kept informed about the project and how they will receive the information. The most common mechanism is a weekly/monthly progress report, describing how the project is performing, milestones achieved and work planned for the next period Risk management plan: Risk management is an important part of project management. Although often overlooked, it is important to identify as many risks to your project as possible and be prepared if something bad happens. Here are some examples of common project risks: Time and cost estimates too optimistic Customer review and feedback cycle too slow Unexpected budget cuts Unclear roles and responsibilities Stakeholder input is not sought or their needs are not properly understood Stakeholders changing requirements after the project has started Stakeholders adding new requirements after the project has started 17 Poor communication resulting in misunderstandings, quality problems and rework Lack of resource commitment Risks can be tracked using a simple risk log. Add each risk you have identified to your risk log and write down what you will do in the event it occurs and what you will do to prevent it from occurring. Review your risk log on a regular basis adding new risks as they occur during the life of the project. Remember, when risks are ignored they don't go away. 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. 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. PLANNING THE QUALITY PARAMETER. Planning for quality requires attention to detail. The goal of quality planning is to assure that the output of the project will perform that it will do what it is suppose to do. The quality plan is also establishes the criteria of performance by which the project output will be measured when it is completed. In planning the quality parameter include specifications for the quality and types of materials to be used, the performances standards to be meet and the means of verifying quality such as testing inspection. Two techniques facilitate planning for quality. Work breakdown structure and project specifications. Creating a WBS structure: A WBS is the starting place for planning all three parameters of a project, quality, cost, and time. It is a technique based on dividing a project in to sub units of work packages because all elements required to complete the project are identified, you reduce the chance of neglecting or overlooking an essential steps. The work of a project is devolved thru increasing levels of details. A work break down structure is typically constructed with two or three levels of detail, although more levels may be required for vary complex projects. Start by identifying logical sub divisions of the projects, then break each of these down further. As you construct a work breakdown structure keep in mind that the goal is to 18 identify a unit of work that is discrete and that advance that project toward its completion. The WBS is a key document in the project and forms the basis of much of the subsequent work in planning, setting budget, cost control, defining the organization, assigning responsibilities and delegating work in coherent packages / sub units. Breaking project down in to manageable units is the key to being able to control it. Through the process of gradually dividing the pieces of work up into something more manageable, we will finally arrive at discrete pieces of work which we will be able to estimate to plan and control. We are also able to study each work package / sub unit and assess the level of risk attached, in order to determine how to manage the risk. WBS enables us to assess the work required to produce each sub units the required to assemble and commission the project from each sub units Project specifications: From the work break down structure, specification can be written for each sub units of the project. Specifications include all relevant requirements to meet the projects quality parameters materials to be used standards to be meet, test to be performed, etc. use extreme care in writing specifications because they became the controlling factor in meeting project performance standard and directly affect both budget and schedule. Add 4 offices to building#7 Exterior Foundation Frame &install, windows 19 Roof Layout Form Pour & finish install siding Paint interior finish Heating/air Electrical conditioning Paint fixtures Electrical Floor covering Cleanup Insulate Dry well Doors & trim Planning the parameter: The objective when planning the time dimension is to determine the shortest time necessary to complete the project. Begin with the work break down structure and determine the time required to complete each subunit. Next, determine in what sequence subunits must be completed, and which ones may be under way at the same time. From this analysis, you will have determined three most significant time elements. The duration of each step The earliest time at which a step may be started The latest time at which a step must be started Planning the time parameter can only be done by people who have experience with the same or similar activities. If you personally do not know how long it takes to do something, you will need to rely on someone else who does have requisite experience 20 Many project managers find it realistic to estimate time intervals as a range rather than as a precise amount. Another way to deal with the lack of precision in estimating time is to use a commonly accepted formula for the task. Or, if you are working with a mathematical model, you can determine the probability of the work being completed within the estimating time by calculating a standard deviation of the time estimate. Using a mathematical model of estimate time Estimating time Tm = the most probable time To = the optimistic time within which only 1% of similar projects are completed Tp = the pessimistic time within which 99% of similar projects are completed Te = the calculated time estimate To + 4Tm +Tp Te = ------------------- 6 δ = standard deviation δ = Tp – To ------------ 6 68.26% of the time the work will be completed within the range of Te+/- standard deviation 95.4% of the time the work will be completed within the range of Te+/-2 standard devations 99.73% of the time work will be completed within the range of Te+/- standard devations. PROJECT SCHEDULING MODELS There are various methods for scheduling projects. Now we look at two simple project scheduling models-Gantt charting and the Program Evaluation and Review Technique (PERT). Both are schematic models, but PERT also has some mathematical model adaptations. Let"s start with:- GANTT CHARTS A Gantt chart is a bar chart shows the relationship of activities over time. Following table gives the symbols often used in a Gantt chart. An open bracket indicates the scheduled start of the activity, and a closing bracket indicates the scheduled completion. A heavy line indicates the currently completed portion of the activity. A caret at the top of the chart indicates current time. 21 Gantt chart symbols Symbol Meaning ( Start of an activity ] End of an activity H Actual progress of the activity v Point in time where the project is now NETWORK MODELING It allows us to address project scheduling a little more formally than we can with the Gantt chart. Although network models are based on rigorous theory and precise definitions, we discuss only a few terms and concepts here. Each activity is symbolized by an arc, an arrowed line segment (or, simply, an arrow). Both the beginning and the ending of each activity are symbolized by a node, a circle at the beginning or ending of the arrow. Joint nodes represent the precedence relationships of the activities: An arc whose ending node is the beginning node of a second arc represents an activity that must precede the second activity. In the following figure there are six nodes, numbered 1-6. The arcs are named by their beginning and ending nodes:- arc 1-2, 1-3, 2-4, 2-5, 4-6, and 5-6. The lengths of the arcs are of no significance. Nodes may be lettered, rather than numbered, or arcs as well as nodes may be numbered or lettered. Since arc 1-3 in the figure ends at the node that begins arc 3-6, arc 1-3 represents an activity that must precede activity 3-6. In talking about networks, we may refer to arc 1-2, for example, interchangeably with activity 1-2. Well my friends, all of you must have a fair bit of an idea of PROGRAM EVALUATION AND REVIEW TECHNIQUE (PERT), that you might have covered under quantitative techniques or operations research papers during the earlier semesters However I would be failing in my duty if I do not take it up again during the current discussion. Indeed such is importance of this technique that universally almost all projects are evaluated on the basis of this method. Here we go. NETWORK MODELING Network modeling allows us to address project scheduling a little more formally than we can with the Gantt chart. Although network models are based on rigorous theory and precise definitions we discuss only a few terms & concepts here. Advantages of planning: 1. we will have more realistic plan one that gives a more accurate picture of what will happen as the project progress. 22 2. we will have better able to anticipate what needs to happen next 3. will know where to concentrate your attention to be sure that the project stays on schedule and within budget. 4. will be able to anticipate bottlenecks and other coordination problems before they occur, so that you can take action to correct a delay before it becomes severe. 5. you will have valuable tool to enhance co ordination and communication among the project team members. 6. you will have a toll to build commitment because it publicly identifies responsibilities and deadlines and creates an awareness of interdependencies. 7. you will have a tool that leads to completion of projects on time, within budget and according to quality standards. ****************************** ***************************************** Q.5 B). Explain how programmable evaluation and review technique [PERT] is used in project management, support your answer with suitable diagram. Ans: PERT, the Project Evaluation and Review Technique, is a network-based aid for planning and scheduling the many interrelated tasks in a large and complex project. It was developed during the design and construction of the Polaris submarine in the USA in the 1950s, which was one of the most complex tasks ever attempted at the time. Nowadays PERT techniques are routinely used in any large project such as software development, building construction, etc. Supporting software such as Microsoft Project, 23 among others, is readily available. It may seem odd that PERT appears in a book on optimization, but it is frequently necessary to optimize time and resource constrained systems, and the basic ideas of PERT help to organize such an optimization. PERT uses a network representation to capture the precedence or parallel relationships among the tasks in the project. As an example of a precedence relationship, the frame of a house must first be constructed before the roof can go on. On the other hand, some activities can happen in parallel: the electrical system can be installed by one crew at the same time as the plumbing system is installed by a second crew. The PERT formalism has these elements and rules: • Directed arcs represent activities, each of which has a specified duration. This is the ―activity on arc‖ formalism; there is also a less-common ―activity on node‖ formalism. Note that activities are considered to be uninterruptible once started. • Nodes are events or points in time. • The activities (arcs) leaving a node cannot begin until all of the activities (arcs) entering a node are completed. This is how precedence is shown. You can also think of the node as enforcing a rendezvous: no-one can leave until everyone has arrived. • There is a single starting node which has only outflow arcs, and a single ending node that has only inflow arcs. • There are no cycles in the network. You can see the difficulty here. If an outflow activity cannot begin until all of the inflow activities have been completed, a cycle means that the system can never get started! BOOK DATA TO BE WRITTEN… Consider the example below given diagram . Perhaps the pouring of the concrete foundation (activity A-B), happens at the same time as the pre-assembly of the roof trusses (activity A-D). However, the finalization of the roof (activity D-E), cannot begin until both A-D and B-D (assembly of the house frame), are done. Of course B-D cannot start until the concrete foundation has been poured (A-B). All of this precedence and parallelism information is neatly captured in the PERT diagram. There are two major questions about any project: • What is the shortest time for completion of the project? Which activities must be completed on time in order for the project to finish in the 24 shortest possible time? These activities constitute the critical path through the PERT diagram. The process of finding the critical path answers the first question as well as the second. Of course we need to know how long each individual activity will take in order to answer these questions. This is why the arcs in diagram are labeled with numbers: the numbers show the amount of time that each activity is expected to take (in days, let's say). The critical path is of great interest to project managers. The activities on the critical path are the ones which absolutely must be done on time in order for the whole project to complete on time. If any of the activities on the critical path are late, then the entire project will finish late! For this reason, the critical path activities receive the greatest attention from management. The non-critical activities have some leeway to be late without affecting the overall project completion time. The following steps find the critical path and calculate other useful information about the project. Step 1. Make a forward pass through the diagram, calculating the earliest time (TE) for each event (node). In other words, what is the earliest time at which all of the activities entering a node will have finished? To find TE, look at all of the activities which enter a node. TE is the latest of the arrival times for entering arcs, i.e. TE = max [(TE of node at tail of arc) + (arc duration)] over all of the entering arcs. By definition, TE of the starting node is zero. Step 2. Make a backward pass through the diagram, calculating the latest time (TL) for each event (node). In other words, what is the latest time that the outflow activities can begin without causing a late arrival at the next node for one of those activities? To find TL, look at all of the activities which exit a node. TL is the earliest of the leaving times for the exiting arcs, i.e. TL = min [(TL of node at head of arc) − (arc duration)] over all of the exiting arcs. By definition, the TL of the ending node equals its TE. Step 3. Calculate the node slack time (SN) for each node (event). This is the amount of time by which an event could be adjusted later than its TE without causing problems downstream. SN = TL − TE for each node. 9 D F 3 7 10 3 3 E H A 5 8 7 5 4 B G C 25 4 5 Step 4. Calculate the total arc slack time (SA) for each arc (activity). This is the amount of time by which an activity could be adjusted later than the TE of the node at its tail with causing problems later. SA = (TL of node at arc tail) − (TE of node at arc head) − (arc duration). Step 5. The critical path connects the nodes at which SN = 0 via the arcs at which SA = 0. It should be no surprise that the critical path connects the nodes and arcs which have no slack. If there is slack, then the activity does not need to be done on time, which is exactly the opposite definition of the critical path! As an example, let's find the critical path for the PERT diagram in Figure 11.1. Note that there is an implied order in which the TE's can be calculated in Step 1. For example, the TE of node D cannot be found until the TE of node B is known. The starting node in Figure 11.1 is node A, and by definition the TE of the starting node is 0. To calculate TE at a node, we need to know the TE of the node at the tail of every entering arc, so we can next only calculate the TE of node B. This is simple since there is only one inflow arc, from node A, so TE(B) = TE(A) + (duration of A-B) = 0 + 4 = 4. The complete set of TE calculations follows: TE(A) = Starting node = 0 TE(B) = TE(A)+(duration A-B) = 0+4 = 4 TE(D) = max{TE(A)+(duration A-D), TE(B)+(duration B-D)} = max{0+4, 4+5} = 9 TE(C) = TE(B)+(duration B-C) = 4+5 = 9 TE(E) = max{TE(D)+(duration D-E), TE(B)+(duration B-E), TE(C)+(duration C-E)} = max{9+7, 4+8, 9+6} = 16 TE(F) = max{TE(D)+(duration D-F), TE(E)+(duration E-F)} = max{9+9, 16+10} = 26 TE(G) = max{TE(E)+(duration E-G), TE(C)+(duration C-G)} = max{16+7, 9+4} = 23 TE(H) = max{TE(F)+(duration F-H), TE(E)+(duration E-H), TE(G)+(duration G-H)} = max{26+3, 16+3, 23+5} = 29 The shortest time in which the project can be completed is now known: it is the same as the TE of the ending node, node H, i.e. 29 days. But we still need to complete the remaining 4 steps of the algorithm to positively identify the critical path. The backwards pass in Step 2 begins with the ending node H. By definition, the TL of the ending node is equal to its TE so TE(H) = 29. This makes sense: otherwise the whole project would be pushed later! As for the forward pass, there is an implied order in which the node TL values can be found, determined by the outflow arcs for which TL is known. The complete set of calculations follows. TL(H) = ending node = TE(H) = 29 TL(F) = TL(H)−(duration F-H) = 29−3 = 26 TL(G) = TL(H)−(duration G-H) = 29−5 = 24 TL(E) = min{TL(F)−(duration E-F), TL(H)−(duration E-H), TL(G)−(duration E-G)} = min{26−10, 29−3, 24−7} = 16 TL(C) = min{TL(E)−(duration C-E), TL(G)−(duration C-G)} = min{16−6, 24−4} = 10 TL(D) = min{TL(F)−(duration D-F), TL(E)−(duration D-E)} = min{26−9, 16−7} = 9 TL(B) = min{TL(D)−(duration B-D), TL(E)−(duration B-E), TL(C)−(duration B-C)} = min{9−5, 16−8, 10−5} = 4 26 TL(A) = min{TL(D)−(duration A-D), TL(B)−(duration A-B)} = min{9−3, 4−4} = 0 It's no surprise that TL of the starting node is 0. If it wasn't it would mean that we could start the whole project late and yet still finish on time! In Step 3 we find the node slack time (SN) for each node (event) as shown below: Node A B C D E F G H SN 0 0 1 0 0 0 1 0 This small PERT diagram is quite tight: only two of the nodes have nonzero slack. Larger diagrams with many parallel activities often have much more slack in the nodes. In Step 4 we find total arc slack time (SA) for each arc (activity) as shown below. Arc AB AD BC BD BE CE CG DE DF EF EG EH FH GH SA 0 6 1 0 4 1 11 0 8 0 1 10 0 1 The arcs have quite a bit more slack time than the nodes in this small example. Later we will see how this slack can be put to good use in adjusting resource demands. Finally, in Step 5, we find the critical path by linking the nodes having no slack via the arcs having no slack. Figure 11.2 shows the critical path for our example PERT diagram. The nodes and arcs having no slack are shown in boldface. If you've been watching closely, you might have noticed that the critical path through the PERT diagram is actually the longest path through the network. If you only needed the critical path and its length, it's easy to convert Dijkstra's shortest route algorithm to a longest route algorithm to find it. Sometimes a situation arises in which one activity must precede two different events. How can this happen when a single arc can terminate only at a single event node? The solution lies in the use of dummy arcs which have a duration of zero. Dummy arcs are normally shown as dashed lines, as in the diagram fragment in which activity A-B is the immediate predecessor of both event C and event D. 9 D F 3 7 10 3 3 E H A 5 8 7 5 4 B 4 G C 5 Determination of the critical path and hence of the duration of the entire project obviously depends very heavily on accurately assessing the duration of each individual activity. How is this done in practice? There are two main approaches: direct estimates, and the three-estimate method. In direct estimation, a single number is stated directly, perhaps based on long experience with similar projects. In the three-estimate approach, 3 estimates with specific properties are used in a weighted average. m is the most likely value, obtained in a manner similar to the direct estimate. a is an optimistic estimate, i.e. the time needed if everything goes just right (the weather is good, building materials arrive on time, crew is on time). Finally 27 b is the pessimistic estimate, i.e. the time needed if everything goes wrong (it's raining, materials are late, crew books off sick, etc.). Given these three estimates, the final uration is set as (a+4m+b)/6. Probabilistic PERT Estimating is an inexact art, so we expect that our initial duration estimates have some error in them. What we would really like to know is how much this error is going to affect our estimate of the total project duration. Fortunately, with a few assumptions and very little extra work we can make some judgments about the likely amount of variation in the total project time. To do this we start with the three-estimate approach to estimating the activity durations. Next we make the following assumptions: • The activity durations fit a Beta distribution. • The range from a to b in the three-estimate approach covers 6 standard deviations. • The activity durations are statistically independent. • The critical path now means the path that has the longest expected value of total project time. • The overall project duration has a normal distribution. A 5 B 0 0 C D TO BE CONTD….. ******************************** *************************************** 28 Q.6 What do you Understand by implementation? Explain various actions carried out in a project in this stage? Ans: In the project life cycle, we now come to the implementation phase. We have spent a great deal of effort and have gone in to great details during the conceptual and planning phases. This time spent and attention to detail will definitely pave the way for the smooth implementation phase. Although planning and organizing have been intensive activities for the project manager, it is controlling the project which consumes the most time and requires a great deal of skill. 29 Controlling project is about ensuring that the three project objectives are met, specifically those of time, cost and quality. Control is the process of monitoring, evaluating and comparing planned results with actual results to determined the status of the project, cost, schedule and technical performance objectives. Control is the constraining of resources through corrective action to confirm to a project plan of action. Monitoring and control are universal activities indispensable to effective execution. Control is a fact finding and remedial action process to facilitate meeting the project objectives and goals. The primary purpose is not to determine what has happened, but rather to predict what may happen in the future if present condition continue & there is no change in the management of the project. Control is made up of two parts. Monitoring and then taking action. Implementation is defined as ―putting the plan in to action‖. The English dictionary has interesting definitions. Implement: To bring about / carry out/ complete / effect / enforces / execute / fulfill / perform / out into action / realize / carry into effect. Implementation: Accomplishment What happens in the implementation stage: During the implementation phase, the project manager coordinates all the elements of a project. This involves a number of responsibilities. Controlling work in progress to see that it is carried out according to plan, providing feedback to those working on the project, negotiation for materials, supplies, and services, and resolving differences among those involved with project. These responsibilities require a variety of skills. This section presents took and techniques to help project managers during the implementation stage. Key duties during implementation controlling work in progresses. Providing feed back Negotiations for materials, supplies and services Resolving difference 1. Controlling Projects monitoring Why do we control? Managing change 30 The awkward things about projects is that they never quite turn out as you expect them to. No matter how through your planning no matter how much senior management commitment you have solicited, no matter how well organized you have been… things go wrong. Factors which change projects The planning assumptions may have been wrong there may more to do then you anticipated it might be harder than you anticipated resources you depend on might not be a available The requirement may change (very common) The deadline may change (usually earlier) The budget may be cut The priority of the project in the mind of senior management might change Barriers / resistance to change. People make mistakes (usually large ones) Acts of God All of these things and many more will conspire against your project and try to force it further and further away from achieving its objectives. Naturally, you don't know what will go wrong at the outset of the project, all though you will have allowed yourself a certain amount of contingency in terms of time and budget, simply because you know that something will go wrong. By maintaining a high degree of control on the project and this must extend beyond the le to immediate project team you will be able to spot these potential dangers early enough to be able to do something about them. Controlling projects is about identifying problems, working out what needs to be done to ameliorate them, and then doing it. It is important that controls is seen by the project team in this positive light. There is always a tendency to view control as merely an enormous chore for all those involved, whose only purpose is to give the project manager an opportunity to blame the guilty. It should be portrayed as a process which is actually designed to help project staff in the work they do, to provide a mechanism by which they can flag problems they are suffering with and through which solutions can be sought and implemented. What do we control? We control divisions from the duration of the activities listed in the gantt bar chart or PERT network to ensure that there is no time over run. We closely monitor the critical path giving those activities on the critical path greater attention to see that there is no slippage. Experience has shown that if there is no time over run it is unlucky that there will be cost over run. We control divisions from the cost budget for each of the sub units of the work break down structure to ensure that there is no cost over run. 31 We control division from the quality standards established the customer expectations which from the basis for the award of the project. The quality standards for each sub unit from the basis for judgment. Time:-- During the planning phase we will have established dates for major milestones on the projects. We have, therefore, a great interest in ensuring that these are adhered to. We also defined start and end dates for all the activities which contributes to the attaining of this mile stones. These also should be adhered to. How ever it is of little use to us if we get to our first major mile stone date and discover that we have not made it. By recording basic data about the progress of tasks we can derive considerable amount of information to assist us in its interpretation. Time Related progress data: Status (future started or complete) Elapsed time spent Days efforts spent Estimate of days effort to go Estimate of elapsed time to go We must choose carefully what is the minimum information you need to able to answer the following questions. * have I made the progress I planned? * Will I finish when I through I would? When determining progresses it is important to remember that if you have spent half the time that you planned on a task it does not necessarily mean ―that you are half way through it‖. The most useful piece of information you can acquire about a task is how much longer (in terms of both effort and elapse time) it will take to complete. By comparing this against your outstanding planned time to complete you can. Easily see if the task has slipped. Cost: By monitoring cost the project manager will glean vital information abut progresses and the value of the work done cost can be used as a measure of progresses. Remember senior management tend to be particularly sensitive to cost, specially when things go wrong. The degree of sophistication applied to the control of cost various according to the type and size of project, it can be simple measurement of the number of people working on it, to complex accounting and control systems. For most projects, how ever it is more important to have a feel for the size of the cost then to have detailed analysis describing how every penny was spent. Some planning tool will go a long way to driving statistic but you should always remember that the 32 quality of what you get out is directly proportional to the quality of what you put in. The most important statistics are Estimated at completion (EAC) What the total cost of the project will be as calculated by looking at the plan as its stands i.e. cost incurred to the date plus scheduled cost. Budgeted at completion (BAC) The total cost derived from the plan any work begin. Actual cost of work performed (ACWP) The amount of money spent so far Budget cost of wok performed (BCWP) What you should have spent to get this far i.e the total budget cost for the project multiplied by the prestige percentage achieved. Budgeted cost of work scheduled (BCWS) What you should have spent by this point in time, that it the total budgeted cost for the project multiplied by the % of elapsed time past. We may appear to be suffering from information over load, but by presenting costs in this way as a measure of performance, we can use the figures to make estimates of future spend, effort and time. Project cost = BAC (ACWP/BCWP) Earned value index = BCWP/ACWP Cost efficiency = (BCWP/BAC)* (EAC/ACWP) Projected duration = elapsed duration + (to go duration/cost efficiency) Cost at completion 1. Cost to complete must be re estimated monthly on in progresses tasks and quarterly on all incomplete tasks. Depending on duration of the project, the frequency could be short end, but not lengthened. 2. Cost at completion must be for cast at least monthly at the task, intermediate and total project levels. Cost at completion is the sum of i) Cost of all completed tasks. ii) Cost to date + estimate to complete all in progresses tasks and iii) Current estimate to complete all future tasks. 33 Partial cost and control report Current month Cumulative to date Cost at completion Actvitiy Latest description Variance Variance revised WBS cost Area - B Civil Budgeted Actual over Budgeted Actual over estimate Over % of code construction B cost cost (under) cost cost (under) Budget (projected) (under) budget 02.01.01 Earth work 0 0 0 4000 6000 2000 4000 6000 2000 50% 02.01.01.01 Excavation 0 0 0 2000 3500 1500 2000 3500 1500 75 02.01.01.02 Backfill 0 0 0 2000 2500 500 2000 2500 500 25 Foundation& 02.01.02 structure 0 500 500 40000 44000 4000 40000 44000 4000 10 02.01.02.01 fromwork 0 0 0 16000 18000 2000 16000 18000 2000 13 02.01.02.02 Rebar 0 0 0 12000 13000 1000 12000 13000 1000 8 02.01.02.03 Embedments 0 0 0 2000 2000 0 2000 2000 0 0 02.01.02.04 Concrete 0 500 500 10000 11000 1000 10000 11000 1000 10 02.01.03 Architecural 1500 1200 [300] 4000 3000 [1000] 4000 3000 [400] [10] Finishes Civil 2.01 construction 1500 1700 200 48000 53000 5000 48000 53600 5000 5 Causes of cost problems: 1. Unrealistic, low original estimate, bids and budgets. 2. Management decisions to reduce bid price and budgets to meet competitive pressure or offset assumed padded estimates. 3. Uncontrolled, unnoticed increase in scope of work. 4. Extra scope work on proposals for change or extension, or in response to customer or managements enquires. 5. unforeseen technical difficulties. 6. scheduled delays that require overtime or other added cost to recover, or change idle labour to project. 7. inadequate cost budgeting, reporting and control practice and procedures Quality: Unlike time and cost, where we have units of measure such as days and rupees, the yardstick by which we measure quality is not so easy to find. Because it is difficult, it is often neglected. The setting of quality standards involves having a clear specification of what the end product of the task should be, including what ever quality factors may be appropriate. The emphasis on quality control must therefore be on ensuring that quality is built in to the process land not applied afterwards. Systematic reviews, walk throughs and inspections are valuable and necessary activities for all deliverables and this should be planned in to the process. 34 Quality control is an important aspect particularly in manufacturing process but a pre requisite for it is quality assurance establishing the right environment for quality to flourish. Quality should be injected in to the process from the outset. A common way of doing this is to develop a quality plan, which expresses your objectives for quality and how you will set about ensuring it. This then becomes a key project document which is maintained to show when and how quality targets have been achieved, and any deviations from the quality plan. The quality plan: Define working methods and procedures Define standards for deliverables Define standards for supervision and review Define project check points Define user involvement A commitment to quality from the project team is vital to achieving it. It should be implicated amongst the staff as being an essential, not a luxury and ingrained in the culture of the project. Progresses reporting: Conducting interim progresses reviews Interim progresses reviews typically occur on a fixed time schedule, such as daily or weekly. They may also occur when some problem in performance is observed or at the completion of a significant step toward the accomplishment of the project. Three topics are usually on the agenda. review of progresses against plan review of problems encountered and how they will handled Review of anticipated problems with proposed plans for handling them Monitoring of time cost and quality requires the project manager to have detailed knowledge of the status of all the task currently being executed. There are number of ways in which this information can be gathered. Progresses reporting: Progresses report One to one progresses meeting Group progresses meetings Wondering about You should use all four of these techniques as each will enable you to discover different pieces of information or different perspectives on the same information. Mile stone charts: A mile stone chart presents a board, brush, pictures of a project scheduled and control dates. It list those key events that are dearly verifiable by others or 35 that require approval before the project can proceed. If this is done correctly, a project will not have many mile stones. Because of this lack of detail, a milestone chart is not very helpful during the planning phase when more information is required. How ever it is particularly useful in the implementation phase because it provides a concise summary of the progresses of the project. Area - B project mile stone status Date : 10th August Scheduled Description of event time Actual date completed Delay (days) complete earth work B 30-Mar 15th Apr 15 Complete main foundation concrete 15th Apr 30th Apr 15 Equipment B received on site 15th Apr 15th May 30 Complete equipment B foundation 30th May 30th May 0 Piping B installation 20% complete 31st July ---- -30 th Install main transformer 15 Aug - - Start area B pre operational tests 1st Oct - - Complete electro mechanical B 1st Dec - - Complete test begin operations 30th Dec - - Progress reports: The production of progress reports should be carried out on a strictly regular basis by all those who are responsible for any planned activity. If this means that every single member of staff reports progress then so be it. The project manager does not necessarily have to read them all they can be summarized by team leaders, junior managers and so on, to give overall progress reports for activities higher up the hierarchy on the WBS. We have already mentioned that the whole area of control should be portrayed as genuinely being in the interests of the project staff. Progress report should therefore, be as easy to complete as possible. A standardized form which shows the work done in a period, deviation from the plan, work for the next period, and any known problems, is ideal. An example is shown below. WEEKLY REPORT For -------------------- Project Team Week pending------------------------ Forcast completion date CURRENT LAST TARGET Activities completed this Critical Path (Y/N) 36 week ▪ CP ▪ ▪ ▪ Activities in progress Target completion CP (Y/N) ▪ ▪ ▪ ▪ Activities planned for next week Target completion CP (Y/N) ▪ ▪ ▪ ▪ Changes to plan To be resolved ………………. Project Leader You will notice that the report calls for the writer to make comparison with the project plan and to reconsider the estimates to complete the work. Although you may often see it, asking people to give a percentage complete figure is usually less than satisfactory as it is only too easy to give a figure which reflects the percentage of planned time spent. By forcing staff to activity reconsider how more time is really needed you will get a much more accurate picture of the genuine progress. Progress report is not, however, all one way. The project manager himself will be expected to report a number of, other people / bodies. Progress reports: From project team to project manager (many repots, weekly) From external suppliers to project manager (many reports, weekly) From project manager to project team (one report, weekly) From project manager to senior user management (one report monthly) Like all reports, the frequency , style, amount of detail and actual content will be varied to suit the particular audience. Remembering that one of the key roles of the project manager as a communicator is to maintain commitment to the project, it is often a good idea to give some of these reports (especially those to senior management ) in the form of presentations. One to one progress meetings: 37 Meetings with the individual members of the project team, although time consuming, are probably the best means of assessing progress. It is important, however these meetings are well structured and reasonably formalized. The purpose of the meeting is to assess progress and discuss any problems it is not to have a generalized chat about how things are going. The best vehicle for structuring the meeting is the progress report. Each activity on it should be discussed – even if there are no problems associated with it. Particular problems which have been identified on the progress report should be discussed in more detail in order to gain a real understanding of why the problem has occurred and what can be done about it. Adopting right style for the meeting is crucial to their effectiveness. There should be no atmosphere of blame or recrimination. Staff should be encouraged to approach the meetings with an honest and open attitude and not in fear that they are to be hauled over the coals. Praise should be lavished generously when things have gone well. One to one meetings are also the best opportunity for the project manager to inspect quality himself. It is very easy for tasks to be 95% complete when you are told that they are finished reports/the user's sign off / the testing certificate or whatever. There is no substitute for seeing it yourself. During one to one progress meetings, the team member will also be more relaxed and place his / her difficulties more openly then in a group / project meeting at which he / she may be embarrassed to blame a fellow member on whom he / she is dependent upon for an input. Group project progress meetings: Meetings of the entire project team (or groups within it if the project is too large to bring it all together regularly) are useful but need to be carefully managed. Their primary purpose is to ensure that all parts of the project are aware of what other parts are doing, and any issues that have arisen. Whilst it is important that team spirit is fostered, you should always be aware that people will show greater reluctance to disclose problems in their own areas in a large group. If there are problems to be discussed at this level, then these should have been identified and corrective action agreed between the relevant parties and the project manager before the meeting. Of greater significance, how ever is the danger of losing the focus of the meeting. In a large group, where many people will hold storing opinions on the issues being raised, there is a great temptation to allow the meeting to digress to discuss issues which are best resolved elsewhere. It should me made clear, therefore, that group progress meetings are arranged to report progress, and not resolve issues. For meetings to be effective, they should be kept short, and to the point. Value each other's time. A meeting longer than half an hour can get to be boring and you may find the team members losing interest. A daily meeting, first thing in the morning for half an hour is most effective. 38 Wandering about: Do it you will find about more about the project by doing this any other way. By talking to your staff, especially the ones doing the actual work, in an informal environment you will be able to grasp that intangible ‗feel' of how will the projects is going, and you will also be able to pick up on issues and problems as they arise, and before they have had time to embed themselves. Look for signals, body language, pensive appearances to instinctively judge that your member has a problem that needs to be addressed. S Curve: Project cost % time At the conceptual and planning phase, time is spent to carry out the activities you have seen necessary. Not much cost has been incurred except human / professional cost. Hence the curve is relatively flat along the X axis. In the implementation phase, the plan is put in to action. Purchases are made equipment and machinery are paid for and funds committed to her project are expended. The progress shoots up in an experimental manner. Once equipment is purchased and installation is carried out, the project is given its finishing touches. Commissioning (start up), polishing etc come under this category. Not much money is spent in this completion project but time is definitely spent. The S Curve: The Project progress is directly proportional to cost spent on the project as on the date. The last 5% of a project progress and the first 5% of a project progress can take longer than the middle 90% if a project is badly planned. In any case the first 5% and the last 5% of a project are not equal to 5% and 5% of the original project time estimate from start to finish. They could vary depending upon. a. complexity of engineering detailing b. lead time for procurement / manufacturing 39 c. complexity of installation d. complexity of commissioning e. mistakes and rework and delays due to poor planning at any stage of the project. Construction project's schedule and progress, as shown by a gantt chart with S-curves super imposed. Area B Months Code Activity Weight % 1 2 3 4 5 6 7 8 9 10 11 12 Progress % 100 ---- 02.01.01 Earthwork 3 80 ---- Foundation 02.01.01 & structures 22 60 --- --- Arcitechures 02.01.03 finishes 1.8 40 ---- Electrical & 02.02.01 control 11 --- 02.02.02 Piping 1.5 20 ----- 02.02.03 Equipment 45 0 ----- Preoperation 2.03 tests 5.7 Cumulative expenditure Total budget Predicted Milestone 2 Actual 40 Milestone 1 Time Expenditure Curve The S curve is the best way to pictorially depict the progress of a project and compare the actual progress with the plan. 2. CONTROLLING PROJECTS – TAKING ACTION. As discussed the ways in which the project manager can gather information which will tell him the status of work being undertaken on the project. Now we will look at what we must do with all that information, how to keep the project on course and see it to a successful conclusion. Controlling projects: Assessing the situation Impact analysis Resolving issues and problems controlling change Completing the project. Control is the heart of what the project manager does. Assessing the situation: Prevention is, of course, better than cure, and this is why we have expended so much effort on producing a plan for time, cost and quality in which we have confidence, how ever things will start happening differently from how you expected almost from the moment the project begins. Activities will start or complete late, costs will escalate and quality will fall. Must be able to assess the impact of these occurrences on the overall project. To do this we need to ask our self number of questions. Assessing the situations How much will this effect other activities? What must I do to correct this particular problem? What must I do to put the project back on track? Why did it happen? What must I do to ensure that it does not happen again? 41 Most problems can be rectified provided that they are caught early enough. This is why we have emphasized the importance of regular and honest progress reporting. We will stand very little chance of putting things right if you only find out a day before the impact is left. Problems comes in all sorts of shapes and sizes so it is hard to generalize about an approach to their resolution. A one day slip on the plan may have no impact whatsoever if there is sufficient slack in the plan to cover it. On the other hand, there may be a one day window in which something has to be done has to be done / and missing it might be disastrous. Impact analysis: Establishing the impact of changes whether brought about internally or through something happening out side of the project, can not be done by the project manager single handedly. The effect of change anywhere in the project is likely to be felt anywhere else. This rippling effect should not be under estimated, and within reason and depending on the sensitivity of the circumstances consultation should be as wide as possible. Where we can look for a degree of help, though in the impact of problems and changes on the plans. If you are using automated planning tools, into which you have recorded the dependencies between tasks, you can very quickly feed in the revised effort estimates from the impact analysis, and so calculate revised end dates for all tasks and the project itself. The dependency network diagram which we constructed as part of the planning process can be used to see which tasks are directly affected by one particular task slipping its planned completion date. The planning tool will also give you a clear picture on costs and how your resourcing profile is affected. If it is a major change, you may be forced into some substantial re planning. Taking the corrective action: As a project progress and we monitor performance, they will be times when actual does not measure up to plan. This calls for corrective action. How ever don't be too quick to take action. Some deficiencies turn out to be self correcting, it is unrealistic to expect steady and consistent progress day after day. Sometimes you will fall behind and sometimes you will fall behind and sometimes you will be ahead, but in well planned project you will probably finish on schedule and within budget. When the project begins to fall behind in schedule, there are three alternatives that may correct the problem. The first is to examine the work remaining to be done and decide whether the lost time can be recovered in the next steps. If this is not feasible, the second is to consider offering an incentive for on time completion of the project. The incentive could be justified if you compare this expenditure to potential losses due to late completion. Finally the third is to consider deploying more resources. This too will cost more, but may off set further losses from delayed completion. When the project begins to exceed budget, consider the work remaining and whether or not cost overruns can be recouped on work yet to be completed. If this is not practical, consider narrowing the project scope or obtaining more funding from your client. 42 RESOLVING ISSUES AND PROBLEMS: Although action to resolve issues will be as varied as the different types of problem that will occur as a project, it can be generalized into several basic categories. Genuinely creative solutions to problems Using contingency Applying more resources. Slipping the completion dates De – scoping Making sure it does not happen again. There is no do nothing option. Problems will not go away of their own accord, nor will they become more tolerable with time. They should be identified and resolved at the earliest possible opportunity. Although problems are different they will nearly always manifest themselves as the project manager being faced with more work to be done in less time. Apart from the first and second approaches given above, resolving most problems implies a degree of compromise on the objectives of cost, time or quality. Genuinely creative solutions: This is the ideal way to resolve a problem, but naturally the hardest. We can all lie awake at night seeking that flash of inspiration which will provide us with the answer to some acute problem. It rarely comes. We cannot cover creative problem solving as a topic here, but one area where it is worth looking for ideas in the original plan. As we said projects change, they sometimes do so in your favor. Re examine the plan and particularly the planning assumptions. What may we appeared to be the only way to do something when you devised the plan might now be one of a number of ways, some of which may be better (hopefully cheap and faster) Resource may constraints may have forced you into doing things as certain times and in a particular order. Check if there resources constraints still exist as it might be possible to juggle some of the work. On particularly long projects you may find that emergent technology or new techniques allow you to review your estimating assumptions. Look again at the dependencies that are built in to the plan. Ask your self if they really are finish to start dependencies, or if the second task can actually start with an incomplete input. (apply cautions here ; it may impact quality and running tasks in parallel which are ideally done one after the other requires very careful management. Using contingency: You had the foresight to build contingency into the plans for this very eventually, so use it! Be aware though that once it is all gone you cannot get it back again, and might be times when your need of it will be greater. So user your contingency only when you really have no choice and monitor and control it carefully. Applying more resources 43 Assigning more people to an activity which is running late is the most common means of rectifying a potential slippage. It is less desirable than whatever imaginative brainwaves we may have come up with earlier, but more so than the other two as it should not adversely affect your objectives of time and quality. It will, of course, but in the majority of projects time and quality tend to be considered more important. Additional resources can be applied to tasks by moving staff off less important tasks (or at least task which are further away from the critical path). Be aware, though, that you may simply be deferring problems until later by doing this. Alternatively, staff can be brought in from outside the project on a temporary basis, either from elsewhere in the organization or by hiring contractors or consultants with specialists skills. Be aware, though, that this may be resented by the project staff who may see it as an unfavorable reflection on their own performance, and ensure that it is presented in a constructive and non threatening manner. Improvements in productivity tend to involve longer term measures than you might be considering but you will always have the option of asking the staff to work additional hours, overtime and weekends. This must, however, be seen as a short term, solution of a recognizable crisis. In the long term it will sap morale and probably reduce overall productivity. Some further words of caution regarding applying additional resources. Firstly, not all tasks can be completed more quickly simply by applying extra resources. Secondly, brining in staff from outside of the project may involve existing staff spending a lot of time teaching and supervising the newcomers. Do not under estimate either the amount of time it takes for people to get up to speed on the intricacies and issues of the project (no two projects are alike) and do not underestimate the impact it will have on other people's work. Thirdly, beware of robbing peter to pay paul. There is no point in moving staff onto a critical task if the first task is going to suffer as a result. Slipping the completion dates. This is, of course, a highly undesirable course of action to have to take, although there may be times when you have no alternatives. This may mean that a particular task will be late, achievement of published milestones or slippages of the overall project will usually require the authority of the project sponsor. Whilst completion of the project on time at all costs should not necessary be regarded as an inviolable tenet, allowing the project to slip may have a demoralizing effect on staff and reduce their confidence in both their ability to deliver and your commitment to timely delivery. Be aware too of the tendency of work to fill available time. If you announce that the end date for the project has been differed by a month, in a matter of days that month will have been fully accounted for. If you have to do it, do it well in advance and ensure that the reasons are well publicized and understood. De-scoping 44 De scoping means delivering less than you originally intended. It is a classic means of delivering something on time, the appropriate only if none of the above approaches will work and the project is in danger of being cancelled it is, of course, a serious compromising of the quality objective, but by delivering the minimum requirement on time, and leaving the nice to haves until later, you at least preserve the organization's investment in the work done to date. Again, this should normally only be done with the consent of the project sponsor and in consultation with the user's of the project's major deliverables. Making sure it does not happen again By and large the above approaches will involve taking the tactical steps to resolve an immediate problem. It is equally important to ensure that the problem does not recur, either later on this project, or on other projects elsewhere in the organization. You should therefore examine in a non recriminatory manner the root causes of the problem and what measures can be put in place to ameliorate them. MULTI PROJECT MANAGEMENT. Determine the long term and short term priorities between projects to enable appropriate decisions regarding allocation of limited resources. Time management: Distinguish between subjects of true importance and those of apparent pressing urgency. Applying pareto's principle to time by using 80% of managerial time of 20% of selected subjects Scheduling time as opposed to scheduling work, since time is the limited resource and work must be prioritized and subordinated to available time. Despite providing contingency at the outside spot potential dangers early enough It is important to remember that if you have spent half the time that you planned on a task, it does not necessary mean that you are halfway through it. Interdependence between & within projects. Projects & activities when projects can be inter related in three basic ways 1. Result of action 2. common unit of resources 3. rate of use of common resources Conflict between activities Priority to be given to 1. Critical Project with overall current priority 2. Critical Vs non critical Critical activity (regardless of over all project priority) 45 3. Non critical Vs Non critical Activity with least slack (allowable delay). If equal slack – shortest or longest activity duration. the value of TIME A fraction of time can not be brought by a tonne of gold You cannot control how much time you have But you can control the way to use it You can not choose whether to spend time or not, Buy you can decide how to spend it You cannot manage time But you can learn to manage yourself in relation to time Time cannot be expanded, accumulated Mortgaged, hastened, or retrieved Hence you should value time As man's most precious commodity and have optimum utilization of every fraction of a second. NETWORK ANALYSIS IN THE CONTROL OF PROJECTS As we discussed simple critical path theory, and mentioned that our project control procedures are the means where by we recognize that there exist many uncertainties in the execution of projects and seek to account of them. When we have drawn a project network and derived an acceptable time schedule from it, how do we ensure that our schedules are implemented and the project completed on time ? and what can we do to ensure that project costs are kept under control and that the necessary resources of manpower, equipment, etc., will be available when they are needed these are the questions we shall seek to answer in our discussion on project control. The control cycle Uncertainty will exist in our critical path schedules for some or all of the following reasons. The estimates of activity duration may prove to be inaccurate The technical specification of the project may lack much detail when the early schedules have to be produced. The circumstances existing when the activities come to be executed can only be guessed at. Suitable staff and equipment may not be available in the right 46 numbers, the weather might delay work, and materials might prove faulty or equipment fail tests. The customer from whom project is being undertaken may change his mind as to what he wants, what he is prepared to pay, and when he wants it. It is impossible to anticipate all these factors. What we must do in these circumstances is to prepare the best network and schedules that we can and then review them from time to time. We say that a control period passes between those reviews, and these may be at either regular or irregular intervals. At the end of a control period we collect the details of what actually took place during the intervals. At the end of a control period we collect the details of what actually took place during the control period in terms of events which occurred and activities which completed or were partially completed, together with our growing knowledge of the technical nature of the project and the circumstances in which it will take place, and we revise our network and produce completely new schedules. The new schedules are then issued to activity managers for use during the next control period, and so the control cycle repeats itself. The project management, or progress, meeting should be timed to take place shortly after the new schedules have been received and examined, so that problem areas which have been highlighted can be discussed by the activity managers and suitable action taken. It should be emphasized that the prime purpose of this control procedures is to keep the future schedules for the project as sensitive as possible to current achievement and growing project knowledge, regardless of what was intended should happen. It is of secondary importance only that we should be collecting facts for use in other projects that might come along later and for post mortem enquires into what went wrong during the control period. If we do not insist on this order of importance the estimates we receive from the activity managers may be biased in undesirable directions. Determining the length of control periods The determination of the time length of the control cycle most appropriate to a particular project is a matter for nice judgment. On the one hand we do not wish to involve ourselves in time consuming schedule reappraisals more than is strictly necessary. On the other hand we wish to ensure that the volume of achievement and technical project information collected at the end of the control period does not result in schedules highlighting serious and unpredicted difficulties. We must relate the order of magnitude of activity durations the length of the control period and this rule pre supposes that we have, even before the network is drawn, some notion of the appropriate length of the control period. If activity durations, foe e.g. are falling in the range between one and 15 weeks with a mean at around 4 weeks, we will not know from this alone whether the control period should be 2, 4 or 8 weeks long. In practice, we would usually be wise to take a longer than a shorter period initially and be prepared to shorten it if this appeared desirable. In the above example we would start with an 8 weeks control period and reduce it to 4 weeks if this became necessary at some stage in the life of the project. If it has been decided that revised schedules will only be produced at irregular intervals whenever major projects upsets have occurred, it can prove difficult in practice to decide exactly when such a revision should be undertaken. This may be a sound reason for not 47 pursuing this policy, especially where an extensive set of information collection procedures have to be set in motion at short notice in order to make such a revision. In projects of short total duration, of the order, say of two or three weeks such as we find in plant maintenance a further factor has to be considered. A certain irreducible time is required to collect, process, and analyse the information at the end of a control period. If this time is three days, we clearly will get little or no value from a control period of four days. In general we might say that control periods lengths should in no circumstances be less than double the time it takes to make a review. Procedures for schedules revision Whether schedules are revised regularly or not, the steps which have to be taken in making each revision are the same. Firstly, we have to collect two kinds of information from those responsible for activities, historical and future. The historical information is a statement of which events have occurred and which activities have been completed, or in the case of partially completed activities what time remains before they are complete. The future information must contain confirmation that time estimates for activities not yet started are still valid, or, if they or not, re estimates must be given. It is most important that this opportunity to correct early estimates which are judged to be inaccurate is taken at each review. In addition, we are dependent on activity managers to tell us when fresh light has been thrown on the technical nature of the project so that the network structure itself may be modified so that it accords with the most up to date knowledge of the project. The total of this information when combined with the network and schedules as they were at the preceding review enable us to produce an up to date network and new schedules. It is most important that we recognize the difficulties that may lie in our way in collecting all this new information. As in most control systems, ultimate success will depend on the accuracy, completeness, and promotions of this feed back from the field of operations. Inaccurate, missing or late information can disrupt or invalidate the effectiveness of project control. It is therefore most necessary that all our activity managers should understand not only the details of the reporting procedure but also the theory of network analysis sufficient to enable them to make proper interpretations of schedules. In addition, since those responsible for the operating of the control procedures will usually be in a staff function relative to the line function of activity managers, the support of top management is vital in maintaining good human relations within the project control systems. In particular, it is top management who can enforce promptness in reporting, and ensure that activity managers are not made to feel that duration estimates are target commitments which might lead them to build in reserves of time. On small projects with control periods of two weeks or more it is usually quite feasible for the reporting information to be collected by one or more men visiting all the activity mangers. Where this is not possible, because for e.g. the activity managers are geographically dispersed, or the volume of information is too great, it becomes necessary to institute a more formal procedure involving direct reporting by activity managers. In all cases, the most fool – proof routine is to mark all change information on copies of the most recent schedules, since these act as a check list. Before the new schedules are issued they must be examined so that we may be sure that they are valid and capable of implementation. There are many reasons why this may not 48 be so, and adequate time for a vetting process should be allowed as a matter of routine. No matter how careful we have been, errors may have crept into either the basic information or into the calculations. If a computer is being used a good computer program will be vary helpful in spotting these errors, although some are such that they cannot be identified in this way. In any event, all schedules, however produced, should be carefully examined for errors. The process is made substantially easier if all input information appears on the schedules themselves, so that the activity managers can assist in this checking process. The new schedule may highlight a serious situations, perhaps an unacceptable delay in project completion, which requires some fundamental investigation before a more satisfactory schedule can be produced. In such a case, the best procure might be to issue the schedules together with a statement of the difficulties and suggested remedial action to those concerned. It may be possible to rectify the schedules in the time available but this not be allowed to delay in their issue. Whenever this kind of situation occurs must always satisfy ourselves on one important point. Is the project in real difficulty, or are we guilty or a failure to use network analysis to adequately represent our project? If the project is in real difficulty we must immediately report the fact to our management , but if our networking is at fault, we must rectify this as soon as possible. In addition to continually improving our network description of the real life project, we may decide to explore the possibility of executing the project in a different way. This procedure of, exploration and testing the alternative possibilities we can simulation. Simulation is the process of answering a number of ‗what if' questions, such as what happens if we change the sequence of activities? Or what if we switch resource effort at some date in the future? Used in the right way, simulation is a powerful tool in the network analysis project control. Simulation may often be used in the time between reviews. We should recognize that there are two parts of new schedules. The short term portion covering the duration of the next control period, and the long term portion extending beyond it. We should be particularly careful to ensure that the short term portion really does have the detail necessary for the day to day control of operations by activity managers. The long term portion may often lack this specific detail and should always be regarded as an area where improvements can be incorporated before it becomes a short term. The use of float values: In the simple critical path theory we defined total, free, and independent float we now discuss where these different kinds of float occur and how they are used in project management. The float is zero on the critical path and is therefore positive on all other activities. On large projects only some 5% of all activities are on the critical path and we therefore find 49 positive total float values on some 95% of all activities. This identification of the important small minority of all activities which determines the shortest time in which the project can be completed is of great value to management in meeting delivery commitments. When we take advantage of total float on a non critical activity, we allow its completion to be delayed beyond its earliest possible completion by up to the amount of its total float. We do this in the know ledge that we will not delay the completion of the entire project, but we will make some following activities more critical. Specifically all activities which follow the one on which the delayed completion which incurred up to the points where they merge with a more or equally critical path will have their earliest start dates delayed, and their total float values reduced by the amount of initial delay. Clearly an uncontrolled use of total float early in the life of a project will tend to make a large proportion of activities critical later in its life. Free float and independent float, both with the characteristic that they are amount of time by which the completion of an activity can be delayed beyond its earliest possible completion without delaying the start of any activities which follow, are introduced to help in overcoming this draw back. Free float is always less than or equal to the total float of an activity. Positive values of free float appear on all but one of the activity is preceding an event, and in no other circumstances. This fact means that we will find positive values of free float on only a minority of activities, perhaps about 20%, all the others being zero. Independent float is always less than or equal to the free float of an activity. Positive values of independent float appear only on one of three activities forming a simple triangular configuration in the network, the one with the largest total float independent float above zero is usually even rarer than free float, & appears on perhaps some 5% of all activities. So far we have not described a kind of float which appears on all non critical activities and which can be used by activity managers without delaying those who follow. Total float is quite unsuited for this purpose, and free and independent float appear only as a minority of activities but are otherwise suitable. What can be done to remedy this situations? We can take the advantage of the position in networks where free float appears as described above, and we will illustrate this point by referring the figure below. Suppose that activity 13-14 has zero free float. Activity 12-14 will therefore have positive free float, and activities 10-11 and 11-12 will have zero free float we can split the free float on activity 12-14 in to 3 parts and assign them to the three activities in the path 10-11 - 12-14. in making such split we can use any rules we wish, and it could be pro rata to number of activities, prorate to activity duration, or it could be a matter subjective judgment based on a technical knowledge of the activities themselves. This idea can be extended to the point at which a portion of free float has been assigned to all non critical activities in a network A method for placing greater emphasis on desired project completion dates: So far we gone thru a method of scheduling in which we make the latest date for the objectives event the same as earliest date we have just calculated. This leads us to critical path with zero total float and zero slack and all other values of float and slack are either 50 zero or positive. We say, that this is how we produced a schedule showing how the project may be completed as soon as possible. A more common scheduling objective is to show how the project can be completed by its desired completion date. we can reflect this objective in our scheduling procedures by making the latest date for the objective event equal to its desired date, regardless of what the calculated earliest date for this event is. This will give either to a positive or negative or zero float and slack values, depending on whether the earliest date for the objective event is earlier or later than the desired date, and the original critical path will be unlikely to have zero float and slack. Of course negative float and slack values appearing in a schedule demonstrate the impossibility of completing the project on time with the network and its data as its stands. How ever, the areas where improvements are needed are very clearly indicated and the immediate task is to so change the data that the negative signs are removed. This minor modifications to the standard scheduling technique places a great emphasis on project completion on time. Resources and cost implications of time schedules\ In all our discussions so for we have concentrate on time considerations only and have ignored the problems of finding the resources to execute activities when needed, and the problems of the project cost. Suppose some category of labor is in short supply and it is known that it will probably cause activity delay, and suppose we have tight budget to project expenditure, how can we take account of this further factors in deriving our schedules? We can see clearly that there will be times when a failure to observe this concentrate will result in schedules which may be satisfactory from the timing point of view but which are incapable of being implemented. There are two approaches to this problem on the one hand we can use project resource and cost characteristic to influence the time schedules as they are being calculated, and the other hand we can examine the resources and cost implications of meeting and acceptable time schedule. Let us examine a simple example of this letter approach. In the below figure we can see a bar chart schedule for the simple network developed in the section simple critical path theory. The category and the number of units of resources required for each activity is shown, and activities start and finish at there earliest dates. A summary of total resources requirements is given at the bottom, if we limits the availability of resources units to one each of X and Y, this schedule is infeasible because two units of Y are shown as being needed in periods 3 to 6. we now examine the activities contributing to this overload with a view to spotting one or more with float sufficient to allow them to be delayed in to a period where capacity is available. Infact, activity 2-4 has 8 periods of total float and can be rescheduled to start on period 9, instead of period 3 without delaying project completion. The another below figure the new schedule which is now feasible from the resources as well as the timing points of view. A delay activity of 6 periods inserted immediately before activity 2-4 in the network will ensure that this infeasibility will not appear in the schedules again. the method just described is essentially one of trail and errors & may be used on projects of a ny size. It should be remembered that a complex chain reaction can be set up when an early activity is delayed in a large project, involving delays in starting activities which follow. It is good practice to make only a few such delays before recomputing the schedules, so that 51 the effect of a small number of changes can be seen before others are made. A similar procedures can be used in fitting activity cost into a limited budget. The place of network analysis in the organization, and staffing considerations Since network analysis is likely to take over wherever bar charts have been the usual plan technique, there should not be much difficulties in visualizing the place of network analysis in the organization. How ever, in using these techniques there is a change of emphasis and three basic functions should be recognized, how ever they are carried out in a particular organization. Firstly, there is the project manager in charge of one or more projects and amongst other things, responsible for coordination and completion on time. His projects pass thru the various line departments, but he usually occupying a staff position in the organization and is not therefore responsible for these departments. Next, there la the activity manager responsible for the work on one or more individual activities, and he will be one of the line managers. Lastly, there is the planning office responsible for the network charts and the production of schedules. The planning office is always a staff function. This three function must work harmoniously together it network analysis is to be a success, and clearly all three are dependent on each oilier. The project management, or progresses, meeting is the idle place in which to discuss difficulties and should, if possible, be arranged to co inside with the issue of new schedules and be attended by the representatives of all three functions. All three of this functions need to be experienced in the use of network analysis in different degrees, and there remains the problem of how this can be achieved. Where there is no experience in the organization, a pilot exercise is essential. The project on which such an exercise is carried out should be of the main stream of company concern where the learning process can proceed without a glair of publicity. It is important that such an exercise should be carried out right thru to completion of the project, since the real effectiveness often does not appear until the end such an exercise will develop a nucleus of people in all these function who are experienced in network analysis. There after major projects cane be undertaken with a greater confidence. 13 10 11 12 14 Period No. Resource No. of Total Activity category Units float 1 2 3 4 5 6 7 8 9 10 11 12 13 14 1-2 X 1 3 1 1 1-3 X 1 0 1 1 1 1 1 1 1 1 2-3 X 1 3 1 1 1 2-4 X 1 8 1 1 1 1 -- -- -- -- -- -- -- -- 3-4 X 1 3 1 1 1 1 1 1 NO.OF UNITS X 1 1 1 1 1 0 0 0 1 1 1 1 1 1 52 REQUIRED NO.OF UNITS Y REQUIRED 1 1 2 2 2 2 1 1 0 0 0 0 0 0 Period No. Resourc e No. of 1 1 1 1 1 Activity category Units 1 2 3 4 5 6 7 8 9 0 1 2 3 4 1-2 X 1 1 1 1-3 X 1 1 1 1 1 1 1 1 1 2-3 X 1 1 1 1 2-4 X 1 1 1 1 1 3-4 X 1 1 1 1 1 1 1 NO.OF UNITS X REQUIRED 1 1 1 1 1 0 0 0 1 1 1 1 1 1 NO.OF UNITS Y REQUIRED 1 1 1 1 1 1 1 1 1 1 1 1 0 0 RISK MANAGEMENT : If it is possible to avoid the effect, can you reduce the impact? For example whether can hold up projects and cannot be avoided The solution is to examine the weather history for the area and the time of year, and to build in to the schedule a reasonable amount of delay. E.g excavation for a building construction is not usual done during the monsoon. You would have just removed all the water by pumping it out, and the same night, these could be pouring rain! Periodically look at the risk registrar and swing into action when the early warning signals appear. The early warning signal is also known as the direction capability Let us go through the process for simple examples Example1: temperature rise in a car Risk identification: if a car heats up, it will cause damage to the engine Risk qualification: the damage can be huge if not attended early enough 53 Risk response development: a]. in older cars, you had to check if there is enough water in the radiator. Putting enough water is the response. b]. in newer cars, an automatic water recirculating system containing a coolant was installed. In both cases, and even in the latest cars, a temperature indicator was fitted on the dashboard. This is the detection capability. c]. in the latest cars, an increase in temperature would automatically stop the cars, thus reducing human error. Risk response control in cases a and b above, the risk response control mechanism is to manually stop the car to prevent damage. Other examples: The same process can be followed to understand why: i] air bags are placed in a car to cushion / minimize the effect of a head on collision. ii] fires sensors are installed in large buildings along with fire extinguishing systems. iii] seat belts are installed in cars iv] we guard against foreign exchange risk.- possible increase in the value of the US dollar in case you have placed an order on an international company for supply of goods. In a development project such as the space shuttle, it is the risk of failure of each one of the parts and the evaluation of their damaging effect that drives the decision. Regardless of their cost , a relatively inexpensive item and cause harm to human life as was sadly experienced on the Columbia shuttle. In the challenger space shuttle disaster, it was a simple O – ring failure that caused great harm to the astronauts. Some member of the project team felt that the probability of O - ring failure at the low launch temperature was quite low. However, the severity of the failure was 10, because the astronauts ‗on board would be killed. In risk management as the saying goes ―expect the unexpected‖. *********************************** ************************************ Q.7 Describe the role of a project manager in an organization, also explain the tasks of teams and individual manager in each phase of a project in an organization. Ans: Some organizations prefer to name two project managers – one for the conceptual phase, to bring it up to confirming the project's feasibility (if the organization is the end – user) or, to be a techno – commercial executive to assist / take the lead in securing the order for the contracting company. (if the organization is the systems development organization – SDO), the other to take over from the project feasibility / order stage and see it though the planning, implementation, and completion phases. 54 In the review phase that is desirable to follow the completion phase, both project managers play a part to recommend and implement improvements in the system to enable better execution in future projects from ―concept of commissioning‖. 1. Organizing projects: The project organization having established the WBS, you will now have a fairly detailed view of what the project looks like in particular, what needs to be done. The next stage is determining who is going to do it and how they should be organized. Although it would be wrong to suggest that correct organization will solve all your problems, it is without doubt that a flawed organization will cause major problems on a project. These will manifest themselves as difficulties in communication, responsibility and commitment. The organization you select for your projects should, therefore, try to address these issues. Logically, your WBS is your project organization, we stated that for each work unit which appeared on the WBS there was a single person responsible for the delivery of the end product associated with it. We should, therefore, be able to map bottom level tasks on to individual workers, higher – level tasks on to their managers, and so on. Structure and flexibility ―What a bureaucracy. I can't get anything to move in this organization.‖ ―you are lucky there's bureaucracy to complain about there is not any organization on our project. I don't know where my job stops and another persons starts.‖ These views reflects opposing complaints about the structure of an organization. The first is a reaction to rigid structures, which funnel information along routes mapped out by flow diagrams and organization charts. The approach allows little flexibility for making expeditious projects moves. The second complaint emanates from a less structured organization characterized by unclear levels of authority and responsibility. In this organization, flexibility is so great that work boundaries become blurry and the result may be a project that, like the proverbial cooking pot, have too many cooks watching over it - or, conversely, none at all. In designing organizations, project decision makers must create structures that will meet widely diverse project needs. If the structure is too rigid – or too loose – the organization may provoke reactions similar to those given in the opening dialog. Simply drawing an organization chart falls far short of designing a project's organization. In addition to sketching out who reports to whom, the over all design should respond to the question, ―how will the organization really work‖? it must provide for effective interaction among all of the project's players. An organization's purpose is to facilitate the interaction of the people to achieve goals. to create an organization design which provides a permanent setting in which managers can influence individuals to do their particular job. To achieve the pattern of collaborative effort among individual employees, which is necessary for successful operations. 55 To create an organization which is cost effective that is one which not only achieves the first two goals, but does so with minimum of duplication of effort, payroll costs etc. A structure that fosters human interaction, that minimizes barriers to such interaction, is required in setting up project organizations. Three classic structures prevail in project work. Although subtle variations exist, the cornerstones of organization design are represented by the following forms. 1. Functional or hierarchical organization. Reportedly the most prevalent type of organization in the world, the hierarchical structure is pyramid-shaped, with stratified management levels subordinated by distinct horizontal tires. Work activities are divided functionally by specialties and disciplines. 2. task force organization. In the task force organization, human resources pooled for a project team are largely separated from other company personal ties. Centralized project management directs the project efforts. 3. matrix or horizontal organization. The matrix organization is a hybrid structure aimed at optimizing strength and minimizing weakness of the functional and task force structures. It is a loose functional structure in which extended lateral mobility exists. A properly designed organization can be hailed as a major contributor to project success. Establishing the structure itself is only part of designing the organization, but it is a crucial part. An organization structure performs the following key functions. when unveiled, after being modeled to specific needs, it represents a psychological ―kick off‖ indicating that the project can move ahead at an increased clip. It formally establishes relationships among project team members and others. It implicitly or explicitly maps out work activities. The key to successful organization design is understanding that most project interaction takes place through people, not through systems or things. Its people who make the organization go, and cause significant things to happen. A project must be organized so as to optimize the human interaction required to carry out the activities necessary to meet final goals. The functional organization: The hierarchy, or functional organization, is an outgrowth of the classic bureaucracy. The hierarchy strives to be rational, efficient, and professional by establishing fixed authority relationships and defined spheres of competence. In project management however where multidisciplined projects must be completed within limited time frames and within predetermined budgets, the functional organization is often inadequate. Multispecialty ventures call for a horizontal form a coordination a characteristic very foreign to vertically oriented bureaucracies. How ever a lack of lateral flexibility does not mean that functional organizations are entirely useless for managing projects. Projects can be directed from a functional base using an approach that is called ‗influence project management'. 56 One type of project where the hierarchical organization is most appropriate is where the bulk of the work is carried out by one particular function or skill. This tends to be the case for technical projects particularly, where the impact of change is more on the technology than on the environment. Functional organization with "influence project management" position General Manager Project activator (influence project management) Design Production Erection Testing Contact Quality Administrati management control on Task force organization The task force organization has been called ―pure‖ project management. It is team effort created specifically to accomplish the projects objective or mission. The project manager deals from a character establishing strong authority. Within the task force the manager is unencumbered by functional strappings and assumes a position of prestige, authority, and responsibility. Many major construction projects and special manufacturing projects, qualify as project oriented or task force organizations. A sample task force organization is shown in below figure. The task force appears to many to be the ideal way to mange project and is often referred to as the projectized form of organization. It is task oriented team oriented, unhampered by restrictions imposed by the external organization and 57 buffered from external conflicts. This advantages make the task force a strong preference for many projects managers. The task force carries with it, how ever some significant disadvantages. Mobilization and de mobilization of personal are a major difficulty because the nature of the work is temporarily. Where do the people came from? Where do they go? Once the project is completed? Technical expertise is difficult to maintain in projectized structures qualified specialist may turn down temporary project assignments in favor of more permanent positions in functional sittings. Also, because the cast of the task force organization are segregated they may appear high in comparison with those of alternative organizational modes, where cost are included with overhead General manager Project manager Other Operations Design Production Eraction Testing Contract management Quality control Administration Matrix organization: Structures that are either purely functional or purely projectaized are becoming relatively rare. More commonly found are organizations representing some type of matrix formation. While these organizations are often carry strong functions or projects over tones, the interconnecting web of relationship and responsibilities characteristic of matrix philosophy is always present. The figure below shows in a simple form how a typical matrix structure might exist for a manufacturing projects. In this section the advantages and disadvantages of the matrix as opposed to those of the functional and the projectaized structures and discussed. 58 The matrix and the camel. The camel is set to have been conceived by the committee whose initial task was to design a horse. The give take compromise of the committee members resulted in and awkward looking and cumbersome creature that was never less highly effective in the in hospitable desert environment for which it was created. The matrix may be regarded as the organizational as the organizational cousin of camel. Surely the original goal was not ambiguous, conflict – raising structure that finally evolved. Despite its ungainliness, the matrix model has proved to be effective in certain complex organizational environments that are perhaps as hostile as the camel's desert locate. Outside of their natural environments, both the camel and the matrix appear strange, clumsy, and very much out of place. Three basic conditions are required for the matrix organization to be effectively applied, 1.outside pressure for dual focus 2. pressure for high information – processing capacity and 3. pressure for shared resources. Where at least two of these conditions exist, the matrix structure should be considered an organizational solution, where non or only one of the conditions appears, establishing a matrix should be questioned. Outside pressure for a dual focused may represent a need to meet customer desires through a central spokes person, even though the worth is developed on a specialty basis within the company. The matrix can relieve the pressure for high information processing capacity because, in terms of speed and agility, its horizontal and informal communication patterns give it a sizable advantage over other forms. The problem of pressure for shared resources can be meet by the matrix by, which is more resource efficient than say, a cluster of numerous independent project structures, which are bound to result in redundancies. The cumulative positive effect of these conditions may be sufficient to off set the difficulties of dealing with the conflict prone, fuzzy organizational compromise called the matrix. The matrix approach leaves staff working on the project within their own departmental structures it allows the project to remain fully integrated with the mainstream organization / and encourages decision making to remain within the organization, rather than isolated within the project in order to avoid this conflict of priorities and accountabilities there needs to be agreement between the project management and the departmental management about the amount of time and commitment that individual members of staff can spend on the project. Matrix organizational for a manufacturing project General manager Design Production Erection Testing 59 Contract Quality control Administration management Pro Design Contrac Product Quality Erectio Admini Product ject persone t ion control n stration ion Mg l manage persona persona persona persona persona r ment l l l l l ―A ‖ persone l Pro ject Mg r ―B ‖ Conclusion: Three distinct structures serve as a basis for designing project related organization functional, task force and matrix. At one extreme is the ―projectized ―task force, and at the other is the functional structure. The matrix organizational is a continuum in between, covering a range of variations. Functional organizations are hierarchical, verticalized structures that establishes clear lines of authority and foster competence within disciplinary specialties. Projectaized structures use the task force team approach marshaling necessary resources around a strong project manager in order to accomplish the projects goals. Matrix organizations result from attempts at making ―the best of two worlds‖ by cross breeding the functional and projectaized forms. The matrix of spring combines the attributes of relative efficiency (through utilization of human resource) and effectiveness (through task oriented coordination). With the not so desirable side effects of ambiguity and conflict. Each type of organizational structure meets project needs to greater or lesser degrees. The comparative performance of each as related to basic criteria is shown below table, which is based on studies done in research and development organizations Comparative performance under project matrix, and functional organizations for R&D project. Criteria Project matrix Functional Achievement of due dates Very good poor poor Technical qualities poor good very good 60 Resource utilization poor good very good Cost control very good good poor Job satisfaction Specialists poor good very good Non specialists very good good poor Client feed back & control very good good poor Unidisciplinary poor good very good Multidisciplinary very good good poor Conflicts Low high Low Decision making responsibilities: Establishing who decides what is a major prerequisites for any project. If clear decision making responsibilities are not defined, then either crucial decisions will not be made and the project will suffer from inertia, or the project team itself will take decisions, resulting in alienation and reduced commitment from the users. As a general rule, decisions should be made by those who normally make them within the organization, or have some accountability for the consequences. Accountants should make decisions about the accounts, technicians about technical problems etc. Levels of authority should also be defined, especially authority to spend money or deviate from the terms of reference. This should include escalation procedures to help resolve conflicts between irreconcilable decisions made by different decision makers. Having decided upon the type of structure of the organization, which is suitable for a specific project we now turn to the project manager. He/she may be either the project leader or sub-project leader. In both cases responsibility, accountability and trust are the three conferment bestowed or a project manager. 61 Sub project team Project leader Sub project leader Team member A project manager is an agent of the proprietor and assumes the role of the proprietor in a construction project where the proprietor lacks the technical and organizational skills for the task. As such, the project manager becomes responsible for preparing a brief, and appointing and coordinating the consultants. The proprietor's requirements are conveyed to the project manager who ensures that they are acted upon by the consultant and contractor. He may, if engaged for a total service, be responsible for such matters as site selection, feasibility studies, preparation of consultants briefs, selection of consultancy team together with negotiation and documentation of conditions of engagement, evaluation of design profiles, supervision of documentation, implementation of programme, selection of contractual system, contract financial control, supervision of letting as well as many other services A project manager should have the following skills: 1. A high level of leadership and communication skills; 2. Ability to manage the client issues; 3. Ability to manage the local government approval process; 4. Ability to manage the design process; 5. Ability to manage the construction process; and 6. Ability to manage risks. A project manager should undertake the following roles: 1. Understanding of the client • Understand the nature of the client as a non-profit entity in relation to decision making, financial capability, high level of volunteers, lack of technical understanding and limited knowledge of contractual issues. • Understanding of the end user requirements (including club members, community groups, other sport or recreational groups). • Resolve any conflicts between users to achieve the optimum design and cost outcomes. 2. Understanding of the project 62 • Understanding of scope. • Understanding of Funding (including funding sources, conditions of funding, constraints and limitations on availability). • Understanding of time constraints (including sporting season, major events). • Understanding of budget (including benchmark costs, market fluctuations, locality issues). 3. Understanding of design • Understand all legislative requirements • Develop functional brief • Prepare design brief • Align scope and budget • Manage sketch design and developed design process • Manage development of contract documentation • Manage the planning process and facilitate gaining all relevant approvals. 4. Understanding of tender process • Understand requirements of State Purchasing Policy • Evaluation of value for money • Ability to revise scope to meet tender price • Understand equity and probity issues as applied to the use of public funds 5. Understanding of the construction process and technical requirements of a building project. • Understanding of the relevant building disciplines • Understanding of relevant building contracts • Understanding of contract administration and roles and responsibilities of Superintendent • Management of time, cost and quality of overall project • Undertake regular reviews of cost and program 6. Development of Risk Management strategies • Review, manage and mitigate risks around technical, financial, environmental and political issues. • Develop proactive risk management strategies. 7. Communication • Provide regular reports to the client that is relevant and meaningful • Include the client in the decision making process. • Provide the client with the tools to make sound decisions. MANAGING A PROJECT TEAM PHASE TASK Conceptual Define scopes- meet/talk to client and sponsor Deliverable: Defamation Planning Plan tasks, deliverables, risks, milestones. 63 Dependencies, expenditures & responsibilities Deliverable: Project schedule & budget Implementation Monitor progress against project schedule /budget Modify the plan as necessary Identify and record changes to scope Liaise with sponsor and client Deliverable: Project deliverable Completion / handover Confirm objective meet Hold official handover event Produce end user instructions Deliverable: completed project Review Conduct post – project review. Agree learning points Deliverable: project review document MANAGING A PROJECT TEAM PHASE TEAM INDIVIDUAL * name the project - this will give the team a point of * Identify the people you would like to reference as it forms take part take preliminary surroundings * negotiate a team building on availablity and interest. CONCEPTUAL budget *Assemble the planning team 64 * Hold preliminary team meetings to establish roles and * Select individuals ground rules * Produce the * Delegate tasks product organization chart *Identify skills shortfalls and agree *Set up a group diary and e- personal development goals. mail address group *Open a personal file on each tean PLANNING *Agree dates for review member * Communicate progress to all team members * Monitor initial delegation *Maintain the profile of the *Delegate further tasks project via minutes, articles and *Bring in new people as required briefings. *Resolve disputes if *Caoch individuals they arise. *Integrate new *Hold individuals review meetings team members *Arrange *Maintain an appropriate level of IMPLEMENTATION regular social events individual social contact. * Involve the team member to hand over * Debrief individual performances. *Represent team in success or Agree any feedback that will be passed failure to manager *Pass on feed back and * Reward success COMPLETION/HANDOVER rewards to team *Thank individuals * Combine the post project review with a social event to * Write reports on individuals noting any REVIEW say than you to all participants skills EIGHT PARADOXES OF PROJECT MANAGEMENT According to the American management guru tom peters, there are eight key paradoxes in a good project manager. The truly successful project manager needs to be able to balance the qualities in the left hand column with their opposites on the right. TOTAL EGO NO EGO 65 Confident in his / her own ability and Not one to pull rank - a true right to make demands of people servant leader. AUTOCRAT DELEGATOR Decisive and authoritative where Encourages team members to necessary act on their own initiative LEADER MANAGER Has a vision of the future and inspires Manages the nuts and bolts of people implementation COMPFERTABLE WITH AMBIGUITY OBSESSED WITH PRECISION Projects are surrounded by ambiguity Some things do need precise searching for exactitudes causes definition. The project manager paralysis. has a nose for what these are GOOD FACE TO FACE GOOD COMMUNICATOR IN COMMUNICATOR WRITING Is confident and persuasive in face to Has the discipline to write things face briefings. Builds rapport with down and ensures paperwork is people. kept up to date. LIKES TO KEEP THINGS UNFAZED BY COMPLEXITY SIMPLE Believes that simple rules are not Recognizes that the direct route is not most likely to be kept and simple the best one solutions most often work AWARE OF THE BIG PICTURE ATTENTION TO DETAIL Pays attention to the small but Is able to take account of the vital components of a project that environment(Political, economic or can mean the difference between business) that surrounds the project failure and success. IMPATIENT PATIENT Sometimes listening is more A project manager often needs to effective than speaking. agitate to overcome resistance and Unnecessary checking slows achieve a result progress The changing roles of a project manager during the different phases of the project life cycle show that the ―human management‖ skills are the most important Personal qualities of the project manager Motivating Directing Communicating leading 66 Role of the project manager To plan To organize To coordinate To control To lead Human factors in project management 1. Project blending – building the project team 2. planning & strategy 3. Organizing projects 4. Project interfacing 5. using managerial time 6. handling conflict 7. Communication 8. Negotiating 9. Decision making & problem solving 10. managing change across changing frontiers 11. Managing behavior Two premises make up the cornerstone of this ‗human side' of project management. 1. People are the cause of a projects problems 2. A projects problems can be solved only by people no matter what type of project or what industry problems occur either because people 1. Make them occur, or 2. Do not tale action to prevent them from occurring At least 50% of the problems that exist on projects are either totally or partially behavioral in nature. The percentage has reached 75% in some groups. The role of a project manager is essentially to keep an objective view of the whole project its trends, problems and activities. From an informed view point it is important that the project manager does not become, for example the engineering manager or the construction manager on the project but stands back and ensures that engineering and construction are performed and properly managed. If he has to write a letter to the client in which some points may be disputed, he first takes the proposed letter to the client unsigned, gets his creation to it, and then sends it to him. He is tactful and realistic. It is necessary to ensure that the actions taken are based on good information and on frank and open exchange of ideas and data relating to the issues. In my experience the need to provide people with time to think before precipitating action is an important function of the project manager. That has to be coupled with making sure that analysis of 67 the circumstances is an complete and as objective as possible. Thus the project manager must firmly control discussions and actions in these circumstances. As the size and significance of the projects increase, coupled with their technical complexity, the need grows to have increased dialogue and understanding between a client and contractor if both are to contribute what is needed to bring large projects to successful conclusions. In handling project overseas, there is a constant need to bear in mind how the environment, the society and its religion and customs will impact on the working of the project, for example, while many people speak English, it is not their mother tongue, and there is need to use mutually understood vocabulary and avoid idioms. Project interfacing is a project management function and where the project manager plays a key role. This includes coordinating between various external agencies and internal departments. Positive approach to environmental problems The environment is complex and changing, and it is impossible to define it precisely or to predict its impact in control terms it will neither go away ignored nor be passive. It is no respecter of authority or feeling and it is definitely not computer friendly. Yet an interactive relationship is possible between the project manager and the environment. He / she anticipate involvemental problems and so minimize their effect and can even lobby people to adopt a positive attitude to his or her project. It is necessary to develop and awareness of and sensitivity to the cultural, political & involvmental situation, and then to use imagination, judgments, and persistence in selecting and following up specific issues. First the manager has to appreciate what aspects of the environment relevant to the project. This is not easy, because the significance of different factors vanes considerably from project to project. There will be no clearly established written guidelines to compare with a standard checklist, and research and investigation will be called for. It is necessary to develop social awareness rather than consider only the technology and this emphasizes the need to stand back occasionally from technical matters to view the forest as well as the trees. How ever ignoressing the immediate tasks, they can often be tackled better by maintaining a balanced perspective. Second, the manager has to be alert to changes and trends. The situation is never static. Apart from the environment / project interrelationship, which itself induces change, the expectations of both the public in general and those more directly involved in the project can have a profound effect on their behavior. Trends and expectations may not have been anticipated fully or correctly at the project inception. It is not sufficient merely to understand the environment. More positive results can be obtained by attempting to influence and change it. Communication and participation play a role here. Implementation phase have been discussed below. Project manager's role during interim progress reviews 68 Listener contributor Integrator Leader Project manager role during an interim progress review is to achieve your objectives of knowing the status of operations and influence the course of future events as necessary. During the discussion, he may have any of the following roles. Listener: listen as the individual update you on progress, deviation from plan, problems encountered and solutions proposed. Listen not only to what is said, but also to how things are said. Is the person excited, frustrated, discouraged? Help clarify what is being said by asking questions, and verify what you think is being said by restating your understanding both facts and feelings. Contributor:in many interim reviews, progress, is in line with plans. However, you will occasionally have problems to deal with. When its occurs, you can contribute their solution by directing the other person toward possible course of action. Use your knowledge and experience as necessary to move the project forward. Integrator: An important role of project manager is to integrate the individual parts of project into a compatible whole. Is something being neglected? Is there duplication of effort? How can the people available be last deployed? Leader:perhaps the most important role of the project manager is that of leader. Through a variety of techniques, you must keep the team's effort directed toward the common goal of completing the project according to specifications, on time, and within budget. You must confirm and recognize good performance, correct poor performance, and keep interest and enthusiasm high. PROVIDING FEED BACK Intentions Actions Results Feed back Project managers find many opportunities to provide feed back to those who have a hand in completing the project. Through feed back, individuals learn about the effect their behavior has on others and on the projects success. It serves to maintain good performance and correct poor performance. To be effective, however, feed back must be handled properly. This illustration shows the continuous loop that exists when there is good feed back. Handling negative feedback: 69 1. describe the observed actions and results. 2. ask the individual if those were his or her results. 3. with a typical ‗No' response, ask what different actions would likely produce the desired results. 4. discuss different alternative courses of action. 5. agree upon a way to handle similar situations if they should occur in the future. Check your feed back style Rate your self by placing a check mark in front of each action that is typical of how you handle gibing feed back. The ones you don't check represent opportunities for development. Describe rather than evaluate. By describing observed action and results, the individual is free to use or not to use the information. By avoiding evaluation, you reduce the likelihood of a defensive reaction. Be specific rather than general. Avoid using ‗always' and never. Rather, discuss specific times and events. Avoid generalized conclusions such as ‗you' re too dominating. Rather be specific by saying, when you don't listen to others, you may miss a valuable idea. Deal with behavior that can be changed. Frustration is increased when you remind someone of a shortcoming over which he or she has no control. Be timely, generally, feed back is most useful at the earliest opportunity after the behavior. Communicate clearly. This particularly important when handling negative feed back. One way to ensure clear communication is to have the receiver rephrase the feed back to see if corresponds to what you had in mind. NEGOTIATING FOR MATERIALS, SUPPLIES, AND SERVICES. Negotiating is an important process that takes up as much as 20% of a manger's time. Negotiating is one way to resolve differences, and it can contribute significantly to the success of your project. The ideas presented here will prepare you to negotiate effectively. Definition:- Negotiation is a discussion between two parties with a goal of reaching agreement on issues that separate them when neither party has the power (or the desire to use its power) to force an outcome. Ten guidelines for effective negotiation: 1. Prepare: Do the home work. Know what outcome want and why. Find out what out come the other party wants. Avoid negotiating when your are not prepared ask for the time you need. As a part of your preparation, figure out what you will do if you are unable to come to an agreement. 70 Your power in negotiation develops from attractive alternatives the greater your ability to walk away, the stronger your bargaining position. 2. Minimize perceptual differences: The way you see something can be quite different from how the other party sees it. Don't assume you know the other person's view ask questions to gain understanding and restate your understanding so it can be confirmed or corrected by the other party. 3. Listen: Active, alternative listening is mandatory to effective negotiation. Let the other side have an equal share of the air time. (if you are talking more than 50% of the time, you are not listening enough). In the process, respect silence. Occasionally people need to collect their thoughts before moving ahead. Don't try to fill this time with talking 4. Take notes: you need to know where you are what has been agreed to, what remains to be resolved. Don't rely on memory. Take notes and then summarize your agreement in a memorandum. 5. be creative: early closure and criticism stifle creative thinking. Be willing to set some time aside to explore different and unusual ways to solve your problem. During this time, do not permit criticism of ideas offered. All negotiations can benefit from nonjudgmental creative thinking. 6. Help the other party: good negotiations recognize the other party's problem is their problem as well. Put yourself in the other's position and work to find a solution that meets everyone's needs. After all, no agreement will hold up unless both parties support it. 7. make trade offs: avoid giving something for nothing. At least get some goodwill or an obligation for future payback. The basic principle to follow is to trade what is cheap to you but valuable to the party for what is valuable to you but cheap to the other party. 8. Be quick to apologize: An apology is the quickest / surest way to de escalate negative feelings. It need not be a personal apology. An apology for the situation you are in can be just as effective also, don't contribute to hostility by making hostile remarks. Hostility takes the discussion away from the issues and shifts it to a defense of self where the goal is to destroy the opponent. 9. Avoid ultimatums: An ultimatum requires the other party to either surrender or fight it out. Neither outcome will contribute to future cooperation. Also avoid boxing someone in. this happens when you offer only two alternatives, neither of which is desirable to other person. 10. Set realistic deadlines: Many negotiations continue too long because no deadline exists. A deadline requires both sides to be economical in their use of time. It permits you to question the value of certain discussion and encourages both sides to consider concessions and trade offs in order to meet deadline. RESOLVING DIFFERENCES: The strategy one chooses to resolve differences tends to result from an interplay of assertiveness and co operation. This process can be clouded by emotion jilt times, and when this happens, it is difficult to achieve a satisfactory outcome. Therefore, when you 71 sense that either you or the other persons thinking clouded by emotion, ask to delay discussion a while. The following issues influence assertiveness and cooperation Assertiveness: People tend to be more assertive when an issue is important to them People tend to be more assertive when they are confident of their knowledge People tend to be more assertive when things are going against them. People tend to be less assertive when they feel they are at a power disadvantage Cooperation: People tend to be more cooperative when they respect the other person People tend to be more cooperative when they value the relationship People tend to be more cooperative when they are dependent on the other person to help carry out the decision. Motivating: No matter how well planned and organized a project may be, its chances of success without the commitment of the project team are limited. It is largely up to the project manager to ensure that the project enjoys a culture and an atmosphere which is conductive to achieving the project objectives. Here are some guidelines Quality of work (interesting, challenging, and useful) Sense of belonging (to project team) Feeling of involvement Sense of achievement Recognition of success and effort. Opportunity for development and progression Fulfillment of skills and abilities Increased responsibility Delegating: For any manager, delegation is a critical skill. It is particularly challenging in the context of a project where work groups are temporary and lines of authority are less clearly defined. BENEFITS OF DELIGATION For the For the project For the project team member organization manager (delegator) (delegate) Allows fullest use Frees up time to gain Gives opportunity to learn or of available an overview of practice new skills resources. progress 72 Encourage Ensures highest Enables them to work on more broadest spread of quality results important aspects of company expertise business Develops highest Allows work to be Exposes them to new and level of team work done quicker through challenging situations and morale concurrent activity Styles of delegation: 1. DO AS I 2. ASK MY 3. ASK MY 4. TELL ME WHAT 5. HAVE MY JOB SAY PERMISSION DEVICE YOU'VE DONE Use when you As delegator you You pass control you have enough The ultimate aim of need retain control but to the delegatee, confidence in the the true delegator s immediate expect the but retain a delegate to allow to prepare the over. action or when delegatee to clsoe interest in him / her to brief Recognition over that explaining a come to you wth what he/she you retrospectively you are prepared to fixed process ideas proposes to do move to level 5 can that must be often be a powerful followed motivator to the delegatee and is the mark of a good manager. BLOCKS AND DELEGATION Many of project managers freely admit that they are overloaded with tasks while your team members do not delegate as much as they should. This is discontented because they are not entrusted with is usually either because they have a negative responsibility, so it is important to recognize attitude to delegation or because they are stopping you. The following factors are simply unaware of how and when to do it. That is among the most common blocks to delegation, if you find up difficult to delegate you may end up. FEAR OVER ENTHUSIASM POWERLESSNESS The mistaken beliief that there is we sometimes continue to do no one delegate to. takes we should delegate Powerlessness is first and of loosing control because we enjoy them. foremost a state of mind of up setting subordinates of failure of being outshone by able subordinates GUILT INSECURITY LACK OF ASSERTIVENESS at not delegating soon People who fear for their own Inexperienced managers enough positions often refuse to sometimes overlook delegate for fear that they will opportunities to delegate become dispensable that require them to be assertive 73 Communication within projects: The project manager has a vital role as the facilitator of communications both within the team and between the project and the wider group of stake holders end users/client/superior. SELECTING THE BEST METHOD OF COMMUNICATION High logical complexity Low logical complexity Low emotional High emotional Low emotional High emotional complexity complexity complexity complexity e.g. here is my e.g. we want these e.g. Can I have complete client three changes made to another copy of that e.g. The project will not database the scope of the project document be ready on time Suggestion: E-mail Suggestion: Best done Suggestion: Deliver this would be ideal for this, face to face or message face to face. or the telephone. occasionally on the Suggestion: Put it in The recipient will not Don't waste time with a phone. If it is required writing. If the doubt want to ask face to face in writing, precede with intermation is needed questions. Arrange a interruption unless the an adhoc meeting or fast, use fax or e-mail. formal meeting. request is urgent. phone call. Handling conflict: This is major role performed by the project manager during all phase of the project life cycle. Conflict & people. Conflict is an off spring of disagreement between individuals. It is a basic to human behavior inevitable in all endeavors involving people. Each unique person is bound to have views that differ from those of others & differing views tend to generate conflict which may range from mild irritations to no holds barred defiance. Types of conflicts: Projects conflicts can be grouped in to 3 major categories, i. Interpersonal, where the individual struggles internally with conflict that may or may not be caused or effected by others. ii. Inter personal, where interaction takes place between individuals, and iii. Inter group where the departments or other groups are at odds. A brief description of these common project conflict mode follows. Intra personal conflict. Conflict occurs within an individual when personal professional or job related expectations or hopes are frustrated. The conflict may stem from personal limitations or anxieties that have nothing to do with the project. If inner project do not over flow and turn in to inter personal clashes, they may remain latent and actually not effect the project at all. Inter personal conflict. This may be originate from difference in project management styles, competing aspirations, or personality differences. 74 Interpersonal conflicts involve two or more people and can focus on just above anything. This type of friction calls for custom made solution, which depend on the specific situation and the players. Inter group conflict. When one group or team is pitted against another, inter group conflict results. Just about any subject whether or not its related to the project ca be the cause of the project. Inter group conflicts are normally the result of interpersonal friction between influential project leaders. They can be partly managed by dealing with the conflict on a personal basis through those influential leaders. While conflict may be exclusive, with only one type exiting at a given time, two or more types might also occurs simultaneously. For instance a intrapersonal conflict over a project cost, quality, trade off (―should I take the risk‖) could set of a interpersonal clash. This might consequently cause respective staff groups to rally around the major participants touching of and inter group dispute. Conflicts in project management: Although conflicts crops up in all human endeavors, projects may offer environments particularly susceptible to generating strife. What are the reasons for conflicts in project work? Thamhain and wilemon conducted extensive research on conflict in project management. In an article published in sloan management review, they identify the following seven primary focal points for projects conflict. 1. Project priorities. Differing views over activity sequence for accomplishing project goals. 2. Administrative procedures. Differences regarding how the project will be managed, included reporting and interface relationships, definition of responsibilities, and procedures for administrative support. 3. technical opinions and performance trade offs. Disagreements over technical issues performance specifications, technical trade offs, and performance issues. 4. manpower resources. Differing viewpoints on staffing and personal utilization 5. Cost objectives. This agreements over cost estimate from support areas. 6. Schedules. This agreement related to timing, sequencing, and scheduling of project related task. 7. personality. Interpersonal difference as opposed to technical issues, often ego centered. Benefits of conflict: The positive value of conflict is under estimated. Properly managed, conflict is valuable tool, particularly when conflictive situation are confronted in their early stages. A side from its role as a sensor, conflict has other positive effects. It offers increased challenge for finding new solutions and give groups and individual opportunities for jointly solving a project's problems. 75 Dissent in projects, if handled properly, can constitute a fundamental tool for achieving results. Thrusting the subject into an arena of potential conflict may set off discussion that will ultimately lead to the timely completion of the project. Conflict serves as a signal that something is wrong, thus calling for remedial action. Detrimental effect of conflict Conflicts negative repercussions may be easier relate to then its benefits, since troubles and friction are generally considered to be synonymous with conflict. This unfavorable reputation is not without justification, of course since conflicts adverse side, if not properly managed, can easily over power potential blessings. Here are some of the drw backs. conflicts causes stress. While part of thriving life forms, stress, in some cases, meets out an unhealthy after math. Stress effects human both physically and emotionally breeding ulcers, back pains, and other superiors palpitations. It brings on sleep less nights, irritable out bursts, and periods of inner with drawal, taking its tall in bodily and mental strain. Conflicts creates an un productive atmosphere. In highly conflictive situations, people's productively levels may fall because of the uncertainly generated by clashing views. As long as the conflict persists confusion and ambiguity keep people from producing at their optimum. Conflict may cause loss of status or position power. Depending on how the conflict is handled and who the players are, dispute may put one of the parties in a ―losing ―pose. Paradoxically, this may mean a loss not only for the loser, but ultimately for the winner as well, because the winner has on going stakes in the project over all success. Conflicts is one of the less easily taught aspects of management. To be effective; a manager must be able to lead to inspire other to follow him; this need is all the ives in project management because a project relies so much on the commitment and loyalty of those involved. Unfortunately charisma cannot be bottled and applied in liberal does every morning . however , a number of adjective spring to mind when describing leaders. Leadership: Leadership one of the easily thought aspects of management. To be effective, a manager must be able to lead, to inspire others to follow him. This need is all the stronger in project management because a project relies so much on the commitment and loyalty of those involved. Unfortunately charisma can not be bottled and applied in liberal doses every morning. How ever a number of adjectives spring to mind when describing leaders. Leadership qualities: * Dynamic * Confident * Visionary * Imaginative 76 * Flexible * Analytic * Creative * Decisive * Patient * Sympathetic * Persistent * Organized * Assertive * Goal driven * Persuasive * Charismatic Each of these qualities will be called upon during a project, the successful leader will instinctively know the right approach to take in the right circumstance. Choosing a project manager Project management is not something which can be done by any one, and all too often there is an assumption that if some one can manage a department then that same person can manage a project. The role of the project manager is an important one and fundamental to the success of any project. Organizations make large investments in projects and should make similar investments in the people they call upon to manage those projects. It calls for additional skills and characteristics over and above those which are normally required for line management. These are skills which can mostly be learnt through training and, above all, experience. Many organizations have now instituted project management development programs which reflects its position as professional discipline in its own right. Project manager"s check list 1. Define a project 2.Select strategy 3. Develop specifications 4. Develop a schedule 5. Develop a budget 6. Organize the project team 7. Assign duties & responsibilities 8. Train new team members 9. Monitor progress 10. Take corrective action 11. Provide feed back 12. Test final outcome 13. Delver outcome to client 14. Write operational manual 15. Train client personal 16. Reassign project staff 17. Dispose of surplus equipment- 18. Release facilities Materials & supplies. 19. Evaluate project performance 20. Complete final audit 21. Complete project report 22. Review project with management ********************************* ************************************* Q.8 Write any Four short notes A. RISK MANAGEMENT: 77 Risk management is a structured approach to managing uncertainty related to a threat, through a sequence of human activities including: risk assessment, strategies development to manage it, and mitigation of risk using managerial resources. The strategies include transferring the risk to another party, avoiding the risk, reducing the negative effect of the risk, and accepting some or all of the consequences of a particular risk. Some traditional risk managements are focused on risks stemming from physical or legal causes (e.g. natural disasters or fires, accidents, death and lawsuits). Financial risk management, on the other hand, focuses on risks that can be managed using traded financial instruments. The objective of risk management is to reduce different risks related to a pre selected domain to the level accepted by society. It may refer to numerous types of threats caused by environment, technology, humans, organizations and politics. On the other hand it involves all means available for humans, or in particular, for a risk management entity (person, staff, organization Steps in the risk management process: Establish the context: Establishing the context involves 1. Identification of risk in a selected domain of interest 2. Planning the remainder of the process. 3. Mapping out the following: o the social scope of risk management o the identity and objectives of stakeholders o the basis upon which risks will be evaluated, constraints. 4. Defining a framework for the activity and an agenda for identification. 5. Developing an analysis of risks involved in the process. 6. Mitigation of risks using available technological, human and organizational resources. Identification: After establishing the context, the next step in the process of managing risk is to identify potential risks. Risks are about events that, when triggered, cause problems. Hence, risk identification can start with the source of problems, or with the problem itself. Source analysis Risk sources may be internal or external to the system that is the target of risk management. Examples of risk sources are: stakeholders of a project, employees of a company or the weather over an airport. Problem analysis Risks are related to identified threats. For example: the threat of losing money, the threat of abuse of privacy information or the threat of 78 accidents and casualties. The threats may exist with various entities, most important with shareholders, customers and legislative bodies such as the government. When either source or problem is known, the events that a source may trigger or the events that can lead to a problem can be investigated. For example: stakeholders withdrawing during a project may endanger funding of the project; privacy information may be stolen by employees even within a closed network; lightning striking a Boeing 747 during takeoff may make all people onboard immediate casualties. The chosen method of identifying risks may depend on culture, industry practice and compliance. The identification methods are formed by templates or the development of templates for identifying source, problem or event. Common risk identification methods are: Objectives-based risk identification Organizations and project teams have objectives. Any event that may endanger achieving an objective partly or completely is identified as risk. Scenario-based risk identification In scenario analysis different scenarios are created. The scenarios may be the alternative ways to achieve an objective, or an analysis of the interaction of forces in, for example, a market or battle. Any event that triggers an undesired scenario alternative is identified as risk - see Futures Studies for methodology used by Futurists. Taxonomy-based risk identification The taxonomy in taxonomy-based risk identification is a breakdown of possible risk sources. Based on the taxonomy and knowledge of best practices, a questionnaire is compiled. The answers to the questions reveal risks. Taxonomy-based risk identification in software industry Common-risk Checking In several industries lists with known risks are available. Each risk in the list can be checked for application to a particular situation. An example of known risks in the software industry is the Common Vulnerability and Exposures. Risk Charting This method combines the above approaches by listing Resources at risk, Threats to those resources Modifying Factors which may increase or reduce the risk and Consequences it is wished to avoid. Creating a matrix under these headings enables a variety of approaches. One can begin with resources and consider the threats they are exposed to and the consequences of each. Alternatively one can start with the threats and examine which resources they would affect, or one can begin with the consequences and determine which combination of threats and resources would be involved to bring them about. Assessment: Once risks have been identified, they must then be assessed as to their potential severity of loss and to the probability of occurrence. These quantities can be either simple to 79 measure, in the case of the value of a lost building, or impossible to know for sure in the case of the probability of an unlikely event occurring. Therefore, in the assessment process it is critical to make the best educated guesses possible in order to properly prioritize the implementation of the risk management plan. The fundamental difficulty in risk assessment is determining the rate of occurrence since statistical information is not available on all kinds of past incidents. Furthermore, evaluating the severity of the consequences (impact) is often quite difficult for immaterial assets. Asset valuation is another question that needs to be addressed. Thus, best educated opinions and available statistics are the primary sources of information. Nevertheless, risk assessment should produce such information for the management of the organization that the primary risks are easy to understand and that the risk management decisions may be prioritized. Thus, there have been several theories and attempts to quantify risks. Numerous different risk formulae exist, but perhaps the most widely accepted formula for risk quantification is: Rate of occurrence multiplied by the impact of the event equals risk Later research has shown that the financial benefits of risk management are less dependent on the formula used but are more dependent on the frequency and how risk assessment is performed. In business it is imperative to be able to present the findings of risk assessments in financial terms. Robert Courtney Jr. (IBM, 1970) proposed a formula for presenting risks in financial terms. The Courtney formula was accepted as the official risk analysis method for the US governmental agencies. The formula proposes calculation of ALE (annualised loss expectancy) and compares the expected loss value to the security control implementation costs (cost-benefit analysis). Limitations: If risks are improperly assessed and prioritized, time can be wasted in dealing with risk of losses that are not likely to occur. Spending too much time assessing and managing unlikely risks can divert resources that could be used more profitably. Unlikely events do occur but if the risk is unlikely enough to occur it may be better to simply retain the risk and deal with the result if the loss does in fact occur. Prioritizing too highly the risk management processes could keep an organization from ever completing a project or even getting started. This is especially true if other work is suspended until the risk management process is considered complete. It is also important to keep in mind the distinction between risk and uncertainty. Risk can be measured by impacts x probability. Risk management activities as applied to project management In project management, risk management includes the following activities: 80 Planning how risk management will be held in the particular project. Plan should include risk management tasks, responsibilities, activities and budget. Assigning a risk officer - a team member other than a project manager who is responsible for foreseeing potential project problems. Typical characteristic of risk officer is a healthy skepticism. Maintaining live project risk database. Each risk should have the following attributes: opening date, title, short description, probability and importance. Optionally a risk may have an assigned person responsible for its resolution and a date by which the risk must be resolved. Creating anonymous risk reporting channel. Each team member should have possibility to report risk that he foresees in the project. Preparing mitigation plans for risks that are chosen to be mitigated. The purpose of the mitigation plan is to describe how this particular risk will be handled – what, when, by who and how will it be done to avoid it or minimize consequences if it becomes a liability. Summarizing planned and faced risks, effectiveness of mitigation activities, and effort spent for the risk management ************************************ *********************************** B. GANTT CHART A Gantt chart is a popular type of bar chart that illustrates a project schedule. Gantt charts illustrate the start and finish dates of the terminal elements and summary elements of a project. Terminal elements and summary elements comprise the work breakdown structure of the project. Some Gantt charts also show the dependency (i.e., precedence network) relationships between activities. Gantt charts can be used to show current schedule status using percent-complete shadings. 81 The first Gantt Chart was developed in 1896 by Karol Adamiecki, who called it a harmonogram. Because Adamiecki did not publish his chart until 1931, it now bears the name of Henry Gantt (1861–1919), who designed his chart in 1915. The 1980s, personal computers eased the creation and editing of elaborate Gantt charts. These desktop applications were intended mainly for project managers and project schedulers. In the late 1990s and early 2000s, Gantt charts became a common feature of web-based applications, including collaborative groupware. Although now regarded as a common charting technique, Gantt charts were considered revolutionary when they were introduced. In recognition of Henry Gantt's contributions, the Henry Laurence Gantt Medal is awarded for distinguished achievement in management and in community service. Gantt charts are a project planning tool that can be used to represent the timing of tasks required to complete a project. Because Gantt charts are simple to understand and ea sy to construct, they are used by most project managers for all but the most complex projects. In a Gantt chart, each task takes up one row. Dates run along the top in increments of days, weeks or months, depending on the total length of the project. The expected time for each task is represented by a horizontal bar whose left end marks the expected beginning of the task and whose right end marks the expected completion date. Tasks may run sequentially, in parallel or overlapping. As the project progresses, the chart is updated by filling in the bars to a length proportional to the fraction of work that has been accomplished on the task. This way, one can get a quick reading of project progress by drawing a vertical line through the chart at the current date. Completed tasks lie to the left of the line and are completely filled in. Current tasks cross the line and are behind schedule if their filled-in section is to the left of the line and ahead of schedule if the filled-in section stops to the right of the line. Future tasks lie completely to the right of the line. In constructing a Gantt chart, keep the tasks to a manageable number (no more than 15 or 20) so that the chart fits on a single page. More complex projects may require subordinate charts which detail the timing of all the subtasks which make up one of the main tasks. For team projects, it often helps to have an additional column containing numbers or initials which identify who on the team is responsible for the task. If it is expected to produce a Gantt chart and to keep it up to date for use in planning your project. Need to follow these guidelines in creating chart: Use weeks as the time unit Include the Mid-project review, Design Show, and Final report due as milestones. We suggest about 4-10 milestones for your project. 82 Show more detail on design tasks, less detail on reports/documentation/presentation tasks. Should have about 3/4 design tasks, 1/4 documentation/presentation related tasks. Getting parts can take 2 weeks or more, depending on the part. If your company is building parts for your prototype, getting your part scheduled can take a long time. Build these delays into your planning chart. Review and update Gantt chart every 14 days, more often if needed. Project Planning Basics A "Project" is a set of activities which ends with specific accomplishment and which has (1) Non-routine tasks, (2) Distinct start/finish dates, and (3) Resource constraints (time/money/people/equipment). "Tasks" are activities which must be completed to acheive project goal. Break the project into tasks and subtasks. Tasks have start and end points, are short relative to the project and are significant (not "going to library", but rather, "search literature"). Use verb-noun form for naming tasks, e.g. "create drawings" or "build prototype". Use action verbs such as "create", "define" and "gather" rather than "will be made". Each task has a duration. Very difficult to estimate durations accurately. Doubling your best guess usually works well. "Milestones" are important checkpoints or interim goals for a project. Can be used to catch scheduling problems early. Name by noun-verb form, e.g. "report due", "parts ordered", "prototype complete". Your plan will evolve so be flexible and update on a regular basis. It also helps to identify risk areas for project, for example, things you don't know how to do but will have to learn. These are risky because you may not have a good sense for how long the task will take. Or, you may not know how long it will take to receive components you purchased for a project. Work Breakdown Structure A work breakdown structure (WBS) is a categorized list of tasks with an estimate of resources required to complete the task. An example WBS appears below. Est WBS Task Person Who Resources M&S # Description -Hrs 5 Profile motor power 5.1 Design test stand 20 SE, JM Pro/E 5.2 Build test stand 15 SE, JM Frame & brake parts $35 83 5.3 Test 3 motors 3 SE, JM Stroboscope $75 5.4 Plot torque vs. speed 2 JM Excel (M&S = Materials & Supplies) Using Excel to Make Gantt Charts A sample Gantt chart made using Microsoft Excel appears in the figure which accompanies this document. If today's date were May 13, Task A would be behind schedule, Task B ahead and Task C right on schedule. The events marked by fat dots are milestones. Gantt charts made with Excel are easy to update and maintain. Here's how to do it. Select tasks from your work breakdown structure. Your WBS also indicates the person- hours of effort and people responsible for the tasks. Assign each task tentative start and stop dates (or durations) based on the information in the WBS. Also list important milestones and their dates. If you have more than 15 or 20 tasks, split your project into main tasks and subtasks, then make an overall Gantt chart for the main tasks and separate Gantt charts for the subtasks which make up each main task. Decide what resolution to use in the timeline. For projects of three months or less, use days, for longer projects use weeks or months, and for very short project use hours. For these instructions, we will assume you have chosen a resolution of days. Fire up Excel. Under Page Setup, select landscape orientation, and then select the options to center the chart horizontally and vertically on the page. Also under Page Setup, activate the "fit to one page" button. (Note that if the text comes out too small, you may have to print your chart on two pages and paste together. Even better, adjust the resolution of your date scale or drop less important tasks to make your chart fit comfortably on one page.) Still under Page Setup, set header and footer to be blank. (It's better to write the title right on the spreadsheet rather than use the header for the title. Finally, under Page Setup, turn off the option to print gridlines. Set up the cells. You can use the sample (found elsewhere on this web page) as a guide. Use the border command to draw boxes around the appropriate cells. Enter your scheduling data. To make the gray bars which indicate length of task, select the appropriate cells, then the fill command (one of the buttons near the top). As the project progresses, fill in the gray bars with black to denote the fraction of a task that is complete. Project Management Packages You can also create Gantt charts using a project managment computer package. A sample chart made using Microsoft Project appears below. Project is the most widely used 84 scheduling tool for small projects. It is available on the PC's in MechE 308 for use by IT students. We strongly recommend that you use MS Project to create your Gantt charts, if nothing else because it will give you experience using this important package. To embedd a Project Gantt chart into a Word document, get the chart showing on the screen, then Edit > Copy Picture... > to GIF file. From there you can import the gif file into Word. You may have to rotate it 90 degrees in MS Paint to get it to fit and be readable. Advantages & limitations: Often the project has important events which you would like to appear on the project timeline, but which are not tasks. For example, you may wish to highlight when a prototype is complete or the date of a design review. You enter these on a Gantt chart as "milestone" events and mark them with a special symbol, often an upside-down triangle. Gantt charts have become a common technique for representing the phases and activities of a project work breakdown structure (WBS), so they can be understood by a wide audience.A common error made by those who equate Gantt chart design with project design is that they attempt to define the project work breakdown structure at the same time that they define schedule activities. This practice makes it very difficult to follow the 100% Rule. Instead the WBS should be fully defined to follow the 100% Rule, then the project schedule can be designed. 85 Although a Gantt chart is easily comprehended for small projects that fit on a single sheet or screen, they can become quite unwieldy for projects with more than about 30 activities. Larger Gantt charts may not be suitable for most computer displays. A related criticism is that Gantt charts communicate relatively little information per unit area of display. That is, projects are often considerably more complex than can be communicated effectively with a Gantt chart. Gantt charts only represent part of the triple constraints of projects, because they focus primarily on schedule management. Moreover, Gantt charts do not represent the size of a project or the relative size of work elements, therefore the magnitude of a behind- schedule condition is easily miscommunicated. If two projects are the same number of days behind schedule, the larger project has a larger impact on resource utilization, yet the Gantt does not represent this difference. Although project management software can show schedule dependencies as lines between activities, displaying a large number of dependencies may result in a cluttered or unreadable chart. Because the horizontal bars of a Gantt chart have a fixed height, they can misrepresent the time-phased workload (resource requirements) of a project. In the example shown in this article, Activities E and G appear to be the same size, but in reality they may be orders of magnitude different. A related criticism is that all activities of a Gantt chart show planned workload as constant. In practice, many activities (especially summary elements) have front-loaded or back-loaded work plans, so a Gantt chart with percent- complete shading may actually miscommunicate the true schedule performance status. ******************************* **************************************** E. "S" CURVE: 86 Project Cost% Time S- Curve is a phenomenon showing the typical path of product performance in relation to investment in R&D. At first performance rises fast and from then on, once a deadline in the slope occurs the productivity is unlikely to increase much by heavy R&D expenses. More likely, a technological discontinuity will occur where an innovative technology is introduced and rapidly creates massive gains in productivity. At the start of the curve, a significant effort is needed to get an achievement, but once this basic learning has been done, productivity can advance significantly with little marginal effort. After a few years further advances get more and more fractional. As technology generation change, few incumbents survive because of a lack of adapting to the new technology. The s-curve function allows the user to define a smooth response yet still maintain a high acceleration. In many applications the ideal step response is not one where the maximum speed is reached instantaneously. The jarring effect of high acceleration and deceleration can damage the application, yet a slow acceleration can slow down production dramatically. In these applications the ideal step response is to have a slow initial acceleration, leading into a high acceleration to a low deceleration to the required speed. The resultant speed curve is what is known as an s-curve The S Curve is a well known project management tool and it consists in "a display of cumulative costs, labour hours or other quantities plotted against time".The name derives from the S-like shape of the curve, flatter at the beginning and end and steeper in the middle, because this is the way most of the projects look like. The S curve can be considered as an indicator and it's used for many applications related to project management such as: target, baseline, cost, time etc. That's why there is a variety of S Curves such as: -Cost versus Time S Curve;(appropriate for projects that contain labour and non-labour tasks). -Target S Curve;(This S Curve reflects the ideal progress of the project if all tasks are completed as currently scheduled) -Value and Percentage S Curves;(Percentage S Curves are useful for calculating the project's actual percentage complete) -Actual S Curve;(This S Curve reflects the actual progress of the project to date) In order to be able to generate a S Curve, A Baseline and Production Schedule are necessary because they contain important information for each task: -the Baseline - contains information about Actual Start date and finish date. -The Baseline - can also contain information about Man Hours and costs. -The Production Schedule contains information about the actual percentage complete. 87 There are some software scheduling packages that generate automatically S Curves. For example MS Project does not have this possibility so a third party software application is needed to process the Baseline and Production Schedule data and generate the needed S Curve.( for example S Curve Generator that integrates with MS EXcel to generate S Curves). Sample project s Curve Project managers often track project schedules and milestones as a mechanism for managing the project and detecting risk. The monitoring is usually at a task level of detail and often quite labor intensive. As it turns out, there is another mechanism for monitoring project state. While its not at the finely grained level of detail as the individual task, it does provide wonderful insight into the nuance of a project. You see projects have a tempo to their development that is usually consistent over time and that can be represented graphically by plotting cumulative effort vs. time. The tempo usually takes the form of an S Curve which represents the normal ramping of a project. An S Curve is a graphical display of cumulative cost, value, labor hours or in our case Active Time vs. time. The name derives from the S like shape of the curve, flatter at the beginning and end and steeper in the middle, which is typical of most software projects. The beginning represents the typical slow, methodical start to projects, as the team sorts through the work and determines how to approach the project. The end represents a deceleration as the work runs out and the middle is the acceleration period as the team attacks the work. Steps in the S curve process: 4. Analyse technology expenditure (both financial & economic ) and achieved gains in productivity. 88 5. Observe the development of this relation over tie and prepare for strategic realignment when the process slows down from rapid growth. Rules of thumb for detection: Feeling among management the R&D productivity is dedining. More and more missed R&D deadlines. Sales-growth shifts to monitor segments. Trend of small firms in industry to invest in radically new technology Overall loss of productivity in industry. Strength of the S-Curve Benefits Indicates the strategic alignment when productivity gains deadline. Havior. Limitations of the S-Curve: The model does not give any clear hints to managers on how to attract in the face of technological discontinuity. It cannot be inferred from the model, how big the gains will be from new technologies. The model does not imply how a new technology will look like and by whom it will be introduced. The model is a generalization of observed technology paths. In reality the size and structure of the S can vary ******************************** *************************************** F. USE OF COMPUTER SOFTWARE IN PROJECT MANAGEMENT Project management software is a term covering many types of software, including scheduling, cost control and budget management, resource allocation, collaboration software, communication, quality management and documentation or administration systems, which are used to deal with the complexity of large projects. Tasks of project management software"s: 89 One of the most common tasks is to schedule a series of events, and the complexity of this task can vary considerably depending on how the tool is used. Some common challenges include Events which depend on one another in different ways or dependencies Scheduling people to work on, and resources required by, the various tasks commonly termed resource scheduling Dealing with uncertainties in the estimates of the duration of each task Arranging tasks to meet various deadlines Juggling multiple projects simultaneously to meet a variety of requirements Calculating critical path: In many complex schedules, there will be a critical path, or series of events that depend on each other, and whose durations directly determine the length of the whole project (see also critical chain). Some software applications (for example, Dependency Structure Matrix solutions) can highlight these tasks, which are often a good candidate for any optimization effort. Providing information: Project planning software needs to provide a lot of information to various people, to justify the time spent using it. Typical requirements might include: Tasks lists for people, and allocation schedules for resources Overview information on how long tasks will take to complete Early warning of any risks to the project Information on workload, for planning holidays Evidence Historical information on how projects have progressed, and in particular, how actual and planned performance are related Approaches to project management software: Desktop: Project management software can be implemented as a program that runs on the desktop of each user. This typically gives the most responsive and graphically-intense style of interface. Desktop applications typically store their data in a file, although some have the ability to collaborate with other users (see below), or to store their data in a central database. Even a file-based project plan can be shared between users if it's on a networked drive, and no two people want to access it at once. Desktop applications can be written to run in a heterogeneous environment of multiple operating systems, although it's unusual. Web-based: Project management software can be implemented as a Web application, accessed through an intranet or extranet using a web browser. This has all the usual advantages and disadvantages of web applications: 90 Can be accessed from any type of computer without installing software Ease of access-control Naturally multi-user Only one software version and installation to maintain Typically slower to respond than desktop applications Project information not available when the user (or server) is offline. Some packages do allow the user to "go-offline" Personal : A personal project management application is one used at home, typically to manage lifestyle or home projects. There is considerable overlap with single user systems, although personal project management software typically involves simpler interfaces. See also non-specialised tools below. Single user : A single-user system is programmed with the assumption that only one person will ever need to edit the project plan at once. This may be used in small companies, or ones where only a few people are involved in top-down project planning. Desktop applications generally fall into this category. Collaborative : A collaborative system is designed to support multiple users modifying different sections of the plan at once, for example, updating the areas they personally are responsible for such that those estimates get integrated into the overall plan. Web-based tools, including extranets, generally fall into this category, but have the limitation that they can only be used when the user has live Internet access. To address this limitation, client-server-based software tools exist that provide a Rich Client that runs on users' desktop computer and replicate project and task information to other project team members through a central server when users connect periodically to the network and other tasks. Some tools allow team members to check out their schedules (and others' as read only) to work on them while not on the network. When reconnecting to the database, any changes are synchronized with the other schedules. Integrated : An integrated system combines project management or project planning, with many other aspects of company life. For example, projects can have bug tracking issues assigned to each project, the list of project customers becomes a customer relationship management module, and each person on the project plan has their own task lists, calendars, and messaging functionality associated with their projects. Similarly, specialized tools like SourceForge integrate project management software with source control (CVS) software and bug-tracking software, so that each piece of information can be integrated into the same system. Non-specialised tools : While specialized software may be common, and heavily promoted by each vendor, there are a vast range of other software (and non-software) tools used to plan and schedule projects. Calendaring software can often handle scheduling as easily as dedicated software 91 Spreadsheets are very versatile, and can be used to calculate things not anticipated by the designers. Criticisms of project management software The following may apply in general, or only to specific products. May not be derived from a sound project management method. For example, displaying the Gantt chart view by default encourages users to focus on task scheduling too early, rather than identifying objectives and deliverables. May be inconsistent with the type of project management method. Focuses primarily on the planning phase and does not offer enough functionality for project tracking, control and in particular plan-adjustment. There may be excessive dependency on the first paper print-out of a project plan, which is simply a snapshot at one moment in time. The plan is dynamic; as the project progresses the plan must change to accommodate tasks that are completed early, late, re-sequenced, etc. Good management software should not only facilitate this, but assist with impact assessment and communication of plan changes. Does not make a clear distinction between the planning phase and post planning phase, leading to user confusion and frustration when the software does not behave as expected. For example, shortening the duration of a task when an additional human resource is assigned to it while the project is still being planned. Offer complicated features to meet the needs of project management professionals, which must be understood in order to effectively use the product. Additional features may be so complicated as to be of no use to anyone. Complex task prioritization and resource leveling algorithms for example can produce results that make no intuitive sense, and over allocation is often more simply resolved manually. Some people may achieve better results using simpler technique, (e.g. pen and paper), yet feel pressured into using project management software by company policy (discussion). Similar to PowerPoint, project management software might shield the manager from important interpersonal contact. New types of software are challenging the traditional definition of Project Management. Frequently, users of project management software are not actually managing a discrete project. For instance, managing the ongoing marketing for an already-released product is not a "project" in the traditional sense of the term; it does not involve management of discrete resources working on a something with a discrete beginning/end. Groupware applications now add "project management" features that directly support this type of workflow-oriented project management. Classically-trained Project Managers may argue whether this is "sound project management." However, the end-users of such tools will refer to it as such, and the de-facto definition of the term Project Management may change. 92 When there are multiple larger projects, project management software can be very useful. Nevertheless, one should probably not use management software if only a single small project is involved, as management software incurs a larger time- There are many PERT & CPM computer programs available, each with its own variations and it is well worth shopping around to discover the system which best suits ones own needs. All computer programs have good user guides. How ever it must be noted here that computer programs are not a substitute for the basic skills that you must posses to manage projects. A computer program which is in effect, a user friendly network analysis program is only a tool in the planning, evaluation and control of projects. Over a million copies of project management computer software have been sold. You would think that with somany scheduling programs around, the world would run like clock. But you still here about projects being finished late, over spent under scope, and at less than required performance. The simple fact is the project management is more than just scheduling. Software: Purpose built computer software packages are available to help project managers plan and coordinate projects. If your project is too complex to plan and co ordinate manually, you will almost certainly find a package to suit you. Do you really need it? Project software is no more than a vehicle to carry your project plan. If you plan is relatively simple, the demands of the software may be out of all proportional to the benefits you can derive from using it. You may even find that instead of making your job easier, the software is creating extra work. Computerized diary system If you are running a project substaintly on your own and with a relatively simple budget, and electronic dairy system may suits your scheduling needs. These now come as standard with many major office software packages. They can schedule tasks for particular time or days, post reminders for you and others, and allow you to monitor progress. If you and your project team are all on the same computer network, you can have access to each others dairies, making it easy to co ordinate meetings and monitor activity. Spread sheet applications: A standard spread sheet application may be able to generate graphs showing budget and actual cost and time usage with far less fulls then specialist software. The advantage of a standard package is that you can decide how much are how little detail to include. In addition if you are already familier with the program you will not have to spend time learning a new systm. 93 Specialist project software: If you are certain that you need a specialist software, decide in advance what you need, then loom for the program that will deliver this. Do not design your specification around what the program can do. If you do features that you donot really need may seem essential as soon as you are aware that they exist. Deciding what you want: Some questions that may help you to clarify what you need are How many people need access to the software What software are they already used to? How much additional training will they need? What package can we supported in your companies IT environment? What reports do I need? How do I want to display my plan? How much is my budget? *********************************** *********************************** 94
Pages to are hidden for
"Project_mgmt"Please download to view full document