The only publication dedicated to OSS     Volume 1, Issue 4 - August 2004
Current Issue
  Cover Page
  Undervalued
  Value of OSS
  Message
  NetCracker
  Publisher's Ltr
News Brief
Subscribe
About Us
Archives
Ed-Opps
Ad-Opps
Advertisers
Sponsors

Download and print this article
download & go

Defining and Measuring Value in OSS Projects (cont'd)

Multiple Groups Need to be in the Process

Building a business case with the cooperation of multiple departments is an ideal way to produce more realistic and defensible cost savings estimates. Gaining support from other groups also helps to create momentum and a positive profile, which in turn may increase an executive's confidence that the promised results are deliverable. It will also help avoid situations where groups competing for project funding argue that inefficiencies exist everywhere but in their own group, which is sure to make an executive skeptical.

Many companies have formalized their approaches for determining the relative value of projects and have a steering committee that evaluates all proposed projects according to a consistent set of criteria. This approach promotes objectivity, reducing the impact of style over substance. The committee ensures that cross-departmental impacts are considered, assigns a priority rating based on each project's alignment with key business objectives, and presents a prioritized list of projects for executive approval. Though this may seem like bureaucracy overload, experience shows that it significantly improves the chances that approved projects gain persistent support, funding and the profile they need to succeed. Without a formal, agreed and published priority ranking, project champions can be embroiled in a continuous battle for funding against each new idea, instead of managing their own projects.

ROI and Value are Different

Clearly, determining value is not as straight forward as OSS vendors would like everyone to believe. The Pragmatic ROI model described in Pipeline's May issue provides a time and cost-efficient approach to gauging the relative value of any planned change to an operations environment. This model can help one to understand the size and scope of a business problem and its solution in a project's earliest stages. The model also helps define the tangible measures that provide the basis for tracking achieved results. These measures provide a basis for evaluating solution options and act as touchstones throughout contract negotiations and implementation.

Determining a project's ROI is not the same as determining value. Value is in many respects more elusive than ROI. There are too many horror stories about managers who have been burned for anyone simply to accept a vendor's promised results. When managers try to get these promises in writing, the “Assumptions” section of a contract tends to expand significantly. Value must take into consideration a broader contribution to the overall health of the service provider's business. Realizing value implies that improved capabilities are delivered, are sustainable over time, and persist even when some products, technologies or services change. Meeting all of these goals is a tall order, but it is achievable if OSS solutions are designed with a solid understanding of the business functions they need to support.

Burden of Proof is on the OSS Vendor

OSS vendors must do more than present tangible evidence of improvements in operations or capital expenditure. They must also present value propositions that show they have a deep understanding of each prospect's or customer's most pressing business problems. Establishing credibility and trust is a necessary step toward creating perceived value. This is achieved by addressing real business problems that the customer faces every day, using the right language or lingo and placing people on site that can roll up their sleeves and work side by side with application users. If a vendor cannot do those things, there is good reason to suspect that its product won't deliver on its promises.

Service providers likely have too many choices when considering an OSS application, which makes relative value important as well. Besides the large number of package OSS vendors, there are other choices like building in-house or outsourcing to a service bureau. With so many choices, it's not surprising that customers may see any vendor as just one more piece in a commoditized market. This should give vendors even more reason to demonstrate their value clearly, or be prepared to settle for low prices and short odds of being selected.

Each vendor's value proposition must state their value in solving business problems, as well as how they do this better than their competitors or than an in-house project could. Competing against an in-house team is a special challenge and requires careful handling. If the in-house team is a major competitor, it is critical for the vendor to propose something that's a win for them as well.

 

 

Subscribe   About Us   Archives   Editorial Opportunities
Advertising Opportunities   News Brief   Advertisers   Sponsors   Search

© 2004, All information contained herein is the sole property of Pipeline Publishing, LLC. Pipeline Publishing LLC reserves all rights and privileges regarding the use of this information. Any unauthorized use, such as copying, modifying, or reprinting, will be prosecuted under the fullest extent under the governing law.