SET-2 PROJECT MANEGEMENT - Doc New

SET -2
1. Write brief note on need for project management , project

management knowledge areas and relationships.
ANS.
Need for project management
Project management is necessary because-
• A project requires huge investments which should not go waste
• A loss in any project would have direct or indirect impact on the society
• Prevent failures in project
• Scope of the project activity may undergo a change
• Technology used may change during the course of project execution
• Consequences of negativity in project related problem could be very serious
• Change in economic condition may affect a project
Project management knowledge areas and relationship
it comprises of various techniques needed to manage project, the practical

methodologies adopted in formulating a project and managing the resources which
would affect the project completion. Relation with other management discipline is
essential for project to be successful. Supporting disciplines includes law, strategic
planning, logistics, human resource management and domain knowledge.
Taha mohammed Page 1

2. Explain the various estimation approaches and estimation tools.
ANS. Estimation approach – there are two types of estimation approaches:
• Bottom up approach:-
The bottom up approach consists of the following –
The factors mentioned above may play a vital role in a project’s failure, and this is the
reason why numerous organizations have turned to a bottom-up management style or
at least some of its elements. The New York Times is one of the good examples. The
bottom-up approach implies proactive team input in the project executing process.
Team members are invited to participate in every step of the management process.
The decision on a course of action is taken by the whole team. Bottom-up style
allows managers to communicate goals and value, e.g. through milestone planning.
Then team members are encouraged to develop personal to-do lists with the steps
necessary to reach the milestones on their own. The choice of methods and ways to
perform their tasks is up to the team. The advantage of this approach is that it
empowers team members to think more creatively. They feel involved into the project
development and know that their initiatives are appreciated. The team members’
motivation to work and make the project a success is doubled. Individual members of
the team get an opportunity to come up with project solutions that are focused more
on practical requirements than on abstract notions. The planning process is facilitated
by a number of people, which makes it flow significantly faster. The to-do lists of all
the team members are collected into the detailed general project plan. Schedules,
budgets and results are transparent. Issues are made clear by the project manager to
avoid as many surprises as possible. Bottom-up project management can also be
viewed as a way of coping with the increasing gap between the information necessary
to manage knowledge workers and the ability of managers to acquire and apply this
information.

However, despite all it the advantages, the bottom-up style alone will not make your
projects flourish. According to many experts, the bottom-up approach is not the
perfect solution, as sometimes it lacks clarity and control. The best way is to find a
balance between the two opposite approaches and take the best practices from both of
them.
• Top down approach:-
The top-down approach remains extremely popular in contemporary project

management. The phrase “top-down” means that all the directions come from the top.
Project objectives are established by the top management. Top managers provide
guidelines, information, plans and fund processes. All of the project manager’s
expectations are clearly communicated to each project participant. Following this
approach, ambiguity opens the door for potential failure, and the managers should be
as specific as possible when communicating their expectations. Process formality is
very important for this approach. Examples of the top-down approach applications
can be found in many organizations. One of such example is the New York Times, a
leader in the newspaper industry. Several years ago, American Journalism Review
(www.ajr.com) reported that The Times’ executive management felt that they were far
from what was necessary for creation of a vibrant workplace and a successful
organization. Power was centralized and masthead editors experienced overall
control. Editors introduced the same management pattern in the projects for which
they were responsible. One person’s emotions and opinions influenced all the project
decisions, and this person was the project manager. What was the result? Team
members felt that they weren't listened to, that their voices didn't count. There was no
effective collaboration between the journalists. They were not morally motivated to
do their jobs. The managing executives then realized that they needed to give more
freedom to the teams and change their management style. It took quite a while to
introduce bottom-up management to the organization. But, obviously, it was worth
the time and effort, as New York Times employees say that collaboration became
much more efficient, and team members now work together more productively.
Similar problems caused by utilizing the top-down approach can be observed in many
organizations with a traditional management style. Experience shows that this top-
down management often results in reduced productivity and causes bottlenecks or so-

called lockdowns. A lockdown gives the project manager total control over his team.
Such lockdowns can lead to unnecessary pain and significantly slow down a project’s
completion.
Perfect balance
If you have tried introducing the best bottom-up practices to your organization, you
have probably found it difficult to do that while utilizing traditional tools for project
management. Traditional project management software, like Microsoft Project, was
mostly designed to fit the use of the top-down approach and is not meant for the
bottom-up management style. This software is focused on the project manager and
places him or her in the center of the project communications. Team members very
often have read-only access to the project plan and cannot make any contributions or
changes. The employees send their updates to the project manager in disconnected
files via e-mail. The project
manager then has to collect all the data and put the information manually into the
project plan. After that, he or she has to communicate the changes to the corporate
executives. All these routine procedures lead to a situation where the project
manager's talents often are buried by the routine work. The huge amount of
mechanical control/synchronization work often leaves little very time for leadership
from the project manager. The good news is the situation is changing thanks to the
transformations going on in how people share and receive information. More
methods for the successful implementation of the bottom-up management best
practices have emerged. These methods include are Enterprise 2.0 technologies –
wikis, blogs, social networks, collaboration tools, etc. They come into organizations
and change the original way of executing projects. They turn traditional project
management into Project Management 2.0 and bring new patterns of collaboration,
which are based on collective intelligence. Collective intelligence is a collection of
valuable knowledge from different fields that each project team member is an expert
in. This knowledge is now successfully collected and shared shared in a flexible,
collaborative environment brought by second-generation project management
software. The project manager is the one to conduct the work of his team and choose
the right direction for the project development, based on the information received
from the individual employees. Thus, the role the project manager plays in the project

changes. Project Management 2.0 software facilitates delegation. It means that people
become less dependent on the manager as a to-do generator. The project manager
turns from a taskmaster into a project leader. His role is to facilitate the team
communications, provide a creative working environment and guide the team. He or
she becomes a visionary able to leverage the team strengths and weaknesses and
adjust the project development, based on various external changes. Individual team
members still have the freedom and responsibility to find their way to the next
milestone. With the help of the second-generation project management tools,
managers can merge the advantages of the two management approaches. These tools
help them to combine control and collaboration, clarity of project goals and visibility
of internal organizational processes. Thousands of companies, such as Bell Canada,
Sun and Yahoo now confirm that bottom-up project management, implemented with
the help of Enterprise 2.0 tools, improved their business performance. Some
companies created corporate blogs to streamline project communications; others
introduced wikis to get their customers’ feedback. Even giants, such as IBM, realize
the benefits of allowing contributors to have a more active hand in how collaborative
work is organized. My conclusion will be that democratizing project management is
never an end in itself. The primary goal is always to find ways to make project
management and project collaboration more efficient. New technologies applied to
projects offer us the ability to make projects more successful and teams more
productive. At the end of the day, projects are delivered faster, and this is to
everyone’s benefit.
Estimation tools:-
An estimate, as defined in the PMBOK® Guide, is an assessment of the likely

quantitative result of a project, an activity, or series of activities . Since we cannot
predict the outcome of a project activity with 100% certainty, we estimate the
outcome using various tools and techniques that can help us determine what should
happen depending on the many conditions that may impact the outcome. Estimation
tools are designed to assist in the process of approximating task or activity duration,
level of effort required and/or costs associated with project resources and other
factors. Generally speaking, they provide the estimator with:
Estimates of the effort (labor hours) needed to do the project

Estimates of the duration (calendar time) required for the project
Estimates of the labor costs of the project
Estimates of the material cost
It is important to note that estimating project work is a project management core

competency. Project managers should be familiar with, and be able to use or direct
the project team, to use the appropriate tools to ensure that estimates provided during
the planning process are reliable. Estimation tools are driven by historical data and
many can serve as a parametric model which can be scalable based on the size of the
project. Based on the specific estimation tool, the user is required to provide at least a
few and sometimes many attributes or parameters that describe the work in question,
the group that will do the work, and the process that will produce the product. The
work is generally described by providing a definition of the size of the project or task.
The group is generally described by measures that deal with skill levels, experience,
labor costs, knowledge of the work product, etc. The process is generally described
by measures that deal with development methods and models, security and control
requirements, quality requirements, reuse requirements, documentation requirements,
etc. The better the data in each of these areas, the better the estimate for the project
will be. From a metrics perspective, the estimates of effort, schedule, and cost
provide the basis for several metrics. For example, they are the foundation for the
computation of variances related to effort, schedule, and cost metrics and the basis for
earned value management.
Common Estimating Tools and Techniques
The project manager has several tools or techniques available for estimating activity
duration, project costs, and preparing the project plan.
Analogous estimating, also known as top-down estimating, relies on previous or

similar projects to establish a broad or high level estimate. This type of estimate relies
on expert judgment, lessons learned, and usually requires adjustments throughout the
project.
Parametric estimating utilizes mathematical models such as the cost per square foot
to build a house or commercial building.

Bottom-up estimating requires a detailed work breakdown structure, more time and
possibly additional experience resources, but will produce a more definitive and more
accurate estimate.
There are also several tools available for use by the project manager and team to
provide the required estimates. These include project management software,
commercial data bases, and internal organization check sheets and estimating models.
An important factor to remember is that estimation tools, like other niche tools, are
usually not designed to be metrics tools. Any measurement or metrics type
information obtained from an estimation tool is a by-product, or an extra feature.
Over time, estimation tools are acquiring more and more utilitarian functions, some
of which will support additional capabilities to produce measurement or metrics data
or information. This is based on demands from the user community most specifically,
the members of that community willing to pay for such capabilities. Some tools use
the user's actual project results to adjust the estimating tool's database parameters to
provide for a more accurate estimate with the next project. Periodically the
maintenance users receive updates that reflect input from users' communities, so the
tool continues to improve the accuracy in each new version.
Any estimating tools will have to be adjusted over time to accommodate new
information and material cost (construction) if the integrity of the database is to be
kept maintained. With software estimating tools, the development platform and the
environment both have to be considered. On software development projects where
much interaction is necessary with groups of people in various departments, another
consideration is how well the interaction with these people is. If these departments
are resistant to the project, then the estimate could take considerably longer than with
departments where there is great cooperation.
Estimation Concerns
There are a number of factors that should be considered during the estimating
process. Every project is different regardless of how similar it may seem to other
projects that have been performed in the past. Remembering this simple fact can
make a big difference in the quality and accuracy of estimates. Other items to
consider include:

misinterpretation of the statement of work or scope statement, omissions to the scope,
an overly optimistic schedule, incorrect skill levels applied to project activities, a
failure to account for risks, failure to account for cost escalations such as contractual
labor rate increases, inflation, and the effects of market demand. It is also extremely
important to ensure that project requirements for quality in connection with features,
functions, operability, safety, and fitness for use have been considered.
Estimate the labor cost
Once requirements are identified, review the task-based estimate of the project to
determine the total hours of effort required. Apply the resource cost rates to derive a
total labor budget amount. Besides labor costs, be sure to include travel expenses,
living accommodations for team members, and expenses resulting from team
meetings and facilitated sessions. Consider variable and fixed costs when estimating
labor costs. The total labor amount for each task is calculated by multiplying the
labor rate by the total assigned hours for each task. Note that some items are
considered support costs and relate to costs associated with legal, marketing, pre-
sales, etc. Each organization will tend to have methods to categorize them. Just be
careful not to omit or double anything and remember "garbage in provides garbage
out." To prevent this from occurring, it's important to utilize the functional managers,
or the people who will actually do the work to provide the estimates. There is always
some room to negotiate, so make sure you keep your team involved. This will help to
obtain and maintain team buy-in to the final plan.
3. What are the activities and approaches of monitoring a project

and controlling the project?
ANS. Project management is the discipline[1] of planning, organizing and
managing resources to bring about the successful completion of specific project goals
and objectives. A project is a finite endeavor (having specific start and completion
dates) undertaken to create a unique product or service which brings about beneficial
change or added value. This finite characteristic of projects stands in contrast to

processes[2], or operations, which are permanent or semi-permanent functional work
to repetitively produce the same product or service. In practice, the management of
these two systems is often found to be quite different, and as such requires the
development of distinct technical skills and the adoption of separate management.
The primary challenge of project management is to achieve all of the project goals[3]
and objectives while honoring the project constraints.[4] Typical constraints are
scope, time and budget.[5] The secondary—and more ambitious—challenge is to
optimize the allocation and integration of inputs necessary to meet pre-defined
objectives.
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 Process Group Processes.

Monitoring and Controlling includes:
• Measuring the ongoing project activities (where we are);
• Monitoring the project variables (cost, effort, ...) against the project
management plan and the project performance baseline (where we should be);
• Identify corrective actions to properly address issues and risks (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 Controlling 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.
Project Maintenance is an ongoing process, and it includes:
• Continuing support of end users
• Correction of errors
• Updates of the software over time
Monitoring and Controlling cycle

In this stage, auditors should pay attention to how effectively and quickly user
problems are resolved.
Over the course of any construction project, the work scope changes. Change is a
normal and expected part of the construction process. Changes can be the result of
necessary design modifications, differing site conditions, material availability,
contractor-requested changes, value engineering and impacts from third parties, to
name a few. Beyond executing the change in the field, the change normally needs to
be documented to show what was actually constructed. This is referred to as Change
Management. Hence, the owner usually requires a final record to show all changes or,
more specifically, any change that modifies the tangible portions of the finished work.
The record is made on the contract documents – usually, but not necessarily limited
to, the design drawings. The end product of this effort is what the industry terms as-
built drawings, or more simply, “asbuilts.” The requirement for providing them is a
norm in construction contracts.

When changes are introduced to the project the viability of the project has to be
assessed again. It is important not to lose sight of the initial goals and targets of the
projects. When the changes accumulate, the forecasted end result may not justify the
proposed investment.

4. Explain in detail the organizational evolutionary and
revolutionary changes.
ANS. Change is both and natural and necessary for the healthy development of
any organization. Management is constantly faced with decisions that will alter the
direction of the organization. The types of change that management can allow fall
into two categories: evolutionary and revolutionary.
Evolutionary change happens gradually over time. Management allows many small
changes to take effect rather than relying on sudden or drastic changes. One example
of evolutionary change is total quality management (TQM). The goal of TQM is to
constantly monitor all business functions in an effort to improve quality whenever
possible. The hallmark of TQM is consistent, incremental change that results in
quality improvements. Over time, evolutionary change leads to fundamental shifts in
the organization’s culture (George & Jones, 2008).
Revolutionary change is a sudden alteration of an organization’s culture or

environment. Often revolutionary change is hard on an organization since individuals
do not have an opportunity to grow into the changes. Revolutionary change may
come about in response to rapidly decreasing performance or at the behest of
managers looking to adopt the latest management fads. Although the impact of this
kind of change can be jarring for established employees, revolutionary change is not
necessarily a sign of faulty management. For example, a company with shrinking
profits might find that its structure has become top heavy and relies on too many
levels of management. Flattening the organization will result in layoffs in middle
management but serve to reignite the passion of employees who are now closer to the
decision making process (George & Jones, 2008).
Management fads represent a special kind of revolutionary change that has no
guarantee of success.
As Annie Paul (2004) illustrates, management fads often have little to no
basis in scientific research. These fads are often championed by a popular
spokesperson and gain momentum as insecure leaders fear they and their
organizations are being left behind (Paul, 2004). The danger in these fads is without
scientific evidence there is no guarantee of success, but there is a definite cost on
terms of expenditure and human resources. As middle management scrambles to
implement the management fad of the month, employees are distracted from their
normal work flows and performance suffers.

5. Write a detailed note on Review templates and post review
activities.
ANS.
Review Templates
Each IT Project Management Review meeting starts with an introduction of the face-
to-face and meet-me call participants and an opportunity for general comments. The
remainder of the Review meeting focuses on six categories of information. Each
category is associated with a standard set of project management reporting
requirements as follows:
Category First Time Review Ongoing Review
(FTR) (OGR)
General Overview FTR slides 3-6 Used only when
changes occur
Status of Action Items from Prior Not applicable OGR slide 3
Review
Project Status FTR slides 7-15 OGR slides 4-9
Product Status FTR slides 16-24 OGR slides 10-13
Issues and Risks FTR slides 25-26 OGR slide 14
Project Unique Information FTR slides 27-29 OGR slides 15-17
Three sets of electronic templates are available to assist project staff in the
preparation of the IT Project Management Review briefings: First-Time Reviews,
Ongoing Reviews, and Samples. The Samples templates include slides from actual
DOE projects and references for completing the First Time and Ongoing review
slides. The Samples slides will continue to be updated with examples from
subsequent IT Project Management Quarterly Reviews.
The briefing templates were developed in Microsoft PowerPoint and can be retrieved
from the Departmental Software Quality and Systems Engineering (SQSE) Web site:
http://cio.doe.gov/ITReform/sqse/template.htm In the ANotes Page@ view of the
PowerPoint slides, additional information is provided on the frequency, purpose,
sources of information, and process to follow in collecting data and producing the
slides.
The templates serve as a means of standardizing the reporting requirements and
enabling a common set of criteria for evaluating the health and progress of the

Department=s corporate and major information systems. Presenters may choose to
develop their own set of slides as long as the requested information is covered.
1.1 General Overview
This category sets the stage for the remainder of the information provided during the
Review. Four slides are included in this set. For the First Time Review, all four slides
should be covered. In subsequent reviews, the slides should be included only if any of
the information has changed. Slide 6 may need to be provided the first quarter of each
fiscal year since it documents the Objectives by Year and is required in Ongoing
Reviews if information has changed.
1.2 Status of Action Items from Prior Review
This slide provides accountability and closure for issues or action items that were
raised during the prior review. Issues and action items are listed in the Review report
that are distributed after the Review by the OCIO staff. The project manager is
expected to check this list in preparation for the current review, include all listed
items on the slide, and provide the status of each item. Issues and action items that
are closed during the period from the prior review to the current review should be
reported in addition to any items that remain open.
1.3 Project Status
The project status category focuses on the management approach (e.g., schedule, cost,
decision points, ROI funding status) used for the project.
Information presented in this category should cover:
• The project plan including a logically laid out schedule with dates
for significant items and decision points over the current fiscal year
as well as the out-years.
• What has occurred during the last quarter

• What was accomplished including any changes from previously
identified project deliverables (the baseline)
• Accelerated or slipped dates
• Any significant newly identified/requested user requirements and

their impacts on schedule, costs, etc.
• Dates planned to achieve the project objectives.
1.3.1 Project Schedule/Decision Points
The project plan and project schedule should demonstrate the inclusion of plans to
address known or likely obstacles, and identified points where decisions or
involvement by the CIO or the project manager=s management is necessary. It should
include expected achievement dates for the item/activity performance metrics (overall
project performance metrics), requirements, and review times.
Critical decisions are defined in DOE O 413.3, Program and Project Management
for the Acquisition of Capital Assets, as formal determinations or decisions at specific
points in a project stage that allow the project to proceed to the next stage and
commit resources. Include key decision points such as when the project exits one
stage and enters another, the contractor(s) comes aboard, date that changes will be
frozen for a particular phase of installation, when deployment and/or conversion to
the new system are to occur, and date that the new system becomes the system of
record.
An updated project plan with a work breakdown structure should be maintained

that contains the details for the next 12-18 months, and less detail for the out-years.
The out-year breakdown should contain the key/major items and decision points, as a
minimum. Provide the detailed work breakdown structure (WBS) as background
material for each review to handout as part of the presentation and to be posted on the
IT Project Management Review information repository.
1.3.2 Development Funding Status

If any portion of the project moves into production while modules are still under
development, the slide should also include funding status for the maintenance costs.
1.3.3 Estimated FTEs and Total Cost
The Statement of Federal Financial Accounting Standards, Number 10, Accounting

for Internal Use Software, effective October 1, 2000, requires all Federal agencies to
capitalize software acquired or developed for internal use if the software=s expected
service life is two or more years and its cost meets or exceeds the agency=s threshold
for internal use software. DOE=s threshold is currently set at $750,000.
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. The DOE CFO has developed a Web site data
collection system for tracking and documenting costs. The Software Project Tracking
System is available at https://crinfo.doe.gov/swprojects. The system is intended for
recording Federal employee time spent on individual projects. The program/project
manager is responsible for ensuring that capitalization costs are captured for the
project. Capitalization should be projected in the business case and then captured and
tracked for each year of the project thereafter. For more information contact the DOE
CFO=s office.
1.3.4 Maintenance Funding Status
This slide is used to identify the maintenance costs and funding sources for the
project. The intent of the slide is to help in forecasting, planning and justifying
expenditures for maintenance of new systems. Maintenance funding needs to be
documented and issues or concerns raised as quickly as possible. Display projected
maintenance costs beyond development completion. Record the project maintenance
funding by source for the next seven years of the project.
1.3.5 ROI Refresh
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 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
see 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 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:

• Decommissioning of mainframe computers
• Reduction/redirection of labor
• Elimination of redundant systems
• Ability to more cost effectively upgrade all sites with one standard upgrade
package
In each case above, identify the specific site, systems, and labor 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 a tool for responding to any
future IG or GAO audit inquiries on project ROI.
For the IT Project Management Review, it is recommended that the project leader
replace the text on the ROI slide template on slide 15 of the First Time Review or
slide 9 of the Ongoing Review with: (1) a note stating which stage of its lifecycle 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 lifecycle that adds a new site or
undertakes an enhancement or technology refresh that reaches the cost threshold
established by the Statement of Federal Financial Accounting Standards (SFFAS)
Number 10: Accounting for Internal Use Software will need to satisfy capitalization
requirements. It requires all Federal agencies to capitalize software acquired or
developed for internal use if the software's expected service life is two or more years
and its cost meets or exceeds the agency's threshold for internal use software. DOE's
threshold is currently set at $750,000. 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. DOE
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.

1.4 Product Status
The product status section focuses on the technical approach, e.g., system
architecture, project methodology and processes, product quality, and risks and
issues. Product measurements are used in quality assurance processes to project and
measure product quality. These include defect reporting, testing status, and customer
satisfaction measurements.
1.4.1 Performance Measures
Performance measurements are used in project management and quality processes to

determine and communicate status and accomplishments measured against specific
objectives, schedules, and milestones. These measurements extend to include delivery
of desired products and services to customers, whether external or internal. The
following definition of performance measures is from the Performance-Based Special
Interest Group at http://www.orau.gov/pbm Performance-Based Management
Handbook, Volume 2, Establishing an Integrated Performance Measurement System,
developed for DOE.
APerformance Measurement is the ongoing monitoring and reporting of program

accomplishments, particularly progress towards pre-established goals. It is typically
conducted by program or agency management. Performance measures may address
the type or level of program activities conducted (process), the direct products and
services delivered by a program (outputs), and or the results of those products and
services (outcomes). A Aprogram@ may be any activity, project, function, or policy
that has an identifiable purpose or set of objectives.@ OMB Circular A-130 indicates
that, as part of an agency=s Capital Planning and Investment Process, it must institute
performance measures and management processes that monitor actual performance to
expected results. Measurements can be reported at the program and project level and
include resource and cost goals, schedule and progress goals, trade-offs and risk
outcomes, product quality goals, and customer satisfaction goals.
Basic categories of performance measurements include: Measures of efforts. Efforts

are the amount of financial and non-financial resources (in terms of money, material,
etc.) that are put into a program or process.

Measures of accomplishments. Accomplishment measures report what was provided
and achieved with the resources used. There are two types of measures of
accomplishments - outputs and outcomes. Outputs measure the quantity of services
provided; outcomes measure the results of providing those outputs.
Measures that relate efforts to accomplishments. Efficiency measures that relate

efforts to outputs of products or services. These indicators measure the resources used
or cost (for example, in dollars, employee-hours, or equipment used) per unit of
output. They provide information about the production of an output at a given level of
resource use and demonstrate an entity=s relative efficiency when compared with
previous results, internally established goals and objectives, generally accepted norms
or standards, or results achieved by similar entities.
More information on OMB Guidance on Performance Measures can be found at the

OMB Web site at http://wwww.whitehouse.gov/omb.
1.5 Issues and Risks
Any Congressional, OMB, GAO, IG, or other external interests or issues should be
covered by the project manager. Issues are expected to be resolved during project
team meetings or stage exits. Significant issues whether resolved or not should be
documented and discussed at the IT Project Management Review for lessons-learned
purposes so that (1) the same difficulties are not repeated during subsequent
enhancements or upgrades nor by other corporate or major systems, and (2) solutions
are shared throughout the Department. Any project unique items that the program or
project manager feel should be brought to the attention of management or senior
management, e.g., the CIO. The issues or concerns that need to be addressed by the
CIO, as well as the status of other project issues or risks.
1.5.1 Concerns/Issues Requiring OCIO Attention
This slide is used to present the issues or concerns that need to be addressed by
management or senior management, e.g., the CIO. Bring to the awareness of the
OCIO those concerns or issues either about the project or the proposed IT solution
that may be resolved by support from the OCIO. This information is typically
identified and raised by the project manager (system owner). It differs from the issues

that may be raised by the OCIO and documented in Slide 3 - Status of Action Items
from Prior Reviews.
1.5.2 Risks/Issues
This slide is used to identify project risks and issues that do not require OCIO support
at the present time, but still may impact the outcome of the project as mandated by
OMB Circular A-130.
1.6 Project Unique Information
This slide (or set of slides) is used to provide any project information that the
program manager or project manager would like to present to management or senior
management, e.g., the CIO.
Create presentation slides to highlight any additional project information to include in

the IT Project Management Review. Also include Next steps.
1.7 Overview of Project Status (last)
This is the last slide in the set. Its purpose is to communicate a visually-oriented
"thumbnail" view of the project's status. The status will be reported as either Green,
Yellow, or Red, using the criteria documented below. Refer to the notes section of the
slide template for detailed guidance on completing other sections of the slide.
The data presented on this slide should be a cumulative representation of the project
status communicated in the slide set and the presentation (if one was conducted).
Based on all the slides presented, all parties present at the review should reach
consensus that this slide fairly represents the status of the project, as it will be used
for (upper) management reporting purposes.
2.0 Post-Review Activities
Once the IT Project Management Review has been conducted, the OCIO will follow
up with program/project managers on any issues or concerns requiring OCIO
attention, the status of open items from the review, and CIO reporting actions, e.g.,
reports to the Secretary and Congress and to the CIO Council. The CIO may also
recommend quality assurance analysis be conducted.

2.1 Issues or Concerns Requiring OCIO Attention
The program/project manager is responsible for raising issues or concerns that require
OCIO assistance or guidance to the attention of the CIO. These items should be
communicated whenever they become known, and not held to the next IT Project
Management Review. The CIO will assign appropriate OCIO staff are 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.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 OCIO staff 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.
2.3 CIO Reports
The OCIO staff supporting the CIO Quarterly Reviews will prepare a summary report
after each IT Project Management Review. The Summary report will include the
following information:
• Summary Status
• Open Issues/Items
• Status Performance Objectives/Measures
• 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 Secretary, Congress and the CIO Council.
6. Write a detailed note on the fundamentals of Application

software and support software.

ANS. Project management software is a term covering many types of software,
including scheduling, cost control and budget management, resource allocation,
collaboration software, communication, quality management and documentation or
administration systems, which are used to deal with the complexity of large projects.
Scheduling
One of the most common tasks is to schedule a series of events, and the complexity
of this task can vary considerably depending on how the tool is used. Some common
challenges include:
• Events which depend on one another in different ways or dependencies
• Scheduling people to work on, and resources required by, the various tasks
commonly termed resource scheduling
• Dealing with uncertainties in the estimates of the duration of each task
• Arranging tasks to meet various deadlines
• Juggling multiple projects simultaneously to meet a variety of requirements
Calculating critical path
In many complex schedules, there will be a critical path, or series of events that
depend on each other, and whose durations directly determine the length of the whole
project (see also critical chain). Some software applications (for example,
Dependency Structure Matrix solutions) can highlight these tasks, which are often a
good candidate for any optimization effort.
Providing information
Project planning software needs to provide a lot of information to various people, to

justify the time spent using it. Typical requirements might include:
• Tasks lists for people, and allocation schedules for resources
• Overview information on how long tasks will take to complete
• Early warning of any risks to the project

• Information on workload, for planning holidays
• Evidence
• Historical information on how projects have progressed, and in particular, how

actual and planned performance are related
• Optimum utilization of available resource
Approaches to project management software
Desktop
Project management software can be implemented as a program that runs on the

desktop of each user. This typically gives the most responsive and graphically-intense
style of interface.
Desktop applications typically store their data in a file, although some have the
ability to collaborate with other users (see below), or to store their data in a central
database. Even a file-based project plan can be shared between users if it's on a
networked drive and only one user accesses it at a time.
Desktop applications can be written to run in a heterogeneous environment of

multiple operating systems, although it's unusual.
Web-based
Project management software can be implemented as a Web application, accessed

through an intranet or extranet using a web browser.
This has all the usual advantages and disadvantages of web applications:
• Can be accessed from any type of computer without installing software
• Ease of access-control
• Naturally multi-user

• Only one software version and installation to maintain
• Typically slower to respond than desktop applications
• Project information not available when the user (or server) is offline.
• Some packages do allow the user to "go-offline"
Personal
A personal project management application is one used at home, typically to manage

lifestyle or home projects. There is considerable overlap with single user systems,
although personal project management software typically involves simpler interfaces.
See also non-specialised tools below.
Single user
A single-user system is programmed with the assumption that only one person will
ever need to edit the project plan at once. This may be used in small companies, or
ones where only a few people are involved in top-down project planning. Desktop
applications generally fall into this category.
Collaborative
A collaborative system is designed to support multiple users modifying different

sections of the plan at once, for example, updating the areas they personally are
responsible for such that those estimates get integrated into the overall plan. Web-
based tools, including extranets, generally fall into this category, but have the
limitation that they can only be used when the user has live Internet access. To
address this limitation, client-server-based software tools exist that provide a Rich
Client that runs on users' desktop computer and replicate project and task information
to other project team members through a central server when users connect
periodically to the network and other tasks. Some tools allow team members to check
out their schedules (and others' as read only) to work on them while not on the
network. When reconnecting to the database, any changes are synchronized with the
other schedules.
Integrated

An integrated system combines project management or project planning, with many
other aspects of company life. For example, projects can have bug tracking issues
assigned to each project, the list of project customers becomes a customer
relationship management module, and each person on the project plan has their own
task lists, calendars, and messaging functionality associated with their projects.
Similarly, specialised tools like SourceForge integrate project management software
with source control (CVS) software and bug-tracking software, so that each piece of
information can be integrated into the same system.
SUPPORT SOFTWARE:-
ARROW overview
Why did ARROW want a repository?
The ARROW project was envisaged in a time when institutional repositories and the
software required for them were still in their infancy. In 2003 ePrints
(www.eprints.org/) was essentially the only player in the field, although DSpace
(www.dspace.org/) had also made its first appearance. Nevertheless, the ARROW
partners recognised that there were a number of compelling reasons to look at the
repository space, and to start working on options beyond the print equivalences that
ePrints were concentrating on. These reasons included:
• the ability to provide a platform for promoting research output in the ARROW
context;
• a way of safeguarding digital information;
• a “place” to gather an institution's research output into one place;
• provision for consistent ways of finding similar objects;
• a method to allow information to be preserved over the long term;
• a method to allow information from many repositories to be gathered and

searched in one step;
• enabling resources to be shared, while respecting access constraints; and

• ways of enabling effective communication and collaboration between
researchers.
A project proposal (http://arrow.edu.au/docs/files/ARROW%20project.pdf) was

written and submitted to the Australian Commonwealth Department of Education,
Science and Training (DEST) (www.dest.gov.au/), under the Systemic Infrastructure
Initiative
(www.dest.gov.au/sectors/research_sector/programmes_funding/general_funding/rese
arch_infrastructure/systemic_infrastructure_initiative.htm) Framework for Australian
Higher Education funding scheme. This was approved in 2003, with the funding
covering three years until December 31, 2006.
The initial goal of the project is best expressed in this quote from the original
proposal:
The ARROW project will identify and test software or solutions to support best
practice institutional digital repositories comprising e-prints, digital theses and
electronic publishing. The project has met, and exceeded this basic goal, by
producing not only a test version of the software, but a working repository solution
that is currently in use at a number of Australian universities, with more to come
online shortly.
Who is ARROW?
The ARROW project has been managed by a consortium of Australian institutions:

Monash University (lead institution), the National Library of Australia, the University
of New South Wales and Swinburne University of Technology. The project currently
employs the equivalent of three full time staff to manage the project on a day-to-day
basis. The project partners also provide staff time and other in kind services to
increase the number of staff available to work on development. These latter staff,
however, are primarily responsible for the management of the repository installed at
their own site.
Since the beginning of 2006, several other Australian universities have also signed up
to use the ARROW solution for institutional repositories. These ARROW members
are also working on development projects to develop and enhance the software.

What did the ARROW project set out to achieve?
The ARROW project had a number of specific goals that it wished to achieve. The
key one was the need for a solution for storing any digital research output, regardless
of format in which it was created. For the sake of simplicity, and as a way to deal
with familiar and accessible materials, the initial focus was on digital objects with
print equivalents, specifically theses and journal articles. As the solutions for these
areas have become clearer the project has been looking at a range of other objects.
These include datasets, specifically those produced as a part of research and which
might usefully be attached to the published research, as well as learning objects that
might need to be organised and made available from a repository.
From the beginning of the project there was a recognition that ARROW needed to be
able to deal with more than just open access materials, and that some things stored in
repositories need to be restricted for a variety of important reasons, such as copyright,
confidentiality or ethical considerations, or because it is work in progress. Therefore
the project had done considerable work on the access and authentication issues
related to research outputs in digital repositories, often in partnership with the MAMS
project (www.melcoe.mq.edu.au/projects/MAMS/). This work is ongoing at time of
writing.
The Australian Government has had a system of reporting research for the purpose of
tracking the output of universities. At the time the project was conceived, this took
the form of reporting eligible research publications. This included the retention of
copies at the reporting institution for the purposes of audit. It was envisaged that a
repository could be used to help manage this process and to retain the audit copies.
Since then there has been a change in direction to a proposed Research Quality
Framework (RQF) system
(www.dest.gov.au/sectors/research_sector/policies_issues_reviews/key_issues/researc
h_quality_framework/default.htm), which will involve the review of research outputs
by experts from outside Australia. DEST have identified that repositories offer the
potential for widespread access to these outputs in a less labour intensive fashion, and
ARROW has been working with them on how this might be achieved.

A key requirement of the project was to employ open standards to make sure the data
stored in the repository would be transferable in the future. In conjunction with this it
was determined that the project would develop and deliver open source tools back to
the Fedora Community. This was also a requirement of the program under which
ARROW was funded.
Of critical importance was the development of an overall solution that could offer on-
going technical support and development past the end of the funding period. DEST
and the developers of the project were concerned that in many cases projects are not
sustainable unless centrally funded, and that this would not be appropriate in this
area. The project needed to find a solution that would mean the repository created
would have a viable strategy for ongoing sustainability.
The end result of these decisions is a software solution combining open source and
proprietary software, made up of open source repository software called Fedora with
a proprietary services layer called VITAL, which has been developed by VTLS Inc.
This is not a centralised or hosting solution – each ARROW partner or member has
their own hardware and software. As each ARROW partner or member is licensing
the VITAL software from a commercial provider, they will receive the following
benefits after the project ends (assuming they continue to pay the annual license fee):
• installation support;
• helpdesk and customer service;
• new features included in successive versions of the software.
Building ARROW
ARROW requirements
ARROW wanted:
• a robust, well architected underlying platform;
• a flexible object-oriented data model;
• to be able to have persistent identifiers down to the level of individual

datastreams, accommodating its compound content model;
• to be able to version both content and disseminators (think of software
behaviours for content);
• clean and open exposure of APIs with well-documented SOAP/REST web

services.
Fedora
After a careful analysis of the candidates available at the time[1], it was felt that only
Fedora provided the right combination of attributes. Fedora™ can best be thought of
as services-mediation infrastructure, rather than an off-the-shelf application. It can
use web services technology (www.w3.org/2002/ws/) to draw on services provided
by other systems as well as expose its own functionality using web services
standards. Key to the Fedora™ architecture is its underlying object-based model.
Fedora™ stores digital content objects, either as datastreams contained within the
repository or as links to external resources. It also stores what Fedora™ calls
disseminators. These are stored programs which provide ways to render these digital
content objects. As an example, a Fedora™ repository might contain an image
disseminator which can take a stored image object and render it on the fly into a
thumbnail, a medium-resolution version or a high-resolution version as required. The
software maintains bindings between content objects and their disseminators. Each
object has a default disseminator (which might just provide the sequence of bits that
comprise the object plus a Multi-purpose Internet Mail Extensions (MIME) type
(www.ietf.org/rfc/rfc2045.txt), much like a web server). Alternatively, the repository
might provide alternative disseminators which will allow the object to be exposed in
other ways. An example of this might be a disseminator which exposes the internal
structure of an Encoded Archival Description (EAD) (www.loc.gov/ead/) as a
navigation mechanism. This architecture, which combines objects and disseminators,
is very flexible, and provides significant advantages as a platform on which to build
other applications (Lagoze et al., 2005) For more background on the reasons for
selecting Fedora for the ARROW project, see Treloar (2005).
Since the beginning of the project ARROW has worked actively and closely with
Fedora™ and the Fedora Community. The ARROW Project Technical Architect is a
member of the Fedora Advisory Board, which provides long term guidance for the

project. This commitment to Fedora is reinforced by VTLS Inc. The VTLS President
is a member of the Fedora Advisory Board, and the VITAL Lead Developer is part of
the Fedora Development Group.
Open source
As indicated above, the project is creating open source components that interoperate
with Fedora as part of its output. Some of these have already appeared:
• SRU/SRW;
• HANDLES;
• JHOVE Metadata extraction;
• exposure to web indexing crawlers;
• VALET for web self-submission.
Others are scheduled to appear in 2006:
• LDAP authentication;
• administrative reporting;
• bulk citation export;
• statistics for public users;
• metadata synchronisation.
Developing with VTLS
ARROW decided that they needed to partner with a developer who could not only
produce the software but could also provide ongoing user support and development
after December 31, 2006. VTLS were identified by the project team as a suitable
partner in the process, and they were interested in working in this area as well. They
had already begun work on a repository solution using Fedora, they were familiar
with the library sector because of their many years experience in developing an

integrated library management system (VIRTUA) and they were willing to produce a
combination of a proprietary solution, Fedora and other open source software.
This decision has resulted in VITAL, which is ARROW specified software created
and fully supported by VTLS, and built on top of Fedora. This software (as of the
date of writing) includes a number of components:
• VITAL Manager – a Windows-based management tool, that allows for ingest,

management, editing and deletion of objects in the repository.
• VITAL Portal – web-based tool for indexing and managing the repository.
• VITAL Access Portal – web-based searching front end for the repository.
• VALET – web-based self-submission tool.
• Batch loader tool – tool for ingesting multiple similar objects into the
repository in bulk.
• Handles server – uses the CNRI technology[2] to create persistent identifiers

into the repository.
• Google indexing and exposure – to allow indexing of objects in the repository.
• SRU/SRW support – to allow for other searching and harvesting of the

repository.
The interrelationships of these components can be seen in Figure 1.
Implementation decisions
During the start-up phase of the project, it was necessary to make a number of
decisions about how to construct the ARROW solution. The requirement for many of
these implementation decisions was inherent in the repository solution that was
chosen. The F in Fedora stands for Flexible. Fedora provides few constraints, but this
requires deliberate decisions.
Atomistic or compound objects

The sort of process the ARROW went through in making this decision can be
illustrated by the diagram taken from a whiteboard shown in Figure 2.
Fedora objects (broadly speaking) can either be modelled as atomistic, or compound.

Atomistic objects consist of an identifier, some metadata and (usually) one
datastream. Compound objects consist of an identifier, some metadata, and multiple
datastreams of different types. Thus a doctoral thesis as submitted for examination
might consist of the bound text of the thesis, and an accompanying video. This could
be modelled atomistically as a series of Fedora objects: the abstract as plain text, a
PDF of the entire thesis, the XML of the entire thesis, an AVI of the video, and an
MOV of the movie. It could also be modelled in a compound way as a single Fedora
object which consists of each of the above elements as datastreams within the object.
ARROW elected to choose compound objects, basing its decision around the majority
use-cases:
• journal articles;
• conference papers;
• working papers;
• books;
• book chapters;
• theses.
It is anticipated that newer forms of research will lead to more content models and
variations.
Descriptive metadata
Early in the project ARROW spent some months examining the idea that a single
descriptive metadata schema for all the objects in the ARROW repositories would be
a sensible goal. After looking at the strengths and weaknesses of numerous metadata
schemas, and on considering the diversity of object types ARROW repositories could
be required to store, it was decided that it was more realistic to accept that the project
would need to support multiple descriptive metadata schemas. As a result, ARROW
has decided to support the metadata generated by communities of practice to
accompany their digital objects. This implies that an ARROW repository will contain
a range of different metadata schemas attached to different objects. The VITAL
software currently transforms MARCXML and ETD-MS metadata into Dublin Core
for OAI-PMH and internal purposes. In the longer term, and to support other
schemas, ARROW is investigating the possibility of using OCLC's interoperable
metadata core (Godby et al., 2003). It is also possible that ARROW may need to
write something itself.
Persistent identifiers
After careful consideration of all the available alternatives, ARROW decided to use
handles for all the partner university sites. The NLA decided to proceed using its
existing persistent identifier scheme. The Handles System (www.handle.net/),
developed by CNRI (http://cnri.reston.va.us/), is a comprehensive system for
assigning, managing, and resolving persistent identifiers, known as handles, for
digital objects and other resources on the internet. Handles can be used as Uniform
Resource Names (URNs). Part of the work done by VTLS and released as Open
Source has been the addition of handles integration to the Fedora software.
The ARROW repositories were designed from the beginning to be as flexible as

possible. To this end, the project decided it would be good practice to be able to
persistently cite both objects and components of objects. The ARROW software
therefore assigns handles to each entire ARROW object (such as a thesis), and to each
component of an ARROW object (such as the metadata, the thesis abstract, the thesis
body, and the reference list). This means that repository managers can disaggregate
and re-aggregate objects as required in the future without the user being aware of it. It
also means that the minimum persistently citeable unit can be made as granular as is
required.
External searching and harvesting
One of the project's aims was to develop a discovery service for Australian
institutional repositories. This service, which is called the ARROW National
Research Discovery Service (http://search.arrow.edu.au/) has been one of the key

work areas undertaken by the National Library. It provides a national resource
discovery service including:
• provision of an appropriate search interface, including simple search, advanced

search, and browse options;
• contributing metadata and gateways to other networks, such as OAIster, Yahoo,

Google;
• ensuring appropriate local institutional and national “branding” of the service,

which occurs throughout the ADS interface and the exchanged metadata;
• providing appropriate subject-based access, based on the Australian Standard

Research Classification list.
This service harvests metadata using OAI-PMH from a number of different

institutional research repositories at Australian universities. These repositories use a
range of software (e-prints.org software, DSpace and Fedora) but all expose their
metadata for harvesting. This service is now live and available either through a link
from the ARROW website or directly at http://search.arrow.edu.au/. This service
allows for searching research outputs across the Australian university sector.
What has the project learnt so far?
A number of valuable lessons have been learnt during the course of the project, even
beyond solving the many technical challenges. For instance, working with multiple
partners has been very beneficial for the sharing of information and experiences, the
sharing of development work and the multiple perspectives on issues of note. The
multiple perspectives on issues, however, have also led to scope creep and difficulty
in managing expectations across the group. This has put pressure on the project
management team who have acted as intermediaries between the project and the
developers. Software development feels slow, both commercial and open source, but
this is more a function of being trapped in the middle of it than any failings by the
developers or partners. Development with a commercial partner can be tricky as well,
as the priorities and needs of commercial and educational partners can occasionally
conflict. The nature of standards in this area remain an ongoing problem, as the
standards that are in place leave a fair amount of leeway, which has forced the project

to spend large amounts of time discussing and trying to refine them for actual use.
The debate over open versus closed repositories, or information management versus
accessibility is an ongoing issue, with much work to be done. The key finding is that
there is no single rule that will work for all digital objects, and that flexibility will be
needed into the future to make repositories effective in all circumstances.
Repositories are only partly about software – advocacy, policy, institutional

engagement and grunt work need equal attention. Even with compulsory deposit
policies, there continues to be a great deal of work to be done to fill the repository
and encourage academics to submit their work. It is clear that no amount of
discussion about repositories will fill them – the relevant data needs to be found.
Copyright continues to be am major area of difficulty. Even beyond the commonly
discussed issues such as publisher versus author versions, attempts to enter material
in areas such as performing arts will present a number of new challenges. For
instance, a video of a dance work may have musical, choreography and personal
intellectual property involved, any of which may prevent it being added to a
repository.
PILIN – PERSISTENT IDENTIFIER AND LINKING INFRASTRUCTURE
As the FRODO and MERRI projects have matured, there is a growing realisation
that sustainable identifier infrastructure is required to deal with the vast amount of
digital assets being produced and stored within universities. This is a particular
challenge for e-Research communities where massive amounts of data are being
generated without any means of managing this data over any length of time.
The emphasis in the PILIN Project will be on building identifier management

infrastructure based on a technology (Handle) that is now under development through
the auspices of CNRI to underpin sustainable global identifier infrastructure.
PILIN aims to meet a specific need common to e-Research communities, the

proposed work to be undertaken will be transferable to other communities, such as
the VTE sector, the Le@rning Federation and the TILIS Project.
The project aims to take advantage of existing governance and consultative

mechanisms within the ARROW environment to ensure relevant and sustainable

outcomes and optimal return on investment. The project will be run in partnership
between ARROW and the University of Southern Queensland (USQ), specifically
through the RUBRIC Project.
Aims and Objectives
• Support adoption and use of persistent identifiers and shared persistent

identifier management services by the project stakeholders.
• Plan for a sustainable, shared identifier management infrastructure that enables

persistence of identifiers and associated services over archival lengths of time.
Project Outputs
1. Best practice and policy guides for the use of persistent identifiers in Australian
e-learning, e-research, and e-science communities.
2. Use cases describing community requirements for identifiers and business

process analysis relating to these use cases.
3. E-Framework representations of persistent identifier management services that

support the business requirements for identifiers.
4. A “pilot” shared persistent identifier management infrastructure usable by the

project stakeholders over the lifetime of the project. The pilot infrastructure
will include services for creating, accessing and managing persistent digital
identifiers over their lifetime. The pilot infrastructure will interoperate with
other DEST funded systemic infrastructure. The development phase of the pilot
will use an agile development methodology that will allow the inclusion of
“value-added” services for managing resources using persistent identifiers to
be included in the development program if resources permit.
5. Software tools to help applications use the shared persistent identifier

infrastructure more easily.
6. Report on options and proposals for sustaining, supporting (including outreach)

and governing shared persistent identifier management infrastructure


SET-2 PROJECT MANEGEMENT - Doc New

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

SET-2 PROJECT MANEGEMENT - Doc New

Загружено:

Авторское право:

Доступные форматы

SET -2

1. Write brief note on need for project management , project

Need for project management

Project management is necessary because-

• A project requires huge investments which should not go waste

• Prevent failures in project

• Scope of the project activity may undergo a change

• Technology used may change during the course of project execution

• Consequences of negativity in project related problem could be very serious

• Change in economic condition may affect a project

Project management knowledge areas and relationship

it comprises of various techniques needed to manage project, the practical

Taha mohammed Page 1

The bottom up approach consists of the following –

Taha mohammed Page 2

• Top down approach:-

The top-down approach remains extremely popular in contemporary project

Taha mohammed Page 3

Taha mohammed Page 4

An estimate, as defined in the PMBOK® Guide, is an assessment of the likely

Estimates of the effort (labor hours) needed to do the project

Taha mohammed Page 5

Estimates of the labor costs of the project

Estimates of the material cost

It is important to note that estimating project work is a project management core

Common Estimating Tools and Techniques

Analogous estimating, also known as top-down estimating, relies on previous or

Taha mohammed Page 6

Taha mohammed Page 7

Estimate the labor cost

3. What are the activities and approaches of monitoring a project

Taha mohammed Page 8

Monitoring and Controlling

Monitoring and Controlling Process Group Processes.

Taha mohammed Page 9

Monitoring and Controlling cycle

Taha mohammed Page 10

Taha mohammed Page 11

Revolutionary change is a sudden alteration of an organization’s culture or

Taha mohammed Page 12

Taha mohammed Page 13

1.1 General Overview

1.2 Status of Action Items from Prior Review

1.3 Project Status

Information presented in this category should cover:

• What has occurred during the last quarter

Taha mohammed Page 14

• Accelerated or slipped dates

• Any significant newly identified/requested user requirements and

• Dates planned to achieve the project objectives.

1.3.1 Project Schedule/Decision Points

An updated project plan with a work breakdown structure should be maintained

1.3.2 Development Funding Status

Taha mohammed Page 15

1.3.3 Estimated FTEs and Total Cost

The Statement of Federal Financial Accounting Standards, Number 10, Accounting

1.3.4 Maintenance Funding Status

1.3.5 ROI Refresh

Return on Investment (ROI) is the calculated benefit that an organization is projected

Taha mohammed Page 16

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

Taha mohammed Page 17

• Elimination of redundant systems