• Prev
  • Next

Software Vendor Savings

Tony MannoDo you engage with software vendors to do your development? If so, then you know the drill. You provide your vendors with detailed requirements and they come back with a price for the project. But how do you really know whether you’re paying a fair price, and what’s your basis for negotiation?

If you could quantify the unit value created by the project, and know the fair market rate for those units, then you would know what you should pay for the project. You would be in a strong position to negotiate a fair price with your vendor.

Function Point Analysis can provide that information. It is a technique for measuring the functionality that is meaningful to a user, independent of technology. Function Point Analysis is governed by IFPUG, which produces the Function Point Counting Practices Manual. This manual is used by all IFPUG-certified Function Point Analysts to conduct function point counts. IFPUG is an ISO standard for software measurement.

Industry standard rates for the development of function points are available. Armed with the function point count for the project, along with the market rate, you’re ready for a win-win negotiation with your vendor.

Additional Resources:

Looking for more information? Check out these publications:

  1. An introduction to Function Point Analysis, including what it is and who would benefit from it. Download.
  2. DCG’s Function Point Analysis services. Download.
  3. DCG’s Software Vendor Savings offering. Learn more.

 If you need more information on how to use Function Point Analysis for evaluation and negotiation of vendor pricing, or if you have general questions about function points, don’t hesitate to reach out! I’m always up for a discussion!

 

Anthony Manno, III
Vice President, Outsourced Services

t.manno@softwarevalue.com

 

Written by Tony Manno at 05:00

How to Ensure a Good Relationship with Your IT Outsourcing Vendor

MikeA recent article from CIO magazine outlined a few steps that everyone should consider in an effort to maintain a good (and effective) relationship with an IT outsourcing vendor. Why bother? Because with any vendor, you get what you give. By putting in the extra effort in your relationship, your vendor will likely perform better in return. Here are some of the recommended steps:

  1. You are entering a long-term relationship, so first impressions matter. When negotiating your initial contract, be reasonable, so that the relationship starts off on the right foot.
  2. Be honest from the beginning, so that there aren’t any unexpected surprises later. Provide an accurate asset inventory, key data on performance, etc. Your vendor will appreciate having all the necessary information up front.
  3. Don’t be too technical when it comes to contract interpretation; instead, face issues with a problem-solving attitude and work through issues together.
  4. Reward performance – easy enough, right? Clearly link financial rewards with performance to show your vendor that you value their work.
  5. Be a team player and foster a team-based atmosphere in every aspect of the relationship.
  6. Understand that when you ask a vendor to do additional work outside of the original scope, you will have to pay more. Don’t take advantage of the relationship or your vendor’s time.
  7. If your vendor is struggling to meet contract terms, work together to resolve the issue, if possible – it’s in the best interest of both parties to foster success.
  8. Pay your bills on time. Easy enough, but often overlooked.

A vendor relationship is a two-way street, so don’t overlook these simple tips!

What would you add to this list?


Mike Harris
DCG President

Written by Michael D. Harris at 05:00

Managing your Vendor’s Performance

David HerronHow much insight do you have regarding your software vendor’s level of performance? And how do you know if an outsourcing arrangement is cost effective?

Outsourcing arrangements typically have contractually agreed to service level agreements (SLA). These SLAs define a variety of parameters, which serve to govern vendor performance. SLAs can include issues of compliance to standards, delivery timelines, penalty clauses, escalation procedures and other guidelines for managing vendor outcomes. But, how do you know that the delivered outcome, usually software, is being provided efficiently and economically? Wouldn’t it be nice if we could measure software deliverables on a cost per unit of work basis just like in manufacturing; whereby, we could evaluate the vendor’s level of performance based on a software cost per unit of work.  

How do you define a unit of work for software, you may ask? We can define a software unit of work by using an industry standard software measurement method known as Function Point Analysis (FPA). We define a software unit of work as a unique software feature or function that an end user has requested; an online screen to process a specific transaction, for example. When software is first being developed, a formal requirements document or backlog of requirements (for you Agile folks) is developed that is intended to describe all the required features and functions for a desired program. The FPA methodology was designed for the primary purpose of measuring or sizing those software features and functions as requested by an end user.

FPA defines a software function as one of five elements; a unique input, output, inquiry, remote data access or internally maintained data. The methodology clearly defines the characteristics of each of these five elements, making it easy to identify and classify the requested functionality. Each element is evaluated and assigned a value based on its complexity. The result is a numeric value of size. The cumulative size of all five elements thus represents the total of all the unique functions – or a total number of units of work.

To develop and deliver software, as defined by the user requirements, the vendor charges a contractually agreed to fee for that service. Now we have all of the ingredients necessary to develop a cost per unit of work measure. A simple example would be: a software requirement was sized using FPA and included features and functions that measured as 150 function points (units of work) and it was delivered at a cost of $150,000; therefore, the cost per unit of work would be $1,000 per function point (or unit of work). 

The real value of using this cost per unit of work approach is to understand what defines a reasonable cost per unit of work. The size of any software deliverable can be consistently determined using the FPA methodology. The cost, however, can vary depending on a myriad of variables.  In other words, not all function points cost the same.

The mature organization has taken the time to baseline their own levels of performance and has established an internal cost per unit of work. At that point, they are well positioned to evaluate vendor bids based on a cost per unit of work basis. For those organizations that do not know their own level of performance, they can utilize industry baseline performance measures based on function points to determine whether or not a particular vendor bid is within an acceptable range of performance.

This blog post is available as a download in our Publication library for your use!

Questions? Leave them in the comments and we'll get back to you!

 

David Herron
Vice President, Software Performance Management

Written by David Herron at 05:00
Categories :

"It's frustrating that there are so many failed software projects when I know from personal experience that it's possible to do so much better - and we can help." 
- Mike Harris, DCG Owner

Subscribe to Our Newsletter
Join over 30,000 other subscribers. Subscribe to our newsletter today!