Mithun Jadhav | Connecting



Software Project Management Question Bank

Questions 1 to 7 are for 20 marks -

1. What is software matrix? Why and how are matrices used in software project management?

Software metric is a measure of some property of a piece of software or its specifications. Since quantitative measurements are essential in all sciences, there is a continuous effort by computer science practitioners and theoreticians to bring similar approaches to software development. The goal is obtaining objective, reproducible and quantifiable measurements, which may have numerous valuable applications in schedule and budget planning, cost estimation, quality assurance testing, software debugging, software performance optimization, and optimal personnel task assignments.

Software metrics are numerical data related to software development. Metrics strongly support software project management activities. They relate to the four functions of management as follows:

i. Planning - Metrics serve as a basis of cost estimating, training planning, resource planning, scheduling, and budgeting.

ii. Organizing - Size and schedule metrics influence a project's organization.

iii. Controlling - Metrics are used to status and track software development activities for compliance to plans.

iv. Improving - Metrics are used as a tool for process improvement and to identify where improvement efforts should be concentrated and measure the effects of process improvement efforts.

Why Measure?

"When you can measure what you are speaking about and express it in numbers, you know something about it; but when you cannot measure it, when you cannot express it in numbers, your knowledge is of a meagre and unsatisfactory kind: it may be the beginnings of knowledge but you have scarcely in your thoughts advanced to the stage of science."

- Lord Kelvin (Physicist)

"You cannot control what you cannot measure."

- Tom DeMarco (Software Engineer)

The software development scene is often characterized by:

• Schedule and cost estimates that are grossly inaccurate

• Software of poor quality, and

• A productivity rate that is increasing more slowly than the demand for software.

This situation has often been referred to as the “software crisis”.

Types of Metrics

• Product metrics

✓ size metrics

✓ complexity metrics

✓ quality metrics

• Process metrics

• Resource metrics

• Project metrics

A) Product metric:

A metric used to measure the characteristic of the documentation and code.

a. Product Metric - Size

✓ Number of Lines of Code (NLOC) - A line of code is any line of program text that is not a comment or a blank line, regardless of the number of statements or fragments of statements on the line. This specifically includes all lines containing program headers, declarations, and executable and non-executable statements.

✓ Function Point Count - A measure of the functionality perceived by the user delivered by the software developer. A function count is a weighted sum of the number of

- Inputs to the software application

- Outputs from the software application

- Enquiries to the software application

- Data files

✓ Internal to the software application

✓ Shared with other software applications

b. Product Metric - Design

Design metrics – computed from requirements or design documents before the system has been implemented

c. Product Metric - Object oriented metrics

Help identify faults, and allow developers to see directly how to make their classes and objects simpler.

d. Product Metric - Complexity

1. The McCabe Complexity Metric / Cyclomatic complexity - A software module can be described by a control flow graph where

- Each node corresponds to a block of sequential code

- Each edge corresponds to a branch or a decision point in the program

V(G) = e - n + 2p

e = number of edges in the graph

n = number of nodes in the graph

p = number of connected module components in the graph

[pic]

e. Product Metric - Quality

Defects - deviation from required product quality attributes like correctness, portability, reliability, integrity, maintainability etc.

Record the following:

- Type

- Cause

- Consequence

- Severity

- Detection mechanism

- Rectification details

- Effort implications

Density of reported defects calculated at the end of each lifecycle phase

Total number of field defects reported after customer installation at the end of each suitable time period

B) Process Metrics:

A metric used to measure the characteristic of the methods techniques and tools employed in developing, maintaining and implementing the software system.

Many facets of the process yield metrics, for example:

- application of methods and tools

- use of standards

- effectiveness of management

- performance of development system

C) Resource Metircs:

• effort expended

- on tasks within a project, classified by lifecycle phase and software function

- on extra-project activities like training

• elapsed time

• computer resources - Provides information on how well the project is meeting its computer resource utilization goals/requirements.

D) Project Metrics:

A project metric can be similar as any of the above three metrics or be derived from a combination of metrics.

1. Effort was defined as the total amount of time for a task that results in a work product or a service. The planned amount of time is called 'Planned Effort' and the actual amount of time spent is called the 'Actual Effort'; it can be measured in hours or in days depending on the specifics of the project. Effort is a directly observable quantity which is measured cumulatively for the tasks being assigned to specific resources or it can also be computed for specific tasks, milestones or phases. The 'Planned Effort' is collected when the work for a specific task is planned and is refined when the task is analyzed or designed. The 'Actual Effort' is collected during the construction, testing and warranty related to the specific task.

2. Productivity was defined as how many "simple tasks" can be delivered by day. It can be computed at various levels within a project: individual, profile, task phase or project.

3. Quality was defined as the number of: severe, medium or low defects delivered through the lifetime of the project. It contributes to identify the goodness of the deliverable to the end user. Each team needs to define what severe, low and medium means to their specific project. Quality should be reported throughout the life of the project; the later defects are caught, the more impact they will cause on the project.

A Metrics Programme:

Software development organisations should have a metrics programme in order to:

- calibrate models that can be used to forecast project/product behaviour

- give measures that can be used to control the software development process

[pic]

2. Importance of project charter. (***create a project charter and explain; similar to class assignment).

The Project Charter is the document that formally authorizes the project. The project charter provides the project manager with the authority to apply organizational resources to project activities.

A Project Charter is a document which embodies the Project Goals and the commitment of the Stakeholders to a project and its outcomes. The Charter is a means of creating a common sense of purpose. The Charter is a formal statement which includes the following:

• A brief statement of purpose of the project

• A statement of scope mentioning such things as the business areas covered by the project

• The Goals of the Project – Business and Solution related

• The key Stakeholders, their needs and expectations

• Priorities for meeting these needs and expectations in case there is a conflict

• Activities required to complete the project – each activity shall be described in the RACI matrix

• Milestones

• Key Risks which are foreseeable even at the start of the project

• Key assumptions related to the project – for instance the client company shall provide the equipment and office space for the project team or that project team shall work 5 days a week etc

• Constraints

• A Financial Evaluation of the project – this is in terms of cost-benefits of the proposed project. The success of the project is to be judged by the achievements of the goals as well as managing the cost-benefit as outlined in the charter.

• Sponsors Commitment to provide resources

• Sign-off of the charter by all stakeholders, sponsors, management, Project Management etc. to indicate their understanding and willingness to contribute to the project success.

Usually the Project Manager is identified at the time of preparing the Charter so that his ownership of the charter is ensured.

A well documented and signed off Project Charter provides a good starting point for a project.

Example of a Project Charter:

Objective: - Implementation of ERP system For Bharat Bijlee Ltd. production planning module.

Refer to ppt sent by Uday.

A RACI matrix describes the participation by various roles in completing tasks or deliverables for a project or business process. It is especially useful in clarifying roles and responsibilities in cross-functional/departmental projects and processes.

RACI is an acronym derived from the four key responsibilities: Responsible, Accountable, Consulted, and Informed.

Responsible - Those who do the work to achieve the task. There is typically one role with a participation type of responsible, although others can be delegated to assist in the work required.

Accountable - Also approver or final approving authority. The one ultimately answerable for the correct and thorough completion of the deliverable or task, and the one from who responsible is delegated the work. In other words, an accountable must sign off (approve) on work that responsible provides. There must be only one accountable specified for each task or deliverable.

Consulted - Those whose opinions are sought, typically subject matter experts; and with whom there is two-way communication.

Informed - Those who are kept up-to-date on progress, often only on completion of the task or deliverable; and with whom there is just one-way communication

3. What is project management? Define its phases.

“A project is a temporary endeavour undertaken to achieve something Unique.”

A project is therefore always characterized by one or more of the following:

- It is a one time and non-repetitive activity,

- Even where it is repetitive – each product/service delivered is very large in terms of magnitude, cost, resource mobilization etc For instance a ship building yard which makes ships but each ship is so large that it could be called a project

- There is something which is unique about it – which means that each project has to be planned separately. The differences in the projects from any other project either in terms of its purpose, goals, stakeholders, risks, requirements or people involved must be studied carefully and should reflect in the plan.

The one time nature, the size, complexity and uniqueness of the project necessitates, proper planning and careful execution to ensure success.

Project management is the discipline of planning, organizing, securing, and managing resources to achieve specific goals. A project is a temporary endeavour with a defined beginning and end (usually time-constrained, and often constrained by funding or deliverables), undertaken to meet unique goals and objectives, typically to bring about beneficial change or added value. The temporary nature of projects stands in contrast with business as usual (or operations), which are repetitive, permanent, or semi-permanent functional activities to produce products or services.

The primary challenge of project management is to achieve all of the project goals and objectives while honouring the preconceived constraints. Typical constraints are scope, time, and budget. The secondary—and more ambitious—challenge is to optimize the allocation of necessary inputs and integrate them to meet pre-defined objectives.

Phases of Project Management:

[pic]

1) Project conception and initiation

The initiating processes determine the nature and scope of the project. If this stage is not performed well, it is unlikely that the project will be successful in meeting the business’ needs. The key project controls needed here are an understanding of the business environment and making sure that all necessary controls are incorporated into the project. Any deficiencies should be reported and a recommendation should be made to fix them.

The initiating stage should include a plan that encompasses the following areas:

- analyzing the business needs/requirements in measurable goals

- reviewing of the current operations

- financial analysis of the costs and benefits including a budget

- stakeholder analysis, including users, and support personnel for the project

- project charter including costs, tasks, deliverables, and schedule

[pic]

2) Project planning

After the initiation stage, the project is planned to an appropriate level of detail. The main purpose is to plan time, cost and resources adequately to estimate the work needed and to effectively manage risk during project execution. As with the Initiation process group, a failure to adequately plan greatly reduces the project's chances of successfully accomplishing its goals.

Project planning generally consists of

- developing the scope statement;

- selecting the planning team;

- identifying deliverables and creating the work breakdown structure;

- identifying the activities needed to complete those deliverables and networking the activities in their logical sequence;

- estimating the resource requirements for the activities;

- estimating time and cost for activities;

- developing the schedule;

- developing the budget;

- risk planning;

- gaining formal approval to begin work.

Additional processes, such as planning for communications and for scope management, identifying roles and responsibilities, determining what to purchase for the project and holding a kick-off meeting are also generally advisable.

3) Project execution

Executing consists of the processes used to complete the work defined in the project plan to accomplish the project's requirements. Execution process involves coordinating people and resources, as well as integrating and performing the activities of the project in accordance with the project management plan. The deliverables are produced as outputs from the processes performed as defined in the project management plan and other frameworks that might be applicable to the type of project at hand.

4) Project monitoring and controlling

Monitoring and controlling consists of those processes performed to observe project execution so that potential problems can be identified in a timely manner and corrective action can be taken, when necessary, to control the execution of the project. The key benefit is that project performance is observed and measured regularly to identify variances from the project management plan.

Monitoring and controlling includes:

- Measuring the ongoing project activities ('where we are');

- Monitoring the project variables (cost, effort, scope, etc.) against the project management plan and the project performance baseline (where we should be);

- Identify corrective actions to address issues and risks properly (How can we get on track again);

- Influencing the factors that could circumvent integrated change control so only approved changes are implemented.

In multi-phase projects, the monitoring and control process also provides feedback between project phases, in order to implement corrective or preventive actions to bring the project into compliance with the project management plan.

[pic]

5) Project closure

Closing includes the formal acceptance of the project and the ending thereof. Administrative activities include the archiving of the files and documenting lessons learned.

This phase consists of:

- Project closure: Finalize all activities across all of the process groups to formally close the project or a project phase

- Contract closure: Complete and settle each contract (including the resolution of any open items) and close each contract applicable to the project or project phase.

4. Why should project team focus on project needs and quality?

Answer:

Focus on project needs - to adhere to the goals and scope of the project, also make stake holders contempt by delivering what was promised to them.

Requirements are (or should be) the foundation for every project. Put most simply, a requirement is a need. This problem, this need, leads to the requirements, and everything else in the project builds off these business requirements.

Importance of Requirements

• Requirements are considered by many experts to be the major non-management, non-business reason projects don't achieve the "magic triangle" of on-time, on-budget and high quality. Very few projects do an effective job of identifying and carrying through the project and all the requirements correctly.

• Various studies have shown that requirements are the biggest problem in projects. Projects fail due to requirements problems. The most defects occur during the requirements phase. Project teams need to do a much better job on requirements if they wish to develop quality software on-time and on-budget.

• Furthermore, requirements errors compound as you move through a project. The earlier requirements problems are found, the less expensive they are to fix. Therefore, the best time to fix them is right when you are involved with gathering, understanding, and documenting them with your stakeholders (who should be the source of your project requirements).

• The hardest requirements problems to fix are those that are omitted. This really becomes the requirements analyst's dilemma. The analyst often doesn't know what questions to ask, and the stakeholder doesn't know what information the analyst needs. Since the analyst doesn't ask, the stakeholder doesn't state requirements.

• Before investing in building a new product, take the time to understand the prospective customer’s problems and needs that you satisfy.

• The Product Requirements document focuses on the problems and needs; not the solutions of the customer.

• Never assume you understand your customer’s problems and needs if you have not worked closely with the customer for this purpose.

• More will be learned about your customer’s problems and needs when you put them in print and verify their accuracy and completeness with your customer.

• A requirements document forces important issues to surface at the start of the project that might otherwise be overlooked, incorrectly assumed, or discovered late in a project.

• A requirements document provides a tangible means against which to validate the solution.

• The most successful product development team will be that which consistently and tirelessly works at understanding their customer’s problems and needs that must be satisfied.

• If your product fails to satisfy your customer’s expectations, competitors will be happy to help.

Focus on project quality - to be compliant of certain standards that help deliver the project as planned with fewer deviations and also helps keep the execution ethical.

Quality is "the degree to which a set of inherent characteristics fulfil requirements".

Project quality management involves making sure the project meets the needs that it was originally created to meet, or in other words, that stakeholder expectations were met. Quality is the result of meeting the triple constraints - time, cost and scope. A guide to the Project Management Body of Knowledge (PMBOK Guide) states that quality management ensures "that the project will satisfy the needs for which it was undertaken," not just to meet or exceed the requirements.

• Clients & users expect quality

• Poor quality results in “rework” at additional cost

• Poor quality results in problems that can be difficult to diagnose and solve

• Poor quality can cost lives

Quality is delivering what you said you would deliver.

– Quality must be written into the project requirements and project scope.

– E.g. we’re asked to build a web application. After it’s built, the client complains that it can’t handle 100,000 simultaneous users. Is this a quality problem?

We don’t have a right to give a client more than he needs.

– If we overbuild more than the client needs, who picks up the bill? Who approved it?

– The client has to define their level of quality for us.

– Put quality metrics into the requirements/design/project plan

Quality processes include:

Quality planning: identifying which quality standards are relevant to the project and how to satisfy them

Quality assurance: periodically evaluating overall project performance to ensure the project will satisfy the relevant quality standards

Quality control: monitoring specific project results to ensure that they comply with the relevant quality standards

Modern quality management complements project management. For example, both disciplines recognize the importance of:

Customer satisfaction - Understanding, evaluating, defining and managing expectations so that customer requirements are met. This requires a combination of conformance to requirements (the project must produce what it said it would produce) and fitness for use (the product or service must satisfy real needs).

Prevention over inspection - The cost of preventing mistakes is generally much less than the cost of correcting them.

Management responsibility - Success requires the participation of all members of the team, but it remains the responsibility of the management to provide the resources needed to succeed.

Continuous improvement - The plan-do-check-act cycle is the basis for quality improvement.

5. Role of risk management in project life cycle. Risk management refer to PMBOK.

Project risk management is an important aspect of project management. Project risk can be defined as an unforeseen event or activity that can impact the project's progress, result or outcome in a positive or negative way. A risk can be assessed using two factors: impact and probability.

If the probability is 1, it is an issue. This means that risk is already materialized. If the probability is zero, this means that risk will not happen and should be removed from the risk register.

Risk Management is the identification, assessment, and prioritization of risks followed by coordinated and economical application of resources to minimize, monitor, and control the probability and/or impact of unfortunate events or to maximize the realization of opportunities.

There are two stages in the process of Project Risk Management - Risk Assessment and Risk Control. Risk Assessment can take place at any time during the project, though the sooner the better. However, Risk Control cannot be effective without a previous Risk Assessment.

Risk Assessment has three elements:

Identify Uncertainties - Explore the entire project plans and look for areas of uncertainty.

Analyse Risks - Specify how those areas of uncertainty can impact the performance of the project, either in duration, cost or meeting the users' requirements.

Prioritise Risks - Establish which of those Risks should be eliminated completely, because of potential extreme impact, which should have regular management attention, and which are sufficiently minor to avoid detailed management attention.

In the same way, Risk Control has three elements, as follows:

Mitigate Risks - Take whatever actions are possible in advance to reduce the effect of Risk. It is better to spend money on mitigation than to include contingency in the plan.

Plan for Emergencies - For all those Risks which are deemed to be significant, have an emergency plan in place before it happens.

Measure and Control - Track the effects of the risks identified and manage them to a successful conclusion.

6. Importance of resource management in IT projects.

Primary Definition: A project resource can be defined as any person, tool, equipment, material or service used to plan, manage, monitor and complete a given project. Resource management is the primary process by which "project resources" are assigned and utilized.

Planning a project requires due consideration to sourcing and scheduling of these resources.

Material required for a project, especially if it is imported material, may require a longer lead time for sourcing. Sourcing must therefore be planned well in advance of the actual requirement of such material.

People resources are vital in most projects. They are also in many cases in short supply. They also have problems associated with them such as inadequate skill level, absenteeism, low productivity, low morale, attrition etc. Hence, planning of people resources is a matter of getting the right person for the right job at the right time and cost.

While preparing a project schedule a resource schedule also needs to be prepared.

The purpose of the resource plan is to ensure that the resource requirement dovetails with the real need for the resource for a specific task in a project, the correct level of skill and productivity are available for the duration required.

Resource planning also aims at smoothing the requirement of a resource type across the project. Thus neither is a resource locked in for a unduly long duration nor is it allotted work in bursts making it difficult to allocate especially from a shared pool of resources.

Each organization also has what is known as a Critical Constraint. Usually this could be a very large or expensive machine, or a highly skilled person etc. For instance an expensive welding machine or a Mobile Cement Mixer or a Forklift crane or a highly skilled Java Programmer could be examples of such a critical constraint.

Planning for these resources amounts to carefully scheduling tasks based on the delivery considerations + the availability constraints of these key resources. This is known as Critical Chain scheduling.

Quite often we are faced with exactly the opposite situation i.e. resources are wasted. For instance the entire team may be waiting because the client’s approval on the requirement or scope of work document is yet to come or a perhaps an important machine has broken down.

Resource optimization and utilization is therefore one of the key aspects of a project managers tasks.

7. Why projects fail? How can failures be overcome?

Why do Projects Fail?

It is common knowledge many projects seem to fail in some ways. A project may either

• Fail to achieve some or all aspects of its basic purpose

• It is completed in a timeframe which exceeds the planned timeframe

• It is completed in with excessive resources & costs

• It drags to such an extent that the management aborts it midway.

In the field of Information Technology project failures are very common. This is perhaps because of the ‘new’ and unexplored technology and the ability of the users and the developers to understand each other’s requirements.

In several surveys of projects in various domains, it has been found that the following are the more important reasons for project failure:

• Unclear Project Goals

• Lack of Management Commitment

• Lack of user involvement and commitment

• New Technical or business area – Uncharted area

• Failure to grasp Stakeholder requirements

Essentially, projects fail because of poor leadership. And the essence of leadership is vision. Without vision, the project lacks purpose and parameters. The result is misaligned expectations between those who are on the project and those who are depending on it for results. The natural tendency for a stakeholder audience is to assume that all ills will be fixed as a result of a project. This is natural because projects tend to receive high visibility given the financial and human resources that they consume. Without vision and the resulting scope definition that ensues, however, expectations will never be overtly aligned, and the project will likely fall short of its assumed goals.

A common mistake associated with vision definition is not fully considering the interplay between the three major dimensions of projects: People, Process and Technology. People refer to the organizational structure, roles/responsibilities, skill sets and incentive structure of the resources who are involved in the system or process under consideration. Process involves the workflow that the people perform to produce desired outputs given a series of inputs. Technology includes the enabling systems that manage data, information and knowledge throughout the process. Unfortunately, the panacea of a bad organizational structure or process is often thought to be a new system. However, schizophrenic systems often reflect schizophrenic organizational structures, and automating a poorly constructed process just makes bad things happen faster. The answer is to get the people and processes right; and then focus on technology.

Because projects deal in the future state, they tend to receive less attention than the day-to-day “fire-fights” of current state operations. Unless senior- and middle-management display continuous support for the project (e.g., by devoting full-time, best-and-brightest resources to the project, building the project’s successes into organizational incentive plans, etc.), the project will by default take a back seat to daily activities. And part-time core team resources simply don’t work. Their allegiances will be split -- with their “day jobs” taking priority over the needs of the project team. The result is almost always a project that slowly dies on the vine or overruns acceptable timeline and budget parameters.

Active sponsorship involvement is also crucial because the project team is rarely empowered with ultimate decision-making authority and the ability to enforce the implementation of the ideas that it originates. Conceptually speaking, a project team is an “organic think pad” that facilitates a concentrated burst of reflection and action to make things better. It is wholly dependent on the sponsorship that surrounds it for direction, decisions and implementation of change. Obviously, then, the project cannot operate in a vacuum. Unless its sponsorship is actively involved throughout the various stages of the project, the project team will arrive at a future state that is out of line with the needs of the organization that commissioned it in the first place.

The essence of the change management challenge is that systems and process redesign projects are not often recognized for what they truly are: change projects. The basic goal of all such projects is to move an organization from an unacceptable current state to a more desirable future state. Sounds simple enough, except that change is difficult because it evokes feelings of fear – fear of the unknown. Many of us would prefer to cling to a familiar “bad” than risk the promise of an unfamiliar “good”. It’s true in jobs… it’s true in relationships… it’s true in organizational change.

The key is to recognize the nature of this fear and to manage the change accordingly. In many respects, the loss an organization’s current state is analogous to the loss of a loved one, and the iterative stages of grieving are predictable: denial --> anger --> bargaining --> depression --> acceptance. Once this dynamic is understood, it can be managed. The basis for managing change is to understand that people will accept change more readily if they feel informed, involved and in control. The implication is that throughout the project, those who will be impacted by it need to be communicated to, included in the decision-making process and in control of how the future state will materialize.

A thorough understanding of these determinants, coupled with a project management approach that responds to the previously-mentioned most common reasons for project failure, can consistently turn a 75% probability of failure into a 75% probability of success.

8. Short notes (5 marks) – contingency, productivity, customer interaction, outsourcing, multi-skilling in projects, roles and responsibilities of project manager, project reviews.

a. Contingency Plan

A contingency plan is a plan devised for an outcome other than in the usual (expected) plan.

It is often used for risk management when an exceptional risk that, though unlikely, would have catastrophic consequences. Contingency plans are often devised by governments or businesses. For example, suppose many employees of a company are travelling together on an aircraft which crashes, killing all aboard. The company could be severely strained or even ruined by such a loss. Accordingly, many companies have procedures to follow in the event of such a disaster. The plan may also include standing policies to mitigate a disaster's potential impact, such as requiring employees to travel separately or limiting the number of employees on any one aircraft.

It is about preparing for events such as the loss of data, people, customers, and suppliers, and other disruptive unknowns. That's why it's important to make contingency planning a normal part of your everyday business operations.

The need for contingency planning emerges from a thorough analysis of the risks that your organization faces. It's also useful in thinking about new and ongoing projects: what happens when 'Plan A' doesn't go as expected? Sometimes Plan A simply means 'business as usual.' Other times, with more sophisticated risk management plans, Plan A is your first response to deal with an identified risk – and when Plan A doesn't work, you use your contingency plan.

Contingency Planning Challenges

You should be aware of a few common obstacles as you begin your contingency planning process:

• People are often poorly motivated to develop a strong ‘Plan B’ because they have too much of an emotional investment in the ‘Plan A’ they want to deliver. Stress that Plan B should be properly thought through.

• There’s usually a low probability of a crisis occurring, so people often don’t feel a sense of urgency to create a contingency plan, meaning that it gets stuck at the bottom of their To Do Lists. Unfortunately, this may mean that contingency planning ends up as a task that never gets done.

• Organizational politics can interfere with prioritizing risk, because many people may want to be seen as an essential part of recovery efforts. If you include all key business managers in the risk assessment and prioritization process, this may help you reach agreement.

Contingency planning is a systematic approach to identifying what can go wrong in a situation. Rather than hoping that everything will turn out OK or that "fate will be on your side", a planner should try to identify contingency events and be prepared with plans, strategies and approaches for avoiding, coping or even exploiting them.

Contingencies are relevant events anticipated by a planner, including low-probability events that would have major impacts. Contingency planning is a "What if?" skill important in all types of planning domains, but especially in contested and competitive domains. The objective of contingency planning is not to identify and develop a plan for every possible contingency. That would be impossible and a terrible waste of time. Rather, the objective is to encourage one to think about major contingencies and possible responses. Few situations actually unfold according to the assumptions of a plan. However, people who have given thought to contingencies and possible reponses are more likely to meet major goals and targets successfully.

b. Productivity

Productivity is a measure of the efficiency of production. Productivity is a ratio of production output to what is required to produce it (inputs). The measure of productivity is defined as a total output per one unit of a total input.

The benefits of high productivity are manifold. At the national level, productivity growth raises living standards because more real income improves people's ability to purchase goods and services, enjoy leisure, improve housing and education and contribute to social and environmental programs. Productivity growth is important to the firm because it means that the firm can meet its (perhaps growing) obligations to customers, suppliers, workers, shareholders, and governments (taxes and regulation), and still remain competitive or even improve its competitiveness in the market place.

There are many factors which can influence productivity. Though there are both positive and negative influencing factors, it is more common to hear about and know those factors which adversely affect production.

One of the primary factors which influences productivity are both intrinsic and extrinsic factors related to the employees in charge of the production process. Attitude has been identified as one of the major contributing factors to employee productivity. Positive attitudes are correlated with increased productivity while negative attitudes are associated with declines in productive behaviours.

Likewise, appropriate and engaging supervision by superiors can have a markedly positive effect on productivity while adverse supervisory practices can have the opposite effect.

Other employee related factors including health which may be influenced by lifestyle, stress in and out of the workplace and primarily by ease of access to health care providers applicability of work-related devices and tools to the present market conditions as well as outsourcing practices can all have either positive or negative influences on rate and quality of productivity.

One of the bigger extrinsic factors to productivity is related to the supply and demand curve. Markets which rely on parts or components from other markets can suffer when adverse conditions inhibit supply. A prime example of this is the 2011 flooding that occurred in Thailand. Because of the widespread flood damage throughout the country many computer companies have been forced to increase their prices on hard drives. Hard drives are a chief technology export from Thailand and American productivity in computer supply markets has suffered due to weather conditions occurring in a foreign country.

There are many factors which can affect productivity. These can be intrinsically related to employees at an individual and interpersonal level and can be extrinsically affected by nature, acts of God and other similar uncontrollable circumstances.

c. Customer Interaction

The way you interact with your customers will determine how your customer’s perceive you, your business and your products or services. It is imperative that you promote your company at every turn and this doesn’t necessarily only involve times when you are meeting customers. Networking is something that you are doing every time you leave your house, you should always be as prepared as possible for meeting prospecting clients and dealers. Looking the part, sounding the part and giving the right general perception of yourself is very important when you own your own business. That doesn’t mean you should wear your suit and tie when you’re out playing golf but you should always carry yourself professionally.

➢ Never argue

No matter how heated discussions with customers get it is very important that you do not lose your cool. Remain calm at all times, and explain your point of view. By all means get your point of view across if it is important but don’t start arguing. It is important that you keep your relationship civil with your customers at all times because even those who seem to want an argument with you can end up buying from you. It is always possible to turn a negative into a positive and subsequently close a sale.

➢ Building trust and loyalty

An important part of your relationship between yourself and your customer is that they trust you. By encouraging trust from your customers you will also encourage them to give your company increased loyalty. It is virtually impossible to make your customers trust you if you are lying to them and you should avoid this at all costs. Lying has a real tendency to come back and bite you when you least expect it. If you get found out that you’ve been lying there is really no return and you will have lost your customer for good.

➢ Make a connection

You should try to find something that you both have in common and use this to your advantage. Or at least find something that your customer is interested in and make sure you take note of what their interest is. Find out the team they support or what they like to do at weekends and before you next meet or speak to them find out a little something to talk to them about. If you both play golf then you have an obvious connection.

➢ Using the icebreaker

By using this connection you have an excellent icebreaker that allows you to start conversations easily. Paying an interest in your customers will make you appear friendly and if you share the same interests this gives you a huge and immediate advantage when you next speak to them. Selling something to a customer who likes you is much easier than selling to somebody you don’t know anything about.

➢ Keep the customer informed

Your customers will become upset if they are kept in the dark. Keep them informed of developments involving them, particularly with regard to technical problems and outages. In particular, keep them apprised even if nothing is going on. For example, let them know you’ve contacted the vendor but still haven’t heard anything back. No news is still news. If a customer leaves you a request via voicemail or e-mail, let the customer know you received it, even if you are still in the process of handling it. Doing so gives the customer one less matter to worry about. When a problem is resolved, let the customer know that, too. Nothing is more frustrating to customers than finding out that they could have been working sooner if they had only known.

d. Outsourcing

Outsourcing is the process of contracting an existing business function or process of an organization to an independent organization, and ceasing to perform that function or process internally, instead purchasing it as a service. Though this practice of purchasing a business function--instead of providing it internally--is a common feature of any modern economy, the term outsourcing became popular in America near the turn of the 21st century. An outsourcing deal may also involve transfer of the employees involved to the outsourcing business partner but it doesn't have to.

Two organizations may enter into a contractual agreement involving an exchange of services and payments. Outsourcing is said to help firms to perform well in their core competencies and mitigate shortage of skill or expertise in the areas where they want to outsource.

➢ Reasons

The most common reasons why companies decide to outsource include cost reduction and cost savings, the ability to focus on core parts of its business, access to more knowledge/talents and experience, and revenue or profit.

➢ Risks

When companies outsource, even though it may not be the core parts of the business, the noncore parts of the business bring jobs to foreign countries. By moving the jobs overseas, this decreases the chances for citizens to obtain these types of jobs. This relocation of jobs overseas hurts the country’s economy. Another large risk companies are also taking is the security of their business along with its services. Companies lose money when they supply third party workers with passwords to accounts and the workers take money from those accounts, this is constituted as fraud.

➢ Advantages

Companies are able to provide services and products to consumers at a cheaper price while still having a large margin for profit. This profit margin benefits both the company as well as the consumer. The cheaper prices lead to an increase a company’s economy. Although losing jobs hurts the economy because more citizens become unemployed, the cheaper prices allows customers to purchase more products and services which helps to rebuild an economy.

e. Multi-skilling in projects

Multi-skilling is the ability of an employee to perform more than one function or the cross-training of an employee in several discipline or tasks.

In today's fast moving world, people are required to do much more than earlier. Everybody wants to equip himself with a variety of skills. We want to be adept at driving, skiing, managing people, organizing parties, raising children, and speaking Hebrew. Time is short, so make hay while the sun shines. This is the new age mantra. Multi skilling has finally arrived.

In organizations, managers are happy to recruit multi talented employees. Can you handle teams? Are you competent to organize events? Can you train and motivate your subordinates? Can you also sell? Well, then walk right in, they say. Multi skilled people seem to be the answer to many of organizational challenges.

All organizations go through a change process. Dynamic environment and changing market scenarios force organizations to be flexible. Meeting competition head on requires companies to always be on the ball. Taller hierarchical structures give way to flatter matrix organizations. Designations have evaporated with the reduction of organization levels. Some organizations are spread out across various industries. Mergers and takeovers have made companies foray in unknown sectors. Given the multi-dimensional nature of organizations, people also have to make use of multi-dimensional skills; and hence, the entry of the multi skilled employee.

Organizations which multi skill employees use lateral shifts as a mode of employee training and development. Cross functional skills are adopted. Employees are given cross functional training to increase the talent pool. Knowledge sharing is encouraged and formally acknowledged in these organizations.

Employees have to multi skill themselves to make more talent available to organizations. It is also a refreshing change of environment for employees who have been specializing in certain functions. Very often managers have reported an influx of new ideas, out of box thinking and creative solution generation purely by role reversals and lateral moves. This helps organizations to gear up for any future personnel requirement.

Advantages:

➢ Workforce is more flexible.

➢ Employees become more aware of the workflow.

➢ Employees are better prepared to anticipate problems or requirements of other areas.

➢ Employees can assume other tasks when there is absenteeism.

➢ Employees can be moved into other positions at peak times of the operation.

➢ A new employee at a job may have new ideas to fine tune that job.

➢ Employees overcome feelings of having a dead-end job.

➢ Jobs remain interesting and challenging.

➢ Tedious tasks can be spread around.

➢ Boredom in the workplace is reduced.

➢ Cohesiveness in enhanced.

Disadvantages:

➢ Possible reduction in productivity during the training period.

➢ Competency assessment may become demanding.

➢ Employees may be forced to stretch to the limits. There is an undercurrent of frustration.

➢ New jobs, new environment, and new learning can unnerve employees. They fear about not being able to live up to the expectations.

➢ Often, employees are uncomfortable with the changes and can't deal with the conflict of the role and their personality.

Without proper counselling and training, multi skilling can backfire. Employees need to be guided and supported through the entire process of multi skilling. Training with feedback is of paramount importance. Multi skilling is a developmental process; it needs to be handled with sensitivity.

f. Roles and responsibilities of Project Manager

A project manager is a professional in the field of project management. Project managers have the responsibility of the planning, execution and closing of projects and are found across industries.

A project manager is the person responsible for accomplishing the stated project objectives. Key project management responsibilities include creating clear and attainable project objectives, building the project requirements, and managing the constraints of the project management triangle, which are cost, time, scope, and quality.

A project manager is often a client representative and has to determine and implement the exact needs of the client, based on knowledge of the firm they are representing. The ability to adapt to the various internal procedures of the contracting party, and to form close links with the nominated representatives, is essential in ensuring that the key issues of cost, time, quality and above all, client satisfaction, can be realized.

Responsibilities -

The project manager is accountable for ensuring that everyone on the team knows and executes his or her role, feels empowered and supported in the role, knows the roles of the other team members and acts upon the belief that those roles will be performed.

Developing the project plan

Managing the project stakeholders

Managing the project team

Managing the project risk

Managing the project schedule

Managing the project budget

Managing the project conflicts

g. Project Review

Project reviews take place during the lifecycle of a project in order to check the likely or actual achievements of the objectives specified in the Project Plan and the benefits detailed in the Business Case. They act to encourage the project managers and project teams to reflect on the project status and objectively review their work.

Schedule of a Project Review - Project Reviews should not occur more frequently than once every three to five months.

Prepare for project review - If projects are given sufficient time to prepare for a project review, they likely will use that time to resolve some of the problems that would otherwise be revealed during the project review.

Aspects covered in a Project Review -

➢ Overview of product

➢ Staffing and skills

➢ Project organization, roles and responsibilities

➢ Schedules and milestones

➢ Product definition and change control

➢ Processes

➢ Quality

➢ Productivity

➢ Project communication and morale

➢ Support from external groups

➢ Customer expectations / Customer satisfaction

➢ Project financials

➢ Significant problems

➢ Project Outlook

➢ Business & legal issues

Project Review

➢ The primary goal of the project review is to identify significant problems and to assess the overall capability of the project to meet its commitments.

➢ Because the overall assessment of the project is, in large part, a reflection of the effectiveness of the project’s leadership, the assessment should be presented first to the project’s leadership.

➢ The most important action of the project review process is for the project’s leadership to satisfactorily resolve the significant problems identified.

➢ Product certification reviews serve your customers by ensuring that they receive the best product possible.

9. Explain in brief (10 marks) – SDLC v/s service life cycle, disaster management, IT policy.

a. SDLC v/s service life cycle

[pic]

The systems development life cycle (SDLC) is a conceptual model used in project management that describes the stages involved in an information system development project, from an initial feasibility study through maintenance of the completed application.

The System Development Life Cycle framework provides a sequence of activities for system designers and developers to follow. It consists of a set of steps or phases in which each phase of the SDLC uses the results of the previous one. These stages can be characterized and divided up in different ways, as follows:

i. Preliminary analysis: The objective of phase 1 is to conduct a preliminary analysis, propose alternative solutions, describe costs and benefits and submit a preliminary plan with recommendations.

a) Conduct the preliminary analysis: in this step, you need to find out the organization's objectives and the nature and scope of the problem under study. Even if a problem refers only to a small segment of the organization itself then you need find out what the objectives of the organization itself are. Then you need to see how the problem being studied fits in with them.

b) Propose alternative solutions: In digging into the organization's objectives and specific problems, you may have already covered some solutions. Alternate proposals may come from interviewing employees, clients, suppliers, and/or consultants. You can also study what competitors are doing. With this data, you will have three choices: leave the system as is, improve it, or develop a new system.

c) Describe the costs and benefits.

ii. Systems analysis, requirements definition: Defines project goals into defined functions and operation of the intended application. Analyzes end-user information needs.

iii. Systems design: Describes desired features and operations in detail, including screen layouts, business rules, process diagrams, code and other documentation.

iv. Development: The real code is written here.

v. Integration and testing: Brings all the pieces together into a special testing environment, then checks for errors, bugs and interoperability.

vi. Acceptance, installation, deployment: The final stage of initial development, where the software is put into production and runs actual business.

vii. Maintenance: What happens during the rest of the software's life: changes, correction, additions, moving to a different computing platform and more. This is often the longest of the stages.

[pic]

The IT service lifecycle describes the life of an IT service, from planning and optimizing the IT service to align with the business strategy, through the design and delivery of the IT service, to its ongoing operation and support. Underlying all of this is a foundation of IT governance, risk management, compliance, team organization, and change management.

The Lifecycle Phases

The IT service lifecycle is composed of three ongoing phases and one foundational layer that operates throughout all of the other phases. They are:

The Plan Phase

The Deliver Phase

The Operate Phase

The Manage Layer

➢ The Plan Phase is generally the preliminary phase. The goal of this phase is to plan and optimize an IT service strategy in order to support business goals and objectives.

➢ The Deliver Phase comes next. The goal of this phase is to ensure that IT services are developed effectively, are deployed successfully, and are ready for Operations.

➢ Next is the Operate Phase. The goal of this phase is to ensure that IT services are operated, maintained, and supported in a way that meets business needs and expectations.

➢ The Manage Layer is the foundation of the IT service lifecycle. Its goal is to provide operating principles and best practices to ensure that the investment in IT delivers expected business value at an acceptable level of risk. This phase is concerned with IT governance, risk, compliance, roles and responsibilities, change management, and configuration. Processes in this phase take place during all phases of the lifecycle.

Use the IT service lifecycle phases regardless of the size or impact of a change. The formality with which you apply the lifecycle is proportionate to the risk of the change. You need to do just what is required — no more and no less. For example, a major new initiative, such as a new service on which a business function depends, should go through in-depth analysis and review in the Plan Phase, a formal project plan in the Deliver Phase, and preparation for and review of how IT will implement, support, and monitor this service in the Operate Phase.

b. Disaster management

Disaster management is a field dealing with the strategic organizational management processes used to protect critical assets of an organization during events like disasters or catastrophes and to ensure the continuance of the organization within their planned lifetime.

Disasters are events distinguished from everyday emergencies by four factors: Organizations are forced into more and different kinds of interactions than normal; Organizations lose some of their normal autonomy; Performance standards change, and; More coordinated public sector/private sector relationships are required.

The entire disaster management process is divided into four fields to aid in identification of the processes. The four fields normally deal with risk reduction, preparing resources to respond to the hazard, responding to the actual damage caused by the hazard and limiting further damage, and returning as close as possible to the state before the hazard incident.

Mitigation

Mitigation efforts are attempts to prevent hazards from developing into disasters altogether or to reduce the effects of disasters. Mitigation is the effort to reduce loss of life and property by lessening the impact of disasters. This is achieved through risk analysis, which results in information that provides a foundation for mitigation activities that reduce risk. Mitigation is the most cost-efficient method for reducing the effect of hazards although not always the most suitable. Mitigation includes providing regulations regarding evacuation, sanctions against those who refuse to obey the regulations (such as mandatory evacuations), and communication of risks to the public.

Preparedness

Preparedness is how we change behaviour to limit the impact of disaster events on people. Preparedness is a continuous cycle of planning, managing, organizing, training, equipping, exercising, creating, evaluating, monitoring and improving activities to ensure effective coordination and the enhancement of capabilities of concerned organizations to prevent, protect against, respond to, recover from, create resources and mitigate the effects of natural disasters, acts of terrorism, and other man-made disasters. In the preparedness phase, emergency managers develop plans of action carefully to manage and counter their risks and take action to build the necessary capabilities needed to implement such plans.

Response

The response phase includes the mobilization of the necessary emergency services and first responders in the disaster area. This is likely to include a first wave of core emergency services, such as fire-fighters, police and ambulance crews. There is a need for both discipline (structure, doctrine, process) and agility (creativity, improvisation, adaptability) in responding to a disaster. There is also the need to onboard and build an effective leadership team quickly to coordinate and manage efforts as they grow beyond first responders. The leader and team must formulate and implement a disciplined, iterative set of response plans, allowing initial coordinated responses that are vaguely right, adapting to new information and changes in circumstances as they arise.

Recovery

The aim of the recovery phase is to restore the affected area to its previous state. It differs from the response phase in its focus; recovery efforts are concerned with issues and decisions that must be made after immediate needs are addressed. Recovery efforts are primarily concerned with actions that involve rebuilding destroyed property, re-employment, and the repair of other essential infrastructure.

Efforts should be made to "build back better", aiming to reduce the pre-disaster risks inherent in the community and infrastructure. An important aspect of effective recovery efforts is taking advantage of a ‘window of opportunity’ for the implementation of mitigation measures that might otherwise be unpopular.

c. IT policy

Information technology policies articulate the organization's vision, strategy, and principles as they relate to the use of information and information technology resources. IT policies interpret applicable laws and regulations and ensure that the policies are consistent with legal and contractual requirements. In addition, IT policies specify requirements and standards for the consistent use of IT resources across the organization.

This IT policy should develop and maintain IT policies that are in step with emerging technologies and align with the evolving role and philosophy of organisation.

To support the IT policy development process, a detailed framework should be adopted that:

● determines when to establish a policy, guideline or standard

● determines the criteria for what should be in a policy, guideline or standards

● creates a collaborative methodology for the drafting, approving, updating, and expiration of policies, standards, and guidelines

● documents and publishes policies, standards, and guidelines

● serves as a campus-wide resource to consistently interpret and arbitrate policies

● measures policy effectiveness and level of adoption

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download