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 company’s 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 company’s 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 enterprise–wide 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 Techlogix’s 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:

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

3
 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 website’s 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.

COMPANY’S 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 Techlogix’s 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
JMT’s application consultants and the Government of Guam’s 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 Guam’s 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 client’s 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.

5
 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 IFCS’s 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 Engyro’s 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.

7
 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
client’s 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 requester’s 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 (Engyro’s 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.

9
 30-118-2003-1

Exhibit 1
Techlogix Client List

ABN AMRO Bank General Electric Renault

American Express Bank Government of Guam State of Arkansas

AMP 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 Motorola
Engyro 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

D
Operations Analysis o
c
u
m
Solutions Design
e
n
t
a
Build
t
i
o
Transition 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 Guam’s 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 Guam’s 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
Trans ition IFCS& Techlogix Onshore
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

Vice President
Project Manager IFCS Project Manager - Techlogix
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 Governor’s 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.

Let’s 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). Let’s hope we don’t 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 Offsite
Project Manager Project Manager
Adil Bashir S. Zubair Ahmad
(Techlogix- Boston) (Techlogix- Lahore)

enGyro Project
Manager
Richard Okun

Engyro Project Team Lead Quality Team Lead

(Techlogix- Lahore) (Techlogix- Lahore)
enGyro Technical
Lead
Andrew Quinn

Engyro
Developer
Quality Engineer Graphic Designer Technical
(5)
(3) (Techlogix- Lahore) Writer
(Techlogix- Lahore) (Techlogix- Lahore) (Techlogix- Lahore)

Offsite Development Team Quality Team

Source: Techlogix Pvt Ltd

15
 30-118-2003-1

Exhibit 7
Engyro Procedure Change Control Process

User sends e-mail to Author evaluates t he change

User Initiates the Process relevant author of request and adds his
Start Change Request document and the comments about the
(F1-POG04) change request is approval or rejection of the
attached request

Reviewer makes evaluation

e-mail is sent to the of the change request and Author sends the change
approver by the reviewer adds his comments about the request to the reviewer
with the change request approval or rejection of the through e-mail
request

e-mail is sent to the

Approver makes reviewer, author and Author prepares draft Draft is forwarded to
evaluation of the change Approves user by the approver of the document to be the reviewer
request and comments about the approval of revised electronically
change request

Needs discussion

Draft with highlighted

Approves Reviewer reviews
corrections is sent
Meeting is held. All Corrections are required the draft version of
Rejects back to the author
concerned participate electronically the document

Corrections are required Approves

Rejects Approves

e-mail is sent to the

Approver gives a
reviewer, author and Draft is forwarded
e-mail is sent to the final review to the draft
user by the approver to the approver
reviewer, author and version of the
about the approval of electronically
user by the approver document
proposed change
about the rejection of
proposed change

Author replaces all older e-mail is sent to all

versions with the revised employees about the
version and keeps one copy change End
of older version in obsolete incorporated by the
records author
End

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

16
 30-118-2003-1

Exhibit 8
Requirements Change Request Form

Techlogix
Requirements Change Request

Adil Bashir 06-12-00

________________________________________________________________ _________________________
Requester’s Name Date

Engyro ASP Payments Application ENG001

________________________________________________________________ _________________________
Project Project Code

Requester:
Engyro Project Manager Project Director Onsite Project Manager
Offsite Project Manager Team Lead or Developer 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 6/16/00

____________________________________ _____________________________
Client Authorization: Engyro Project Manager Date

Adil Bashir 6/16/00 ENG-01-CR03

___________________________________ _____________________ _____________________________
Received: Onsite Project Manager Date Request Log Number

Muammar Lone 7/7/00

________________________________________________________________ _____________________________
Assigned to Date

Syed Zubair Ahmad 7/12/00

________________________________________________________________ _____________________________
Returned with Analysis Date

Source: Techlogix Pvt Ltd

17
 30-118-2003-1

Exhibit 9
Requirements Change Decision Form

Techlogix
Requirements Change Decision

Engyro ASP Payment Application ENG001

_______________________________________________ __________________________
Project Project Code

ENG-01-CR03 6/16/00
_____________________________ __________________________
Request Log Number 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: Requester’s Signature Date
Source: Techlogix Pvt Ltd

18
 30-118-2003-1
Exhibit 10
Engyro Phase Release Development Model

Onshore Offshore Team

Weeks Client/Onshore Team
Team
Development Quality Configuration Management
1 Proposal
2 Contract
3 Plan
Requirement QA Audit of
and Requirements and
4
Functional Functional

Configuration Management Process

Specification Specifications
5 High Level Design Test Plan Acceptance Testing Plan

Specification Change Management

6 Detailed Design - 1 Deployment Plan

Requirement & Functional

7 Coding and Documentation - 1 Operation & Maintenance Plan
8 Bug Fixing - T1 Testing - 1
9 Detailed Design - 2 Release - 1

Process
10 Coding and Documentation - 2 Bug Fixing - CT1 Customer Testing - 1
11 Bug Fixing - T2 Testing - 2
12 Detailed Design - 3 Release - 2
13 Coding and Documentation - 3 Bug Fixing - CT2 Customer Testing - 2
14 Bug Fixing - T3 Testing - 3
15 Detailed Design - F Release - 3
16 Coding and Documentation - F Bug Fixing - CT3 Customer Testing - 3
17 Bug Fixing - TF Testing - F
18 Release - F
19 Acceptance Testing
20 Bug Fixing - AT Deployment
21 Operation & Maintenance

Source: Techlogix Pvt Ltd

19