30-118-2003-1

PROJECT MANAGEMENT APPROACHES AT TECHLOGIX

In November 2001, Kewan Qadrie Khawaja Co-Chief Executive Officer (co-CEO) of
Techlogix was sitting in his Lahore office reviewing the Engyro project. Happy with the way
the project was managed, Kewan wanted all projects at Techlogix to follow the same structure
of project management to avoid problems like those encountered during the development of a
Financial Management System (FMS), for the Government of Guam.
According to him;
In the past we have always found it difficult to lock in our customers to specifications
agreed upon in the beginning of the project. This has created problems during the
execution of the project as customers insisted upon changes much later in the
development of the application. This practice affected our project plans and costs. It is
quite difficult to cater for last minute changes requested by the client when you are
developing software projects in the Internet time, which leaves you a window of only 3
to 4 months from conception of the project to its deployment. With the increasing
number of projects being developed in such a short time frame, it is very important to
focus on project management and requirement change management practices to be
able to better serve our clients.
COMPANY BACKGROUND
Two graduates of Massachusetts Institute of Technology (MIT), Salman Akhtar and Kewan
Khawaja founded Techlogix in 1996 in Lahore, Pakistan. Salman had bachelors and masters
degrees in Electrical Engineering and Computer Sciences and he had previously worked at
IBM TJ Watson Research Laboratory. Kewan with a Masters degree in Information Systems
had previously worked at Cambridge Technology Group and as a Research Associate at MIT.
Techlogix evolved on the basis of an onshore/offshore software development model. Its
onshore offices were established in Boston, New York and the Silicon Valley while the
offshore facility was based in Lahore. By the end of year 2000 the company had a turnover of
around $2 million, which had been growing at a rate of 60% since its inception.

This case was written by Associate Professor Jamshed H Khan with the assistance of
Research Associates Mahvesh Mahmud & Mustafa Bhatti to serve as a basis for class
discussion rather than to illustrate either effective or ineffective handling of an administrative
situation. This material may not be quoted, photocopied or reproduced in any form without
the prior written consent of Lahore University of Management Sciences.
2003 Lahore University of Management Sciences

30-118-2003-1
The companys mission statement was, to be one of the premier solution providers and
technical consultancy resource for clients to partner with.
Techlogix hired the 'best of the best' in engineering and management talent from across the
globe and maintained close relationships with leading universities and picked the finest IT
graduates. The Lahore facility alone employed more than 80 software development
professionals by January 2001. Members of the companys senior technical staff constantly
trained the software developers , in- house at Lahore, Boston, Houston, and Silicon Valley
offices. They were exposed to new technologies and concepts, management techniques and
disciplines and knowledge sharing was encouraged within the organization and externally as
well.
Techlogix provided software package solutions in the areas of enterprisewide client/server
database applications, web- intranet technologies and object oriented component architectures.
It had developed two main software products called Maestro and Jazba, which served a large
client base. It specialized in Enterprise Application Integration (EAI), Enterprise Portal
Solutions and Supply Chain Management (SCM).
1. Enterprise Application Integration (EAI) solutions, involved business integration for
automating routine tasks and processes, accelerating time-to- market, streamlining supply
and demand chains.
2. Enterprise portal solutions involved Customer Relationship Management (CRM)
applications, Business Intelligence and Business Activity Monitoring (BI/BAM).
3. Supply chain applications allowed Techlogix clients to reduce inventory, lower costs and
increase velocity across business units, suppliers, outsourcing partners, exchanges and
value-added service providers.
Techlogix had Fortune 500 firms as its clients ranging from Daimler Chrysler, Ford, General
Motors, to BMW, which sought automotive designing of advanced electrical components and
systems. Other clients included various leading manufacturing concerns, diversified financial
services companies, retailing and distribution firms, technology companies and large public
sector agencies. Exhibit 1 lists some of the Techlogixs clients.
Techlogix had also built relationships with those partners whose technology complemented its
innovative eSolutions. This allowed Techlogix to offer its clients fully integrated, end-to-end
eSolutions and services. Some of the leading partners of Techlogix were Oracle, Sun
Microsystems, Web Methods, Ascential Software and Attunity.
COMPANY STRUCTURE
Techlogix was based on an onshore/offshore model, which is described below:
Onshore Presence
On a typical fixed price/fixed time project, Techlogix placed 20% of its engineering resources
onshore in the USA. These resources were divided into the following three categories:

30-118-2003-1

1. Project Architect
The project architect focused on technical architecture, high- level design and business
process issues. He conducted an initial two to three weeks scoping exercise for each
project and performed a quality audit on the product of the project team. The architect was
involved in no more than two to three projects at any given time.
2. Onshore Project Manager
The Project Manager (PM) had joint responsibility for the project and was the main client
liaison. Each PM was dedicated to a single project at any given time.
3. Project Engineer
The project engineer provided engineering backup to the project manager and was
responsible for delivery and deployment issues at the client site. Each project engineer
was assigned to an average of two projects at any given time.
Offshore Presence
Techlogix placed 80% of its engineering resources at the Offshore Development Centre in
Lahore. Each project team utilized the following five resources:
1. Offshore Project Manager
Along with the on-site project manager, the offshore project manager was the key
manager responsible for the development and delivery of the project. He was the third
participant in the project scoping exercise at the client premises and was the joint author
of the Functional Specifications and the Technical Design (along with the Onshore Project
Manager). The offshore project manager was dedicated to a single project at any given
time.
2. Project Developers
The project developers formed the engineering team that was responsible for the core
development activity. The engineering team was dedicated to a single project at any given
time.
3. Quality Engineers
These constituted the Quality Assurance (QA) team. This team was brought on to the
project as needed with a single QA engineer given lead responsibility. This engineer was
responsible for the Testing Specifications and for the QA of the Functional Specifications.
The QA team reported directly to the Vice President Quality and through him to the
Centre Director.

30-118-2003-1

4. Project Architect
The Offshore team was also able to draw on the knowledge and experience of the Project
Architects as they produced the detailed Design Document.
5. Content Development Consultant
If a websites design was a part of the project, the Content Development Consultant
(CDC) assisted the project team and worked with the client to develop the theme and
templates for standardized content.
COMPANYS RISK-MITIGATION METHODOLOGY
Through the years, Techlogix evolved and refined Real Time Results (RTR) Project
Methodology, geared towards delivering high-quality solutions in Internet time. Working in
tandem, its onshore/offshore teams executed a fast-paced follow the sun development
schedule. Although much of the work was performed off-site, Techlogix mitigated the risk of
offshore development through features of the RTR methodology:
1. RTR Vault: This maintained current code and documentation library onshore, with
direct access to the customer.
2. RTR Access: Maintained current project information completely accessible on a real
time basis through a secure web portal.
3. RTR Global Meet: Within 24 hours, a client could schedule global audio/video
conferencing with the offshore project team.
This highly scalable RTR Methodology allowed Techlogix to deliver most projects within
similar delivery windows (90 120 days on an average) almost without regard to their size.
The combination of RTR methodology with an onshore/offshore model allowed Techlogix to
deliver products for a fixed price, 30-70% less than its competitors. The results were more
apparent when in 2001 Dun and Bradstreet evaluated Techlogixs performance as a 9.6
aggregate out of a potential 10 points in the areas of reliability, cost, accuracy, delivery
timeframes, quality, business relations, quality of personnel, customer support and
responsiveness.
PROJECT MANAGEMENT METHODOLOGY
Techlogix used multiple approaches to manage projects, from highly structured formal
configuration management systems as experienced in the Engyro project to very informal
systems utilized in developing a Financial Management System (FMS) for the government of
Guam. The case histories for these projects are discussed below:
Financial Management System for the Governme nt of Guam
In 1998, JM Taurus (JMT) a software development house in Guam asked Techlogix and an
International Financial Consultant Services (IFCS) firm to develop an Enterprise Resource
Planning suite (ERP) of Financial Management System (FMS) for the Government of Guam.
4

30-118-2003-1
The application was to be developed in Oracle Federal Financials and had the following
components:
1. Budget Information System (BIS).
2. Core Accounting Procurement System (CAPS).
3. Executive Information System (EIS).
Every major component of the ERP comprised different sub-components (modules) like
CAPS had six modules, which included Purchasing, Payroll and Receivables etc.
JMT was represented by their President and the Vice President acted as a liaison between the
Government of Guam and the teams from Techlogix and IFCS to resolve any issues that came
up during the execution of the project. The Techlogix team of six software developers was led
by its Projector Director Kewan Khawaja who bore the overall responsibility for the project
while Mr. Zubair Ahmad was designated as the Project Manager. John Deer represented a
team of five financial system analysts from the IFCS responsible for analyzing the legacy
system and designing the new financial application with Zubair (see Exhibit 4).
The methodology followed for the development was Oracle Application Implementation
Methodology (AIM), a linear sequential software development model that emphasized
product development in different modules or phases in case of a large project (see Exhibits 2
and 3). Though tightly integrated, Oracle application product suites were modular and hence
supported a phased implementation. This allowed the modules to be implemented in logical
groups based on the requirements of the Government of Guam. The methodology provided
JMTs application consultants and the Government of Guams user teams with a formalized
and standardized approach and work plan for the whole implementation process. This
approach ensured the proper definition of specific business requirements so that the final
implemented solution fully supported the Government of Guams business needs and
practices. Most importantly, the methodology also defined a complete approach to Quality
Assurance to ensure a successful project outcome through building quality into the
implementation process from the very start.
The Implementation Strategy Phase included a high level design of the application. The major
activities carried out during this phase were resolving the discrepancies in the customer
requirements, selecting an implementation methodology for the project and project planning.
John Deer and his team along with Zubair collected information regarding the existing system
and its performance at the clients site. As the software application required analysis of all
existing systems, all the components were studied and analyzed together and the results were
presented to the client. This exercise, which took two months, was carried out to establish the
functionality of the proposed application with the client.
Zubair commented:
We realized that the scope of this project necessitated an extremely organized and
detailed approach to develop a clear understanding of the requirements of the
application in order to commit ourselves to delivering what the client needed.

30-118-2003-1
After the implementation strategy phase a detailed Operations Analysis was carried out that
translated the business requirements into functional requirements for the applications. This
phase, which took three months to complete, was carried out solely by IFCSs project team.
Modules of the ERP were assigned to different members of the team for systems analysis. The
analysis was documented and presented to all parties in the project so that they had a common
understanding of the financial systems in place and the functional requirements of the new
application. The feedback was incorporated in the analysis.
According to Zubair:
The operation analysis and detail in which these systems were to be studied were
important for the project. Once the contract was signed and we had entered the design
and build phase it would have been difficult to incorporate any major changes in the
functionality of the application.
Before the Solutions Design Phase a formal contract was signed with the Government of
Guam that gave details of mutually agreed upon business and functional requirements of the
application. In this phase the functional requirements developed in the earlier phases were
used to formulate a detailed architecture of the application. A complete project plan was built,
which included milestones and deliverables for all the modules of the application. IFCS and
Techlogix completed this phase jointly in three months. Financial consultants contributed
their expertise in the financial systems while Techlogix incorporated those systems in the
software design.
Techlogix in Lahore carried out the Build Phase with a team of six software engineers within
five months. In this phase, modules were developed separately and later integrated. The
sequence in which they were integrated was based upon priority of modules agreed upon
earlier with the client in the contract. The proposed system depended on Oracle Federal
Financials, while, the legacy systems in place were independent applications with different
operating systems some of which could not even communicate with each other.
The Transition Phase which included training, data conversion and onsite testing spanned
over one year. Training of about 500 people dispersed over the city was carried out onsite in
Guam with the help of JMT and the IFCS teams. The training was carried out on the beta
version of the product to assess the comfort level of the users involved. It was during this
stage that a lot of minor and major changes were made. For functional changes requested by
the Government in the payroll module, the whole operation analysis exercise had to be carried
out again.
Reflecting on this Kewan commented:
We took this issue up with both JMT and the Government of Guam. The government
maintained that IFCS was notified of these issues and showed us the forms which were
communicated to the consultants. However, the changes requested were not
incorporated into functional specifications by the financial consultants. Even the way
functional specifications were written by the consultants did not meet the current
standards. When we took this issue with JMT, they blamed us for accepting those
functional specifications if we thought that they were not up to the standard.
6

30-118-2003-1

The analysis on the payroll module along with other modules had been completed in the
operations analysis phase. The changes that were later requested during this transition phase
required a detailed analysis of the operations involved in incorporating the changes before the
implementation deadline of the module.
Reflecting on the changes requested by the client, Zubair said:
Usually no one person can anticipate everything and when you have the application in
front of you, you get a clearer picture and more ideas about the application. On hind
sight, if we had spent a little more time in the analysis phase, the requirements would
have been clearer. Unless you and the client are extremely organized and the client
knows precisely what he wants there will always be changes in the requirements. We
even developed a prototype for some of the modules and showed it to the client but
even then there were some changes requested by the client at the later stages. It is
difficult to build everything in the prototype for such a big project.
Commenting upon the FMS project, Kewan said:
FMS was an experience. The night before we were to give a demonstration of the
payroll application, we were correcting the algorithm of the application. Zubair was on
the phone from Guam with me and it was 2 am in the morning in Pakistan. We did it
successfully but we could have done it better in a more professional way. I remember
the mail that was circulated about the experience and we often talk about it as an
experience we would not want to relive (see Exhibit 5).

Engyro
Engyro provided financial services such as payments handling and support to Application
Service Providers (ASPs), and portals. Engyro approached Techlogix to develop an ASP
Payments System an application designed to automate financial transactions for the ASP
industry.
The project involved the development of the user interface concentrating on the screens
required to support Engyros ASP customers. The underlying database scheme was designed
with the modes of operation in mind, so that future phases would allow extension of the
functionality of the system. The major focus of the application was automated billing, contract
management, metering interfaces, presentation of usage statistics, registration of portal users
and administration interfaces for ASP, Portal and Engyro administrative users.
Dr Khurram Afridi, Chief Operating Officer (COO) in Boston, led the project team, while
Adil Basheer was appointed onshore Project Manager based in Boston and Zubair was
assigned to the project as the offshore Project Manage r based in Lahore. Engyro was
represented by President Richard Okun and Andrew Quinn as Technical Lead (Exhibit 6).
Adil and Zubair established the functional requirements of the application based upon the
system requirements provided by the Engyro team over a period of one week.

30-118-2003-1
After receiving all the business requirements and functional specifications from the onshore
team, the offshore team developed a high level design of the application. The Requirement
and Functional Specification Change Management Process (RFCMP) was initiated right after
Quality Assurance audit of functional specifications to control any changes required by the
client at a later stage. The configuration management process, on the other hand, became
active as soon as the contract was signed before the system requirement phase started. Once
the high level design was in place the Quality Assurance (QA) team developed the test plans
for the overall product. Based upon these test plans an acceptance plan was made at the
clients side and the whole exercise completed within a week.
The software development work for the project was broken down into releases and developed
in an iterative manner with each release focusing on a certain functional area of the final
product. Within each release the functional specifications were analyzed, designed, coded and
then sent to the QA for testing. The QA team tested each release both separately and along
with other releases developed to date. After passing the QA tests, the release was sent to the
client for onsite testing and deployment.
Commenting on the release phases, Zubair said:
To have better control over the development of the product and handling of client
requirements we decided to further break down the development phase if it exceeded 7
to 10 weeks. The development in each phase was then sent for customer evaluation
while the work on the next phases continued. As the application developed the
feedback from the customer on each phase was incorporated in such a systematic way
that the next release included the changes from the feedback on the previous released
phases.
After the initiation of RFCMP, any changes in the functional specifications requested by the
client had to go through a formal approval process, which included documentation, analysis,
escalation and decision (see Exhibit 7). The documentation for requirement and functional
specification change management process included generation of a change request form (see
Exhibit 8), which contained the nature of the change and the requesters name. If a request
was an addition of field in a report generated by the application, Adil initiated the change
request on behalf of the client. This was conveyed to Zubair on a Requirement Change
Request (CR) Form. He then passed the CR form to the software development team lead who
gave an assessment of the time and effort that would be spent on the change and its
implementation. The QA people, who reviewed the assessment and maintained all the
documentation for that change, also evaluated this change. The analysis of the assessment was
reported to Zubair who gave feedback to Adil. The assessment including additional time and
cost requirements was then conveyed to Richard Okun (Engyros Project Manager) who had
to make the decision whether to incorporate the change or not. The decision regarding the
change request was documented in a Requirements Change Decision Form as shown in
Exhibit 9.
Please also see Exhibit 10 for a detailed view of the Engyro phase releases.
Kewan wanted to standardize the project management systems followed in the Engyro project
for all projects undertaken by Techlogix, but was concerned about the reservations that some
8

30-118-2003-1
of the project managers had about standardizing such a structured system. They felt that this
would reduce flexibility available to project managers. They also feared that with such a
formal structure any changes in product specification would require a lengthy bureaucratic
process, which would either discourage change, thereby annoying the client or force the
project managers to circumvent the procedures creating other problems.

30-118-2003-1
Exhibit 1
Techlogix Client List
ABN AMRO Bank

General Electric

Renault

American Express Bank

AMP

Government of Guam

State of Arkansas

Hautedecor.com

Illinois and New Mexico

Bank of America

Infonox

TEKchand

Bosch

Kaman Industrial

USCO

Citibank

MIT

Visage Technology

Clickmarks.com

Mindfabric

Whiteflash.com

Commerce One

MassMutual

Wordwalla.com

EnforSYS
Engyro

Motorola
Nestl

Source: www.techlogix.com

10

30-118-2003-1
Exhibit 2
Application Implementation Methodology
AIM is divided into Seven Phases. Each phase is discussed below:
Implementation Strategy

Operations Analysis

Solutions Design

Build

Transition

D
o
c
u
m
e
n
t
a
t
i
o
n

Production

Implementation Strategy:

To establish and plan the business and technical execution of the

project.

Operations Analysis:

To identify business and technology requirements to propose a

solutions architecture.

Solutions Design:

To create the optimal business process solution to meet the

Government of Guams current and future business
requirements.

Build:

To construct, test and confirm the full-system solution.

Documentation:

To prepare system and end- user documentation for the

Government of Guam.

Transition:

To migrate the Government of Guams systems and people into

the new system.

Production:

To monitor and refine the production system and plan for the
future.

Source: Techlogix Pvt Ltd

11

30-118-2003-1
Exhibit 3
AIM Methodology used in FMS

STAGES

DURATION

RESPONSIBILITY

ON SHORE/ OFF SHORE

Implementation Strategy

2 Months

IFCS & Techlogix

Onshore

Acceptance

1 Month

Operations Analysis

3 Months

IFCS

Onshore

Acceptance

1 Month

Solution Design

3 Months

IFCS & Techlogix

Onshore/Offshore

Acceptance

2 Month

Build and Develop

5 Months

Techlogix

Offshore

Acceptance

2 Months
IFCS& Techlogix

Onshore

Trans ition

1 Year

Production

Source: Techlogix Pvt Ltd

12

30-118-2003-1
Exhibit 4
Organizational Chart for FMS

Government of Guam
(Client)

Mr. Kewan Khawaja

President

Project Director - Techlogix

JMT

Mr. John Deer

Mr. Zubair Ahmad

Project Manager IFCS

Project Manager - Techlogix

Vice President
JMT

Consultants
IFCS (5)

On-site Team -Techlogix

Off-site Quality Assurance Team - Techlogix

Off-shore Development Team Techlogix

(2)

(2)

(4)

Source: Techlogix Pvt Ltd

13

30-118-2003-1
Exhibit 5
Internal Mail Regarding FMS Experience

Assalam O Alaikum!
It is 10:00 a.m. here, and we are almost through with printing the payroll checks. We started printing the checks at about
midnight. There were several hiccups on the way. Some took more time to resolve than others. Alhamdolillah we resolved all the
issues identified so far.
Tariq did a wonderful job. He handled all the technical issues by himself. His calm during some of the most critical problems was
amazing. Zubair and I were available for moral support as well as to help Tariq concentrate on the major task, which was to fix
the algorithm and print checks.
We had to call Kewan thrice at night, as changes were required in the algorithm. Kewan stayed online from his home till after
6:00 a.m. Guam time for support. He was as usual handy in resolving all the issues, no matter how huge they appeared in the
beginning. His optimism was our biggest asset!
It was very tense here in the beginning. The Governor was getting extremely nervous. Clifford Guzman and the Governors Chief
of Staff arrived at 5:30 p.m. and stayed with us till after midnight. In the absence of the payroll staff, Clifford Guzman stayed till
2:00 a.m. checking the Deductions Combined Register for the key agencies with the record provided by Payroll Section. Rodney
Webb stayed till 5 a.m., after making sure that we were on track. Arleen stayed with us till 6:00 a.m. checking most of the
deduction-combined register for critical agencies.
There were issues coming up all the time and at one time the printer jammed but everything was taken care of. Just when we
printed the first check, there were group photos taken to record the momentous occasion.
Lets hope it stays that way, and the three of us, Zubair, Tariq and I can go home and sleep. We started at 9:00 a.m. yesterday and
have been in this room since then. That is slowly taking its toll. The most affected is of course, Tariq as he remained in the line of
fire all along.
This has been one memorable night (and day). Lets hope we dont have to go through it again. However the experience was
worth sharing.
Best regards,
Faisal.

Source: Techlogix Company Data.

14

30-118-2003-1
Exhibit 6
Organizational
Chart For Engyro
enGyro's Organizational
Chart

Project Director
Khurram Afridi
(Techlogix- Boston)

Client
enGyro

Engyro

Onsite
Project Manager
Adil Bashir
(Techlogix- Boston)

Offsite
Project Manager
S. Zubair Ahmad
(Techlogix- Lahore)

enGyro Project
Manager
Richard Okun

Engyro

Project Team Lead

(Techlogix- Lahore)

Quality Team Lead

(Techlogix- Lahore)

Developer
(5)
(Techlogix- Lahore)

Quality Engineer
(3)
(Techlogix- Lahore)

enGyro Technical
Lead
Andrew Quinn

Engyro

Offsite Development Team

Source: Techlogix Pvt Ltd

15

Graphic Designer
(Techlogix- Lahore)

Technical
Writer
(Techlogix- Lahore)

Quality Team

30-118-2003-1
Exhibit 7
Engyro Procedure Change Control Process

Start

User sends e-mail to

relevant author of
document and the
change request is
attached

User Initiates the Process

Change Request
(F1-POG04)

Reviewer makes evaluation

of the change request and
adds his comments about the
approval or rejection of the
request

e-mail is sent to the

approver by the reviewer
with the change request

Approver makes
evaluation of the change
request and comments

Approves

e-mail is sent to the

reviewer, author and
user by the approver
about the approval of
change request

Author prepares draft

of the document to be
revised

Author evaluates t he change

request and adds his
comments about the
approval or rejection of the
request

Author sends the change

request to the reviewer
through e-mail

Draft is forwarded to
the reviewer
electronically

Needs discussion

Approves
Rejects

Meeting is held. All

concerned participate

Draft with highlighted

corrections is sent
back to the author
electronically

End

Reviewer reviews
the draft version of
the document

Corrections are required

Approves

Rejects

e-mail is sent to the

reviewer, author and
user by the approver
about the rejection of
proposed change

Corrections are required

e-mail is sent to the

reviewer, author and
user by the approver
about the approval of
proposed change

Approver gives a
final review to the draft
version of the
document

Author replaces all older

versions with the revised
version and keeps one copy
of older version in obsolete
records

e-mail is sent to all

employees about the
change
incorporated by the
author

Source: Exhibit # E1 -POG06 Version # 1, Techlogix Pvt. Ltd

16

Approves

Draft is forwarded
to the approver
electronically

End

30-118-2003-1
Exhibit 8
Requirements Change Request Form

Techlogix
Requirements Change Request
Adil Bashir
________________________________________________________________
Requesters Name

06-12-00
_________________________
Date

Engyro ASP Payments Application

________________________________________________________________
Project

ENG001
_________________________
Project Code

Requester:
Engyro Project Manager
Offsite Project Manager

Project Director
Team Lead or Developer

Onsite Project Manager

Other:

Proposed Change:
Provide Bill Number on the View Disbursement Reports of the Portal Admin

See attached documents and figures

Effected Version of Functional Specification:
Rationale For Change:
This allows the Portal Admin to easily access and view the bill against which the disbursement is made

See attached supporting documents and figures

Richard Okun
____________________________________
Client Authorization: Engyro Project Manager
Adil Bashir
___________________________________
Received: Onsite Project Manager

6/16/00
_____________________________
Date
6/16/00
_____________________
Date

ENG-01-CR03
_____________________________
Request Log Number

Muammar Lone
________________________________________________________________
Assigned to

7/7/00
_____________________________
Date

Syed Zubair Ahmad

________________________________________________________________
Returned with Analysis

7/12/00
_____________________________
Date

Source: Techlogix Pvt Ltd

17

30-118-2003-1
Exhibit 9
Requirements Change Decision Form

Techlogix
Requirements Change Decision
Engyro ASP Payment Application
_______________________________________________
Project

ENG001
__________________________
Project Code

ENG-01-CR03
_____________________________
Request Log Number

6/16/00
__________________________
Date

Analysis of Proposed Change Request:

See additional details attached

Impact of Proposed Change Request: Time:

2 days

Budget:

Decision:

Approved Adjustments:

Incorporate in current phase

Time:

Defer for a future phase

Budget:

Incorporate with modification in current phase

Defer with modification for a future phase

Other:

Reject

(Specify)

Affected Work Items:

Functional Specifications Design, UI Design, Development
______________________________
______________________________

______________________________

______________________________________________________________
Authorization: Engryo Project Manager

_____________________________
Date

______________________________________________________________
Authorization: Project Director

_____________________________
Date

______________________________________________________________
I am satisfied with the decision: Requesters Signature

_____________________________
Date

Source: Techlogix Pvt Ltd

18

30-118-2003-1

Exhibit 10
Engyro Phase Release Development Model

4
5
6

Client/Onshore Team
Development

Quality

Proposal
Contract
Plan
Requirement
and
Functional
Specification
High Level Design
Detailed Design - 1

Coding and Documentation - 1

8
9
10
11
12
13
14
15
16
17
18
19
20
21

Bug Fixing - T1
Detailed Design - 2
Coding and Documentation - 2 Bug Fixing - CT1
Bug Fixing - T2
Detailed Design - 3
Coding and Documentation - 3 Bug Fixing - CT2
Bug Fixing - T3
Detailed Design - F
Coding and Documentation - F Bug Fixing - CT3
Bug Fixing - TF

Configuration Management

QA Audit of
Requirements and
Functional
Specifications
Test Plan

Testing - 1
Release - 1
Testing - 2
Release - 2
Testing - 3

Configuration Management Process

1
2
3

Offshore Team

Onshore
Team

Requirement & Functional

Specification Change Management
Process

Weeks

Acceptance Testing Plan

Deployment Plan
Operation & Maintenance Plan

Customer Testing - 1

Customer Testing - 2

Release - 3
Customer Testing - 3
Testing - F
Release - F
Acceptance Testing
Deployment
Operation & Maintenance

Bug Fixing - AT

Source: Techlogix Pvt Ltd

19