The First Attempt

Test Estimation Technique: Hybrid of Story Points and Test Points Analysis

2009-07-31T17:34:00.007+05:30

Test Estimation is one field of Software Engineering where little work has been done. Much work is still to be done to mature the field.
The most scientific approach known to date for Test Estimation is Test Point Analysis. However in its current form, it is mostly based upon the Project Size (arrived at by Functional Point Analysis or Use Case Point Analysis).
The accuracy of Test Estimates worked upon by Test Point Analysis depends upon the accuracy (and relevance) of the Project Size. If the Project Size is not known (not calculated or not available) it becomes very hard to estimate the Test Effort. Also, for Scrum based projects where estimates of Project Size is usually calculated using Planning Poker (Story Points); test estimation is very hard.

Recently, for a client we had to come up with some numbers about Test Effort required for the UAT with no readymade information about the project size available. The actual Project Size was something the vendor was supposed to come up with. From our end there was no time and capacity to start with the Project Size Estimation and then extend it to Test Estimation due to lack of resources, SMEs and lower level project details available.

The idea of breeding Story Points with Test Point Analysis struck my mind and I started working on this hybrid model.

So here's the final model (I am yet to validate the accuracy levels):

1. List all the high level test aspects (test stories).

2. Assign Story Points (relative) to all test stories. (Follow all the conventions attached to Story Points/ Planning Poker et al).

3. Identify the Dynamic Test Factors relevant to your project situation. (Limit this to 5 only). This is a limitation since we are going to modify the Test Point Analysis methodology a bit to suite our needs (deriving the estimate from Story Point instead of Use Case based Project Size called Use Case Points).

4. For the Dynamic Test Factors assign weights like:
Dynamic Test Factor #1: Low=3, Medium=6, High=12
Dynamic Test Factor #2: Low=2, Medium=4, High=12
Dynamic Test Factor #3: Low=2, Medium=4, High=8
Dynamic Test Factor #4: Low=3, Medium=6, High=12
Dynamic Test Factor #5: Low=3, Medium=6, High=12

5. You can reverse the weight assignment if the Dynamic Test Factor has a reverse impact on the test effort. For example, if Dynamic Test Factor # 3's High intensity decreases the test effort whereas, for other test factors the High intensity increases the test effort, then you can have Low= 8, Medium = 4, High = 2 for Dynamic Test Factor #3.

6. Now identify the 8 Environmental Test Factors impacting your project, and rate them on a scale of 0 to 5.

7. Calculate the Environmental Test Factor for the project by the formula

ETF= 1.4 + (-0.03*Sum of all Environmental Test Factors)

9. To each Test Story identified in step 1, assign Dynamic Test Factor weights (out of the Low, Medium High).

10. For each Test Story, You will get 5 distinct values -- one each for each Dynamic Test Factor. Now you need to consolidate these five values into a single value. For this apply the following formula (Sum all 5 values of Dynamic Test Factors, and divide it by 26).

Weighted Dynamic Test Factor= Sum(Dynamic Test Factor Values)/26

The value 26 is the nominal value of the Dynamic Test Factor weights. By doing so, you will get a single weighted Dynamic Test Factor value for each Test Story.

11. Now calculate Adjusted Dynamic Test Factor by multiplying the Weighted Dnamic Test Factor by its Story Points.

Adjusted Dynamic Test Factor = Weighted Dynamic Test Factor * Story Points

12. Now calculate Test Points for each Test Story by the following formula:

Test Points= Adjusted Dynamic Test Factor * ETF

13. The final Test Points for the entire project would be the sum of all the Test Points.

Now in order to do the Effort Estimation you need to factor the staff's Productivity.
The Productivity has the industry standard range of 0.7 to 2.0. (0.7 is for the highly productive team, whereas 2.0 is for a poorly productive team).

Effort = Test Points * Productivity

Let us say that the total Test Points you arrived at were 400, and your team's productivity is 1.0 then
Person Hours= 400 *1.0

Hence you need 400 person hours of test effort for this project with your current team.

Traveling Onsite: Reasons (contd.): # 5

2009-07-24T12:37:00.000+05:30

Reason 5: Strategic Staff Exchange

Long term relationships between a client and a vendor; joint ventures and partnerships; merger / acquisitions trigger the need for a strategic staff exchange program. The motive of such staff exchange program can vary from basic training knowledge sharing to a more intangible benefits like cultural sensitization, international exposure to staff (in order to scale up their abilities) or job enrichment (to keep the morale high).

Post-merger Consolidation measures often trigger large scale staff exchange programs wherein the teams of the two business entities work together in order to gel the systems, processes and work approaches together.
I once happened to witness some client side engineers to travel to India to work with their vendor's team just because they wanted to add 'international exposure' in their CV. Their complaint was that often Indians travel to US which inflates their profile whereas the professionals in US miss on this international exposure tag because company does not send them to India. So it was more of an HR issue which the client had to deal with. Not so often seen but yes, it has started to happen in US :-).

Traveling Onsite: Reasons (contd.): # 4

2009-07-22T17:18:00.000+05:30

Reason 4: Project Knowledge Gathering

As resources are inducted to an existing project or as a new project is initiated, the resources are asked to visit onsite for knowledge gathering purpose. The reason is induction in simplified terms. Resources are exposed to the new project environment (and organization culture, processes, standards etc) so that they can become productive in the project from offshore.
Usually this kind of travel is organized in groups involving formal or informal means of training or induction. Usually it is a low key affair and the skill set required is very much specific to the project requirements. This kind of travel is often done for a group of team members or batches (in case of operations outsourcing). As evident, this kind of onsite travel is a very low key affair and does not impact much on the individual's profile since not much depends upon an individual's capabilities. However, the resources gain substantial knowledge in terms of exposure, experience and cultural diversity which can be very useful in future.

Traveling Onsite: Reasons (contd.): # 3

2009-07-22T17:07:00.000+05:30

Reason 3: Providing Consultancy

A reason of onsite travel which stands much higher in the value chain is providing consultancy. The seasoned Subject Matter Experts travel onsite for providing consultancy. The nature of consultancy and the impact on client's business are key drivers towards the kind of resource required and the duration of onsite stay. It may range from a specific project's topical area or may be a detailed recommendation fuelling a strategic decision.

Most of us feel onsite travellers as consultants (and most of those traveling onsite are indeed consultants in some way) however there are some big differences which need to be noticed.

Pure-play Consultants vs Service Delivery Consultants

If someone tells you 'how should you do something' or 'what will be impact of X on Y' from a strategic or long term perspective then it can be considerred as Pure Play consultant. However, if someone tells you 'how this thing can be done in this project' or 'what will be impact of this feature X on feature Y' then it is a consultancy provided during service delivery.

Pure-play consultants solve problems with global or larger impact; Service Delivery executives may provide topical consultancy with local impact.

Traveling Onsite: Reasons (contd.): # 2

2009-07-22T16:51:00.000+05:30

Reason 2: Establishing Long-term Relationships

Long term contracts once signed trigger the immediate travel of the middle level executives to the onsite location for establishing the relationship. The nature of such onsite visit is very different from winning new accounts (described earlier). Here the contract has already been signed, bringing in some certainty and confidence in vendor. However, the mid-level executive team is sent to setup the core team for a long term . Some of the key expectations from this core team's travel are:
1. Sufficient absorption of the client's technical environment, processes, and infrastructure.
2. Understanding the client organization's culture, environment and way or working.
3. Establishing communication channels within the client organization's segments.
4. Establish a positive sentiment among the (a bit nervous) staff of client organization due to recent offshore decision.
5. Chalk out the long term communication, collaborative work plans between the two business entities for a healthy business relationship.

Another key point of this kind of onsite travel is that it is non-project specific even though it may appear to be for a particular project. Such contracts are often done under a framework agreement between two companies, and under this umbrella framework agreement multiple project specific agreements are signed. For the first project the core team who travels has few members specific for the project in hand and some key resources for the higher level long term relationship establishment (as mentioned above).

Traveling Onsite: Reasons (contd.): # 1

2009-06-05T17:46:00.000+05:30

Reason 1: Winning New Accounts

Onsite travel for serving a prospect adds highest value in a person's professional profile.
A typical large outsourcing deal takes 3-9 months before it finalizes. Vendor selection is the most exhaustive task during this phase. Most organizations typically follow multi-level shortlisting process, starting from the vendor selection due-diligence, understanding vendor's capabilities, service offerings, past experience, costing, productivity, utilization, and the overall total cost of ownership. Once the probable vendors are shortlisted, the organization assign them a small project to evaluate their delivery. Such projects are called 'pilot projects'.
The vendor who shocases best performance in the pilot project wins the account. It is during these pilot projects, the vendor sends the skilled resources to the onsite location for showcasing the skills, understand requirements and more importantly build cotarie with the client organization.
Resources traveling onsite for such assignments are usually smart enough to understand the client requirements, power centers of the organization, assess the unquoted factors of the evaluation. These resources are often expected to take the spot decisions after aptly judging the situation. Vendor's chances of winning or losing the account directly depend upon these resources.

Selecting the resources for pilot project onsite visit:
Since the chances of winning the account depend upon the technical competency, delivery excellence and smartness of the onsite resource, due care must be taken in selecting the right resource for such purposes.

1. Resource's technical capabilities must exceed the project demands.
2. Besides technical skills, the soft skills play a larger role in winning the deals. Hence, the person must have great interpersonal skills.
3. Capability to judge the organization's way of working, its needs and actual requirements must exist in the person.
4. The person should be articulative enough to hide the vendor's weaknesses/ negative aspects. However, the capability to understand where to draw the line between ethical non-disclosure of vendor's weaknesses or honest confession must be made by this person. So high level of maturity is involved. (It is always prudent to take time and include opinion from vendor's senior management before giving important commitments).
5. Outsourcing decision is usually painful for the client organization's employees (due to fear of losing job). Hence, the person should be smart to obtain best utilization of client's current staff and gather all valuable details.
6. Person should be strong to handle extreme pressure, especially when the stakes are high; multiple vendors are involved and the evaluation is taking place centrally.

More to come on this...

Traveling Onsite: Reasons

2009-06-03T18:07:00.000+05:30

Being in outsourcing industry you get to travel a lot. People find it valuable to quote such travel experiences in their professional resume. There is a great 'demand' for skilled resources having international exposure- at least in India. Prospective employees with 'onsite experience' are valued more as compared to equally qualified people with no onsite exposure. This trend is more prominent in India.

I got several chances to travel various locations of US and Europe for serving client organizations. The most common reason for such travel is to gather knowledge, get training from onsite resources and then come back to your offshore location and carry out the work (and extend the training to other offshore resources). When I visited abroad for the first time, this was the very reason for my travel. However, over a period of time, I have seen more pervasive reasons for such onsite travels. These reasons are rarely known to most of the people and lesser understood by the recruiting agencies.

The reasons are (in their order of value addition):

1. Winning new accounts by showcasing skills to (still a prospective) client.
2. Establishing the building blocks of a long term outsourcing relationship.
3. Providing consultancy to clients
4. Knowledge gathering for new project (to be executed at offshore)
5. Visits under staff exchange program as a strategic step for long term relationships (between vendor and client).

Watch this space for interesting findings about the nature of onsite visit, and the recruitment perspective attached with them...

First Disconnenct-27 March 2007 to 2 June 2009

2009-06-02T18:13:00.000+05:30

On 28 March 2007 it was not thought of. Till 2 June 2009 it was seemingly unintentional disconnect. Today on 2 June 2009 it seems that the enlightenment has come. The Disconnect must fade away.

I am talking about the disconnect I imposed upon myself from the digital world by not blogging. Forgot password? Nope, I didn't. Shifted priorities? Somewhat, not exactly. Then what?
'The First Attempt' is the place where I tell you about whatever I attempt for the first time. However, during this period of disconnect, I slid myself into the cocoon just to explore my inner self. Exploring inner self by becoming a monk is common- several saints have done it, many more are doing it. I explored myself but did not disconnect from the outside world including friends & family.
Did you see the disconnect in my disconnect from the digital world and the outside world? Does that mean that the digital world is not the outside world for me? I don't know exactly, but digital world is the one which helps me to stay with myself more freely. Outside world imposes restrictions.

Enough about disconnect, lets us see what all I explored about myself and how I looked at the various facets of life, world, nature, business, people and economy et al.

Quantifying Scope Creep using Scope Creep Index

2007-03-27T20:02:00.000+05:30

Background

Over a period of time the software industry evolved its ways of managing software development projects with increased maturity by devising, and adopting the methodologies and recommendations of various best practices mentioned in process standards like CMM/CMMi, ISO 2000:9001, TickIT, Spice and BS standards. The organizations adopted these practices in order to manage the projects in a mature way and gain competitive advantage while doing pre-sales. However, the software engineers found it hard to complete the plethora of documentation imposed upon them with these methodologies in addition to their prime deliverable—working software code. The main problem in adopting to these documentation practices was the need to update the documents and records timely with each change request consistently.
The industry found a solution to this problem with “Agile Manifesto”. Agile Methodology was developed with the philosophy to develop software with the least amount of documentation (doing only the ‘needed’ amount of documentation) and accommodating ‘change requests’ with open-arms. This philosophy was found to be fruitful and is actually very effective in getting the working ‘production ready’ software. The Agile practitioners appreciate this ‘sex appeal’ of accepting and doing changes as and when proposed with least documentation. However, in doing so the ‘intellect’ of managing the change implied in Agile Manifesto is lost somewhere. This leads to project delays and failures at times.

The followers of traditional SDLC who try Agile Methodology with a great understanding of the ‘sex appeal’ and less thought about its implied ‘intellect’ reject Agile Manifesto with the claims of project delays.

Managing Scope Change

I have burnt my hands a couple of times with the Scope Creep – the name given to the phenomenon of frequent scope changes – leading to some of the project delays.

With a deeper understanding of the situation, I have tried to device a way to manage scope changes in a better way by using Scope Creep Index.

There is no standard term prevailing in the industry with the name of Scope Creep index. Neither I could find any practised way of monitoring Scope Creep quantitatively in various resources on the internet. I therefore coin the term of Scope Creep Index for my own use and for the benefits of the interested readers.

Scope Control Vs Scope Monitoring

Working in the offshore software development project for the requirement specified by the client involves two different aspects of Scope: “Controlling” and “Monitoring”.
Sitting at the offshore location working as a contractor for client’s project and performing as per the scope indicated by the client, we can only “Monitor” the scope changes. “Scope Control” can be done by the client only. We as a contractor can (and should) provide an indication of a scope change by ‘monitoring’ it quantitatively, so that the client can ‘control’ it at her end.
This is the basic premise with which I planned to device the Scope Creep Index.

Factors included for Scope Creep Index

As per my observation of the past few projects, the following factors affect the scope creep: 1. Baseline Deliverables, 2. Supplementary Work Items, 3. Scope Impact (& its weight), 4. Phase of Change Inception, 5. Estimated Effort, and 6. Additional Effort.

1. Baseline Deliverables: The agreed upon deliverables listed down in the initial Work Breakdown Structure at the start of project. The baseline deliverables indicate the initial scope of work.

2. Supplementary Work Items: The additional work item that may be requested as an associated deliverable along with an existing Baseline Deliverable OR and additional Work Item requested to be delivered over and above the Baseline Deliverable. The weight of the Supplementary Work Item can be actually the weight assigned to the Phase of Inception.

3. Scope Impact (SI): The Impact of the requested Scope Change can be classified in any form. I have used the plain and simple ‘Low-Medium-High’ classification. Each classified Scope Impact value can be assigned a weight to it. Ex: Low=0.3, Medium=0.6, High=0.9.

4. Phase of Change Inception: We follow Agile Scrum approach wherein we divide the project work in multiple ‘Sprints’. Each ‘Sprint’ is then divided into multiple Sprint Phases. We use ‘Design-Code-Test’ phases in each sprint. The sprint phase in which the scope change request is raised, affects the difficulty of accommodating that change within that sprint with an increasing trend. Therefore, it made sense for me to assign weight to each sprint phase for evaluating its impact on project schedule. It is easy to accommodate change during Design phase while the change requests coming during Test phase are quiet hard to accommodate. Therefore, I assigned Design=0.1, Code=0.4 and Test=0.8 weights.

5. Estimated Effort (EE): The effort required to develop each Baseline Deliverable Work Item in person hours.
6. Additional Effort (AE): The effort required to develop each Supplementary Work Item in person hours.

Scope Creep Index: Calculations
Supplementary Work Item Weight (WT) = Weight of Phase of Inception.

Scope Creep Index =
Additional Effort (AE) / Estimated Effort (EE) * (Supplementary Work Item Weight (WT) + Scope Impact weight (SI))

Assumptions: In case of a completely new work item being gives as a Supplementary Work Item, the Estimated Effort would not be available. This would make the Scope Creep Index calculation impossible. Therefore, I assign Scope Creep Index a value of 100 for such mutually exclusive Supplementary Work Items. This is a hard-coding for a special case in this formula.

Accommodating Change Vs Spill Over

The decision to accommodate change within the sprint or to take it as a spill over for next sprint can be made by assigning a threshold limit for the Scope Creep Index. For example, we have decided to accommodate the changes within the sprint if the Scope Creep Index value is less than or equal to 0.35. If the Scope Creep Index exceeds the value of 0.35 we consider it as a spill over for the next sprint.

Project Managers at the client side can benefit greatly by using this simple metrics since it raises the flag as soon as the change request is made. Also, it helps in evaluating the time/phase/state of the project during which change requests are raised. Proactive decisions can be made based upon this metrics easily.

Since it is a completely indegenious way, I welcome all sorts of comments/criticisms/feedbacks/enhancements/inputs/recommendations from everyone who is reading this.

A New Feather: Harsh Vardhan PMP

2007-03-06T10:56:00.000+05:30

Well, as usual after spending around an year of post-MBA boredom, I have succeeded in breaking the pattern. Yet again!

Harsh Vardhan, PMP is the new title I have acquired now.
Well not discounting the MBA, I would prefer to be called Harsh Vardhan, MBA PMP now onwards.

Sounds like too much of whistle blowing, but it is required.

Now a new set of qualifications, new set of revised aspirations and a new job hunt. This is the saddest part. I always wanted to start on my own, but Personal family commitments have reduced my risk taking abilities. Few more years of working for others! phew.
:-)

Structural Unemployment in Indian IT Industry!

2006-12-19T00:20:00.000+05:30

"The global software service industry is fast asleep and no action is taking place. The business stakeholders, private equity funds, angel investors and other stakeholders need the dose of basic education. And the task force needs to break the pattern!"

No. These are not the excerpts from the writings of an eccentric maniac under the influence of dope!

This is the ultimate conclusion I have arrived at after the 3 months emotionally destructive undocumented analysis I have done about the present state of global software service industry.

How come?? Read on!

Uh.. the basic problem which initiated this was the Structural Unemployment.
Starting my career with the basic engineering degree with a dash of quality certification something any student would have dreamt of. I was placed and well placed even before any other student of my class was the best thing that I could have dreamt of. Clock hands kept on rotating and I spent 3 years in the Software Service industry. Adding the cherry of management degree on my software career pudding was the next logical step. So far so good.. I tried the IIMs and didn't get through. Never lost patience and thought not to break the smooth sailing career in order to join a B-rated B school, I opted for Part time MBA along with the job. Well, sounds logical so far. Clock hands didn't break the rotation and I spent another 3 years studying the management concepts. Dream was to redo 'all' the things at the work place after the daunting 'unlearning' I did in the management program. Plan was to do everything from a fresh perspective like an alphabet on a clean slate uncluttered with rotten theories and obsolete concepts.

Today, I stand at the cross roads struggling to find a suitable position in the Software Service industry worldwide which 'expects' management degree. The irony started when I observed that the software service sector can only think of Business Development as the role to be assigned to a Techno-Manager.

Oops.. I am being cynical? Not yet. Because I am yet to find a Job Description which quotes MBA as an essential qualification in the sector? From supervisory positions to Project Managers, Program Managers and beyond the only qualification which I come across is Engineering with past management experience. If you see the Organizational hierarchy of any company, the next obvious promotion of a Supervisory position is a Managerial position! And where does the qualified manager position go? God damn only in Sales and Business Development.

The real need is to stitch the management positions with management qualifications. That is the reason why more and more engineers are unsatisfied with their managers because they observe the lack of basic management skills. Organizations worldwide have failed to find the root cause of the scarcity of a smart manager. Recruiters are looking for PMP certified managers but they are-- believe me-- really expensive. Small and mid sized organizations cannot afford to have a PMP certified manager in a basic Project Management position. And the collective employee count in the small and mid sized organizations is way more than the employees working in large organizations in this sector. Hence the growing dissatisfaction, employee turnover, and mis-management. Then organizations try to correct these problems partly by investing heavily on soft skills, time management, communication skills, presentation and other soft skills. All this money which is going down the drain in recruitment (due to employee turnover), training and external consultancy can be saved by recruiting the Managers with a Management qualification (read MBA).

The time has come to stop this Structural Unemployment and misfit recruitment. It is high time that the business stakeholders start questioning the credibility of management position holders in the organizations. Also, I think it is prudent on an employee's part to question the management qualification of his/her manager.

So what can be done to kill this structural unemployment?

Answer: Find the Techno-Managers for all the cross-functional positions of Project Managers, Program Managers, Practice Heads, Product Managers. Avoid the Manager-by-line promotions and prefer the Manager-by-Ability promotions. Encourage supervisory staff to attend the long-term comprehensive management courses instead of unstructured topical trainings in soft skills, communication, time management etc.

Surveys-Out: Games-In

2006-12-12T19:25:00.000+05:30

While going thru the latest updates of the recent Bar Camp held in Noida, I came across an interesting company Uzanto. The sheer curiosity of an interesting name pulled me to their website www.uzanto.com. I had never thought that what I am going to see will leave a strong impact on the Market Research subject I have studied in my management degree.

I like doing primary analysis and data collection. But the old mundane way (copy 'old mundane way') of collecting data can be so interesting and so very Web 2.0 compliant :-)

Uzanto ('user' in esperanto) provides a service of doing User behavior and data collection to aid in the Systems Designing. It can suggest UI Design Patterns by doing cognitive methodologies. Look at the url www.themindcanvas.com. I am impressed by the Mind Canvas software (service essentially) which captures the User-System interaction analysis by using simple games (specially designed for each customer). Look at the demos and the analysis they provide.

Toast to Rashmi Sinha the founder of Uzanto for such a fruitful methodology & tool.

Client Experience Management in Software Service Relationships

2006-09-26T18:21:00.000+05:30

Client Experience Management in Software Service Relationships
~ Harsh Vardhan

Till few years ago the primary market for Indian software companies was United States of America. Now organizations are diversifying to the relatively untouched soils of Australia, Europe (primarily Belgium, France, Germany and The Netherlands) and East Asia (Japan, China, Singapore, and The Philippines). The diversification of client engagements, nevertheless, adds color to one’s experience and work portfolio, but the challenges of meeting and exceeding client expectations in international contracts are probably a reason for nightmares for the Delivery Heads. A need to have an organized client experience management system in place has evolved, so as to maintain and improve the extent of Indian leadership in the Software outsourcing market.

Software Contracts

Software Service engagements are largely governed by Contracts. Contracts define the scope of work, the team headcount, time required and most importantly the process to be adopted for project development and implementation. Another important aspect of contract is the accountability of the defects and non-conformances. Consider an example, “ABC Inc. is into developing software products. It outsources a part of the software product development to another organization XYZ Ltd. XYZ delivers the deliverables on time to ABC. ABC checks and bundles the delivered piece of software to its product suite. However, when ABC releases the suite in the market, the end-users report bugs in the part, which was worked on by XYZ. In the mean time, the contract between XYZ and ABC has expired, or no longer holds. In this case the accountability of the bugs lies entirely in the hands of ABC for no fault of theirs. Such annoying situations discourage the conservative countries (most of the European region) to outsource their software jobs to India. Such instances can be averted and confidence of the European region can be gained by managing the client experience in a better way.

Managing the Client Experience

Client Experience can be managed only after thoroughly understanding client expectations. To outsource a job to a low cost country is not necessarily an indication that the client needs a low cost solution to benefit from the potential savings owing to the cost differential. What the client actually values may sometimes be drastically different from what is perceived to be of value to the client.
For example, while the software service provider may perceive that client values cost benefits; the client might be in a hurry to put the systems in place to meet a deadline without any regard to the cost incurred in achieving that. In this scenario, providing a low cost pricing for a software service delivered at a normal pace may be of little value to the client. What the service provider is expected to do is to provide a faster service by adopting a time saving process, may be at an additional cost.

Coming out of Process Paralysis

Another aspect of client experience management is the dynamic nature of expectations in long-term engagements. A software service provider might have acquired a long-term contract on the basis of, say, SEI CMM Level 5 competence. However, providing CMM level 5 compliant solutions all the time may not be the right thing to do. For a particular phase to be completed as part of an ongoing long-term relationship in less-than-normal time, the service provider should have the ability to adopt a faster process like Agile Methodology.

This leads us to another syndrome very often seen in the Indian software Industry, which I call process paralysis. Indian Software companies are rushing towards CMM compliant processes, ISO certifications, Six Sigma methodologies and many other process management initiatives. While these competence initiatives help to a great extent in adding credibility and convincing the prospects about a better and consistent level of service quality; the irony of the industry is that most client engagements are driven by client-driven processes. Therefore, the service provider, even though being at CMM Level 5, may be asked by the client to follow its own internal project development processes.

In that scenario, the employees become blind followers of the client’s processes. The prevailing perception among employees, including their project managers, is that “in order to gain client confidence and achieve desired service value deliverance, conformance of client processes is the best thing to do.” This is not always true!

I have myself experienced this process paralysis while working for one of the CMM Level 5 Indian software majors. Our client then was a major travel solution provider in the USA seeking some software testing services. We were bound to follow the client’s processes as per the terms of contract. However, while providing the testing services, the Configuration Management tool was at client’s network and we had to send all the artifacts as fresh emails for uploads to that tool as we were not given sufficient access privileges for data secrecy reasons. As the project progressed, what resulted was a heap of similar documents having similar content without having a version control in place. We decided to develop a Traceability matrix for all the artifacts. It was a seemingly impossible task at the face of it. The unanimous solution, which came to our sight, was to compile all the documents and give a fresh revision number to them and upload in a systematic manner in our own Configuration Management tool and share that database to the client. It took us 5 days to bring everything in place.

The learning in the case: Had we been proactive enough to convince the client to have a strict version control at our end in place, the scenario would never have occurred. At times, going out of contract norms is a way to provide more value to the client.

Please employees to please clients

Managing employee value in order to manage client value is the key to successful software contract engagements. It has been proven that most client defections are due to unsatisfied employees sitting at the client touch points.

An employee who is unsatisfied with his/her job or employer cannot completely fulfill client needs. Therefore, in order to minimize contract breakups and client defections, the company needs to show same value towards its employees, which it would like to be shown towards its clients. Employees are the only source available in the hands of the organization to reverberate the magnitude of client value wavelength.

Converting intangibles into tangibles

Conclusively, the client engagement experience can be made a joyride by implementing some small, but valuable organizational initiatives. The management might be very keen on delighting a client, but the client can only experience this when they can visibly see and feel the value, in some kind of a tangible form. The need is to convert this intangible intent into tangible initiatives. Following is a list of few steps, which can be taken and communicated to the client in order to gain goodwill.

Declare that a discount of say $5 will be provided in the billing of the Software Engineer who is responsible for a Severity 1 bug in milestone build.
“Clients invoice will reflect the discount of say $20 per hour delay in delivery of the deliverables.”
Project Managers feel loss of control when they outsource a task to a different service provider. Creating a project status extranet portal and showing the project status on that portal can attain his/her confidence. Client may be provided with a username/password to access only those parts of the portal, which talk about his/her project. Entire team’s timesheets, daily work done, work in progress, leave requests of all the associated resources can be shown there. Additionally, Organizational Holiday list can also be displayed on that portal so that the client can plan out accordingly and timely.
In addition to that, consider how elated would the client feel if she finds a Birthday/Anniversary wish flashing up on your portal’s dashboard!
Variable pricing by having a lower fixed price and a variable component depending upon the value provided to the client certainly helps in long-term relationships. Example: Fixed: $ 8 per hour per person + variable; Variable: $0 to $20 per hour per person, depending upon the value which client receives from the delivery. Let the client decide the variable component for the period. Trust them and earn goodwill.

Author: Harsh Vardhan

The First Attempt

2006-09-18T10:30:00.000+05:30

Harsh Vardhan - the name people recognize me with!

A sunny September 18, 2006 morning in India, just in the office at 9:48AM. The way to office was sunny, boring with mad traffic and blank faces aimlessly zipping thru. I thought of starting the day with a difference... "Hey.. how about jump-starting with my own blog-- the first one to be for that matter?" Oh yeah, I was uninitiated on this front till now.

Before I start scribbling the 5 Ws of me, lemme see the template and preview.

:-) Harsh

======================================
Ok, So the preview looks good.
At least for the novice like me:-)
Well now I don't want to beat my own trumpet but just for the heck of it lemme introduce myself to you.
A child for some, a dude for many and a male for all. Personality: Type B. (Intuitive Introvert Feeling and Perceptive... though the Introvert part is fading away now I believe. What is INFP? check this out: http://www.personalitypage.com/INFP.html). I don't believe in micro-management. Cultivating Self-Orientation is my philosophy.
Started my career in 2000 --just before the dot com bust-- into the field of Quality Assurance for Software industry. Switched some jobs in the same field. Shifted the gears to the management program which I got myself enrolled in after about two years of working. I am grinning ear to ear while typing that I am graduating this year. Looks like the industry won't be same now onwards. :-)

I like reading and thinking. Alternative Rock (seemingly a disconnect between thinking and rock ) yeah.. thats there coz I am a Saggi by sun sign. Roaming, experiencing new things, risk taking, and a complete foodie. I prefer eating anything except reptiles. (... eeek.) (so you can feel my discomfort when u invite me for dinner and show me the menu card for placing the order. "Oh my! I can have any/all..so you decide babe."

Food reminds me .. its lunch time now... so lemme grab something... till then do see the INFP link.

cya
Harsh
20 Sept 2006