AGPR

ACCOUNTANT GENERAL PAKISTAN REVENUES

ANA 1/1/21 Project Management

Contents
1.1 Brief history and introduction:......................................................................................4
1.2 Services of the AGPR:..................................................................................................5
1.3 Overview of administrative arrangements:...................................................................5
Located in the federal area (Islamabad)..........................................................................5
Located in each capital of all the provinces....................................................................5
Located in every district of Pakistan..............................................................................5
Other bodies....................................................................................................................5
1.4 Organizational hierarchy of AGPR:.........................................................................6
1.5 Departments and Their Functions.................................................................................7
1.5.1 Major Functions of Admin Section In AGPR.......................................................7
1.5.2 Major Functions of Pre-Audit Sections In AGPR.................................................7
1.5.3 Major Functions of Accounts Sections In AGPR:.................................................8
1.5.4 Major Functions of GP Fund and Pension Sections In AGPR:.............................8
1.5.5 Major function of HR Section in AGPR:..............................................................8
2. IT/MIS DEPARTMENT:...............................................................................................9
2.1 Stakeholders:.................................................................................................................9
SYSTEM DEVELOPMENT PROCESS..............................................................................10
3.1PRELIMINARY INVESTIGATION & PROBLEM ANALYSIS.............................10
3.1.1 Study of the existing system;...............................................................................10
3.1.2 Problem in the existing system:...........................................................................10
3.1.3 Solution and Its Scope:........................................................................................11
3.1.4 CHALLENGES:..................................................................................................12
3.2 CONSTRAINTS.........................................................................................................12
3.2.1Schedule constraints.............................................................................................12
3.2.2 Budget constraints...............................................................................................12
3.2.3 Technological constraints....................................................................................13
3.3 REQUIREMENT ANALYSIS PHASE:....................................................................13
3.3.1 Functional requirements......................................................................................13
3.3.2 Non-functional requirements...............................................................................13
3.4 TECHNIQUES USED FOR IDENTIFYING THESE REQUIREMENTS:..............14
3.5 FEASIBILITY STUDY:.............................................................................................14
3.5.1 Economic Feasibility:..........................................................................................15
3.5.2 Operational Feasibility.........................................................................................16
3.5.3 Technical Feasibility............................................................................................16
3.5.4 Schedule Feasibility:............................................................................................17
3.6 SYSTEM DESIGN PHASE:......................................................................................17
3.6.1 Data flow diagram (DFD):...................................................................................17
3.6.2 Computer input design:........................................................................................19
3.6.3 Computer output design:......................................................................................21
3.6.4 Entity-relationship (ER) modeling......................................................................22
3.6.5 Database design...................................................................................................23
3.6.6 Activity-Networking-Diagram:...........................................................................23
3.7 CONSTRUCTING & TESTING NEW SYSTEM.....................................................27
3.7.1 Data conversion:..................................................................................................28
3.7.2 Testing:................................................................................................................28
3.7.3 Front end and back end tools used:......................................................................29
3.7.4 Software packages used:......................................................................................29
 3.7.5 Hardware packages:.............................................................................................30
3.8 SYTEM IMPLEMENTATION PHASE:...................................................................30
3.8.1 Train end-users:...................................................................................................31
3.8.2 Convert to a new system:.....................................................................................32
3.8.3 Post-implementation review:...............................................................................33
3.9 MAINTENANCE AND SUPPORT PHASE:............................................................33
3.9.1 Maintenance Phase:.............................................................................................34
3.9.2 Support Phase:.....................................................................................................35
3.9.2 System enhancement:..........................................................................................35
Project termination/Closing:.................................................................................................36
References/sources used:......................................................................................................37
Bahria University, Islamabad
 INTRODUCTION TO AGPR:

1.1 Brief history and introduction:

AGPR (Accountant General Pakistan Revenues) was established under the Pakistan audit
and accounts order 1947 repealed the audit and accounts order 1943 of India to perform
accounting function for the Government of Pakistan. A BPS-21 officer of the accounts
group of Pakistan heads AGPR. Before the separation of audit and accounts function in
2001, accounting records were the responsibility of AGPR and was directly responsible to
Auditor General Pakistan. After separation of audit and accounts function in 2001 AGPR is
now responsible to Controller General of Accounts who laid down the financial statements
and accounting records (compiled by AGPR) to AGP for onward transmission to the
President of Pakistan.

The AGs are established in each province and federal govt. & each report to CGA. AGPR,
Islamabad is working for the federal govt. with the assistance of sub-offices in each of the
provincial & other designated areas. The objective of AGPR, Islamabad is to keep
accounting records of its transactions and perform a pre-audit (validation) functions on the
payments of all the spending divisions/ ministries working under its jurisdiction. It is an
attached department of the finance division. AGPR is in Islamabad for the federal govt.
with sub-offices in each of the provincial capitals and other designated areas. All AGPR
sub-offices (now referred to as Deputy Accountant General Pakistan Revenues), report
monthly accounting information, in respect of federal transactions to AGPR, Islamabad.
AGPR, Islamabad plays a very important role in keeping the accounting records of all
government organizations working under its jurisdiction and performs pre-audit
(validation) functions on the payments of these government organizations (Spending
Divisions, ministries, and departments).
1.2 Services of the AGPR:

AGPR, Islamabad is an accounting organization, of the Government of Pakistan. Basic

responsibilities of AGPR include:
 Keeping the accounting records of its transactions.
 Performing pre-audit (validation) function on payments submitted to it by spending
division/ ministries under its jurisdiction, within the budgetary provisions.
 Maintaining the record of the payroll of all the federal government employees.
AGPR, Islamabad recognizes the payments of spending divisions, Overall check and
balance of the federal transactions is the responsibility of AGPR, Islamabad with the
assistance of its subordinate officers. It also includes the HR section whose main
responsibility is to keep the record of all the employees whether serving or retired. This
section also provides the information on payment of loan and advances to the employees
and constant up-gradation is necessary for this section each month. Any change in the
budget of Pakistan will affect directly and all record is fully updated in July each year.
1.3 Overview of administrative arrangements:

As AGPR is not any business entity so WE can't describe its volume in respect of its sales
revenue. It’s a public sector organization and its administrative jurisdiction is spread throughout
the country in the following heads.
Located in the federal area (Islamabad)
 AGP (Auditor General of Pakistan)
 CGA (Controller General of Accounts)
Located in each capital of all the provinces
 AGs (Accountant Generals)
Located in every district of Pakistan
 DAOs (District Accounts Offices)
Other bodies
 MINISTRIES
 SELF ACCOUNTING ENTITIES
 SBP (STATE BANK OF PAKISTAN)
 FINANCE DIVISION/ DEPTT.
 All these entities work jointly to perform the accounting needs of the country within their
powers. AGPR just monitors their activities and allocate funds for their projects through
the state bank of Pakistan.

1.4 Organizational hierarchy of AGPR:

A.G.P.R

D.G.P.R

4 DDI.
Addl.
A.G
A.G
D.A.G A/C’S D.A.G F&P

D.A.G D.A.G (Comp)

(Sr) AO/AAG’S
AAG/AO
A.O/AAG
(PIFRA)
A/C’S Sections Fund/
HR FI section Pension
section Branches

AAG/AO’S of
D.D.O AO pre-audit
Admn-1

A DMN-II All Other

Branches.
1.5 Departments and Their Functions

AG (Accountant General) (BPS-21) is overall in-charge of all the activities of AGPR.

During his absence, DGPR (Deputy Accountant General) (BPS-20) look after his work.
But all the administrative powers are in the hands of the Additional Accountant General
(BPS-19) who also supervise the 4 Deputy Accountant Generals (DAG) (BPS-18) of each
department who are listed below.
1. D.A.G senior (supervise Admin and pre-audit sections)
2. D.A.G ACCOUNTS (supervise all the accounts sections)
3. D.A.G COMPUTER (supervise finance and human resource sections)
4. DAG FUND AND PENSION (supervise pension sections)

1.5.1 Major Functions of Admin Section In AGPR

Major functions of the admin section are
a) Recruitment, Selection
b) Posting/ Transfers
c) Career Planning
d) Compensation (Govt. Pay Scales)
e) Training (PIFRA)
f) File Maintenance

1.5.2 Major Functions of Pre-Audit Sections In AGPR

These sections prepare and pass bills/vouchers of all non-gazette and gazette employees
of different departments within the budget allocated to them. There is a total of 14 pre-
audit sections in AGPR. 6 of them deal with non-gazette employees and 8 deal with
gazette employees.
1.5.3 Major Functions of Accounts Sections In AGPR:
Accounts section deal all officers correspondence, gazette officers’ matters, such as their
appointments, transfer, issuance of last pay certificate, joining, relieving, monthly
payments of bills, contingency bills, etc.
1.5.4 Major Functions of GP Fund and Pension Sections In AGPR:
GPF(general provident fund) section prepare and maintain GPF record, GPF accounts,
slip, GPF advances, GPF payments and also advance payments, etc., GA (gazette
Pension section, prepare all pension cases death cases, pension final payments pension
books & prepare final payment documentation, etc.
1.5.5 Major function of HR Section in AGPR:

The major function of the HRM section of AGPR includes:

 The hiring of Federal Government employees
 Punching of form-1 called FO1 into the database (it contains all the initial information
of person hired I-e date of appointment, bank account number, basic paying scale,
address, etc.
 Punching of form-5 called FO5 into the database (it contains data regarding the loans
and advances granted to employees I-e motorcycle advance and HBA loan etc.
 Punching of form-2 called FO2 into the database (it contains the entries regarding up-
gradation or correction of the old record of employee I-e change of pay scale or bank
account etc.
 Punching of form 3 called FO3 into the database (it contains the entries regarding
payment and recoveries of federal government employees.
 Selection
2. IT/MIS DEPARTMENT:

The Management Information System MIS department of AGPR does not exist. It is
wholly maintained by Siemens Pvt ltd as the contract was given to Siemens Pvt Ltd until
2010.
As the system was developed by a private company named Siemens and funded by the
Auditor General Of Pakistan handed over to AGPR in 1993 and used up to 2003, but still in
operation in some sections but its record is constantly shifting to the new system promptly.
Currently, it is very rarely used.

All financial activities starting with planning, preparation, and execution of the budget,
accounting of all resultant transactions, evaluation and audit of accounts, and
ultimately financial reporting to serve as the basis for future planning and budgeting.
The financial management system is the embodiment of macroeconomic management
which affects all internal and external stakeholders. In turn, the macroeconomic
indicators such as rate of inflation, changes in current and capital account, rate of
growth, GNP, etc. are all based on this financial management system.

This system is now implemented throughout Pakistan. Therefore, all the record of
expenditure and receipts of the Government of Pakistan is now centralized. The online
backup of this record is taken daily by siemens and one offline backup is taken each
month. Keeping in view all the expenditure and receipts it is now easy for the ministry
of finance to prepare an annual budget and analyzing other economic issues like rate of
growth, GNP, etc.

 2.1 Stakeholders:
 Planning Division.
 Ministry of Finance, AGP, CGA.
 Provincial Finance Departments.
 NRB (National Reconstruction Bureau).
 Provincial Local Government Departments.
 This new system implemented SAP (system application product) as a front-end tool
and Oracle 9i as a database. This greatly improved the efficiency of the
Government and reengineered the old system quite effectively.

SYSTEM DEVELOPMENT PROCESS

The system development process is a set of activities, methods, best practices, and
automated tools that are used to develop and continuously improve information systems
and software.

3.1PRELIMINARY INVESTIGATION & PROBLEM ANALYSIS

3.1.1 Study of the existing system;

The old system was very much ineffective as we already mentioned that it was designed in
1993 by Siemens Pvt limited. This system was called the legacy system and it worked in
the following way.

The application was received by the R&I (receipt & issue) department regarding the
recruitment of a new employee or change in scale of a current employee with necessary
documents. Then the case was dispatched after manual recording to the concerned pre-audit
section. the case is then verified accordingly by the section and further transferred to the
payroll section. Concerned auditor of payroll section then audit the case comprehensively
and remove any discrepancies. After complete verification, the data is punched into the
database of fox pro. At the end of each month, the print of the whole database is taken in
the form of pay slips.
3.1.2 Problem in the existing system:

Following issues were there in the old payroll system of AGPR.

Time-consuming:

Time is always a critical issue in the Government sector. So, the process of punching the
data requires a lot of time after receiving applications from the concerned section.
 Extra staff is required:

As the machinery was too slow so extra staff is required not only for punching but also for
sorting of forms.

The record was not secure:

As there was no system of online and offline backup so in case of any disaster there was
no recovery of data. At that time the system of floppies was there, and it was un-secure to
save the data on the magnetic disk.

Lack of communication:

lack of communication between the AGPR Islamabad and other sub-offices does not
exist, therefore data cannot be verified from other districts and cities.

Chance of error & omission:

As most of the work consists of the manual audit so there were more chances of error
and omission exist and data can be mishandled.
As the existing system was based mostly on manual work therefore its data flow doesn't
exist. The database contains only records in a manner WE tried to find the “dfds” in the old
record, but WE couldn't find them.
3.1.3 Solution and Its Scope:
There was a need for a system that can remove all the discrepancies of the existing
system and which must be flexible and quick. Other than these changes it has the scope in
the following issues-engineered Business Processes.
 Prompt processing of claims.
 Improved HR functionality.
 Improved monitoring of the budget.
 Accurate, Transparent & Timely reports.
 Good Governance.
 Improved Decision-Making Process.
 Cash Forecasting Systems.
  Automated Financial Management System with greater Internal Controls
Facilitating System based Audit.
 More visible Audit Trails.
 High Level of Accountability.

3.1.4 CHALLENGES:
At Organizational Level

 Ensure successful implementation.

 Manage & sustain the change.
 Plans for developing skills and competence level.
 Develop organizational leadership.
 Introduce changes smoothly and efficiently.
 New HRM approach and corresponding framework of policies and
procedures.

At Staff Level

 Develop an understanding of the new system.

 Adopt transformed office routines & processes.
 Acquire new professional skills & competence

3.2 CONSTRAINTS

3.2.1Schedule constraints
 Implementation of the new system might disturb the existing
schedule of the system therefore to remove this constraint the new system
must run in parallel with the old system to keep the old schedule intact.
Therefore, administration has decided to keep all schedules as decided in
respect with the old system therefore this constraint was removed.
3.2.2 Budget constraints
 A huge budget of US $ 37.2 Million was required for the
implementation of a highly equipped system. Therefore, financing should be
 done accordingly. In AGPR, the budget was provided by World Bank
amounted to the US $ 28.8 M and the rest US $ 8.4 million was local share
to improve the system. So, this constraint was removed.

3.2.3 Technological constraints

Technological constraints required skills related to modern equipment for

efficient use of information system AGPR arranged the training in contract with
Siemens for the employees at its own cost. Due to this many employees gained
skillful knowledge of the new system and they further trained the newly
recruited employees to make them aware of the new technological development.
In addition, to that AGPR also hired the services of some (PROJECT FOR
IMPROVEMENT OF FINANCIAL REPORTING PAKISTAN) PIFRA
officials to maintain and update the system at regular intervals.

3.3 REQUIREMENT ANALYSIS PHASE:

3.3.1 Functional requirements

 Strengthening Government financial management policy and capacity, including the
role and the reach of the CGAs office, internal controls, and accounting skills
requirements across the board. 
 Modernizing and strengthening the AGPR office.
 Strengthening communication and change management to promote transparency
and increase stakeholder awareness and ownership.
 Establishing a basis for a structured R&D
 To provide integrated government-wide accounting, encompassing the functional
requirements for budget preparation and budget execution, covering appropriation,
commitment, funds allocation, and payment processes.

3.3.2 Non-functional requirements

 To create accurate timely and meaningful accounts
 To decrease the gap between the actual budget and expenditure.
  The budget formulation in a more constructive manner.
 Improve business process re-engineering to decrease the cycle time of each file
in the process.

3.4 TECHNIQUES USED FOR IDENTIFYING THESE

REQUIREMENTS:

Following techniques were used to know about the functional and non-functional
requirements of the new system.

1. File work of higher management to know the process of allocating the budget.
2. Interviews with the PIFRA officials
3. General public opinion.
4. Complaints from other departments
5. Improved planning by the Government to computerize the body of the whole
account
6. Suggestion from the world bank to improve the accounting system.

3.5 FEASIBILITY STUDY:

The feasibility study was carried out by the PIFRA consultants. They thoroughly
examine the functional and non-functional requirements. Different solutions were
proposed as per the requirement, but the most feasible solution was accepted called the
SAP (system application product) proposed by Siemens Pvt limited as it was already in
contract with the Govt of Pakistan since 1993.

The feasibility study comprises of different steps and techniques but some of the
most common feasibility operations are

 Economic feasibility
 Operational feasibility
 Technical feasibility
 Schedule feasibility

We will explain each feasibility study in respect of its costs and benefits
3.5.1 Economic Feasibility:

Costs:

It is no doubt that the new proposed system was initially very much costly i.e.
the cost of about 37.2 million US $ was required but with time, the system will reduce
its cost. Because the bulk of the expenditure will incur on machinery and types of
equipment also with training cost. Following were important contributors

sponsoring Agency: World Bank, Government of Pakistan.

Pakistan Audit Department (Comprising AGP & CGA), 

Implementing Agency:
Planning Division, Ministry of Finance.
Amount: US$ 37.2 M
World bank: US$ 28.8 M

Govt Of Pak: US$ 8.4 M

Benefits

Efficient and effective utilization of human, physical, financial, technological, and

administrative resources. Most of all in the current world time is the greatest resource
and by investing too much cost we have earned a wealth of time as less time is required
as compared to a manual system.
3.5.2 Operational Feasibility

Cost:

The implementation cost of the system was initially mentioned as about 40 Million
Pakistani Rupees but with time it changes accordingly. Implementation of a system for
operation requires the will of employees and most of them don't like changes, especially
in the government sector. Therefore, it is a great hurdle between the implementation and
operation of the new system for this we run both systems parallel so that employees
become used to the new system.

Benefits:

As per the operational point of view, this new proposed system is very effective,
especially it enhances the process of completing the decision making, budget allocating
and we can say that it enhances the old system through business process re-engineering.
It is therefore we can say that operational benefits are enormous in this system. And if
the system is flexible then it can also provide long-term benefits to the organization.

3.5.3 Technical Feasibility

Cost:

The system should be technically flexible which can adopt the changes that
occurred shortly. The hardware and software for the system must be secure and
registered thus require a great budget. In addition to that antivirus software, backups,
and power generators are also required for the smooth working of the system. Other
things required are highly trained staff new computers, networking, etc. also carry huge
costs.

Benefits:

All sections are connected through Local Area Network even the Head Quarter
and all sub officers are interconnected through WAN (wide area network). So, there
would be no chance of data redundancy or data duplication and only one Change in one
section effect in all sections.
3.5.4 Schedule Feasibility:

Costs:

The most difficult task in the implementation phase is that at what time the
system should be implemented so that it might not disturb the other
schedules of the organization June and December are the two most
important months of the AGPR fiscal year therefore the implementation
time must be in between these two months.

Benefits:

The schedule is made in the period when most of the employees are ready to
accept the change. In February 2004 it was implemented the shortest month
of the year and it was very much adaptive especially for payroll activities
and before June 2004 it was completely in operation, especially in the
payroll section/HR section.

3.6 SYSTEM DESIGN PHASE:

3.6.1 Data flow diagram (DFD):

The third major in information engineering designs. The purpose of this stage is to
transform the information models that were developed during analysis to models that
conform to the target technology we will use for information systems implementation.
There are two steps within the design: design databases and design processes responding to
the data and process columns of the framework. In the Human resource system of AGPR,
the payroll record of the employees of the Federal Government is maintained the DFD of
the system is as follows.

Data Flow Diagram:

 2
Government
D3 Employee personal file
Employee Hiring of
3.6.2 Government
Employee

Hiring New
Employee

Checking the
record of
employee

D2 All Employees File

4
D1 Status File
Check the
employee
status

Create Bank
Account

Create payroll
D4 Bank File
Each data flow in this diagram represents a view of data based on an entity type (or possibly more
than one entity type) and its associated attributes. Through a detailed analysis of dataflows, we can
specify the data required by the processes in each diagram. The figure shows a logical data flow
diagram using the six processes. show processes as rounded rectangles and data flows by labeled
arrows.

3.6.2 Computer input design:

Users of the HR section when entering the records of the newly hired employees from FO1. The
input form that appears in front of the users is as follows.
In this overview in the hiring manual F represents the Federal area, 7 represents the status and 18
represents the scale. After the execution whole record of the employee is entered in the next
windows of SAP.
Another example of computer input is bank details which are entered in the following window
In this window, the branch code and the account number of the employee are punched, and at the
end of each month, that branch is credited with the employee's pay by payroll order.

3.6.3 Computer output design:

The output design is in the form of a payslip of the employee which shows all the details of the
employee and its output view is as follows.
3.6.4 Entity-relationship (ER) modeling.

ENTITY RELATIONSHIP DIAGRAM OF PAYROLL SYSTEM

3.6.5 Database design
The major objective of database design is to map the conceptual data model to an
implementation model that a DBMS can process with a performance that is acceptable to
all users throughout the organization. Database design can be divided into the following
two phases:

Logical database design:

The process of mapping the conceptual data models (from analysis) to structures
that are specific to the target DBMS. If the target environment is a relational
DBMS, then the conceptual data models are mapped to normalized relations.

Physical database design:

The process of mapping the database structures from logical design into physical
storage structures such as files and tables. Indexes are also specified, as well as
access methods and other physical factors. A major objective of physical design
is to provide adequate performance for user applications in terms of response
times, throughput rates, and so on.

3.6.6 Activity-Networking-Diagram:

Duration (In
Activity Names Activity
Week) Precedents

Data conversion A 6 –

Testing B 4 –

Front-end tool C 3 A

Back-end tool D 4 B

Software
Packages E 3 B
 Duration (In
Activity Names Activity
Week) Precedents

Hardware
Packages F 10 –

Train end users G 3 E, F

Convert to new
system H 2 C, D

3.6.6.1 Activity on node diagram:

3.6.6.2 Forward Pass:

The forward pass is carried out to calculate the earliest dates on which
each activity may be started and completed.
Activity A may start immediately. Hence, earliest date for its start is zero
i.e. ES(A) = 0. It takes 6 weeks to complete its execution. Hence, earliest
it can finish is week 6 i.e. EF(A) = 6.
Activity B may start immediately. Hence, earliest date for its start is zero
i.e. ES(B) = 0. It takes 4 weeks to complete its execution. Hence, earliest
it can finish is week 4 i.e. EF(B) = 4.
Activity F may start immediately. Hence, earliest date for its start is zero
i.e. ES(F) = 0. It takes 10 weeks to complete its execution. Hence, earliest
it can finish is week 10 i.e. EF(F) = 10.
 Activity C starts as soon as activity A completes its execution. Hence,
earliest week it can start its execution is week 6 i.e. ES(C) = 6. It takes 3
weeks to complete its execution. Hence, earliest it can finish is week 9 i.e.
EF(C) = 9.
Activity D starts as soon as activity B completes its execution. Hence,
earliest week it can start its execution is week 4 i.e. ES(D) = 4. It takes 4
weeks to complete its execution. Hence, earliest it can finish is week 8 i.e.
EF(D) = 8.
Activity E starts as soon as activity B completes its execution. Hence,
earliest week it can start its execution is week 4 i.e. ES(E) = 4. It takes 3
weeks to complete its execution. Hence, earliest it can finish is week 7 i.e.
EF(E) = 7.
Activity G starts as soon as activity E and activity F completes their
execution. Since, activity requires the completion of both for starting its
execution, we would consider the MAX(ES(E), ES(F)). Hence, earliest
week it can start its execution is week 10 i.e. ES(G) = 10. It takes 3 weeks
to complete its execution. Hence, earliest it can finish is week 13 i.e.
EF(G) = 13.
Activity H starts as soon as activity C and activity D completes their
execution. Since, activity requires the completion of both for starting its
execution, we would consider the MAX(ES(C), ES(D)). Hence, earliest
week it can start its execution is week 9 i.e. ES(H) = 9. It takes 2 weeks to
complete its execution. Hence, earliest it can finish is week 11 i.e. EF(H)
= 11.

3.6.6.3 Backward Pass:

The backward pass is carried out to calculate the latest dates on which
each activity may be started and finished without delaying the end date of
the project.
Assumption: Latest finish date = Earliest Finish date (of project).
Activity G’s latest finish date is equal to the earliest finish date of the
precedent activity of finish according to the assumption i.e. LF(G) = 13. It
takes 3 weeks to complete its execution. Hence, latest it can start is week
10 i.e. LS(G) = 10.
Activity H’s latest finish date is equal to the earliest finish date of the
precedent activity of finish according to the assumption i.e. LF(H) = 13. It
takes 2 weeks to complete its execution. Hence, latest it can start is week
11 i.e. LS(H) = 11.
The latest end date for activity C would be the latest start date of H i.e.
LF(C) = 11. It takes 3 weeks to complete its execution. Hence, latest it can
start is week 8 i.e. LS(C) = 8.
The latest end date for activity D would be the latest start date of H i.e.
LF(D) = 11. It takes 4 weeks to complete its execution. Hence, latest it can
start is week 7 i.e. LS(D) = 7.
The latest end date for activity E would be the latest start date of G i.e.
LF(G) = 10. It takes 3 weeks to complete its execution. Hence, latest it can
start is week 7 i.e. LS(E) = 7.
The latest end date for activity F would be the latest start date of G i.e.
LF(G) = 10. It takes 10 weeks to complete its execution. Hence, latest it
can start is week 0 i.e. LS(F) = 0.
The latest end date for activity A would be the latest start date of C i.e.
LF(A) = 8. It takes 6 weeks to complete its execution. Hence, latest it can
start is week 2 i.e. LS(A) = 2.
The latest end date for activity B would be the earliest of the latest start
date of D and E i.e. LF(B) = 7. It takes 4 weeks to complete its execution.
Hence, latest it can start is week 3 i.e. LS(B) = 3.
 3.6.6.4 Identifying Critical Path:

Critical path is the path which gives us or helps us to estimate the earliest
time in which the whole project can be completed. Any delay to an activity
on this critical path will lead to a delay in the completion of the whole
project. In order to identify the critical path, we need to calculate the
activity float for each activity.
Activity float is actually the difference between an activity’s Earliest start
and its latest start date or the difference between the activity’s Earliest
finish and its latest finish date and it indicates that how much the activity
can be delayed without delaying the completion of the whole project. If the
float of an activity is zero, then the activity is a critical activity and must be
added to the critical path of the project network. In this example, activity F
and G have zero float and hence, are critical activities.

3.7 CONSTRUCTING & TESTING NEW SYSTEM

Since system construction logically follows system design in the overall lifecycle, the
team's focus will be on designing the application components needed to build the final
solution. Other critical aspects of the project must also be addressed. While many of the
activities surrounding these efforts may occur later in the project, the project manager must
ensure that the Planning and coordination of these efforts occur throughout system design,
 coincident with the application design, data conversion, testing, and deployment. The
intent is to demonstrate the level of thought and consideration that must go into planning
and designing every element outlined in the technical specification.

3.7.1 Data conversion:

Much of the data required by the system was entered through normal day-to-day business
operations, whether through manual input or automated mechanisms. Additional data may
be required, however, before the system can effectively begin operation, such as:
historical data, typically found on existing legacy systems, that may need to be migrated
to the new system to provide a basis for future calculations, historical or trend reports, etc.
reference data, also known as lookup data, which can be used to populate common tables
upon which other data is dependent (e.g., system codes that might be referenced across
multiple tables). This information may or may not reside on existing systems, depending
upon how the eventual design of the new system maps to the legacy environments.
new data, essential to the initial operation of the system being built, that may not be
available on any legacy systems. Whether or not the data the new system requires exists on
legacy systems (or in spreadsheets, or on scraps of paper, etc.), the project manager must
ensure that the project schedule.

3.7.2 Testing:

Test plans created in the product technical specifications process define the overall strategy
for validating the functionality of the system being developed, as well as the individual test
cases that will be performed in the execution of this strategy. Additionally, the
environments in which these tests will be executed must be defined in detail. Three
common types of testing are:
Unit-testing, where individual system components are independently tested as they are
developed to ensure that each logic path contained within each module performs as
expected. Many tests performed during unit testing can be used for more than one module
(error handling, spell checking of screens and reports, etc.).
 Integration testing, where multiple, related elements of the system are tested together to
validate components of the system and to ensure that the appropriate edits and controls are
functioning correctly. This testing concludes with the entire system being tested. “bottom-
up” and/or “top-down” testing approaches can be used. With bottom-up testing, the lowest
level modules are created and tested first, and successive layers of functionality are added
as they are developed. Top-down testing takes the opposite approach, where the highest-
level modules are developed and tested.
System testing, where the entire system is linked together and tested to validate that it
meets the operational requirements defined during system requirements analysis. Factors
that are commonly tested at this level include performance, load, boundary, and external
interfaces.
3.7.3 Front end and back end tools used:

There were many tools used in the software development of AGPR but some of the well-
known and most common tools used are
Oracle 9i as a back-end tool
SAP R/3 as a front-end tool

3.7.4 Software packages used:

Unix operating system as a database server operating system

Windows 2003 server as a client-server operating system

Reasons for using these tools:

As oracle 9i is a very secure and reliable database and can store unlimited records,
therefore, it's preferred over the other databases and due to its support with other operating
systems

SAP is a very flexible and technically enhanced front end application and can be very much
user friendly therefore it is helpful to install the SAP in an organization such as AGPR.

Among all the operating systems the Unix is the most secure command user interface
system free of all kinds of viruses and very difficult to hack therefore the management
decided to implement Unix based server for managing the whole database.
 Windows 2003 server is updated and enhanced operating system for the networking and all
the computers in the network can be managed easily through the system therefore its
installation is made in the client-server.

3.7.5 Hardware packages:

 The mainframe server by Haw Ellet Packard is installed as a database server

 Pentium 4 central processing system by Acer are used as client-server
 Network switches in different locations of the office are located to ensure the
smooth flow of data
 Network cables are attached throughout the office for the proper network called
LAN.
 Tape drives are installed in the server room for taking online and offline backup
automatically
 Wireless WAN is also working on attaching our office to the other sub-offices
throughout Pakistan still under process.

3.8 SYTEM IMPLEMENTATION PHASE:

The last stage in information engineering is implementation. The purpose of this stage is to
construct and install the information systems according to the plans and designs from the
preceding steps.
Implementation involves a series of steps leading to operational information systems that
include creating database definitions, creating program code, testing the systems,
developing operational procedures and documentation, training, and populating the
databases. In the context of information engineering, we are concerned with only two of
these steps: creating database definitions and creating applications. Database definitions are
ordinarily expressed in the form of schemas and sub-schemas.
 Schema
A schema is a description of the overall logical structure of a database. Schemas are
expressed in a language called the data definition language (DDL), which may range from
a few simple menu choices for a personal computer.
Sub-schema
A subschema is a logical description of a user's view (or program's view) of the data that
are used. A subschema is derived from an associated schema, and we normally define
numerous sub-schemas for each database schema.
The purpose of system implementation can be summarized as follows: making the new
system available to a prepared set of users (the polydent) and positioning on-going support
and maintenance of the system within the performing organization (the transition). At a
finer level of detail, deploying the system consists of executing all steps necessary to
educate the consumers on the use of the new system, placing the newly developed system
into production, confirming that all data required at the start of operations is available and
accurate, and validating that business functions that interact with the system are functioning
properly. Transitioning the system support responsibilities involves changing from system
development to a system support and maintenance mode of operation, with ownership of
the new system moving from the project team to the performing organization. A key
difference between system implementation and all other phases of the lifecycle is that all
project activities up to this
The point has been performed in safe, protected, and secure environments,
Where project issues that arise have little or no impact on day-to-day business operations.
Once the system goes live, however, this is no longer the case. Any miscues at this point
will almost certainly translate into direct operational and/or financial impacts on the
performing organization. It is
Through careful planning, execution, and management of system implementation activities
that the project team can minimize the likelihood of these occurrences and determine
appropriate contingency plans in the event of a problem.

3.8.1 Train end-users:

All user training should be performed before physically migrating the system to the
production environment. This will enable the consumers to begin to familiarize themselves
with the system and will help to establish their expectations regarding what the system will
 and will not do. The sequencing of deployment activities is just as important as it was with
previous testing activities. This sequence of events should be encompassed in the
deployment and transition plan section of the technical specification and will address and
prioritize any necessary training activities, set-up activities needed to prepare the
production environment (desktop, LAN, servers, data center, etc.), and data conversion and
validation activities. This deployment plan will also define the steps for
Physically migrating the system and any associated utilities to production, and for
validating the accuracy and completeness of this migration after these steps have been
performed. During deployment, project team members may often be required to work extra
hours to meet aggressive timeframes, or additional staff may be brought in temporarily to
assist with large data entry efforts. Proper planning and sequencing of the deployment
Can help to minimize these situations and reduce the chance of any missteps that could
result in having to restart the deployment process or lengthen the implementation schedule.
As the system is enabled, and the project team validates that the application is performing
to expectations, there may be
Times when certain system functions seem suspect. One of the challenges most frequently
faced by project teams is to determine the root cause of potential issues. Discrepancies that
exist within the data could be due to defects in the application's business logic or could be
the result of data that was improperly migrated into the system. Similarly, the inability of a
Consumer to access specific features of the system could be caused by improperly
configured hardware, or incorrectly.

3.8.2 Convert to a new system:

The more extensive and complex the system, the better the chance that something will go
wrong in production, no matter how well the system acceptance phase went. That why it
behooves the project manager not only to execute a comprehensive check of the entire
production environment every time anything is moved to production but also to have an
orderly
Fall-back plan for restoring production to a workable condition when – not if – something
goes wrong. Some error conditions are obvious and unmistakable – wrong heading on a
screen, and improperly calculated total on a report; others are insidious in their
perniciousness – a database update
 A mechanism that deletes rows infrequently and at random or miscalculates results by a
small fraction. Those conditions may persist for days before being detected, and present
insurmountable challenges in absence of a deliberate plan for a retreat. Save snapshots of
the database; concatenate transactions; mothball but do not discard older versions of
application code.
Be ready to roll back or to jump back and roll forward – if you are not rolling off the deck
of a sinking ship. A user reaction to the new system,
Especially if the said user was not directly involved in system acceptance. It is possible,
indeed likely, that some feature of the new system will be at odds with what the consumer
thinks it ought to be. After all, it was requested by somebody else, and somebody else again
built it. So, a vocal consumer will complain that the new system is wrong. This situation is
dangerous on two fronts: first, if accepted at its face value, it may mean rework, delays, or
worse; second, if not handled correctly, it may taint the perception of the new system and
may lead to more complaints.

3.8.3 Post-implementation review:

There is a song that never ends, it just goes on. But what if you are stuck
In the implementation phase that just does not seem to end. As soon as you fix all the
technical problems, a consumer reports a new bug, and you go through the cycle of fixing
and testing and moving and checking, and then another customer requests an urgent
change, and the implementation cycle starts all over again, and then you encounter another
technical issue, and it
Just goes on and on and on somewhere preferably sooner rather than. So, the post-
implementation strategy is to look after the whole system installed and remove the defects
that arrive during the time for this purpose the basis experts are there in the office 24 hours.

3.9 MAINTENANCE AND SUPPORT PHASE:

This key question assesses maintenance and support systems in terms of the number of
maintenance incidents, the amount of downtime, and the stages of response to a request for
maintenance; provisions for preventive maintenance; access to FAQ resources and
technical manuals; backup and disaster recovery procedures; replacement and upgrade
procedures; and diagnostic and repair procedures.
3.9.1 Maintenance Phase:
Cause of maintenance incident, categories:

Human error; software failure; hardware failure; network switching device or router failure;
network cable or wiring failure; wireless system failure.

Downtime:

The amount of time a machine or system spends in an inoperable state; alternatively, the
amount of time between a call for maintenance and the resolution of the problem.

Technical manual location categories:

At workstation; in classroom or laboratory; in the library or other building central location;

at district office or technology support office; online through local resources; online
through a vendor or other remote resource.

Maintenance procedures used in AGPR.

Preventive maintenance Preventive maintenance schedule established.

procedures Preventive maintenance checklist provided for the end-user.
FAQ access provided (to tech support; to end-users).
Access to technical manuals provided for end-users.
Backup procedures in place.
Disaster recovery procedures in place.
Update and replacement Replacement/upgrade schedule established for hardware.
procedures Replacement/upgrade schedule established for software.
Diagnostic and repair Help desk support software available (trouble ticketing,
resources resolution tracking).
Diagnostic software available (where appropriate).
Appropriate repair instruments/tools available.
Basic replacement parts in stock.
3.9.2 Support Phase:

The term support refers to actions taken on behalf of users rather than to actions taken on
equipment and systems. Support denotes activities that keep users working or help users
improve the ways they work. Included under support such items as:

 Help desks and other forms of putting a person in touch with another person
to resolve a problem or provide advice;
 Automated information systems, such as searchable frequently-asked-
question (FAQ) databases or newsletters;
 Initial training and familiarization tours for equipment and software,
whether automated or conducted by a human;
 Instructional and curriculum integration support, usually through
observation and personal interaction between a teacher and a technology
coordinator; and
 Technology integration support for administrative applications, usually
conducted through specialized consultants or software/systems vendors.

3.9.2 System enhancement:

In AGPR SAP R/2 system replace by R/3 system recently it shows that system of AGPR is
flexible and adaptive to technological changes. And its further updating with the advent of
new technologies.
Project termination/Closing:
AGPR is basically a public sector organization, with the implementation of new
technology not only the manual work is reduced up to great extent, but it also helped in
fast processing of government documentation. Other than that, the typical organizational
look of public sector is changed which contain so many paperwork now reduced to 2 or
3 computers in each section. These are just the short-term benefits but if look at the
broader side of the picture it contains flexible operations in all the sectors of the
economy. I-e AGPR has a key role in allocating the budget of the country and if it works
smoothly the budgeting system can become more efficient using new sources of
technology and become precise. As We am preparing my report which focus mostly on
pension department, We will encourage the use of new system in the organization like
AGPR as it provide great benefits to the pensioners but also to itself by keeping secure
and reliable record which hardly contain any kind of ambiguity. Keeping in view SWOT
analysis of the AGPR with the current system We must say that the image of public
sector in the mind of general public is very vague and they consider this sector an
inefficient and unreliable. But due to implementation of new techniques it will improve
further. For improving further, we have following suggestions

 There should be proper selection criteria in order to train employees.

 Ideas/ suggestions / recommendations should be encouraged in public sector as is done
in private Sector.
 QWL should be improved by providing well-trained and qualified supervisors over
subordinates and by providing hygiene in each branch of AGPR, Islamabad.
 Proper measures should be adopted to avoid accumulation of dust in the technical
offices.
 The performance of the employees should be encouraged
 There should be no nepotism
 Implementation of skill full management
 Train your own staff instead of hiring from private companies so the cost should be
reduced.
 To decrease the gap between private sector and government sector salary packages
should be increased to increase the work efficiency of the employees.
  Modernized government audit procedures and adoption of internationally accepted
auditing standards will eradicate program oversights and improve evaluation
capabilities.
 effective accounting and reporting systems will enable the government to better
formulate, control, and monitor its budget.

References/sources used:

 Interview
 Discussions
 Web sites
http://www.agpr.gov.pk
http://www.pifra.gov.pk