Q.

1 List and explain the traits if a professional manager

Fig. 7.3: Instruments of revolutionary change Let us discuss each of these instruments. a) Reengineering: This is a process by which managers redesign a bundle of tasks into roles and functions so that organisational effectiveness is achieved. By doing so dramatic improvements in critical measures of performance like cost, quality and service are expected. There will be a radical rethink about the business processes adopted. A business process may be of any activity like inventory control, product design, orders processing, and delivery systems. No reference is taken to the existing process and an entirely new process is adopted. The following rules for reengineering are effective: i) Make changes with the outcome in mind not the tasks that result in them. ii) Make the users of the results of the process effect the change. iii) Let the people on the spot decide on the solution decentralise. b) E-Engineering: The term E-Engineering refers to the attempts of companies to make use of all kinds of information systems, to make their functions efficient. New information systems are installed for conducting all business processes in the organisation. The use of electronic communication within the organisation enables frequent interactions between employees and results in better communication. Typically meetings require their presence, but with teleconferencing a lot of time and money is saved. Data have repositories which are accessible, transferable and updatable instantly and used by all concerned. Cross-functional workflows make it easier to coordinate activities. The increase in efficiency makes the organisation meet customers requirements faster. All these result in widespread utilisation of knowledge in the organisation. It helps in creating and making available high quality of information. The information system also comprises of intranet and internet solutions to carry on their regular activities online. c) Restructuring: This is attempted with change in authority and task relationships of managers. The move from the functional form or a standard division structure to combine or divide areas of control and authority to facilitate better coordination and/or workflow can be described as restructuring. In the process, a few jobs may not be there. Few people may have multi-functional activities. The main purpose is to reduce bureaucratic costs. This is because of a change in strategy. Downsizing is also a way of restructuring.

d) Innovation: It is the successful use of skills and resources in such a way that the outcome effectively meets customers needs. Changes in technology have made computers cheaper, faster and more user friendly. This has made a thorough change in the skills of employees and managers. Every company needs to adopt new methods, find them and to make them relevant in the changing world. The thrust in every department/function should be to do things better with new methods. A culture that promotes this thought across the organisation is the best way to benefit from it. For promotion, suitable people have to be selected, trained, empowered and rewarded. A thorough change in the way problems are solved is needed. The Project Manager may have to initiate the change process to increase the effectiveness of his team. Being a key person and the change agent in the organisation, his actions are always under scrutiny. If he takes initiative, whenever the opportunity arises, to effect incremental changes, he will face minimum resistance both by the top management and his team members.

Q.2 Describe in brief the various aspects of programme management?

a programme manager will address risks and issues but focusing on impacts for the overall initiative and the best interests of the organisation as a whole. A project manager performing the same tasks would, in contrast, address risks and issues to delivering the specific defined deliverables of the concerned project. After gaining a significant insight into programme and project management, let us have a look on effective programme management. Effective programme management involves: Focusing on the various strategic initiatives taken up for multiple projects and the issues related to benefits and risks Bringing about the attention of management to a defined set of benefits, which are understood immediately, which are managed throughout the implementation and completion Helping top management to set priorities, choosing options and allocate resources Setting up mechanisms to measure and ensure that the projects making contributions for realising expected business benefits Ensuring that the effects of the programme driven changes are coordinated, the transitions are successfully managed. The operations are effective and efficient.

Q.3 Compare the following: a. Traditional Vs. Projectised Organization

Traditional organisations Projectised organisations They have the formal organisation They have teams comprising structure, with departments, functions, members who are responsible for

sections having a hierarchy of managers and their assistants. All of the managers function on a continuous basis catering to a series of requirements issued by the planning department. An assembly of various units of their production forms a products and a variety of such products make up the business of the company. No particular member or a department or a team is responsible for the completion of any particular product. Their creativity and innovation is in particular respect of their jobs. Most of the members do not get exposed to other areas of operations in the organisation. They become specialists and insular.

completing one entire deliverable product. The teams will have all the resources required to finish the jobs.

They have a time schedule within which all the elements of the projects have to be completed. There is greater accountability among team members and everyone is responsible for the delivery.

It is found that a sense of ownership of the project motivates team members to be creative, cooperative among them to achieve high productivity.

a) Reengineering: This is a process by which managers redesign a bundle of tasks into roles and functions so that organisational effectiveness is achieved. By doing so dramatic improvements in critical measures of performance like cost, quality and service are expected. There will be a radical rethink about the business processes adopted. A business process may be of any activity like inventory control, product design, orders processing, and delivery systems. No reference is taken to the existing process and an entirely new process is adopted. The following rules for reengineering are effective: i) Make changes with the outcome in mind not the tasks that result in them. ii) Make the users of the results of the process effect the change. iii) Let the people on the spot decide on the solution decentralise. b) E-Engineering: The term E-Engineering refers to the attempts of companies to make use of all kinds of information systems, to make their functions efficient. New information systems are installed for conducting all business processes in the organisation. The use of electronic communication within the organisation enables frequent interactions between employees and results in better communication.

Typically meetings require their presence, but with teleconferencing a lot of time and money is saved. Data have repositories which are accessible, transferable and updatable instantly and used by all concerned. Cross-functional workflows make it easier to coordinate activities. The increase in efficiency makes the organisation meet customers requirements faster. All these result in widespread utilisation of knowledge in the organisation. It helps in creating and making available high quality of information. The information system also comprises of intranet and internet solutions to carry on their regular activities online.

Q.4 List out the macro issues in project management and explain each.

4.4.2 Macro Issues a. Evolving Key Success Factors (KSF) Upfront: In order to provide complete stability to fulfilment of goals, a project manager needs to constantly evaluate the key success factors from time to time. While doing so, he needs to keep the following aspects of KSFs in mind: The KSF should be evolved based on a basic consensus document (BCD). KSF will also provide an input to effective exit strategy (EES). Exit here does not mean exit from the project but from any of the drilled down elemental activities which may prove to be hurdles rather than contributors. Broad level of KSF should be available at the conceptual stage and should be firmed up and detailed out during the planning stage. The easiest way would be for the team to evaluate each step for chances of success on a scale of ten. KSF should be available to the management duly approved by the project manager before execution and control stages. KSF rides above normal consideration of time and cost at the levels encompassing client expectation and management perception time and cost come into play as subservient to these major goals. b. Empowerment Title (ET): ET reflects the relative importance of members of the organisation at three levels: i) Team members are empowered to work within limits of their respective allocated responsibilities. The major change from bureaucratic systems is an expectation from these members to innovate and contribute to time and cost. ii) Group leaders are empowered additionally to act independently towards client expectation and are also vested with some limited financial powers. iii) Managers are empowered further to act independently but to maintain a scientific balance among time, cost, expectation and perception, apart from being a virtual advisor to the top management. c. Partnering Decision Making (PDM): PDM is a substitute to monitoring and control. A senior with a better decision making process will work closely with the project managers as

well as members to plan what best can be done to manage the future better from past experience. The key here is the active participation of members in the decision making process. The ownership is distributed among all irrespective of levels the term equally should be avoided here since ownership is not quantifiable. The right feeling of ownership is important. This step is most difficult since junior members have to respond and resist being pushed through sheer innovation and performance this is how future leaders would emerge. The PDM process is made scientific through: i) Earned value management system (EVMS) ii) Budgeted cost of work scheduled (BCWS) iii) Budgeted cost of work performed (BCWP) iv) Actual cost of work performed (ACWP) d. Management by Exception (MBE): No news is good news. If a member wants help he or she locates a source and proposes to the manager only if such help is not accessible for free. Similarly, a member should believe that a team leaders silence is a sign of approval and should not provoke comments through excessive seeking of opinions. In short leave people alone and let situation perform the demanding act. The bend limit of MBE can be evolved depending on the sensitivity of the nature and size of the project. MBE provides and facilitates better implementation of effectiveness of empowerment titles. MBE is more important since organisations are moving toward multiskilled functioning even at junior most levels.

Q.5 Describe the various steps in risk management listed below

Risk Identification

11.3 Risk Identification Risk identification occurs at each stage of the project life cycle. To identify risks, we must first define risk. As defined earlier, risks are potential problems, ones that are not guaranteed to occur. When people begin performing risk identification they often start by listing known problems. Known problems are not risks. During risk identification, you might notice some known problems. If so, just move them to a problem list and concentrate on future potential problems. As projects evolve through project development so too does the risk profile. Project knowledge and understanding keep growing, hence previously identified risks may change and new risks identified throughout the life of the project. Here we will discuss various tools and techniques available for risk identification. The best and most common methodology for risk identification is done using a brainstorming session. The brainstorm typically takes 15-30 minutes. You have to be sure to invite anyone who can help the team think of risks. Invite the

project team, customer, people who have been on similar projects, and experts in the subject area of the project. Involving all stakeholders is very important. Limit the group size to nine people. In the brainstorming session, participants discuss out potential problems that they think could harm the project. New ideas are generated based on the items on the brainstorm list. A project manager can also use the process to refer to a database of risk obtained from past. Here, prior experience and learning from past project plays a very important role. The information obtained from such databases can help the project manager to evaluate and assess the nature of the risk and its impact on the project. Also to a great extent the judgment of the project manager based upon his past experience comes very handy in dealing with risks. Another important method is to generate alternative solution or methodology to deal with risk. Generate solution by means of group review meetings or a brainstorm session. However, consider the following points during a brainstorm session: Selection of weak areas in a project, such as unknown technology being used or to be used Things those are critical or extremely important to the effort, such as the timely delivery of a vendors database software, creation of translators, or a user interface that meets the customers needs Things that have caused problems in the past, such as loss of key staff, missed deadlines, or error-prone software Some examples of risks that may be identified in such sessions are: We may not have the requirements right The technology is untested Key people may leave The server wont restart in situation X People might resist the change Any potential problem, or critical project feature, is a good candidate for the risk list. Once we have created a list, work with the group to clarity each item. Also ensure that duplicate items are removed. The output of this step should include: Name of the risk Detailed description of risk event Risk Trigger Risk Type Potential Response

 Comments, if any

Risk Analysis:

11.4 Risk Analysis The first step in risk analysis is to make each risk item more specific. Risks such as, Lack of management buy-in, and people might leave, are a little ambiguous. In these cases the group might decide to split the risk into smaller specific risks, such as, manager decides that the project is not beneficial, Database expert might leave, and Webmaster might get pulled off the project. The next step is to set priorities and determine where to focus risk mitigation efforts. Some of the identified risks are unlikely to occur, and others might not be serious enough to worry about. Paretos law studied earlier applies here. During the analysis, discuss with the team members each risk item to understand how devastating it would be if it did occur, and how likely it is to occur. This way you can gauge the probability of occurrence and the impact created. You can form a matrix based on the likeliness of occurrence and the impact created as shown in table 11.2. For example, if you had a risk of a key person leaving, you might decide that it would have a large impact on the project, but that it is not very likely.

Table 11.1: Risk Analysis In the process, we make the group agree on how likely it thinks each risk item is to occur, using a simple scale from 1 to 10 (where 1 is very unlikely and 10 is very likely). The group then rates how serious the impact would be if the risk did occur, using a simple scale from 1 to 10 (where 1 is little impact and 10 is very large). To use this numbering scheme, first pick out the items that rate 1 and 10, respectively. Then rate the other items relative to these boundaries. To determine the priority of each risk item, calculate the product of the two values, likelihood and impact. This priority scheme helps push the big risks to the top of the list, and the small risks to the bottom. It is a usual practice to analyse risk either by sensitivity analysis or by probabilistic analysis. This is shown in figure 11.5.

Fig. 11.5: Quantitative risk analysis Sensitivity Analysis: In sensitivity analysis, a study is done to analyse the changes in the variable values because of a change in one or more of the decision criteria. Probabilistic Analysis: In the probability analysis, the frequency of a particular event occurring is determined, based on which its average weighted average value is calculated. Each outcome of an event resulting in a risk situation in a risk analysis process is expressed as a probability. Risk analysis can be performed by calculating the expected value of each alternative and selecting the best alternative. Now that the group has assigned a priority to each risk, it is ready to select the items to manage. Some projects select a subset to take action upon, while others choose to work on all of the items.

C: Risk Management Planning

11.5 Risk Management Planning After analysing and prioritising, the focus comes on management of the identified risks. In order to maximise the benefits of project risk management, you must incorporate the project risk management activities into our project management plan and work activities. There are two things you can do to manage risk. The first is to take action to reduce (or partially reduce) the likelihood of the risk occurring. For example, some project that work on process improvement make their deadlines earlier and increases their efforts to minimise the likelihood of team members being pulled off the project due to changing organisational priorities. In a software product, a critical feature might be developed first and tested early. Second, you can take action to reduce the impact if the risk does occur. Sometimes this is an action taken prior to the crisis, such as the creation of a simulator to use for testing if the hardware is late. At other times, it is a simple backup plan, such as running a night shift to share hardware. For the potential loss of a key person, for example, you might do two things. You may plan to reduce the impact by making sure other people become familiar with that persons work, or reduce the likelihood of attrition by giving the person a raise, or by providing extra benefits.

d. Risk Review

Establish how often risks should be reviewed (once a month is typical). Risk reviews can be incorporated into existing project status and phase reviews. Update the list based on risk review sessions. Control Risks: It refers to controlling the deviations in a project which may be one of the reasons to induce a risk element in the project. Controlling the risk ensures that the project is likely to be completed as per the plans and heading towards the goals set for the project. It is preferable to work in a structured mode to handle risks in a project. The final goal should be to complete the project on time and as per the schedule within the given budget and limited resources with the desirable quality. Q.6 XYZ Company implements CMMI level-03. To make further changes it decides on

starting a new division in the organization. It decides to advance the existing project management. What are the steps to be followed by the organization to drive project management to a new horizon?

Capability Maturity Model Integration (CMMI) is a process improvement approach that helps organizations improves their performance. CMMI can be used to guide process improvement across a project, a division, or an entire organization. CMMI in software engineering and organizational development is a process improvement approach that provides organizations with the essential elements for effective process improvement. CMMI is a trademark owned by Software Engineering Institute of Carnegie Mellon University. According to the Software Engineering Institute (SEI, 2008), CMMI helps "integrate traditionally separate organizational functions, set process improvement goals and priorities, provide guidance for quality processes, and provide a point of reference for appraising current processes."[2] CMMI currently addresses three areas of interest: 1. Product and service development CMMI for Development (CMMI-DEV), 3. Product and service acquisition CMMI for Acquisition (CMMI-ACQ).

2. Service establishment, management, and delivery CMMI for Services (CMMI-SVC), and

CMMI was developed by a group of experts from industry, government, and the Software Engineering Institute (SEI) at Carnegie Mellon University. CMMI models provide guidance for developing or improving processes that meet the business goals of an organization. A CMMI model may also be used as a framework for appraising the process maturity of the organization.[1]

CMMI originated in software engineering but has been highly generalised over the years to embrace other areas of interest, such as the development of hardware products, the delivery of all kinds of services, and the acquisition of products and services. The word "software" does not appear in definitions of CMMI. This generalization of improvement concepts makes CMMI extremely abstract. It is not as specific to software engineering as its predecessor, the Software CMM. CMMI was developed by the CMMI project, which aimed to improve the usability of maturity models by integrating many different models into one framework. The project consisted of members of industry, government and the Carnegie Mellon Software Engineering Institute (SEI). The main sponsors included the Office of the Secretary of Defense (OSD) and the National Defense Industrial Association. CMMI is the successor of the capability maturity model (CMM) or software CMM. The CMM was developed from 1987 until 1997. In 2002, CMMI Version 1.1 was released. Version 1.2 followed in August 2006. CMMI representation CMMI exists in two representations: continuous and staged. The continuous representation is designed to allow the user to focus on the specific processes that are considered important for the organization's immediate business objectives, or those to which the organization assigns a high degree of risk. The staged representation is designed to provide a standard sequence of improvements, and can serve as a basis for comparing the maturity of different projects and organizations. The staged representation also provides for an easy migration from the SW-CMM to CMMI. CMMI model framework Depending on the CMMI constellation (acquisition, services, development) used, the process areas it contains will vary. Key process areas are the areas that will be covered by the organization's processes. The table below lists the process areas that are present in all CMMI constellations. This collection of eight process areas is called the CMMI Model Framework, or CMF. Capability Maturity Model Integration (CMMI) Model Framework (CMF) Abbreviation Name REQM Requirements Management Area Engineering Maturity Level 2

PMC PP CM MA PPQA OPD CAR

Project Monitoring and Control Project Planning Configuration Management Measurement and Analysis

Project Management 2 Project Management 2 Support Support 2 2 2

Process and Product Quality Assurance Support Organizational Process Definition Causal Analysis

Process Management 3 Support 5

Maturity Levels There are Five maturity levels. However, maturity level ratings are awarded for levels 2 through 5. Maturity Level 2 - Managed

CM - Configuration Management MA - Measurement and Analysis PP - Project Planning PMC - Project Monitoring and Control PPQA - Process and Product Quality Assurance REQM - Requirements Management SAM - Supplier Agreement Management

Maturity Level 3 - Defined

DAR - Decision Analysis and Resolution

IPM - Integrated Project Management +IPPD OPF - Organizational Process Focus OT - Organizational Training PI - Product Integration

OPD - Organizational Process Definition +IPPD

RD - Requirements Development RSKM - Risk Management TS - Technical Solution VAL - Validation VER - Verification

Maturity Level 4 - Quantitatively Managed

QPM - Quantitative Project Management

OPP - Organizational Process Performance

Maturity Level 5 - Optimizing

CAR - Causal Analysis and Resolution

OID - Organizational Innovation and Deployment

CMMI models CMMI best practices are published in documents called models, each of which addresses a different area of interest. The current release of CMMI, version 1.2, provides models for three areas of interest: development, acquisition, and services.

CMMI for Development (CMMI-DEV), v1.2 was released in August 2006. It addresses product and service development processes. CMMI for Acquisition (CMMI-ACQ), v1.2 was released in November 2007. It addresses industry.

supply chain management, acquisition, and outsourcing processes in government and

CMMI for Services (CMMI-SVC), v1.2 was released in February 2009. It addresses guidance for delivering services within an organization and to external customers. be released in 2010. CMMI Version 1.3Plans for the Next Version CMMI Product Suite (includes Development, Acquisition, and Services), v1.3 is expected to

Regardless of which model an organization chooses, CMMI best practices should be adapted by an organization according to its business objectives.

Appraisal An organization cannot be certified in CMMI; instead, an organization is appraised. Depending on the type of appraisal, the organization can be awarded a maturity level rating (1-5) or a capability level achievement profile. Many organizations find value in measuring their progress by conducting an appraisal. Appraisals are typically conducted for one or more of the following reasons:

1. To determine how well the organizations processes compare to CMMI best practices, and to 2. To inform external customers and suppliers of how well the organizations processes 3. To meet the contractual requirements of one or more customers Appraisals of organizations using a CMMI model must conform to the requirements defined in the Appraisal Requirements for CMMI (ARC) document. There are three classes of appraisals, A, B and C, which focus on identifying improvement opportunities and comparing the organizations processes to CMMI best practices. Appraisal teams use a CMMI model and ARC-conformant appraisal method to guide their evaluation of the organization and their reporting of conclusions. The appraisal results can then be used (e.g., by a process group) to plan improvements for the organization. The Standard CMMI Appraisal Method for Process Improvement (SCAMPI) is an appraisal method that meets all of the ARC requirements. A class A appraisal is more formal and is the only one that can result in a level rating. Results of an appraisal may be published (if the appraised organization approves) on the CMMI Web site of the SEI: Published SCAMPI Appraisal Results. SCAMPI also supports the conduct of ISO/IEC 15504, also known as SPICE (Software Process Improvement and Capability Determination), assessments etc. Achieving CMMI compliance The traditional approach that organizations often adopt to achieve compliance with the CMMI involves the establishment of an Engineering Process Group (EPG) and Process Action Teams (PATs).This approach requires that members of the EPG and PATs be trained in the CMMI, that an informal (SCAMPI C) appraisal be performed, and that process areas be prioritized for improvement. More modern approaches that involve the deployment of commercially available, CMMI-compliant processes, can significantly reduce the time to achieve compliance. SEI has maintained statistics on the "time to move up" for organizations adopting the earlier Software CMM and primarily using the traditional approach.[6] These statistics indicate that, since 1987, the median times to move from Level 1 to Level 2 is 23 months, and from Level 2 to Level 3 is an additional 20 months. These statistics have not been updated for the CMMI. The Software Engineering Institutes (SEI) Team Software Process methodology and the Capability Maturity Modeling framework can be used to raise the maturity level. compare to CMMI best practices identify areas where improvement can be made

Applications The SEI published that 60 organizations measured increases of performance in the categories of cost, schedule, productivity, quality and customer satisfaction.[7] The median increase in performance varied between 14% (customer satisfaction) and 62% (productivity). However, the CMMI model mostly deals with what processes should be implemented, and not so much with how they can be implemented. These results do not guarantee that applying CMMI will increase performance in every organization. A small company with few resources may be less likely to benefit from CMMI; this view is supported by the process maturity profile (page 10). Of the small organizations (<25 employees), 70.5% are assessed at level 2: Managed, while 52.8% of the organizations with 10012000 employees are rated at the highest level (5: Optimizing). Interestingly, Turner & Jain (2002) argue that although it is obvious there are large differences between CMMI and agile methods, both approaches have much in common. They believe neither way is the 'right' way to develop software, but that there are phases in a project where one of the two is better suited. They suggest one should combine the different fragments of the methods into a new hybrid method. Sutherland et al. (2007) assert that a combination of Scrum and CMMI brings more adaptability and predictability than either one alone. David J. Anderson (2005) gives hints on how to interpret CMMI in an agile manner. Other viewpoints about using CMMI and Agile development are available on the SEI Web site. The combination of the project management technique earned value management (EVM) with CMMI has been described (Solomon, 2002). To conclude with a similar use of CMMI, Extreme Programming (XP), a software engineering method, has been evaluated with CMM/CMMI (Nawrocki et al., 2002). For example, the XP requirements management approach, which relies on oral communication, was evaluated as not compliant with CMMI. CMMI can be appraised using two different approaches: staged and continuous. The staged approach yields appraisal results as one of five maturity levels. The continuous approach yields one of six capability levels. The differences in these approaches are felt only in the appraisal; the best practices are equivalent and result in equivalent process improvement results

Project Management MB0049 - 4 Credits

Q.1 Write a short note on the following:

Work Breakdown Structure (WBS) The entire process of a project may be considered to be made up on number of sub process placed in different stage called the Work Breakdown Structure (WBS). A typical example of a WBS of a recruitment process is indicated in figure 2.5:

Fig. 2.5: Work breakdown structure (WBS) WBS is the technique to analyse the content of work and cost by breaking it down into its component parts. Project key stages form the highest level of the WBS, which is then used to show the details at the lower levels of the project. Each key stage comprises many tasks identified at the start of planning and later this list will have to be validated. WBS is produced by identifying the key elements, breaking each element down into component parts and continuing to breakdown until manageable work packages have been identified. These can then be allocated to the appropriate person. The WBS does not show dependencies other than a grouping under the key stages. It is not time based there is no timescale on the drawing.

b. Estimation Approaches

There are two types of estimation approaches. Figure 1.3 lists the two approaches. Let us discuss each of them.

Fig. 2.6: Estimation Approaches

2.6.1.1 Bottom up approach The bottom up approach consists of the following steps. i) Project manager first divides the product under development into major modules. ii) Each module is subdivided into smaller units. iii) Project manager defines a standard for manufacturing and self-testing by Identifying modules in the system and classifying them as simple, medium or complex Using either the provided standard definitions or definitions from past projects as much as possible Getting the average build effort for simple/medium/complex (S/M/C) programs from the baseline if a project specific baseline exists 2.6.1.2 Top Down Approach The top down approach consists of the following steps. i) Getting the estimate of the total size of the product in function points ii) Fixing the productivity level for the project using the productivity data from the project specific capability baseline from the general process capability baseline, or from similar projects iii) Obtaining the overall effort estimate from the productivity and size estimates iv) Using effort distribution data from the process capability baselines or similar projects to estimate the effort for the various phases v) Refining the estimates taking project specific factors into consideration

Q.2 List and define in Brief all the tools for Post Implementation Review

There are various tools for post project implementation review that may be considered for improving and developing processes of the project. Reports are prepared on the same which becomes the basis for all future discussion. Some of the tools that may be considered for post implementation review are shown in figure 3.10.

Fig. 3.10: Tools for post implementation review a) Final Product Evaluation: This may be done through regularly organised meetings and quality reviews. b) Outstanding Project Work Evaluation: All outstanding works of a project can be reviewed to check its output quality, its performance compared to planned and evaluate the same. c) Project Review: Review questionnaire may become important if the reviews are to be structured and group discussion may be initiated depending upon the points to be discussed. d) Process Evaluation: Evaluation of any process is one of the key issues of the project

Q.3 Define the Basic categories of performance management.

a) Measures of efforts: Efforts are the amount of financial and non-financial resources (in terms of money, material) that are put into a program or process. b) Measures of accomplishments: Accomplishments measures report what was provided and achieved with the resources used. There are two types of measures of accomplishments outputs and outcomes. Outputs measure the quantity of services provided; outcomes measure the results of providing those outputs. c) Measures that relate efforts to accomplishments: These are efficiency measures that relate efforts to outputs of products or services. They also measure the resources used or cost (for example, in rupees, employee-hours, or equipment used) per unit of output. They provide information about the production of an output at a given level of resource used and demonstrate an entitys relative efficiency when compared with previous results, internally established goals and objectives.

Q.4 Write a short note on the following: a. Professional Responsibility

With increasing competition, organisations have to finds new ways of customer retention and adopt innovative measures to increase their customer base. However, one common requirement is productivity improvement. Professional responsibility is very much expected by customers. They want to ensure that the project managers and executives take the baseline responsibility and follow all the codes of conduct. Managerial and executive productivity are measured with respect to zero defects and overall team performance. Installing Development Methodologies and Quality Systems is the responsibility of managers. Another area of Professional Responsibility for managers is reduction in process cycle time. This is defined as the total time taken to complete an entire single process. It is also termed as turn around time. A few examples of high cycle time activities are: a) Procurement Time: This is for outsourced software and hardware. There are multiple factors which go into a procurement process. Activities like identification of the requirements, their details, verification and authorisation, inputs from the company, the start of the activities by the vendors are all parts of this process. Due to extreme dependencies on various parties, procurement cycle has a high turnaround time b) Processing Time: This refers to the time lag which goes into and between each of the processes mentioned above. c) Order Confirmation Time: This refers to the time taken by the company as well as the vendors to take a final call on a particular discussion. Besides, there are many opportunities for laxness to enter. The common factors for all these are absence of details, lack of awareness and absence of checks and balances. The project manager should set up systems that will take care of these. In addition to these, a few more areas where managerial productivity are taken into reckoning are: a) Creativity b) Lateral thinking c) Quality Circles d) New Product Introduction Lead time e) Managing Change f) Implementing Total Quality Management (TQM) g) Empowerment of junior level executives You will notice that none of these factors are directly connected with the implementation. But, when these are undertaken the effectiveness of every member improves bringing about

all round development. Hence, a great amount of emphasis is given on professional responsibilities across organisations.
b. Business Orientation

Business Orientation: The project manager should understand the business of the organisation he works for. He should know the way things are looked at by the top management and align his thoughts and conduct, so as not to be in confusion or conflict with them. In addition to these soft skills he should also have a good knowledge of the domain. He should have his senses tuned to grasp business opportunities that crop up during the implementation. Personnel Productivity As discussed earlier, personnel productivity is an important parameter which determines project performance. Personnel productivity can be at various levels right from top management to a project team member. Productivity at the junior level can be assumed and controlled only if all other supporting elements of business are well balanced. Higher productivity cannot be expected if they are not motivated enough. The ways in which you can boost their productivity is given below. They can be motivated through: a) Sufficient content of development activities. The work should be interesting and challenging enough. It should bring a sense of satisfaction and achievement. b) Favourable working condition. Productivity decreases if the environment is not supportive. The environmental conditions should make one feel comfortable to stay at the workplace c) Proper delegation of activities. It is important to have a clear line of authority and balanced delegation of work. d) Timely reward and recognition. Acknowledging a good task or work always boost morale of the resource. e) Adequate availability of resources. If adequate resources are not present, it would lead to frustration and finally loss of focus and commitment. f) Properly planned system of quality control and process control. If the process is not supportive and flexible, even the best efforts will not be enough to get tolerable quality. g) Adequate maintenance support for hardware and software. These ensure that no work gets held up on this account efficiencies bring in productivity and time lag decreases it. As far as productivity as well as quality is concerned, especially where projects are concerned, it is good to follow Demings philosophy, which states create conditions for performance, do not use rhetoric, pay him well and give the pride of working. 5.7.1 Assessment of Personnel Productivity

As discussed earlier, as personnel productivity is critical to success of any project, it is very important to measure it so that it can be monitored and improved. There are many standard tools and templates available to assess the productivity. However, the methodology may be customised depending upon situations. Unlike productivity on shop floors, Personnel Productivity can be considered on a collective basis. The following can be used as guide lines to make assessments: a) Time for development of a new product b) Index of financial cycles c) Time for finding and proving a solution to serious customer complaints d) Time for development of a bigger market for an existing product It is better to avoid the following parameters for assessment: a) Individual achievements or failures b) Individual outputs c) Reflection on Financial Health d) Reflection on Inventory It is better to remember always that the first person to know that something has gone wrong is the person who caused it. If left alone or hinted in privacy, contemplation and a desire to make amends is strong in every individual. It is not suggested here that mistakes should be forgotten or excused. If tendency persists, then serious corrective action should be initiated at the earliest.

Conflict Management The basic characteristic of a project is that it is set of non-repetitive activities which create a unique product or service. The activities utilise a variety of resources. Systematic acquisition and deployment in a relatively short span of time is the essential process of a project. Development of a project starts with the acceptance of the proposal by the customer in all respects technical and commercial. The marketing people first take agreement of the details and the time schedules for various stages from the project manager and then give their commitment to the customer. Let us now have a look at the stages in the project development process. Figure 6.1 lists the stages in a sequential manner.

Q.5 Comment on the following

The modern mantra of project management seems to have five essential aspects Define, Measure, Analyse, Improve, and Standardise (DMAIS).

Fig. 4.3: DMAIS 1. Define benchmark, customer requirement, process flow map, quality function deployment, project management plan 2. Measure data collection, defect metrics, sampling 3. Analyse cause and effect, failure modes and effect analysis, decision and risk analysis, root cause analysis, reliability analysis 4. Improve design of experiments, modelling , robust design 5. Standardise control charts, time series, procedural adherence, performance management, preventive activities

c.

Knowledge areas of project management

Project Management Knowledge Areas refer to various techniques needed to manage projects, the practical methodologies adopted in formulating a project and managing the resources which would affect the project completion. Relationship with other management disciplines is essential for a project to be successful. Supporting disciplines include law, strategic planning, logistics, human resource management and domain knowledge