MIME-Version: 1.0 Content-Location: file:///C:/C4AC30E5/r_and_d_guide.htm Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii" Executive Summary

 

 

 

 

 

 

 

 

 

 

 

 

the_company= R&D and Product Development Management 2003


Table of Contents

1. R&D Mission and Direc= tion.. 4

1.1= Growth Path. <= /span>4

1.1.1 Projects to Products. 4=

1.1.2 A Phased Growth. 5=

1.1.2.1 Cashflow Management 5=

1.1.2.2 Recruitment 5=

1.1.2.3 Training. <= /span>6=

1.2= Key Performance Indicators. 6

1.2.1 Performance Targets. 6=

1.2.1.1 Number of Products/Versions Released per quarter/year 6=

1.2.1.3 ROI (Profit) per product 6=

1.2.1.4 Number of Bugs Reported. 7=

1.2.1.5 Number of Bugs Fixed. 7=

1.2.1.6 Client Satisfaction. 7=

1.2.1.6.1 Completeness of Functionality. 7=

1.2.1.6.2 Issue Resolution response time. 7=

1.2.1.6.3 Ease of deployment 7=

2. = Research Guidelines.. 7

2.1= Defining Research Focus. 7

2.1.1 Synergy: Marketing/Sales/Technology Drives. 8=

2.1.2 ROI: Market Size and Accessibility. 8=

2.1.3 Competitive Analysis. 8=

2.1.4 Leveraging Projects for Prototyping. 8=

2.1.5 Needs Analysis. 9=

2.2= Controls and Quality Assurance. 9

3. Development Guidelines.. 9

3.1 Recruitment Criteria (Team size and skills) 9

3.2 Documentation. 9

3.2.1 Functional Specifications. 9=

3.2.2 Design Document, Object Models, and DB Schemas. 10=

3.2.3 User Guide and Demo. 10=

3.2.4 Deployment Guide. 10=

3.2.5 Administration Guide. 10=

3.2.6 Data Center Support Guide. 10=

3.2.7 Developers Guide. 10=

3.2.8 Test Plan. <= /span>10=

3.3= Controls. 10

3.3.1 Product Development Management 10=

3.3.2 Specifications Management 10=

3.3.3 Progress Reports. 11=

3.3.4 Time Sheets. 11=

3.3.5 Source Control 11=

3.3.6 Change Management 11=

3.3.7 Issue Tracking. 11=

3.4= QA Quality Assurance is adhered to through two primary mechanisms: coding standards and testing. = 11

3.4.1 Coding Standards. 11=

3.4.2 Testing. <= /span>11=

3.4 Productization and Branding. 11

3.4.1 Partnerships and Channels. 11=

3.4.1.1 Training Materials. 12=

3.4.2 Brand Management 12=

3.4.3 Packaging. <= /span>12=

3.4.4 Pricing. <= /span>12=

3.4.5 Licensing. <= /span>12=

3.4.6 Deployment 12=

3.4.7 Support and Maintenance. 12=

3.4.8 Collateral Development 12=

4. = Accounting Guidelines.. 13

4.1 Recognition of R & D cost in the accounts. 13

4.1.1 Recognition. 13=

4.2.2 Amortization. 13=

4.2= Approval Process. <= /span>13

4.2.1 Future Process. 13=

4.3 Guidelines on Spending. 14

4.3.1 Budget 14=

5. = Product Development Plan 2003. 14

5.1= Products and Timelines. 14

5.1.1 ACE.. = 14=

5,1.2 the_company CM2. 14=

5.1.3 the_company Fees Module. 14=

5.1.4 the_company App Factory. 15=

5.1.5 the_company Deployment Tools. 15=

5.1.6 the_company Trade Finance. 15=

5.1.7 the_company Payroll/Bulk Payments. 15=

5.1.8 the_company Treasury. 15=

5.2= Scale up plan. <= /span>15

 


 

 

        =           =             &nb= sp;            =             &nb= sp;            =            1. R&D Mission and Direction

 

At the_company, as with any software company moving from a projects-focused business model to a products-focused business model, the Research and Development (R&D) activity is increasingly critical to the future success of the company.

 

 

This document provides working guidelines by which all= the_company R&D can be driven, implemented and measured.

 

1.1 Growth Path

1.1.1 Projects to Products

The decision to transform the_com= pany from a projects-based company to a products-based company was made by the m= anagement team during the middle of 2001.

 

By that time, it was clear that while the projects-bas= ed business model had allowed the_company to boots= trap itself from a startup to a small-sized company, it wou= ld not scale and would not provide the right story for IPO.

 

The management team felt that 4 factors contributed to= the weakness of the project-based business model.

 

1)     Culture of the_company – the ‘nerd’ f= actor

2)     Available pool of skilled labor

3)     Projects-based profit margins

4)     Competition from projects-based IT firms and an inability to differentiate

 

The products-based business model, on the other hand, leveraged these same factors. 

 

The fact that the_company = had the “right” kind of technical capability and culture would provide a distinct barrier to entry for local competitors, the_c= ompany is by design and by cultivation a nerdy company with an extremely highly skilled technical staff. Though funded through projects, since 1994, the_company has ‘shined’ through its R&am= p;D capabilities.

 

Similarly, products-based companies needn’t grow= as large as headcount-reliant projects-based companies.  Thus, labor pool shortages are not= as problematic. 

 

Finally, license-based sales leverage initial investme= nt many times over yielding a much higher ROI than one-off project sales with = poor reuse of technology.

 

1.1.2 A Phased Growth

The transformation from projects to products will be p= hased.

 

In fact, the transformation that begun in force in Q1 = 2002, is expected to continue steadily throughout 2003 and 2004.  Currently we are running at about = 20% R&D capability.  By end of= 2004, we hope to achieve a state of 80-20, with only 25% of the company focused on project-based development and sales.

 

The reason for a phased approach stems from several cr= itical factors:

 

 

1.1.2.1 Cashflow Management

Products take time to be developed and marketed.  During that time period, which can= be quite considerable, ROI is non-existent.&n= bsp; In addition, despite the best efforts of the company to invest well, some products will not be as marketable as expected.

 

While these factors are manageable for a pure-play pro= ducts company with a diversified portfolio and solid brand, they can be devastati= ng for a company in transition such as the_company= .

 

As such, project-based revenue will continue to be vit= al to the management of cashflow for 2003 and even the first half of 2004.

 

1.1.2.2 Recruitment

Hiring R&D developers takes time, even given the_company’s excellent global recruitment network.  Unlike project devel= opers, R&D developers must come with a great deal of experience and technical skills.  Note also that salary= costs for R&D developers will typically run higher (20-30%) than for project developers.

 

An R&D developer must be senior enough to envision= the product being used in a variety of circumstances and design it while still balancing the practical issues of time to market and resource constraints. While the technical prowess of a project developer is also important, the architectural capability is less of a concern because the projects are typically dictated by the needs of the single client.

 

1.1.2.3 Training

Once hired, typical R&D developers must spend 1-2 = months to familiarize themselves with the the_company methodology and environment (e.g.: ADT).&n= bsp; Following their initial indoctrination, they must spend an additional 2-3 months coming up to speed on their product.  As such, when building new R&D teams, one must assume a half-year down time where the output is poor compa= red to the cost.

 

the_company has a competitive advantage in it’s transition from projects to produ= cts in that it has always strived to hire R&D capable programmers. Thus, the developers who currently do projects for the_company can transition easily into an R&D role without the startup costs and initial productivity loss another company might have as described above.

 

All R&D developers at the_com= pany start off in projects in order to allow for the client to essentially pay f= or the training given above.

 

1.2 Key Performance Indicators=

As should be clear by now, R&D at the_company is driven by profits. The primary performance indicators are based off of revenue and profit generation ability such as sales revenue and profit per product.

 

The second half of performance indicators is based aro= und the direct quality of the products themselves such as number of bugs fixed = and completeness of functionality.

 

1.2.1 Performance Targets=

The performance targets are designed to provide quanti= tative measures by which R&D can be measured.

 

1.2.1.1 Number of Products/Versions Rel= eased per quarter/year

The number of products and versions released has a dir= ect impact on the ability of sales to generate revenue. Each product should hav= e at least one major version per year as an incentive of clients to subscribe to regular updates.

 

1.2.1.2 Revenue per Product

Each product should generate direct sales. Early in th= e life cycle of the product, revenue is a better key indicator of success than pro= fit (especially the first quarter a product is released). As the year progresse= s, profit would become a more key indicator of overall product success.

 

1.2.1.3 ROI (Profit) per product=

As product sales are made, and the life cycle of the products are realized, profit may be calculated.

 

1.2.1.4 Number of Bugs Reported

As part of the quality assurance team measurements (in R&D), they are responsible for finding bugs before clients find them. As such, the performance measure is to allow them to find as many bugs as possible. Likewise, the developer’s performance measurement is based = on finding as few bugs as possible in the QA side of R&D.

 

1.2.1.5 Number of Bugs Fixed

Developers will be measured based on the number of bug= s that are resolved and the timely fashion in which they are resolved.

 

1.2.1.6 Client Satisfaction

Ultimately client satisfaction is another way to gauge= the success of a product. Late in the life cycle of a product, the client may directly provide a measure client satisfaction. Early in the life cycle of = the product (pre-sales), this may be measured by how well the product meets sal= es and marketing department expectations.

 

1.2.1.6.1 Completeness of Functionality=

Early in the life cycle, marketing and sales will have= given a list of requirements to the R&D team. The R&D team, within the ti= me and resource constraints, should satisfy these requirements as much as possible.

 

1.2.1.6.2 Issue Resolution response tim= e

Any bugs discovered by the client should have as fast = an issue-resolution time as possible.

 

1.2.1.6.3 Ease of deployment

As we progress from projects to product-based company,= we will start to become less involved in Systems Integration and more dependent on = our channel partners to do SI. However, our channel partner’s will prefer pushing our products only if their ability to do SI is enhanced by making o= ur product easy to deploy. At the_company, we alwa= ys take project experience gained in the real world and feed that back into the products so that they become easier to deploy as time goes on.

 

        =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =       2. Research Guidelines

 

2.1 Defining Research Focus

Research focus is a company-wide effort= but is ultimately driven by sales and marketing projections. This section of the R&D guide will be supplemented by a marketing guidelines document to be written by David Florey, the_company Marketing Director when he starts work at the_company in January.

 <= /span>

2.1.1 Synergy: Marketing/Sales/Technology<= /span> Drives

There are three legs upon which the R&D efforts stand:

 

 

Together, these three ideals are balanced together in deciding which R&D products= to develop next. Early in the history of the_company as a product-based company, we see sales having the greatest say over product development because cashflow and immediate profitability is a key factor. O= ver time once a series of products is developed, cashflow will be less of a fac= tor and long-term profitability (e.g. being more profitable 3 quarters from now rather than making a tiny gain this quarter) will be more compelling.

 

R&D effort will always be taken into account as both sales and marketing departments know that when R&D is able to take advantage of previously developed components, the time to market for the product will be faster.

 

2.1.2 ROI: Market Size and Accessibilit= y

The marketing department will analyze the potential ROI based on input from past clients and studies of the market itself. A study of the market will also a= llow us to find out how much money a client would be willing to spend on a certa= in product.

 

2.1.3 Competitive Analysis

It is not enough to know the market for a product. We = must also know how saturated that market is. For example, the market for consumer retail banking and brokerage is large, but the market is saturated with competitors.

 

the_company’s greate= st competitive advantage is that we have been doing business and corporate ban= king products for several years whereas most competitors are only now reaching i= nto that space.

 

Part of the competitive analysis should also include companies willing to develop a product from scratch.

 

2.1.4 Leveraging Projects for Prototyping

Ideally, every product done at th= e_company should be a project first. A project immediately gains marketing bonus poin= ts because a client somewhere was already willing to pay for the raw effort to build the product from scratch. If one client is willing to do this, then i= t is also likely other clients will want a similar feature or product. We have f= ound this to be true with ACE, our first product, as every banking client we have encountered so far has asked for the features of ACE.

 

Based on a needs analysis done for the product, a gap analysis is performed to find out what the difference is between the project and product.

 

2.1.= 5 Needs Analysis

The product must be developed based on a defined requirements document. A needs analysis will determine what the requirements are with regards to the market and sales requirements.

 

2.2 Controls and Quality Assurance

Each product has a product development manager assigne= d to the product developer team. A given PDM may manage several products. This P= DM, viscerally aware of the requirements of the project also performs a general= QA role. Eventually, as product development grows in the_= company, we may hire specifically for a QA role.

 

        =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            3. Development Guidelines=

   &nbs= p;       

3.1 Recruitment Criteria (Team size and skills)

The ideal product team size should be 3-4 developers in order to realize a fast life cycle for developing the product without slowi= ng down the team with overly large communications burdens. For example, a team= of six would be too cumbersome with much time wasted on management.

 

Ideally, in the team of three, a mix of Microsoft, Java Server Side, Java Web Skills, Java Architect skills should exist with one member serving as a technical team lead who also performs systems analyst duties (e.g. writing specs and design documents).

 

3.2 = Documentation

The following lists all the ideal documents that should correspond to each product. Not all products require these documents for sa= les and marketing efforts. However, we have found that sales and marketing is m= uch easier if a full set of documentation is provided to the client.

 

In other words, documentation is a key differentiating factor for a company selling a product and making the client feel as if they are purchasing something that is easy to support.

 

3.2.= 1 Functional Specifications

This is the same documentation that is required for any project.

3.2.2 Design Document, Object Models, and DB Schemas

Unlike projects where the client may not pay for a des= ign guide, a design guide is mandatory in a product because the long life cycle= of a product makes it necessary to mark down design decisions. This also helps support greatly down the road.

 

3.2.3 User Guide and Demo

The user guide is a user-centric view of the applicati= on. It is usually accompanied by an HTML based demo that allows a trainer to train= a user on how the application will work. The HTML demo and the user guide are usually developed early in the product cycle so that sales can already start using this to sell the product.

 

3.2.4 Deployment Guide

This is a guide for system integrators about how to de= ploy the application.

 

3.2.5 Administration Guide

This is a guide for system integrators to understand w= hat sort of administration may be done from time to time. For example, a call center might need to add or delete users.

 

3.2.6 Data Center Support Guide

This is a guide for data center personnel to know what procedures to run at the start of day, end of day, as well as how to troubleshoot common problems.

 

3.2.7 Developers Guide

The developer’s guide is an extension of the des= ign document and explains how an SI who needs to write modules to extend our application should do it.

 

3.2.8 Test Plan

This is a standard test plan that indicates all the functions that the application does along with the expected results.

 

3.3 Controls

Controls are in place to assure repeatable product development success at the_company. In addition= , they provide financial controls to allow us to know whether our R&D develope= rs are continually producing high value for the company.

 

3.3.1 Product Development Management

Each product has an assigned product development manag= er. This person has a combination of skills that a project manager has plus marketing skills. The PDM serves as the liaison between the business and the developers (through the tech lead).

 

3.3.2 Specifications Management

Specifications are signed off on each project.

 

3.3.3 Progress Reports

WeeCountry2y Progress Reports ensure that key members = of marketing and the business team know that the project team is on track and = if not, can quicCountry2y rectify the matter.

 

3.3.4 Time Sheets<= /span>

Time sheets provide a means of tracking the cost to bu= ild a product for later ROI calculations.

 

3.3.5 Source Control

Currently managed by the Infrastru= cture department at the_company. There are a v= ariety of versioning SOPs enforced by Infrastructure using the CVS product (Concur= rent Version System).

 

3.3.6 Change Management

Changes go through a product development manager and a= re discussed to see how useful the changes are and if they provide financial v= alue to the company either short or long term (as with any other feature identif= ied early on in Needs Analysis).

 

3.3.7 Issue Tracking

Bugs or other issues with the products are tracked thr= ough Bugzilla, an in-house issue tracking system. This system includes the abili= ty to create and manage requests using both the Web and an email interface (for those on the road).

 

3.4 QA Quality Assurance is adhered to through two primary mechanisms: coding standards and testing.=

 

3.4.1 Coding Standards

For details see the_company Coding Standards document by XXX.

 

3.4.2 Testing

For details see the_company Testing Standards document by XXXX.

 

3.4 = Productization and Branding

Simply developing a product, does not make it a produc= t. The marketing team is also heavily involved in bringing that product to a speci= fic market and to uphold or enhance the branding of the company as well as the product being sold.

 

3.4.1 Partnerships and Channels

Our primary market channel is through partnerships. the_company is strong tech= nically but lacks sales manpower. In any case, even with a large number of sales people, the_company would still require the rig= ht connections within Asia. Therefore, we p= romote partnerships where those with the right connections can partner with us, who have the right technology for a win-win sale.

 

3.4.1.1 Training Materials

Part of bringing a partner on board selling our produc= ts consists of training that partner to understand our products. Therefore, the marketing and sales department in the_company is responsible for providing training.

 

3.4.2 Brand Management

The brand of both the product and the company should be upheld or enhanced with every new release. For details, see the Marketing Department Guidelines document.

 

3.4.3 Packaging

The package of the product should fit the market of the product. For details, see the Marketing Department Guidelines document.

 

3.4.4 Pricing

The pricing of the product should fit the market of the product. For details, see the Marketing Department Guidelines document.

 

3.4.5 Licensing

The licensing of our products should be standard yet flexible enough to suit the needs of changing markets. For details, see the Marketing Department Guidelines document.

 

3.4.6 Deployment

Each product must be as easily deployable as possible.= Typically, this means that without modification, it should be installable in less than= a day. Average customizations should require less than 1 month of SI work.

 

Because the nature of the software we develop is Enterprise-class, it is usually impossible to completely make the full installation just take place in 10 minutes. The reason for this is that Enterprise level software must integrate with the particular client’s systems that may, more often than not, be custom developed.

 

3.4.7 Support and Maintenance

The support and maintenance guidelines exist to standa= rdize how the_company deals with support including post-mortem on how to make sure problems that occur are learnt from organizationally. For details, see the Marketing Department Guidelines Document.

 

3.4.8 Collateral Development

Sales collateral is an essential part of selling each product and should go hand-in-hand with the documentation and packaging developed for it. For details, see the Marketing Department Guidelines Document.

 

 

        =                      =             &nb= sp;            =             &nb= sp;            =        4. Accounting Guidelines<= /h1>

 

4.1 Recognition of R & D cost in the accou= nts

The following sections outline the basic methods for k= eeping track of R & D cost, the controls on expenditure and the guiding princi= ples for R & D spending.

 

4.1.1 Recognition

Since the_company has alwa= ys been extremely cost conscious, we feel it is important that R & D spending be tracked in a clear and systematic manner. Currently, the cost is recognized= in terms of man-hours spent by our developers on specific R & D projects at specified times in the year. If a developer spends all his time on one proj= ect, then his full salary is that cost. If part of his time is spent on an R &am= p; D project, then he is given a “budget” of say two weeks, and then= two weeks from his full month’s salary is recognized as an R & D cost, and capitalized.

 

4.2.2 Amortization

Currently we have not amortized any of our R & D spending yet, but expect that the_company ACE, = the first version of which will be completed soon, will be amortized with effect from the first sale of the product. An estimated date of amortization shoul= d be given with the R & D plan (see 4.2).

 

4.2 Approval Process

There is currently no formal approval process in place= for product development. But R & D is still strictly controlled with each project undergoing deep scrutiny by the management team together with the Director of R & D.

 

4.2.1 Future Process

What we propose for future R & D projects going fo= rward is a more structured approach, with a proposed plan and budget jointly submitted by the R & D and Sales & Marketing Directors, and commenc= ing only upon approval from the board of directors. A plan should be submitted before the end of each year, and followed up with monthly reports on progre= ss.

 

Since the product development cycle is usually less th= an a year, it is probably advisable that revised and new plans for product development be submitted on a quarterly basis, especially with market chang= es and developments. That way, if there is a case for extending a period of ti= me for development of a project, it can be made during these quarterly reports= .

 

The R & D plan should specify the length of the pr= oject; resources required and should be supported by a technical and business case= for investing in the development of this product.

 

4.3 Guidelines on Spending

The planners must ask if there is a probable return on investment within a reasonable period. Also does the launch of this product require a heavy investment in sales and marketing or even a change in our current business processes? How long is the shelf life of the product? When would the company recoup its investment? Is this in demand by the company’s current customers, or would additional marketing be require= d?

 

4.3.1 Budget

This needs to be detailed enough to include number of developers needed, cost of market research, and raw materials such as books, equipment and software.

Besides the budget on the development side, there need= s to be a budget for bringing the product to the customer and a pricing model for the sale of the product.

 

        =             &nb= sp;            =             &nb= sp;            =             5. Product Development Plan 2003=

 

5.1 Products and Timelines

The following sections outlines the basic plans for 20= 03 in terms of the R&D that the_company plans to accomplish to meet sales and profit targets.

 

5.1.1 Product 1

YYY

 

5,1.2<= /span> Product 2

YYY

 <= /span>

5.1.3 P= roduct 3

ZZZ

 

5.1.4 Product 4

 

5.2 Scale up plan<= /span>

Clearly, there are more products to develop than there= is technical staff at the_company to support the R= &D plus projects at the same time. Therefore, we need to either forgo doing projects or hire more R&D personnel.

 

However, neither of these solutions will work by thems= elves.

 

Merely letting go of projects would rob us of a valuab= le source of marketing ideas from the real world. The features clients are wil= ling to pay for on a project basis are most likely the features they will want f= or a product. Therefore, even in a product-based mode, the_= company should continue doing at least some projects.

 

At the same time, if we hire so many R&D personnel= , we may run the risk of the economy ups and downs. During a few months where th= ere are not so many projects going on, we would have an overcapacity of develop= ers.

 

We would therefore, propose a hybrid approach to scali= ng up. On an average basis, our ideal scale up would consist of having four teams = of 3 developers. On an average worCountry2oad basis, 2 of those teams would be working on projects whilst the other 2 would be working on product developm= ent.

 

During a period of time when projects require more personnel, developers from the R&D teams could be moved over temporaril= y. Likewise, at a time when there are not enough projects, a 3rd R&D team could be formed to work on a subsequent product life cycle.

 

As the_company already has approximately six developers in Country1 that are already suited to R&D work, we would recommend migrating them to a mor= e pure R&D role.

 

New developers would be hired in Country2 under the le= ad of XXX. These would primarily be project developers capable of being moved to R&= ;D as needed.

 

There are a variety of reasons for doing this. First, developers in Country2 are much less expensive than developers in Country1. Therefore, our scale up plan should take profit into account.

 

Second, our primary project business is in Country2. As such, having the developers in COUNTRY2 will also make our project costs competitive, as we no longer would have to bill for airfare and hotel stays= .

 

Third, if PKTech has an over capacity of developers, w= e will be able to utilize them (and vice versa). Thus, keeping both organizations flexible in both lean and fat times.

 

In terms of general hiring, we would intend to move XXX (currently Infrastructure) to ZZZ’s group= as a combination of HTML workflow, process analyst and QA role. 

 

We would hire a Country2n PM (for same reasons we woul= d hire Country2n developers) for projects in COUNTRY2. And move our current Countr= y1-based PM back to Country1 to do Product Development.  BBB would initially move up to COU= NTRY2 to be the GM of the Country2n office. AAAA in Country1 would temporarily fi= ll BBB’s role, but ideally a “CTO” in Country1 would be hired eventually= to reduce BBB’s need in Country1 and freeing WWW to do sales.

 

What does this mean for product development schedule? = Well, with an average of 2 R&D teams going at once, we would anticipate the following schedule:

 

SCHEDULE HERE

 

Note that Deployment and App Factory R&D is overhe= ad that is take care of by infrastructure group and also partially absorbed by Proj= ect development. Hence, it is not listed as a specific R&D effort with rega= rds to scaling up or scheduling.

 

Our ramp up schedule is summarized in Table 5-1.

 

Table 5-1: R= amp Up plan

Employe= e

Monthly= Cost SGD

Country=

Dec

Jan

Feb

Mar

Apr

GM and Biz Analyst (XXX)

XXX

Country1=

 

X=

 

 

 

Director Marketing (YYY)

 XXX

Country1=

 

X=

 

 

 

Director of R&D (XXX)

 XXX

Country1=

X=

 

 

 

 

Accountant

XXX

Country1=

X=

 

 

 

 

 

 

 

 

 

 

 

 

Senior Project Manager

XXX

COUNTRY2=

 

X=

 

 

 

QA/Testing

XXX

Country1=

 

 

 

X=

 

 

 

 

 

 

 

 

 

Senior Project Developer

XXX

COUNTRY2=

 

X=

 

 

 

Senior Project Developer

XXX

COUNTRY2=

 

 

X=

 

 

Project Developer

XXX

COUNTRY2=

 

 

X=

 

 

Project Developer

XXX

COUNTRY2=

 

 

 

X=

 

Project Developer

XXX

COUNTRY2=

 

 

 

 

X=

 

 

 

 

 

 

 

 

* Note: the COUNTRY2 project developers replace the Country1 project develo= pers on projects and the Country1 developers are moved into two R&D teams under the Director of R&D.