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 the

resource requirement increases from start to an intermediate stage of the project. It

further increases at rapid rate and becomes constant while the project is during its 80 to

95% progress stage. 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 completes the 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

based upon 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 is perfected, it might have become obsolete. This necessitates that the period be

shortened. The other alternative is to make technology developments futuristic i.e. keep

the aim or target one step beyond what 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 to counter 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 follow up 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 whose system 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 face-to-face briefing may not be required each quarter. The CIO will

notify the system

Owner/program/project manager have to schedule the face-to-face 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 review 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, up-

to-date Process documentation. The System allows users to navigate through graphical

structures to relevant documentation and processes which were created with the ARIS

Toolset.

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 top down 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 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 SCMo

documentation contains three levels:

Level 0: Work Package

Level 0 shows the work packages, which represent the different part projects. At present

only the SCMo processes 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 self-contained process blocks.

Level 2: Sub Process

In Level 2, the processes are graphically depicted in the form of process chains. The

process chain model itself can be opened via the assignment.

The chart describes the objects that are used in the function tree model:

Object Definition Example

Function an object that represents a work package, a process or a sub process.

Operative Processes

* Update SCMo Inventory

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 ARIS

Toolset. 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 double clicking 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 Sub Process level. In the model “Process Overview SCMo” those processes are

assigned to the functions on Level 2. In the models there can be assignments for some

functions, e.g. for a Function Allocation Diagram or a sub process 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 account

opening 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, XL’s and analyzed

for impact on 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/delivery on time 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, re estimation 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

of completion or delivery of the item to the customer. This is specified in the form of a

table indicating 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 one

person 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.