1. What are the various characteristics of a project?

What is the importance

of each characteristic? Give examples.
Any project may be considered to have the following characteristics:
a) Resource requirement : During the course of executing the project, it is seen
that theresource requirement increases from start to an intermediate stage of the
project. It furtherincreases at rapid rate and becomes constant while the project
is during its 80 to 95% progressstage. Thereafter the resources requirement
decreases to zero i.e when the project comes to a finish. Refer the Characteristic
chart.
b) Funds : The requirement of funds for the completes execution of the project
also follows the same trend as that of the resources. The two are more or less
proportional.
c) Probability of completion: The probability of completing the project can be
estimated basedupon the normal distribution curve. In the initial stage of the
project the probability of completing the project is low though not zero. It
gradually increases and as the project approaches finish the probability of
completing the project tends to become 100%. Refer the Characteristic chart.
d) Risk : The risks involved in the project affecting its completion time is high at
the initial stages and low at the later stages of the project. Refer the
Characteristic chart.
e) Design changes : The project during the course of its progress may be
subjected to changes because of some external factors. The influence of such
external factors on the project may result in changes in the design f the project
though not very often. It is observed that such changes if any are normally high
during the initial stages of the project and decreases as the project approaches
finish.

2. State the principles of Deming’s Philosophy relevant to Project Management.

Explain how each one is applicable in management?
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 through
a) Sufficient content of development activities the work should be interesting and
bring a sense of satisfaction and achievement;
b) Favourable working conditions – environmental conditions should make a
man/woman feel comfortable to stay at the workplace
c) Planned activities – clear line of authority and recognition of performance;
d) Adequate availability of resources; otherwise frustration sets in and
commitment is lost;
e) Properly planned system of quality control though Process Control If
the process is not good, even the best efforts will not be enough to get tolerable
quality and the person doing it is made responsible;
f) Adequate maintenance support for Hardware and Software; these ensure that
no work gets held up on this account – efficiencies bring in productivity.
As far as productivity as well as quality is concerned, especially, where projects
are concerned, it is good to follow Deming’s philosophy, which states – create
conditions for performance, do not use rhetoric, pay him well and give the pride
of working.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 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. 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. Some
times, training will help.

3. Explain the concept of concurrency in High Technology Development.

Always aim one step higher in performance

Usually, high technology development has a long gestation period. By the time
the product isperfected, it might have become obsolete. This necessitates that
the period be shortened. The other alternative is to make technology
development futuristic i.e. keep the aim or target one step beyondwhat is
required. Combination of both will yield better results. Using principles of
concurrent engineering, we can start building components as developed and
assembling on ad hoc basis and testing them and making changes taking into
consideration any new requirements. Every effort to make the product
contemporary will improve the competitive advantage.

Build concurrency into every activity

Building concurrency into every activity is essential to reduce the development
cycle time and tocounter the technology obsolescence. Many of the tasks that
 are normally done in a serial fashion can be done in parallel by synchronizing the
flow of information. The practices of the concurrent engineering where the design
of the product and all its associated processes are carried out simultaneously
based on team work and participation. Would not only help in reducing the
development cycle time, but also improves the product functionality with regard
to requirements. Concurrency can be accomplished in many ways both for
product development as well as technology
transfer, user evaluation and production.

4. Explain in detail the project management review process. What are the
various post review activities ?
The Project Management Review Process includes the following steps:
a. Identification of projects that will participate in the Reviews
b. Development and adherence to a quarterly reporting schedule
c. Compilation of standard project management data into a presentation data
d. Collection of detailed project files that support the information reported during
the project
Management Reviews and may be requested for inspection during a formal audit
e. Participation in the Review meetings with any required followup activities
Applicable Projects
Any corporate or major information system at any facility is a candidate for the
Project
Management Review Process. A meeting will be scheduled to introduce and
explain the Project Management Review Process and reporting tools. As
candidate projects are added to the Review portfolio, they will be incorporated
into the next review cycle schedule.
The program and project managers of the information systems that are included
in the Review portfolio are expected to comply with the process described in this
guide. The program and project managers of information systems that are not
being reviewed through the Project Management Review Process should also
consider using this guide as mandates, that all information technology resources
undergo a management, control, and review process. Several of the current and
future corporate and major information systems initiatives have been identified in
the Departmental information Architecture Program guidance series and in the
Corporate Systems Information Architecture (CSIA) document. Infrastructure
projects may be considered candidates for the Review process. Modernization
plans are also sources for identifying corporate and major systems that should be
included in the Review portfolio or whosesystem owners should implement and
follow this process.
Reporting Schedule: The Project Senior Management Reviews are scheduled
every
three months in conjunction with the fiscal year. A table may be prepared to
contain the columns
“As of Date” column indicates the last day in which information should be
included for each
reporting period, the “Briefing Due Date” column provides the date that an
electronic version of the briefing is due.
Project Management Data
Legislative and regulatory mandates ensure that technology initiatives are
implemented at
acceptable costs within reasonable and expected time frames. The team ensures
that
investments in information technology are fully justified and aligned with agency
missions and business needs. Agency CIOs have the responsibility to ensure
coordination
and tracking of investments.
Throughout the project lifecycle it is important to apply standard project
management best
practices, including tracking and reporting, to all projects, regardless of size. For
smaller projects, stages may be combined and deliverables reduced in scope as
appropriate. For larger or more complex projects, additions project planning,
tracking, and reporting activity may be appropriate.For all projects identified to
participate in project Management Reviews the standard set of project
management reporting requirements fits into the following five categories:
i) General Project Overview
ii) Project Status
iii) Product Status
iv) Issues and Risks
v) Project Unique Information
A substantial amount of project management information that is useful
throughout the information system’s lifecycle should be gathered in a central
project file maintained by the project manager.All work products developed
during the project lifecycle
should be included in the project file.The project manager should verify that all
pertinent project information and documentation are placed in the project file on a
timely basis. In addition to being useful in responding to routine and adhoc
requests for information, a project file is instrumental in case of internal or
external audits.Information about projects in the Review portfolio will be made
available for addition to a corporate and major information system repository.
This repository serves as a database or data warehouse for storing and
accessing information. In addition to the Project Management Review briefing
slides, the repository is being used to store other information needed for
reporting. The following list includes some of the documents that should be
provided for the projects participating
in the Review Process:
i) Set of review charts
ii) Supporting documentation (if any)
iii) Handouts (if any)
iv) Project Plan
v) Work Breakdown Structure
vi) Review meeting notes
Access to the repository is restricted to members of the staff responsible for the
Reviews,
responding to Congressional inquiries, and preparing federally mandated reports,
and to the
program and project managers.
Review Briefings
There are two formats for the Review briefings: First Time and Ongoing. The
First Time Review is the initial briefing that occurs when a project is first added to
the Review portfolio. All subsequent reviews use the Ongoing Review briefing
format. The primary difference between the two formats is the General Overview
of the project that is presented during the First Time Review (FTR). This
information is omitted from the Ongoing Review briefings unless it has changed
since the previous review. It is expected that some of the charts in the First Time
Review will need to be included in the first Ongoing Review of the Fiscal year
since annual objectives and funding may change at the start of the fiscal year.
The briefing content is designed to address all of the pertinent information about
the project at a level appropriate for management and senior management e.g.,
the CIO.
Preparation and electronic submission of each briefing to the CIO is required on
a quarterly basis.A facetoface briefing may not be required each quarter. The
CIO will notify the system
owner/program/project manager to schedule the facetoface briefings that are
required for each reporting period.
Following are some general guidelines for preparing the briefings:
The briefing can be given by the project manager. Other project stakeholders or
key personnel may be involved in the presentation. The briefings should focus on
the current status and issues associated with the project. Two hours are
allocated for each briefing. Participants may attend the meeting in person.
Program and project managers are expected to bring their senior management to
the quarterly briefings. Senior contractor management attendance is considered
to be a good indicator of their interest in assuring their staffs are delivering good
products. A detailed WBS should be provided with the presentation charts.
Termination from the Review Process
By mutual agreement between the CIO and the Program Manager, once a
project has been
implemented (i.e., the system is in operation), the project may discontinue the
Review briefings.Once the Project Management Review has been conducted,
follow up with program/project managers on any issues or concerns requiring
attention, the status of open items from the review,and CIO reporting actions,
e.g., reports to the CIO Council. The CIO may also recommend quality
assurance analysis be conducted.
.1 Issues or Concerns Requiring Attention
The project manager is responsible for raising issues or concerns that require
assistance or
guidance to the attention of the CIO. These items should be communicated
whenever they
become known, and not held to the next Project Management Review. The CIO
will assign
appropriate OCIO staff available to help resolve open items. The program /
project manager
should communicate the status of these items in each quarterly reviews until the
items are
resolved / closed.
.2 Status of Open Items from Review
The program/project manager is responsible for tracking the open items from the
review and
communicating the status in each quarterly review until the items are closed. The
supporting the scheduling of reviews will coordinate with the program/project
manager after the quarterly reviews to help ensure that new items have been
captured for tracking and action by the program/project manager.
.3. CIO Reports
The staff supporting the CIO Quarterly Reviews will prepare a summary report
after each Project Management Review. The summary report will include the
following information:
i) Summary Status
ii) Open Issues/Items
iii) Status Performance Objectives/Measures
iv) Status of Schedule/Cost
The summary report will be provided to the program/project manager to gain
concurrence on the content. The summary report will be used by the CIO when
reporting status to the CIO Council.

5. Explain the structure of the documentation systems as required by supply

chain monitoring. What is the significance of documentation? How does it
help a manager?
The intent of this document is to define the structure of the Documentation
System, its content, the method of content generation and to attain common
documentation of all standard processes of Odette.The documentation is valid for
the SCM group
of Odette. The Documentation System is intranet based to provide immediate
access to current, uptodate Process documentation. The System allows users to
navigate through graphical structures to relevant documentation and processes
which were created with the ARISToolset.
The process documentation system serves the following objectives :
1. Present standard processes to be adhered to across the Industry, and in so
doing secure their correct
application .
2. Offer a central location of all process and system related information – form
customizing
documentation to working guidelines.
3. Allow flexible and quick adaptation in case of process changes or
enhancement and provide the
updated information immediately.
4. Present the standard processes in the intranet, where users can look up the
current processes whenever necessary.
5. Availability at every working location.
Defining the Process Documentation System
The content of the process Documentation System includes the area supply
chain management from the Odette Supply Chain Management Group. The
system includes graphical process documentation, in the form of process chains,
as well as the entire range of documentation related to the processes. Related
information is attached to each documentation level, where it can be in the form
of a single document or a link to further documents or other process chains.The
process Documentation System gives, according to its objectives, an overview
and a detailed view of the relevant processes for SCMo. The processes give the
information as to which activities are done and by whom, when the activities are
done and which systems and information support those activities. Easy system
operation is achieved though the use of topdown navigation and the availability of
a search
index.
Model, object and Symbol Specifications
Models and Model Types being Used:ARIS offers a wide variety of model types
to enable modeling customized to individual specifications.The models and
model types used in the documentation system are listed in the following table:
Model Identification Model Type
Work Package Function Tree
Process Function Tree
Sub Process Process Chain (eEPC)
Description of Models and Objects
Function Tree
The entry level of the process documentation structure is the function tree that
shows the hierarchic structure of the process documentations. The function of
the SCModocumentation
contains three levels:
Level 0: Work Package
Level 0 shows the work packages, which represent the different part projects. At
present only the SCMoprocesses are described in this documentation.
Level 1: Process
On Level 1, the processes that belong to the work package on Level 0 are listed.
Project Management Unit 12
Sikkim Manipal University 175
They are not yet the specific processes, but rather selfcontained
process blocks.
Level 2: SubProcess
In Level 2, the processes are graphically depicted in the form of process chains.
The process chainmodel itself can be opened via the assignment.
The chart describes the objects that are used in the function treemodel:

Object Definition Example

Function An object that represents a
work package, a process or a sub
process.
Operative Processes
* Update SCMoInventory
Information
Edge Illustrates logical succession by
connecting the individual elements.
* Alert Workflow
Process Chain
The Process Chain describes a process based on the chronological as well as
the logical
interdependencies.
A process Chain contains the following elements, which are called “objects” in
the ARISToolset.Some objects are mandatory like event, function, edge and
connectors
Model Integration and Model Navigation
The above mentioned models are connected with one another to create the
integrated model in its entirety. The entry point in the documentations system is
the model “Process Overview SCMo”. This model is the starting point for the
navigation to other models. The navigation between models is done via the
assignment symbol. The assignment symbol of a Function / process Interface
indicates that there is a link to another model. The linked / assigned models can
be opened by doubleclicking on the assignment symbol.

Supply Chain Modeling / Mapping assignment symbol

Vertical navigation:
The vertical navigation is the navigation on different levels. Starting on the Work
package level and going downwards into more detail, the first models of
processes are found on the SubProcess level. In the model “Process Overview
SCMo” those processes are assigned to the functions on Level 2. In themodels
there can be assignments for some functions, e.g. for a Function Allocation
Diagram or a subprocess that describes that function. Those two examples are
currently the models on the lowest level.
Horizontal navigation:
The horizontal navigation is the on one level. Some processes have a link to
other processes, which can be at the start or end or even in the process itself,
 when another process is imbedded in the process.Those links are represented
by Process Interfaces.

6. Write down a brief outline of any assumed project management plan.

1 PROJECT SUMMARY
Project Overview – Consider a firm XYZ
as a Stock Broker/ Dealer firm. Any support software will
have applications supporting the following components:
· first, a Brokerage Account Opening application on XYZ’s Web site that will allow
any internet user to open a brokerage account with XYZ.
· Second, an account opening and maintenance application, which is primarily for
XYZ’s
representatives to open accounts for the applications received in paper format.
This is an intranet application. The application will provide features such as
account history viewing and account balance, status, and activity information.
This will allow XYZ to effectively evolve to a client account servicing application
besides being an accountopening engine. This is an enhancement of an existing
application.
14.2.2 Project Scope
· To provide an effective, efficient means of amount maintenance activities
· To allow representatives to provide information
· To provide a complete picture to the client representatives for account status,
valuation, order
status, and trade activity
· To increase the intelligence of the update process
· To Provide an interface that can display required amount history
14.2.3 Value addition to the customer
· This project will allow XYZ to effectively evolve a client account servicing
application besides being an account giving engine.
a. Objectives
Strengthen relationship with XYZ by delivered high quality software on time
Become preferred vendor by developing expensive on XYZ product and systems
b. Commitment made to the customer
c. Assumptions:
Assumptions made while planning
· Intelligent update to business partners will be incorporated in only the
maintenance part of the application and not in the Account opening engine.
· Qualified people will approve Rational Unified Process methodology for
implementing this project Changes in functional and technical requirements
during the life cycle of the project may have an impace on the schedule. Any
impact on cost or schedule due to these changes will be intimated to XYZ.
· XYZ reviewers will take seven days to approve a milestone document. If no
comments are received within this time period, it will be considered as approved.
Project Planning
Change request tracking
· Changes requested by customer will be logged in change request. Xls and
analyzed for impacton the project . A change request form will be submitted to
customer for approval. Change request that are approved will be attached to the
project contract as agenda.
· Major change usually has an effort/deliveryontime impact on the project. The
customer needs to formally approve these
· Because this is a short duration project, if any one or a group of changes
request takes more than 2% of the total estimated effort for the project,
reestimation
of the project schedule and effort will be done.
c. Requirement Trace Ability – Requisite tool will be used
a. Estimated build effort – Estimate the effort required in man days for each
program or function of the project. This will help in estimating the total build effort.
Project
b. Phase Wise effort estimation – Estimate the total effort wrt each activity and
effort for each phase of a project expressed as percentage of man days.
c. Schedule – Prepare a list of items as deliverable to the customer and indicate
the date ofcompletion or delivery of the item to the customer. This is specified in
the form of a tableindicating various milestone of commitment to the customer.
People – Make a list of the people required for each role in the project along with
number of members required for each role. The list should consist of skilled and
unskilled people depending upon the role and experience of the individual. Also
prepare the requirement plan of people as to when and how many of each type
would be required on the project.
14.2.6 Hardware, Software and Tools – Indicate the hardware and software
resources required in the project at every stage. Plan for procurement of
hardware and software depending upon the need at various stage of the project.
Prepare a date wise plan of procurement. Tool List has to be prepared phase
wise and activity wise. Specify the tools to be developed on the project along with
the house tools to be developed in project which can be in the form of
14.2.9 Reviews
Prepare a table of important review points. The table should contain the review
item and the type of review required for each of the review item. Type of review
could be oneperson review, group review
etc.
14.2.10 Risk Management Plan
Prepare a table of risk management plan to indicate the risk type, probability of
each risk, impact of the risk on the project, risk exposure and a risk mitigation
plan for each risk.
14.2.11 Project Tracking
Prepare a measurement plan for tracking the project. The plan must indicate the
appropriate metric to be used, the unit of measurement and the tool to be used.
Also prepare the procedure for task tracking. Similarly prepare a table for
tracking various issues of the project like logging details, review by, review time,
floats etc. Obtain customer feedback on the various items of the project.
Determine the actions for each quality activity. Plan for a review by a senior
management and have a planned frequency of reviews. Verify the status report
about each activity of the project. Prepare a list of
tolerances for the defects observed in items and monitor such items. Prepare
Reports to be given to the Customer which may indicate ·
Milestones reports and weekly status reports
· Issue requiring clarification
· Escalation, if any
Prepare Report to be given to the Business Manager which should contain ·
Customer feedback
· Milestones and weekly status reports
· Issues requiring clarification / attention
· Escalation, if any
· Number of requirement changes and estimated effort for them
· Major changes in plan
Prepare the project organization chart as applicable to the project under
consideration. Include the project team members list along with their
responsibility, starting date and completion date of the activity. A detailed table of
roles and responsibilities for each m
4.2.12 Closure report
At the end prepare closure report table. Indicate the necessary project
phase/entity along with project code and corresponding status.

SET 2

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

example.

Risk management may be classified and categorized as

1.Risk assessment and identification The assessment and identification
focuses on
enumerating possible risks to the project. Methods that can aid risk identification
include
checklists of possible risks, surveys, meetings and brainstorming and reviews of
plans, process and work products. The project manager can also use the
process database to get information about risks and risk management on similar
projects.
2. Risk prioritization – focus on the highest risk. Prioritization requires analyzing
the possible effects of the risk event in case it actually occurs. This approach
requires a quantitative assessment of the risk probability and the risk
consequences. For each risk rate the probability of its happening as low, medium
or high. If necessary, assign probability values in the ranges given for each
rating. For each risk, assess its impact on the project as low, medium, high or
very high. Rank the risk based on the probability. Select the top few risk items for
mitigation and tracking.
3. Risk Control: The main task is to identify the actions needed to minimize the
risk
consequences, generally called risk mitigation steps.Refer to a list of commonly
used risk mitigation steps for various risks from the previous risk logs maintained
by the PM and select a suitable risk mitigation step. The risk mitigation step must
be properly executed by incorporating them into the project schedule. In addition
to monitoring the
progress of the planned risk mitigation steps periodically revisit project. The
results of this review are reported in each milestone analysis report. To prepare
this report, make fresh risk analysis to determine whether the priorities have

Risk Analysis
The first step in risk analysis is to make each risk item more specific. Risks such
as, “Lack of
Management buyin,” 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 Jane 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. 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. 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. In the process below, we have 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 analyze risk either by sensitivity analysis or by probabilistic 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. In the probability
analysis, the frequency of a particular event occurring is determined, based on
which it 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 alternativeand selecting the best alternative.
Ex : Now that the group has assigned a priority to each risk, it is ready to select
the items to
mange. Some projects select a subset to take action upon, while others choose
to work on all ofProject the items. To get started, you might select the top 3 risks,
or the top 20%, based on the priority calculation.

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

types of reviews?

In a team the maxim that all members will do well to remember is “Learn to
appreciate the problems of others, and some others would appreciate yours”. It is
therefore important that in a business environment, particularly in Project
Management, efforts to evolve solutions jointly has great benefits, both for the
teams as well as the organisation. The top management has the responsibility of
encouraging such a culture to develop team work to healthy interpersonal
behaviour.
Interpersonal behaviour calls for:
· Projection of a pleasant, but firm personality
· Clarity of expression and communication
· Patience in listening and reacting with empathy
· Documentation and correct recording
· Offer to help
· Call for help whenever necessary
· Seeking information before attempting decisions
· Not waiting for things to go wrong
· Motivation of others through efficiency and meticulousness, rather than urging
and exhibiting dependency
· Putting team goals ahead of individual targets.
The project manager should make it a habit of expressing appreciation openly for
any good work done. Cross Functional Teams have become a necessity and the
synergy they generate would be lost if interpersonal behaviour is not of high
standard. As members are from different functions, understanding the
requirements or compulsions of others is difficult. This fact should be impressed
upon all the members and requesting them to cooperate is vital.
5.8 Traits of successful teams
Work Teams in organizations empower employees to take maximum
responsibility to make decisions, which were once thought to be the prerogative
of managers. Decision of the team represents the collective wisdom of its
members and as they all are bound by them, they try to make it better. The point
of interest is that the outcomes of the decisions will have a bearing on their
performances.On the other hand, if they are carrying out the decision of the
manager, they do not feel responsiblefor the consequences. Their commitment to
perform well is reduced. This is the logic behind
successful teams. The presumption is that the members are endowed with the
knowledge, skill and commitment to perform the activities upon whom they take
decisions. It is the manager’s responsibility to provide them with knowledge and
training to enable them to have confidence. The secret of team work advantage
lies in the following:
1. Clear understanding of the organizational goals, objectives and norms.
2. Open communication among team members;
3. Creation of balance among team members by having a high sense of
ownership;
4. Recognition of the strengths and weaknesses of the members.
5. Closeknit relationship for performance enhancement;
6. Accepting the leadership qualities of one or two members and offering
unconditional support for them;
7. Encouragement of constructive evaluation of each member’s contribution with
a view to resolve problems;
8. Willingness to accept differences of opinion, but capacity to make concessions
with the team in mind.
9. Taking initiative and giving it all to complete challenging jobs.Teams are not
built in a day. Owing to circumstances and opportunities, managements put
together a group of persons, who they have decided will be able to take up a job
or project and complete it.
Since different skills at different levels are needed along with knowledge of
different kinds, an
hierarchy is created. As jobs get done, each of them would have evaluated the
others. Factors of congruence and dissonance will make some adhere and some
depart. During this period the Manager with a knowledgeable Human Resource
person, should facilitate this process. Wherever necessary, training programmes
have to be conducted. Each organisation has to find path it has to take. Top
management’s commitment and competent managers should guide the teams.

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

examples.

Project and Programme Management P2M

the considerations for effective programme management are given below:
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 at 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
realizing expected business benefits. Leading the organisation on the path of
‘where it ’ an ‘where it wants to be’ Ensuring that the effects of the programme
driven changes are coordinated, the transitions are successfully managed. The
operations are effective and efficient.
1Process of P2M
The objectives sought to be achieved and the methods which are adopted and
the activities that are
going to be undertaken i.e. the process include the following steps :
Preparing and maintaining a set of activities and the workflow that is to be
followed and identifying business areas responsible for different stages in the
above;
1. Making sure that the priorities that the above generate are relevant and the
projects are run on the basis of their impact on the business as a whole;
2. Structuring the programme so that the responsibilities and roles – at both
programme and project level – are acceptable to both the top management and
managers;
3. Planning the various points of review between various phases of the projects.
The process has to incorporate all the important aspects which are to be
addressed during implementation and management of the projects. It is important
to identify all factors and incorporate resources – men, materials, technology and
time – so that their provision can be planned.
Managing the Programme
When we consider the portfolio of projects as a programme, the main
considerations will be on resources, risks associated with the programme, quality
of the projects at every stage of the executionas meeting the requirements of the
client as per the contract and monitoring the change processes that get
enmeshed during implementation. The specifics concerning the above are listed
below:
i) Evaluating the risks associated with the programme – the planned changes to
the business operations;
ii) Ensuring that the processes to ensure quality are sufficient and purposes are
fully met;
iii) Keeping track of the changes and developments external to the project
environment and studying their impact on the programme.
iv) Making sure that the personnel in business affected by the above are
informed and trained so that the projects are smoothly;
v) Ensuring that the support services like human resources and IT are able to
adopt to the changes that take place in the projects and business operations as a
whole.

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

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 lifecycle. 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 underor
nonperformance.
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 breakeven point (BEP), which is the date when the investment
begins to generate a positive return. ROI should be recalculated 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 decisionmaking based on the value of the investment throughout
the project lifecycle.
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 itscycle 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 form the
package. There is one notable exception to this guidance. Any internal use
software project in the maintenance phase of its lifecycle 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?

Project Management using Software
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 thecapability to manage resources from
a central repository. Microsoft has a team project managementsolution 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 theoriginal project plan with actual events and achievements.
12.4.1 Reviewing the Baseline
The Baseline created can be used to compare the original project plan with
actual events andachievements. This will display the days required for each task
and project phase. For actual operatinginstruction please refer the Microsoft
Project User Handbook.
12.4.2 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.
12.4.3 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.
12.4.4 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.
12.4.5 Creating Reports
Project has many different builtin 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.

The Global Delivery Model (GDM) is adopted by an Industry or Business such

that it has a capabilityto plan design, deliver and serve to any Customers or
Clients Worldwide with Speed, Accuracy,Economy and Reliability.

The key Features of GDM are ·

Standardization
· Modularization
· Minimum Customization
· Maximum Micro structure
· Adoption of a Combination of the Greatest Common Multiple and the Least
Common Factor of a
Large Mass of Microbial Components.
a) Standardization Ingenious
Design and Development of Components and Features which are like to be
accepted by 90% of Worldwide Customers. Global Standards of Design focusing
on highly
standardized Methods and Processes of manufacture or Development. Adopt
Plugandsocket 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 addonssuit belated Customer Needs.
Special Features of GDM
Some of the special feature of GDM are ·
Cuts across Geographical and Time Zone Barriers
· Unimaginable Speeds of Response and Introduction.
· Common Pool of Microbial Components
· Largely Independent of Skill Sets required at Delivery Stages
· Highly automated Processes
· Quality Assurance as a Concurrent rather than a Control Process
NearShore Development, Manufacture and Delivery for better Logistics
· Mapping of Economical Zones rather than Geographic Zones
· Continuous Floating virtual Inventory to save Time and Efforts.