Sunday, October 17, 2010

Distributed Agile in Outsourced Product Development - 10 Critical Success Factors

On 23rd October, I am speaking at 'agile tour 2010, Pune'.   India Scrum Enthusiasts Community is organizing this event.     This is a forum for software engineers at all levels - from programmers to professionals at very senior levels.    My presentation is going to be on our experience related to implementing Distributed Agile practices in Outsourced Product Development at MindTree.

On 20th November, at Agile Tour 2010, Bangalore, I am going to speak on Distributed Agile and this session is based on my white paper published last year at International Conference on Software Engineering, CONSEG-09. 

Sunday, September 26, 2010

Outsourced Product Engineering: Tip of the Iceberg

Outsourced Product Development (OPD) has become an integral part of Software Product Engineering for more than a decade. OPD business has high potential as well as challenges. The idiom ‘tip of the iceberg’ applies to OPD in two contexts – at a macro or industry level, in business context, and at the micro or product level, in engineering context.

At industry level we have seen little more than the tip of the iceberg and we do have a lot more to see.

Every engagement in OPD offers services for multiple products. At every product level we have seen just the tip of the iceberg. Understanding the rest of it is very mandatory!

More on this at:

Sunday, May 16, 2010

SaaS - Disruptive but Positive !

My interview on this topic appeared on CIOL last week.  The full version  is available at

Disruptive means "Break through traditional teachings to truth and the word of life".  Disrupt(verb) means 'to interrupt the normal course' or 'to through into disorder'. (courtesy: )

Service Oriented Architecture (SOA) and Software as a Service (SAAS) are disruptive.   In general, end users use only 20% of the features of any software product 80% of the time.  And in how many instances have we used 100% of the features?  The answer is an obvious one.  But the fact is that we pay for the entire product.  Annual support and maintenance overheads prevail throughout the lifecycle!  This trend required some disruption !   SOA and SaaS came in to disrupt.

SOA and SaaS have emerged strongly to promote 'Pay-Per-Use' model.   Almost all product companies do have strong focus on releasing new versions of their products that support such paradigms. In order to leverage the benefits of these technologies the volume of hosted software licenses and related business models in the IT landscape will increase. This will benefit several small and medium business.   They will be able to avail niche products by means of transaction based license fee or similar models. This is a disruptive but positive trend.

This trend in disruption extended to infrastructure provisioning as well.  Now, businesses can purchase 'on-demand' infrastructure for a limited period of use and thus can save loads of costs involved in hardware and software procurement.  'On-demand provisioning' is an application of Cloud Computing.   An anology for this is the hotel industry that provides for booking a desired room configuration for a limited period and attracts customers with several offerings with discounts.    As one may think, 'Cloud' is not just a retirement home for 'end-of-life' 'non-ctirical' applications and data!

We could not have thought about SaaS two decades ago!  It has emerged over the past 5 years or so.   Is n't SaaS an impressive disruption?

Saturday, May 15, 2010

Software Architects – An Evolving Breed of Software Professionals!

Software Architecture is considered to be one of the overused terminologies in our industry. Typically, any contemporary software project team, depending on its size, consists of a team of one or more architects that is responsible for providing a sound architecture for the proposed software system. Contemporary projects that involve cross-functional solutions based on multiple technologies, platforms and user groups require a dedicated team of architects in addition to a typical design team as compared to traditional projects. The characteristics of software architects and their role have evolved over a period of time.

Traditional waterfall approach comprises of Requirement Analysis, Design, Construction (Coding, Unit Testing), Documentation, and System Testing and this provides for an intensive design activity during the design phase. The term ‘Software Architecture’, though originated long ago, is being focused upon in the industry during the last couple of decades and this coincides with the evolution of new technologies (such as Web Technologies) and evolutionary methodologies (such as Rational Unified Process and Agile Software Development) in IT industry.

Architecture is a software engineering activity in software projects and a civil engineering activity in civil engineering projects. The myth about the term ‘Architect’ in both Software Engineering and Civil Engineering is that an architect is an individual who brings just a good amount of technical experience in the respective engineering discipline. Though this is the fundamental requirement, an architect needs more than the technical skills specific to the project he has been hired for. The definition of ‘Software Architecture’ would help us identify the desired characteristics of ‘Software Architects’ – the not-so-new but evolving breed of software professionals.

Software Architecture has been defined by various organizations and professionals and a definition that consolidates many such definitions is

“Software Architecture is based on strong architectural principles and guidelines. It provides the blue print of the proposed software system and such a blue print consists of all necessary views of the software system, its components, their interaction and addresses the requirements (both functional and non-functional). Besides, it exploits the available technology with a clear strategy in order to reduce the impact on existing systems in an enterprise, stands cost-effective and delights the stake holders.”
Thus, it is not enough if software architecture addresses the functional and non-functional requirements. The architecture itself has to be based on strong principles, guidelines and it must address the long-term requirements related to the structure of the software itself. The long-term requirements related to the structure of the software are derivable from the best case requirements, long-term focus of the IT organization, reuse considerations, technology preference, proposed budget, wish-lists and other up-coming technologies that could benefit the organization.

This makes it clear that all user requirements mapped into an excellent set of use cases is just one of the inputs to the architect to produce a sound architecture. An architect need not wait until all detailed requirements are documented and use cases are identified. The architect can start his activity with initial requirements, high-level use cases, based on a set of organizational standard (or project specific) architecture goals, principles (typically a set of Dos and Don’ts) and guidelines, keeping in mind the clear picture of the customer’s IT infrastructure, mission and vision. Unless the architecture is aligned to customer’s IT infrastructure, mission and vision, it would prove itself to be fruitless and evolve as a major risk for the project as well as the IT organization as a whole.

A software project, depending on its size, may require a team of one or more architects to accomplish this vital task of identifying, consolidating, documenting, reviewing, finalizing and maintaining the architecture of the software system through out the project’s lifecycle. Such a requirement essentially focuses on a professional who is not only broadly technical but also very good at soft skills especially in the areas of business communication, conflict resolution, self-expression, emotional intelligence, and team skills. Often, a highly respected technical professional in an organization fails to be a good architect because of his lack of soft skills in getting things done on time with a team of professionals. When a team of technical architects meets the project team to propose an architecture there could be conflicting issues and interests among the architecture team as well as the project management team as a whole. It is the architect who needs to posses strong skills in putting his architecture across by means of presentations or discussions. He has to be open-minded to encourage, understand and appreciate the suggestions or conflicting opinions. Meanwhile, he must be time-bound and decisive to make his team as well as his stakeholders understand the rational behind the proposed or renewed architecture. And he must carry the right level of self-esteem and feel proud of the final decision and exhibit ownership throughout the product life cycle.

In summary, software architects need to be experienced in various areas including core technologies, peripheral technologies, application development & implementation and variety of soft skills. Software architects need to hone their skills and build knowledge to research and understand emerging technologies, technology trends, client’s IT infrastructure, mission and vision. Finally, they need to have necessary expertise in identifying and using necessary software processes, tools and techniques to architect the software system, document the architecture with required granularity (with APIs and code samples), communicate it to the project team and be a mentor for the team to implement the system. With these qualities, this new breed of software professionals can definitely be identified and admired as visionaries for the software project and team they are working with!


  1. A framework for information systems architecture – J.A.Zachman, IBM Systems Journal, Vol26, NO 3, 1987
  2.  Extending and formalizing the framework for information systems architecture – J.F.Sowa, J.A.Zachman
  3.  Architectural Blueprints – The “4+1” View Model of Software Architecture – Phillippe Kruchten, Rational Software Corp., 1995
  4.  The Role of the Architect – Dana Bredemeyer and Ruth Malan, Bredemeyer Consulting
  5.  Design Patterns – Elements of Reusable Object-Oriented Software – Eric Gamma, Richard Helm, Ralph Johnson, John Vlissides
  6.  Software Architecture: a Roadmap – David Garlan, School of Computer Science, Carnegie Mellon University
  7.  Functional Requirements and Use Cases – Ruth Malan and Dana Bredemeyer, Bredemeyer Consulting
  8.  How Do You Define Software Architecture? (

Saturday, March 6, 2010

Attaining Code Quality Excellence !

Software quality has two primary dimensions: Internal Quality and External Quality. External Quality is an attribute that relates the end-user experience. External Quality can be assessed and improved through defect prevention as well as black box testing.

Internal Quality is visible to various groups in the development team such as designers, developers, maintainers and technical reviewers. Internal Quality is invisible to the end-users. Internal Quality can be improved by means of defect prevention as well as defect detection followed by analysis and correction or defect fixing. Software inspection and reviews are the means to assess, control and assure Internal Quality. Although software inspection and reviews have operational differences, both are aligned towards the objective of examining work products to unearth defects.

Great focus on black box testing by means of well-documented test cases, multiple rounds of rigorous testing, defect fixing and defect verification is mandatory for successful deliveries. However, lack of focus on Internal Quality could pose serious consequences in the form of unexpected naive defects, technical issues and maintenance nightmares. Poor Internal Quality encompasses the root causes for issues related to External Quality. Thus, in order to improve Software Quality, Internal Quality must be improved.

I could identify seven critical milestones that are necessary to attain Code Quality Excellence through experiential learning and a list of five best practices that were useful in ensuring good coding practices and assurance of Internal Quality.    My second paper on Code Quality ("Critical Milestones and Best Practices for Code Quality Excellence") provides a comprehensive coverage of these milestones and best practices.

As I wrote in my previous blog, Code Quality continues to be an unfading focus area in Software Engineering!   Any thoughts?

On Code Quality

Code Quality has been an unfading focus area in Software Engineering.  Software inspection and reviews have been in practice in the industry for over three decades.  Reviews uncover errors while they are relatively inexpensive to find and correct.

In any project, code reviews need to provide a complete coverage of the entire code base for better results. Code reviews need to focus on adherence to various factors such as

a) Content Quality:   Adherence to requirements, architecture, design, coding standards, programming principles and coding style
b) Format Quality:   Readability in terms of adequate internal comments, indentation, structure
c) Business Quality:   Alignment with business goals in terms of extensibility, maintainability, and so on.

Implementing rigorous reviews has always been a challenge in the industry due to time-to-market and budget constraints.

Roger S Pressman uses the term ‘Formal Technical Reviews’ (FTR) to denote work product inspections, reviews and walk-throughs. The motivation of all kinds of FTRs are the same – ‘ To have a work product examined by an external group of professionals so that they can unearth as many defects as possible at early stages of software life cycle.’

One of the great breakthroughs in software engineering was Gerald Weinberg’s concept of egoless programming – the idea that no matter how smart a programmer is reviews will be beneficial. Reviews and Inspections are considered to be one of the 10 best influences on Software Engineering. Defect prevention at early stages is invaluable as it enhances software quality. Code review automation saves human intervention in detecting issues related to the static nature of the code. Defect prevention and code review automation make manual reviews more effective. Refactoring is a valuable practice to improve code quality to improve the design.

Systematic Focus on Code Quality(SFCQ) is a technique to improve Code Quality and Design. It is technology independent. Besides, it is suitable for projects that follow either waterfall or iterative life cycles.

It ensures
• Improvement in code quality & hence customer satisfaction
• Constructive feedbacks and improvements in software design
• Enhanced maintainability
• Professional development in design and coding skills
• Improvement in team morale & esteem

The guiding principles of this technique are
• Increasing developers’ accountability in producing good quality code
• Improving productivity by deploying tools for code reviews
• Leveraging expertise in manual reviews to improve code quality
• Refactoring instead of reworking to make the development process more challenging

I presented my first paper on this subject during 2004.  (Raja Bavani, Systematic Focus on Code Quality: A Technique to improve Design and Implementation, 5th Annual International Software Testing Conference in India 2005).  Several practitioners have tried this approach and found positive results.  Just thought of sharing this on this blog!

Tuesday, January 5, 2010

Reusability and Usability

Reusability is no longer an uncommon buzzword in Software Engineering.

Several months ago one of my team members had identified a reusable component from his code and wanted to release it to his colleagues. When he approached me with his idea, I asked him ’Have you used this component in different contexts and found it reusable?'. He responded with a firm 'Yes'. I ticked the first checklist item to qualify his component as 'reusable'. There started his uphill task of publishing it and getting acceptance from our local community of Software Engineers. He stretched himself to make it happen. That was indeed an uphill task!

Last week I was in a meeting with my engineers where all of us delved into a discussion on reusable components. Our conversation emerged with a flavor of belief that the reuse of concepts, designs and templates are easy to implement and it is very hard to develop and release reusable components that other developers can use to avoid reinventing the wheel. Our conversation openly claimed that developers do not like to use a component developed by others and would rather develop their own.

Eventually, after several minutes of debate we settled together with the fact that developers do utilize reusable components. Reusability does exist in many forms including component reuse. Typical examples of reusable components are Apache's FOP or Log4j in J2EE world – to name a few.

This makes it evident that if we want our components to be reused, we have to look into the usability aspects while designing, coding, testing, maintaining and releasing reusable components. Usability plays a critical role in creating usable systems. To create usable systems, we need to consider human abilities and limitations, learn about the needs of end users and involve them while designing such components.

How do we do this when we create reusable components? The answer, though not very simple, is two-fold. First the creator needs to understand the end-users, their needs and think like the end-users throughout the design process. Next, the creator needs to test the reusability of any component among peer groups or projects and enhance it so that it becomes reusable among a wide spectrum of users. For frequent reuse the creator may have to provide the following artifacts in addition to the source code.

1. Feature list
2. Tips/Instructions on usage
3. Sample code on how to plug-n-play
4. Contact info (Email/Phone) for help

Interestingly, usability evolves with the evolution of user experience on what is available and user expectation. The more our users understand and relate well to the systems they use, the better and faster they are in liking or disliking the systems we provide. Progressively, end users become more and more aware and demanding too. Unfortunately, the more and more we, the software professionals get detached from users and usability, we become responsible for designing and delivering systems that fail to meet usability expectations.

Clearly, it is not enough if we understand just the business requirements and technology to deliver software. The more we understand our users as well as the importance of usability, the greater our results will be in delivering usable systems. To conclude, if ‘Know Thyself’ is the mantra for happy living, ‘Know Your Users’ is the mantra for delivering successful systems.

Software Engineers do spot reusable components in the code they produce. Couple of days ago a young engineer in my team identified a reusable component from his code and wanted to release it to his colleagues. He approached me with his idea.

I asked ’Have you used this component in different contexts and found it reusable?'

He responded with a firm 'Yes' and agreed to take up the uphill task! He needs to make it usable. Am sure he will succeed.

Naturally, usable reusable components become reusable, live long and evolve!

Related Article: 

      Reusability, Usability and Flexibility


Monday, January 4, 2010

Requirements Engineering = Elicitation + Analysis and Negotiation + Specification or Documentation + Validation !

Yes! Requirements Engineering is composed of four key activities – Requirements Elicitation, Requirements Analysis and Negotiation, Requirements Specification or Documentation and Requirements Validation.

Requirement Elicitation is to discover system requirements through consultation with stakeholders. Some of the sources of this discovery could be system documents, domain knowledge and market studies. Requirement Analysis and Negotiation is to analyze requirements in details and negotiate them with stakeholders on which requirements are to be considered. Requirement Specification or Documentation is to document agreed requirements at a certain level of detail. Requirement Validation is to review or validate requirements for clarity, consistency and completeness.

This is an attempt to address a set of key areas where things can go wrong during Requirements Engineering.

Who Plays the Role? Sometimes, project teams go by the assumption that every skilled programmer is also proficient at interviewing customers and writing requirements specifications. This is a risky assumption. This may not yield good results in all cases.

Training alone would not suffice: Requirement Analysts are grown – not just trained! A good training in various areas related to requirement analysis is mandatory but not sufficient. This includes training sessions on business, software engineering as well as soft skills. A requirement analyst needs to be aware of the business domain, technology aspects as well as user expectation management. Soft skills such as effective listening, negotiating and facilitating, help analysts uncover users’ unspoken desires. Thus, training alone would not suffice. Adequate mentoring and coaching is required to groom Requirement Analysts. Requirement Analysts grow to higher levels based on their work experience in performing their role effectively – a good training is just a starting point.

Focus on Soft Skills: Most of the times, due to factors such as information over flow, analysts focus more on business requirements itself and lose focus on their soft skills. Soft skills such as listening, interviewing and questioning, analytical reasoning, facilitation, observation, writing, organizing, modeling, interpersonal intelligence, collaboration and creativity are to be consistently honed to conduct requirement analysis effectively.

Planning: Requirement Analysis needs thorough planning. Typical deliverables need to include traceable requirements, open issues, open queries - in addition to other artifacts. Formal reviews need to be planned to ensure quality before design. Often analysts rely on a series of meetings to perform Requirement Analysis. This is not sufficient. Various techniques such as user interviews, demonstrations, walk-through of live data and processes, etc., are to be considered while planning.

Inadequate Elicitation: Inadequate or elicitation will result in poor specification. Requirement elicitation consists of fact-finding, information gathering and integration. Identification of various sources of requirements (such as end users, interfacing systems), gathering requirements and integrating them is key to the success of Requirement Analysis. Inadequate Elicitation could be the result of factors such as ineffective meetings, not asking relevant or revealing questions, not scooping, not modeling, not prioritizing etc. Some of such key factors have been explained below.

Ineffective Meetings: Effective meetings ensure progress. Requirement Analyst needs to plan effective meetings with a manageable list in the agenda and ensure that all action items are followed-up and closed.

Not Asking! Many experts provide the tip – ‘Communicate, Communicate & Communicate’ to ensure project success. Requirement Analysis (as well as any other phase in a project) can go wrong when the team members (more specifically the Requirement Analyst) do not ask questions. Thus the tip for successful analysis is ‘Ask, Ask, Ask’ – specifically, ask revealing and relevant questions. Asking good questions to explore and understand detailed requirements provide the base for thorough testing. Both the type and timing of questions are very important. Questions related to requirement originating during Integration Testing are not uncommon in projects. It is good to identify, ask and resolve queries during early stages of the project. The book ‘Exploring Requirements: Quality Before Design’, Dorset House, 1989 by Donald Gause and Gerald Weinberg is worth reading to understand this aspect.

What, How and When? Sounds simple to follow – but this is forgotten at times. Analysts capture ‘What is required’ – but they forget ‘How’ and ‘When’! Here is an example. The business users want an email notification facility that sends an email notification whenever a user is registered into the system. The analyst captures the ‘What’ factor which goes in to the FS document ‘A email has to be sent whenever a user is registered into the system’. During acceptance testing, the user elaborates on the ‘How’ factor and says - ‘…the system should detect the delivery status of such emails and resend the mail until it is delivered successfully. The email message should contain few dynamic links as well as a logo. The users should have an option of not receiving such emails’ and stresses that he wanted the email functionality to work this way in the initial delivery itself. This is reported as a critical issue and the project team works late nights to provide this functionality. In this example, initially the analyst should have given adequate stress on the ‘How’ and ‘When’ factors that help him focus on elaborating the requirement. This happens when the analysts focus on ‘elicitation’.

Not Modeling! Modeling is done across industries and disciplines. Requirements need to be modeled using appropriate techniques and tools. A textual description may not be adequate in all instances. Use Modeling. Use examples, illustrations and substantiate them with good data.

What is the Scope? Things can definitely go wrong when the analyst gathers exhaustive requirements but fails to qualify if all of them fall under the scope of the project. This could lead to misunderstanding, overruns and poor quality. Requirement Management: Requirement Analysis as a project phase need to end with a set of baselined requirements. Still, Requirement Management activity progresses until acceptance of the end product. Loosing focus on Requirement Management may lead to conflicts and poor quality.

Communication Gap: Requirement Analyst acts as a bridge between the end-users and the project team. The objective is to transform user requirements in to system requirement specifications and ensure good quality of traceable requirements so that end-users get what they wanted. Any communication gap in this area could result in customer dissatisfaction.

Not Prioritizing! Not prioritizing requirements is a potential risk, as the project team has no means to handle design, implementation and testing issues. Prioritization cannot be overruled in any project.

Missing out Non-Functional Requirements: A project cannot succeed with high-quality functional requirements alone. Non-functional requirements play crucial role in planning design, coding and testing activities. Non-functional requirements fall in to categories such as Reliability, Scalability, Installability, Useability, Availability, Performance, etc.

Missing Assumptions, Dependencies and Constraints: Identification, elicitation and documentation of assumptions, dependencies and constraints is a vital part of Requirement Analysis. It is a good practice to understand the list of assumptions, dependencies and constraints specified in project proposal or statement of work & plan meetings to discuss all assumptions, dependencies and constraints pertaining to project requirements. Missing assumptions, dependencies and constraints would guarantee chaos and customer dissatisfaction.

Inadequate Validation or Reviews: Validation of requirements is the responsibility of the Requirement Analyst. The relatedness and conflicting nature of requirements are to be identified and resolved during initial stages. All artifacts of Requirement Analysis are to be reviewed to identify and resolve defects.

Not Measuring the Quality of Requirements: Quality of requirements affect the quality of subsequent phases. Quality of requirements can be measured using organizational metrication process in organizations that follow standards such as CMM.

Not documenting “What is not in scope”: It is a good practice to document the list of things that are out of scope. During meetings with the stakeholders or end users, a set of features may be qualified for subsequent phases of the project. If not documented, such features may creep in during the time of project execution or acceptance testing. It is good to document all such features and get a sign-off to mitigate requirements creep.

Not focusing on ‘Technical Requirements’: Technical requirements are vital for the acceptance of the system. Such requirements could be related to areas such as compatibility, coding standards, error handling and propagating errors with user-friendly messages, audit trial, data interfaces, design of multi-currency support, design of multi-lingual support and UI design. Requirements Engineering needs to consider technical requirements with respect to what the stakeholder want on technical perspective. Design Phase would address these requirements with respect to how they would be implemented. Thus, the identification and documentation of technical requirements should not be forgotten or pushed to Design Phase.

Needless to say, practitioners need to focus on these areas to mitigate risks related to Requirements Engineering. Any thoughts?

Other Posts on Requirements Engineering:

Friday, January 1, 2010

Customer Value Management and IT Outsourcing

Welcome 2010! This decade is going to see a great shift from value-neutral to value-based IT outsourcing trends…

The last two decades encompassed huge opportunities to software service providers. IT evolution and cost-effective onsite-offshore operations offered stability and growth in the areas of Software Maintenance and Support, and Sustenance Engineering. Service providers played in a value-neutral way looking at the opportunities alone to reap benefits. Over the years the competition has grown to a global level. Under these circumstances, Customer Satisfaction Surveys failed to assess the relative performance in a competitive world and hence to understand customer values. Customer Value Management (CVM) is an emerging art and science – it is a way of thinking coupled with a set of techniques and methods that anyone in business can use to decide where to expend time, energy and money to create value for customers. Mature disciplines such as consumer electronics, telecommunication and automobiles focus immensely on Customer Value Management to delight and retain customers.

Software Engineering is a maturing discipline. The focus on CVM in Software Engineering is too low compared to other mature disciplines. Offshore Software Service Providers realized the demerits of ‘one-size-fits-all’ approach during the post-Y2K era and took the first step by means of defined organizational structures or business units based on verticals and horizontals to provide focus on domain-specific as well as technology-specific customers. Strategic initiatives of Software Service Providers during the mid-90s focused on the adoption of process maturity models (such a, ISO and/or CMM) and enrichment of skills with professional certifications (such as PMP). These initiatives focused on standardizing organizational software processes and strengthening the delivery arms. However, for more than a decade, the contribution of such initiatives to Customer Satisfaction as well as the overall success of the Offshore Project Management could not provide consistent results across projects.

Software service providers go with their Unique Selling Points (USP) and Value Propositions to win new business relationships. Seldom do they focus on answering the following questions.

1) Do we choose the right set of values?
2) Do we manage our business processes to deliver the values we promised?
3) Do we communicate the values we offered to the customer and understand customer's perception?

Customer Value Management is all about this focus. Do software projects deliver software as well as customer values? The answer is not a definite 'Yes'. In many cases unfortunately, the answer is a definite 'No'. This is due to the mindset of businesses that deliver software - the mindset that treats software as a technical commodity executable on a piece of hardware to satisfy user requirements. As the competition gets truly 'Global' this mindset will transform towards value-orientation. Delivery Management community will work towards managing customer values effectively.

Obviously, cost effectiveness as a singular value proposition will lose gravity. Cost pressures will continue to exist. Increasing number of service providers will move their operations to cost effective geographies. Organizational focus on cost effectiveness and cost cutting measures will become ubiquitous. Worldwide blended rates will emerge.

Surveys show that when customers slip from ‘Highly Satisfied’ to ‘Satisfied’ (the ‘Slippery Slope’ syndrome) they do limit existing relationships to low-end services with the current vendor and seek new providers for value-added high-end services. For example, in banking industry customers who are just ‘Satisfied’ with the current bankers keep their relationship to maintain a savings bank account and open new accounts with other providers for high-end services. This is a classic scenario that could happen and restrict players from growing up in the value-chain in our industry. Unless the current service offerings are value-centric, existing customers will never ‘Pull’ a provider to offer high-end services or succumb to any ‘Push’ to buy additional services. In fact, service providers do go with ‘Value Propositions’ to customers and sell their services. This was the first step taken by service providers towards value-orientation during the current decade –‘Going with Value Propositions’. This partially answers the first question – ‘Do we choose the right set of values?’ In reality, the industry has a long way to go in choosing the right set of values, in managing business processes to deliver such values, and finally, in communicating the values delivered to understand customers’ perception. CVM is the way to go in order to evolve a value-based delivery model and hence to stay ahead of competition.

Incremental & Evolutionary Development Methodologies will become a dominant factor of delivery models. Software Application Development and Maintenance has undergone a major paradigm shift from traditional waterfall life cycle to iterative and incremental life cycle. Incremental and Evolutionary Development Methodologies (for example Agile Methodologies and Lean Development) have proved to be successful. The trend will continue and there will be many adopters of such methodologies to ensure early deliveries, high quality and effective risk management. The need of the hour in software development is to plan for early and continuous delivery of high-quality software along with the flexibility to respond to changes and provide better visibility and predictability to the customer. Time-to-market and budget constraints put tremendous pressure on Global Delivery Models in meeting this need.

Foundation of critical resource pools at customer-centric locations will become a necessity to attain competitive advantage. Customer-centric locations will provide competitive advantage to position critical resources to offer high-end service offerings such as Consulting Services and Package Implementation. Businesses will strive to hire resources in order to overcome cultural and linguistic barriers. There are two dimensions to this foundation – a) Establishing critical operations close to customers for value addition and b) Exploring worldwide locations for business operations, talented resources and operational efficiency. With cost effectiveness being the basic ingredient the ability to compete globally will make these two dimensions the key strategic options to establish effective delivery models. Service provides operating from a base country with sales forces across geographies will have to provide value-addition to its existing as well as potential customers by forming ‘expert teams’ consisting of domain as well as technical expertise to increase their ability to respond fast to market situations. This will become a necessity to be a true ‘Global’ player in the industry.

The significance of relationship will surpass the power of branding when it comes to business continuity with existing customers. This will limit the power of branding in business continuity and entrust enriched customer relationship as the strategy to retain and grow businesses. Branding will prove to be advantageous in entering new accounts and attracting new talents. When it comes to ‘Retention & Continuity’, ‘Relationship’ will play a key role in global competition. Customers will create and sustain business relationships purely based on value offerings. Branding and market dominance will never bias a relationship or business continuity in the competitive world. Rather value offerings and business relationships will add power to branding.

Services offerings will get wrapped around innovative value-based alternatives that provide for Flexibility, Risk Mitigation, Business Continuity, Partnership Opportunities, Technology Leadership and Relationship Commitment. The last decade was predominantly full of opportunity-based value-neutral selling. Delivery Models were SLA driven with contractual bindings. Though this trend will continue to exist, the next generation will see different kinds of value-based alternatives.

Focus on Employee Skill Building will mature further to ‘Value-Based Competency Building’ (VBCB). Global competition will transform businesses to strategize on Value-Based Competency Building. ‘Value-Based Competency Building’ will address contemporary challenges in building competencies specific to Verticals or Horizontals. This will enable businesses to establish the basic foundation for effective Customer Value Management. ‘Value-Based Competency Building’ will become a critical aspect of Human Resources Development and Planning. Global players will evolve VBCB to establish a strong foundation for their delivery models to improve quality of deliverables and to reduce project costs.

Partnered Delivery Model will emerge as a new trend. To build a successful Value-Based Delivery Model’ the new generation will see the trend of ‘Partnered Delivery Model’ where Service Providers will establish partnerships to enable value-addition to their system. Partnerships will emerge in the areas of Resourcing &Competency Building, Employee Care, V&V Services, Package Implementation and Technical Writing. Matured industries such as consumer electronics and airlines operate with partners who supply both products and services. In these cases the delivery system operates by consuming products and services from partners to optimize internal value creation and hence to exceed customer expectations.

Value-Based Software Engineering (VBSE) originated by Berry Boehm will become a catalyst in IT services industry and Value-Based Process Frameworks (VBPF) may evolve as well – both of these will become the building blocks delivery models. VBSE is currently maturing among the academia and research communities. It is going to reach practitioners in few years from now. It focuses on both monetary and non-monetary values and explores ways to infuse value orientation in each and every activity of Software Engineering starting from Requirement Analysis to Verification & Validation. The VBSE agenda includes Requirement Engineering, Architecting, Design and Development, Verification & Validation, Planning and Control, Risk Management, Quality Management, People Management, and Principles and Practices.

Adoption of Quality Processes will upgrade to Value-Based Process Optimization and Process Tailoring (VBPO &PT). Quality Processes and Process Model will upgrade to include value definition, measurement, corrective action and optimization. Process Areas will include key value elements to practitioners and Process Tailoring will help them the right set of key elements are add new ones to ensure successful deliveries. This is a potential area of research and practice in the industry.

An organizational level CVM initiative will be the first step to create awareness and develop CVM skills in the organizations. Implementation of CVM will require an experimental approach on a selected set of projects of business units and customers. A customer’s view on the market depends on various factors including the maturity of the market, value-offerings, and supply. This is true for a vast majority of the customers of any industry. Cost effectiveness alone cannot survive businesses that are stronger in value-neutral organizational or process maturity frameworks. Organizational Value Orientation and CVM in IT Services Industry are in their infancy. As of now, less than a handful of organizations have started moving in this direction. The next decade is going to see a great shift from value-neutral to value-based IT outsourcing trends.

  1. Bates Collin, Forget the value of the customer to you and think about your value to the customer, Customer Management, September/October 2003
  2. Boehm Berry, Value-Based Software Engineering: Overview and Agenda, University Of Southern California, Computer Science Department, February 2005
  3. Boehm Berry, Turner Richard, Observations on Balancing Discipline and Agility
  4. Favaro John, When the Pursuit of Quality Destroys Value, IEEE Software, May 1996
  5. Gale T. Bradley, Introduction to CVA – Trends in Customer Satisfaction, Loyalty and Value, Customer Value Inc.
  6. Highsmith Jim, Cockburn Alistair, Agile Software Development: The Business of Innovation, September 2001
  7. Minseong Kim, Sooyong Park, Value-Based Requirement Analysis of Product Families: A Goal and Scenario Oriented Approach, Department of Computer Science and Engineering, Sogang University
  8. Poppendieck Mary, Principles of Lean Thinking
  9. Shirhattikar Gautam, Future Winners and Losers in Global Outsourcing, CHAZEN Web Journal of International Business, Winter 2005
  10. Terdiman Rita, New Dynamics in the Application Outsourcing Marketplace, Gartner Inc Article Top View, 30 January 2003