Project Management Institute

Value enablers--mechanisms to capture and deliver value in software projects

Abstract

The impacts of software-enabled change reach much further across and into organizations today than in the past (Thorp, 1998). Software has the potential to provide enormous benefits in improving the efficiency of the existing business functions and creating possibilities for new functions to be performed. But is the software “correctly” produced today by the software organizations to pass on this benefit to the customer, is a question. While the customer has been kept in the centre in most software projects the focus has excessively been on completeness (standards) rather than correctness and on “hygiene factors” like minimizing defects, schedule slippages, cost overruns rather than the “customer's need” itself. As a result, customers don't get the value for money and the desired business benefits. Software's value proposition will only increase when the software organizations increase their understanding of how customers will use their software to create value for themselves. Software project managers who understand these value motivators and how customers define them across various dimensions not only deliver successful projects and achieve a profitable growth but also become a trusted advisor. This paper is focused on enabling project managers to (1) Understand and capture value drivers (2) Implement practices that consistently help them create and deliver greater value to customers and (3) Align the organization and its people with the value creation principle.

Introduction

The concept of customer value itself is not new. It has been in existence for close to a decade now. In current days with the risk of software becoming more commoditized the only way for software service organizations to differentiate and remain competitive and profitable in the industry is by improving the delivered value. Fierce competition amongst service organizations and cost cutting in some industries has increased the focus on value again. Though an old concept, value has not been correctly understood by all project managers in the software industry today. Is delivering on schedule, as per quality requirements and within budget considered value? Or is producing all required deliverables like use-case models, object models, data models, code and test results considered value? – Probably not always. So what is value? The subjective theory of value (or theory of subjective value) is an economic theory of value that holds that “to possess value an object must be both useful and scarce,” (Moser, 1997, p 1) with the extent of that value dependent upon the ability of an object to satisfy the wants of any given individual. Thinking in this direction makes one realize the following (1) Each deliverable made towards solving a customer need – say, solving a business problem or creating a new business opportunity, is “value”. (2) If schedule adherence in projects in the industry is low and if the same is provided it is “value”. (3) If globalization, innovating with limited resources, shorter project cycle-times are challenges in the industry and if the software organization responds to this then it is “value”. In addition, it is important to realize that “value” consists of both explicit and implicit connotations and touches both tangibles and intangibles. Examples of intangibles are (1) Usability (2) Product experience etc. In the software industry, it is typical for the project managers to usually concentrate on the tangibles as a result of which intangibles like usability is sometimes missed.

The subjective theory of value also holds that things become valuable in the economic sense (have exchange value or price) under two conditions: (1) They are useful in satisfying human wants, and are therefore desired. (2) There are not enough of them, or just enough of them, to satisfy demand. In other words customers pay for the above and not for the deliverables per say. (Moser, 1997) This is shown in exhibit 1.

Simple Value Chain

Exhibit 1 – Simple Value Chain

Understanding Value

The Value Equation

Values perceived by the customer vary based on the customer's belief about the application/ product, the company itself, the problem statement and the customer's motivation. With respect to the software services industry, value can be described as a function of Utility, Delivery, Experience, Benefits, Cost and Brand. Each of these categories will have multiple attributes that are perceived to be the most important factors for the customer. In this paper a custom software application is taken as an example. A sample set is depicted in exhibit 2 below.

The Value Equation

Exhibit 2 – The Value Equation

Utility for a custom software application comprises of the following dimensions (1) Tangible features and functions of the software product which the customer evaluates (2) Non-functional attributes like design, usability, performance, learnability, reusable components provided and (3) Innovative use of technology. Delivery comprises of (1) Timely & Quality delivery (2) Delivery model (3) Methodology and Tools used (4) Focus on scope management (5) Span of services offered and (6) Communication and monitoring capabilities. Customer's Experience during the transaction from end-to-end, which consists of (1) Ease of relationship (2) Commitment to partnership (3) Product experience (4) Customer Enthusiasm and (5) Teamwork. Enterprises that pay careful attention to customer's experiences across transactions, reap benefits of superior pricing and higher margins (Kothari and Lackner, 2005, pg 4). Benefits comprises of (1) Solution proposed for the customer (2) Impact on customer's customer and (3) Cost reduction for the customer. The ability of the project manager and the organization to address a larger sphere of influence – business services, operations, customer and supplier interactions, impact on existing systems and standardization at enterprise level enables one to appreciate the problem completely and deliver a holistic solution. Cost comprises of (1) Price (2) Contract/ Payment terms and (3) Total cost of ownership. Brand comprises of (1) Reputation/ Brand image of service provider (2) Prior experience with the customer (3) Customer Reference

It is critical that the project managers understand these key value drivers and the competitive position of these drivers relative to its competition to deliver a unique value proposition. Once the key value drivers are identified, determine the Key Process Indicator (KPI) for each business value driver (both tangible and intangible). Identifying the data to be gathered against each KPI would help prioritize the action internally and ensure that the impact is highest with the customer. An example KPI – Value Driver Matrix is as given below in Exhibit 3:

KPI vs Business Value Driver

Exhibit 3 – KPI vs Business Value Driver

It is not just sufficient to understand the value drivers as of today. It is equally important to understand the forces that will change the value drivers and what will those be in the subsequent years. Ability of the project manager and the organization to pre-empt this would be a key value proposition.

Creating & Delivering Value

Once the meaning of value is understood and the most critical value drivers are known, specific mechanisms need to be established to systematically create value. Some of these mechanisms which can be implemented to improve the attributes in the categories “utility” and “benefits” are discussed below:

Improving Utility

As discussed before, any software that does not help the customer solve their problems is of no value. The pain-points/ challenges faced by the customer needs to be understood. Will studying a 200+ page requirements document or conducting focus groups or facilitating discussions or following a questionnaire based approach “really” help in understanding the “context of the customer” or the very purpose for which a use-case was born? – Probably not. This would only give an abstract knowledge of the customer's requirements. The true pain-point can be obtained only by going to the place where the problem exists. Gaining this level of understanding and translating the same to “requirements” along with the benefits they would provide the customer, will help deliver a “solution” which makes a difference for the customer.

Normal, Expected and Exciting Requirements (Kano, Seraku, Takahashi, & Tsuji, 1984)

Exhibit 4 – Normal, Expected and Exciting Requirements (Kano, Seraku, Takahashi, & Tsuji, 1984).

Another aspect with respect to requirements would be to capture the “implicit” requirements. There are 3 types of requirements: Normal requirements, Expected requirements and Exciting requirements (Kano, Seraku, Takahashi, & Tsuji, 1984). Normal requirements are those which the customers want the software to perform. The satisfaction or dissatisfaction is directly proportional to the presence or absence of these normal requirements as shown in exhibit 4 above. Exciting requirements are those which are beyond the needs of the customer. Presence of the same will increase the satisfaction to large extent but the absence of the same does not affect the satisfaction. Expected requirements are those requirements which the customer has assumed to be present by default (in other words, they are implicit). Presence of these requirements does not increase satisfaction however absence of the same results is higher dissatisfaction. Customers cannot be relied upon to tell the project manager about the list of all expected and exciting requirements. The business analyst needs to elicit the same. While doing so, focus should be on the real “need” of the customer and not on what “customer wants”. A “want” is something the customer would ‘like’ to have. While a “need” is something the customer ‘should’ or ‘must’ have. Ford once said: “If we'd listened to our customers, we would have given them a faster horse” (Hohmann, 2005) – the real need was a faster transport!

Studies show that a characteristic of good requirements are those that are prioritized (Wiegers, 1999). Very often usage of prototypes (wireframes and functional prototypes), scenario descriptions, and effort estimations enable customers to obtain a better mutual understanding of which aspects of an application are most important and achievable in the given timeframe. It is important that the prioritization/ value quantification is done along with the key requirement providers (subject matter experts among business users), key customer stakeholders and key representatives from the delivering organization (e.g. program manager, project manager, analysts and architects). Once prioritization is done the benefits need to be captured and quantified. Requirements and software definition need to be based on a business case, which should essentially translate to $ or some aspect in the Balance Sheet. One way in which value of a requirement can be quantified is by using the estimated present value of the feature (in $) if it were delivered immediately (Little, 2004). This level of understanding will also help monitor the extent of value created during the course of the project.

Once the problem, requirements, prioritization and the benefits are known, development should be done systematically for the customer to receive value. The methodology developed for this very purpose is Quality Function Deployment (QFD). Traditionally software development has focussed in minimizing customer dissatisfaction and not to enhance value delivered to customer and increase the satisfaction. QFD employs certain techniques which help gain a deeper understanding of the customer's problems and priorities during the requirements collection phase. Once this is done this information is passed to the subsequent development phases consciously and the team's best possible efforts are directed to these high-value items. Best possible efforts would mean assigning high skilled resources, investing time and involving stakeholders. This is shown in exhibit 5. Though QFD itself was not invented in the software industry it can be high value if followed. (Krogstie, 1999) suggests how this can be done in detail.

Traditional development vs QFD based development (Zultner, 1993, pg 6)

Exhibit 5 – Traditional development vs QFD based development (Zultner, 1993, pg 6)

As the best efforts are aligned, project managers, designers and developers need to understand on how to make the required decisions and maximise value. Making this decision requires a paradigm shift – moving out from the technical world and thinking in-line with the customer and the value desired. Three examples in the context for design are discussed here: (1) Customers generally think software as a tool that should adapt to their needs over time. This means that most life-cycle cost is expended in change (Leintz & Swason, 1980). In such a situation, for a system to create value, the cost of making an incremental change to the system should be proportional to the benefits delivered by that change. If a system has not been well designed the cost of incremental change will be disproportionate to the benefits (Parnas, 1972, p1053-58). “Design for change” is therefore a value maximizing strategy, provided one can anticipate changes correctly (Boehm & Sullivan, 1999, p 14) (2) Re-use in design may not just be cost-reduction or effort reduction to the delivering organization but can translate to reduced time to market and improved software quality to meet user's expectations. Enabling reuse with careful cost-benefit analysis adds value to the customer. (3) Architecture itself can create value when multiple variants need to be created to address new or changed markets in the same domain and to develop them quickly.

Improving Benefits

Customer value is also a function of the tangible and intangible benefits gained from the software solution delivered. Here are some mechanisms which will help the project consciously realize these benefits for the customer.

Today cost benefit analysis is done by some customers. However software organizations are not tied into this model. Project managers from software organizations therefore make an assumption and fail to question the very purpose of the application being developed and the benefits it need to realize. Lack of having this 30,000 ft view of the requirements leaves a little chance for the project team to see and think beyond the narrow boundaries of a “requirement”. It is imperative that the project managers are an integral part of the cost-benefit analysis and be part of customer's success or failure. Doing this opens a door to many possible options to deliver a “beneficial solution” to the customer rather than just a custom application with “n” number of features.

Gaining an understanding of the market trends in the industry or the domain in which the customer is operating will help the project managers capture the key success factors (KSF) for the customer and their driving forces. This is more than having a 30,000 ft view, since the analysis is not on the present state but also on the future trends. For example, if the customer belongs to the automotive industry, some of their KSFs could be (a) Reduced cost of production (b) Reduced sourcing and distribution costs (c) Innovation – cheap hybrid, higher fuel efficiency, alternative fuel (d) Globalized business processes and IT systems (e) Improved supplier dealer collaboration and (f) Reduced warranty costs. Understanding customer's KSFs, their business model and pain points enable the project managers offer customized solutions which fuel customer's business. KSFs need not be market trends alone but can also include regulatory compliances required, data granularity, advances in technology etc.

Once the context and KSFs are understood, project managers and software organizations need to leverage this to develop deeper client relationships and become trusted advisors building innovative business and technical solutions. Innovative solutions can be best described as innovative ideas which provide answers to industry wide issues by marrying technology to business. For instance, employing RFID in improving supply-chain visibility and employing service oriented architecture in Warranty Management Solutions are solutions which leverage emerging technologies to tackle business problems. In addition to thinking of possibilities which can be achieved with existing technologies, one needs to think of the needs of the business irrespective of the constraints in technologies today. Out of the box thinking like this will lead to inventions which move the possibilities to the next level. Unlike custom software which aims at resolving specific issues faced by a customer, a solution aims at resolving issues in a broader spectrum and thereby imparting more value. Some of the unique characteristics of solutions are that they are (1) Repeatable, (2) Experience based, (3) Leverage alliances for speed, expertise and market presence, and (4) Utilize an investment and Return-On-Investment-based model.

Finally, partnering organizations involved in the problem and solution domain to focus on the overall business benefit desired adds value. Peter Drucker noted in Management Challenge for the 21st Century that “In every single case… the integration into one management system of enterprises that are linked economically rather than controlled legally, has given a cost advantage of at least 25 percent and more often 30 percent” (Peter Drucker, 2001, p 33). It is crucial to understand that when organizations work together for their mutual benefit rather than optimizing the results of the individual organizations (2003, Software Development Productivity [Electronic Version]), the whole becomes larger than the sum of the individual parts, resulting in exponential increase in values gained and providing breakthrough solutions.

Aligning Organizational Culture and People Processes to the Value Creation Logic

As seen above value creation mechanisms for the software organization can be customer-in-focus, excellence in service quality or continuous innovation. However to ensure value is generated consistently the organizational and people processes need to be aligned with the value creation logic. They need to be mutually consistent. This is shown in exhibit 6 below. For example to create innovative solutions the following needs to be in place:

(1)    Empower the frontline managers with domain knowledge, awareness of technology potential, market trends and pulse of the customer

(2)    An organizational culture which promotes innovation, encourages experimentation, promotes coordination between innovation and delivery teams, engages customer in innovation and leverages research in different parts of the organization

(3)    People processes which make senior managers as coaches and mentors.

All the above need to be supported by the organization's value system also. It is important to realize that not all factors promoting value generation rests at the project manager level. Numerous factors are dictated by the company's working style. There could be even more challenges internally like staff capability, multi-site development, delivery model, process maturity, relationship model and focus on service quality which must be addressed by the software organization based on the value creation principles it employs.

Kano, Seraku, Takahashi, & Tsuji, 1984

Exhibit 6 – Aligning organizational culture and people process with the value creation theme

Conclusion

The focus of project managers in software organizations has typically been to ensure predictable delivery of predefined requirements instead of delivering value. In this increasingly competitive environment coupling business knowledge together with information technology, is probably one of the greatest requirements to differentiate from the rest. Software organizations should move out from an “optimized delivery” paradigm to an “innovative delivery” paradigm driven by the value needs of the customer. By doing this, capturing customer problems/opportunities becomes more important than capturing customer requirements, traceability to value propositions become more important than tracing to requirements, designing for value becomes more important than designing for requirements, delivering value becomes more important than delivering millions of lines of code, delivering solutions becomes more important than delivering applications. Organizations that understand these build long-lasting relationships with the customers; proceed to win markets and see a non-linear profitable growth.

References

Boehm, B. W. & Sullivan, K.S. (1999, Dec) Software Economics [Electronic Version] Retrieved on Oct 23, 2006 from http://www.cs.ucl.ac.uk/staff/A.Finkelstein/fose/fdboehm.pdf

Drucker, P. (2001) Management Challenge for the 21st Century, Harper Business, 33

Hohmann, L. (2006) Faster Horses, Henry Ford, Bob Sutton, and Innovation [Electronic Version] Retrieved on Nov 3, 2006 from http://www.lukehohmann.com/blog/?p=18

Kano, N., Seraku, N., Takahashi, F. & Tsuji, S (1984, February). Attractive and must-be quality (in Japanese) Hinshitsu 14 (2) 39-48

Kothari, A. & Lackner, J. (2005) A Value Based Approach to Management [Electronic Version] Retrieved on Oct 24, 2006 from http://www.charterconsult.com/Value%20Based%20Approach%20to%20Mgmt.pdf

Krogstie, J. (1999), Using Quality Function Deployment in Software Requirements Specification [Electronic Version] Retrieved on Nov 4, 2006 from http://www.ifi.uib.no/konf/refsq99/papers/krogstie.rtf

Leintz, B. & Swason, E.B. (1980), Software Maintenance Management, Reading, MA: Addison-Wesley,

Little, T. (2004, June) Value Creation and Capture, a Model of the Software Development Process, IEEE Software 21(2) 48-53

Moser, J. (1997, Spring) The Origins of the Austrian School of Economics, Humane Studies Review 11(1)

Parnas, D. L. (1972) On the criteria to be used in decomposing systems into modules, Communications of the Association of Computing Machinery, 15(12) 1053-58

Poppendieck (2006) Software Development Productivity [Electronic Version] Retrieved on Nov, 3 2006 from http://www.poppendieck.com/pdfs/Software%20Development%20Productivity.pdf

Thorp J., Fujitsu's Center for Strategic Leadership (1998), The Information Paradox: Realizing the Benefits of Information Technology, McGraw-Hill

Wiegers, K. E. (1999), First Things First: Prioritizing Requirements [Electronic Version] Retrieved on Oct 28, 2006 from http://www.processimpact.com/articles/prioritizing.pdf

Zultner, R. E. (1993, Oct), TQM for Technical Teams, ACM Digital Library 36(10)

© 2007, Ananth Subramanian
Originally published as a part of 2007 PMI Global Congress Proceedings – Hong Kong

Advertisement

Advertisement

Related Content

Advertisement