MB0033: PROJECT MANAGEMENT

ASSIGNMENT SET 2

1. How can risks be prioritized in a project management? Give any suitable

example.
Ans:- Risks should be as specific as possible. It’s true that “The project might be delayed” or “We
will go out of business” are risks; however, they are far too vague to do anything about. When a
vague risk comes up, the project manager should prod the team into making it more specific.
What are the possible sources of the project delay? How have past projects been delayed? For
example, if the last project was late because a major stakeholder quit and was replaced by
someone who disagreed with his predecessor’s vision, the team should write that down as a
risk. The assumptions documented in the vision and scope document and identified in a Delphi
session are another good source of potential risks. The team should go through them and
evaluate each assumption for potential risks as part of the risk brainstorming session.

Estimate the impact of each risk

Once the team has generated a final set of risks, they have enough information to estimate two
things: a rough estimate of the probability that the risk will occur, and the potential impact of
that risk on the project if it does eventually materialize. The risks must then be prioritized in
two ways: in order of probability, and in order of impact. Both the probability and impact are
measured using a relative scale by assigning each a number between 1 and 5.
These numbers are arbitrary; they are simply used to compare the probability or impact of one
risk with another, and do not carry any specific meaning. The numbers for probability and
impact are assigned to each risk; a priority can then be calculated by multiplying these numbers
together. It is equally effective to assign a percentage as a probability (i.e. a risk is 80% likely to
occur) and a real duration for impact (i.e. it will cost 32 man-hours if the risk occurs). However,
many teams have trouble estimating these numbers, and find it easier to just assign an arbitrary
value for comparison.
Many people have difficulty prioritizing, but there is a simple technique that makes it much
easier. While it’s difficult to rank all of the risks in the list at once, it is usually not hard to pick
out the one that’s most likely to occur. Assign that one a probability of 5. Then select the one
that’s least likely to occur and assign that one a probability of 1. With those chosen, it’s much
easier to rank the others relative to them. It might help to find another 5 and another 1, or if
those don’t exist, find a 4 and a 2. The rest of the probabilities should start to fall in place. Once
that’s done, the same can be done for the impact.
After the probability and impact of each risk have been estimated, the team can calculate the
priority of each risk by multiplying its probability by its impact. This ensures that the highest
priority is assigned to those risks that have both a high probability and impact, followed by
either high-probability risks with a low impact or low-probability risks with a high impact. This
is generally the order in which a good project manager will want to try to deal with them: it
allows the most serious risks to rise to the top of the list.

Make a mitigation plan

All of this risk brainstorming and estimation is only useful if it leads to the team taking actions
to avoid the most pressing risks. The remainder of the risk planning meeting should be
dedicated to identifying these actions. The project manager should start with the highest-
priority risk, working with the team to decide on any actions that should be taken. After that,
the team should move down the list of risks, until they decide that the priority of each of the
remaining risks is low enough that no action would be required.
The team can take any or all of these actions to mitigate a risk:
  Alter the project plan. The project schedule can be adjusted to help reduce the risk.
Riskier tasks can be moved earlier in the project, or given more time. This will give the
team an early warning or a time cushion in case the risks materialize. The project
manager can also hold an additional estimation session to break down the riskiest tasks
into sub-tasks. More detailed planning will help reduce the risk.
 Add additional tasks. There are certain actions that can be added to the schedule to help
avoid risks. For example, if there is a high probability that a critical team member will
leave the organization, cross-training tasks can be assigned to other people. This will
increase total effort in the project, but it will be worth it if the team member leaves.
 Plan for risks. For risks with a high impact that do not need specific tasks or project plan
changes, the project manager should have the team spend a few minutes identifying the
steps that should be taken in case the risk does occur. These do not need to be added to
the project schedule, but they should be written down and added to the risk plan. This
way, if the risk does occur, nobody will panic. Problems that have a large impact on the
project can be demoralizing to the team and may throw the project into chaos. Simply
having pre-planned the steps needed to fix the problem is highly reassuring; it keeps the
team feeling like they are on track.

Once the mitigation steps are identified, all of these risks and actions should be documented in a
risk plan. The easiest way to do that is to create a simple spreadsheet with five columns: Risk
(one to three sentences which describe each risk), Probability (the estimated probability from 1
to 5), Impact (the estimated impact from 1 to 5), Priority (Probability × Impact) and Action (the
specific actions that will be taken to mitigate the risk, or “None” if the risk is deemed a low
enough priority to ignore).

Sample Risk Plan

2. Mention any six characteristics of interpersonal behaviour. What are the

types of reviews?
Ans: - Following are the six characteristics of interpersonal behaviour:

i. Clarity of expression and communication

ii. Patience in listening and reacting with empathy
 iii. Documentation and correct recording
iv. Offer to help
v. Call for help whenever necessary
vi. Seeking information before attempting decisions
The reviews are generally divided into four types which are conducted at different stages of the
project.
1. Initiation Reviews (IR)
2. Planning and Proposal Reviews (PPR)
3. Procurement Reviews (PR)
4. Quality Assurance Reviews (QAR)

A project review is a process where we capture information from the team experience and see
the variances and deviations from the plan. These reviews help in increasing productivity and
improve organizational success.

3. What are the main considerations in planning P2M? Give relevant examples.

Ans:- Some of the considerations for effective programme management are given below:

a) Focusing on the various strategic initiatives taken up for multiple projects and the issues
related to benefits and risks.
b) Bringing about the attention of management to a defined set of benefits, which are
understood immediately, which are managed throughout the implementation and at
completion.
c) Helping top management to set priorities, choosing options and allocate resources
d) Setting up mechanisms to measure and ensure that the projects making contributions
for realizing expected business benefits.
e) Leading the organisation on the path of ‘where it is ‘and ‘where it wants to be’ and
ensuring that the effects of the programme driven changes are coordinated, the
transitions are successfully managed. The operations are effective and efficient.

4. What is the significance of reviewing ROI? Explain in detail.

Ans:- Return on Investment (ROI) is the calculated benefit that an organization is projected to
receive in return for investing money (resources) in a project. Within the context of the Review
Process, the investment would be in an information system development or enhancement
project. ROI information is used to assess the status of the business viability of the project at key
checkpoints throughout the project’s life-cycle.

ROI may include the benefits associated with improved mission performance, reduced cost,
increased quality, speed, or flexibility, and increased customer and employee satisfaction. ROI
should reflect such risk factors as the project’s technical complexity, the agency’s management
capacity, the likelihood of cost overruns, and the consequences of under-or non-performance.
Where appropriate, ROI should reflect actual returns observed through pilot projects and
prototypes.

ROI should be quantified in terms of dollars and should include a calculation of the break-even
point (BEP), which is the date when the investment begins to generate a positive return. ROI
should be re-calculated at every major checkpoint of a project to se if the BEP is still on
schedule, based on project spending and accomplishments to date. If the project is behind
schedule or over budget, the BEP may move out in time; if the project is ahead of schedule or
under budget the BEP may occur earlier. In either case, the information is important for
decision-making based on the value of the investment throughout the project life-cycle.
Any project that has developed a business case is expected to refresh the ROI at each key project
decision point (i.e., stage exit) or at least yearly.
Exclusions
If the detailed data collection, calculation of benefits and costs, and capitalization data from
which Return on Investment (ROI) is derived was not required for a particular project, then it
may not be realistic or practical to require the retrofit calculation of ROI once the project is
added to the Review portfolio.

In such a case, it is recommended that a memorandum of record be developed as a substitute for

ROI. The memorandum should provide a brief history of the program, a description of the major
benefits realized to date with as much quantitative data as possible, and a summary of the
process used to identify and select system enhancements.

Some of the major benefits experienced by sites that installed the information system that
would be important to include in the memorandum are:
a) Decommissioning of mainframe computers
b) Reduction/redirection of labour
c) Elimination of redundant systems
d) Ability to more cost effectively upgrade all sites with one standard upgrade package.

In each case above, identify the specific site, systems, and labour involved in determining the
cited benefit. Identify any costs or dollar savings that are known or have been estimated. The
memorandum will be used as tool for responding to any future audit inquiries on project ROI.
For the Project Management Review, it is recommended that the project leader replace the text
on the ROI document through –
(1) a note stating which stage of its-cycle the project is in;
(2) A bulleted list of the most important points from the memorandum of record; and
(3) a copy of the memorandum of record for the Review repository.
In subsequent Reviews of the information system, the ROI slide can be eliminated from the
package. There is one notable exception to this guidance. Any internal use software project in
the maintenance phase of its life-cycle that adds a new site or undertakes an enhancement or
technology refresh that reaches the cost threshold established by Standard will need to satisfy
capitalization requirements. It requires all agencies to capitalize items acquired or developed
for internal use if the expected service life is two or more years and its cost meets or exceeds the
agency’s threshold for internal use software. The standard requires capitalization of direct and
indirect costs, including employee salaries and benefits for both Federal and Contractor
employees who materially participate in the Software project. Program managers are
considered to be the source of cost information for internal use software projects. If
capitalization data is collected for the project in the future, the project would be expected to
calculate and track its ROI.

5. What is meant by baseline? How is it reviewed?

Ans:- The Microsoft Project family of products offers tools to work on a Project from
management point of view. Microsoft Project is designed for people who manage projects
independently and don’t require the capability to manage resources from a central repository.
Microsoft has a team project management solution that enables project managers and their
teams to collaborate on projects.
After creating a fairly complete final project plan it is a good idea to create a baseline to
compare the original project plan with actual events and achievements.

Reviewing the Baseline

The Baseline created can be used to compare the original project plan with actual events and
achievements. This will display the days required for each task and project phase. For actual
operating instruction please refer the Microsoft Project User Handbook.

Tracking Progress
After creating a baseline, if the project has begun, it is necessary to enter actual dates that tasks
are being completed and the resource utilization used to complete them. Again review different
views and the cost and summary tables before proceeding to the next section. Return to the
Entry view of the Gantt chart before proceeding.

Balancing Workloads
At times people and equipment can become assigned more work than they can complete in
normal working hours. This is called over allocation. Project can test for this condition and
reschedule (or level) their workload to accommodate completing tasks during a normal day.

Monitoring Variances
After a baseline has been established and the project has begun, it is desirable to determine if
tasks are being accomplished on time and /or if cost over runs are occurring.

Creating Reports
Project has many different built-in reports and has the capability building custom reports and
exporting data to other MS Office applications for integration into other reporting venues.

6. Explain in detail GDM and its key features.

Ans: - The Global Delivery Model (GDM) is adopted by an Industry or Business such that it has
a capability to plan design, deliver and serve to any Customers or Clients Worldwide with
Speed, Accuracy, Economy and Reliability.
The key Features of GDM are –
a) Standardization – Ingenious Design and Development of Components and Features which
are like to be accepted by 90% of World-wide Customers. Global Standards of Design
focusing on highly standardized Methods and Processes of manufacture or Development.
Adopt Plug-and-socket Concepts with minimum adaptable joints or Connections.
b) Modularization – Product or Solution split up into smallest possible individual Identifiable
Entities, with limited Individual Functioning Capability but powerful and robust in
Combination with other Modules.
c) Minimum Customization – Minimum Changes or Modifications to suit Individual
Customers.
d) Maximum Micro Structuring – Splitting of the Product Modules further into much smaller
entity identifiable more through characteristics rather than application Features. Approach
through Standardization of these Microbial Entities even across Multiple Modules.
Application of these Microbial Entities to rest within multiple Projects or Products or even as
add-ons suit belated Customer Needs.