Software selection tools

TABLE of CONTENTS

I.        Why use an RFP?
                The "bridge" to many benefits...
                Earned Value Management tool...

II.       Pre-RFP Preparation Needed
                Identifying the Project Domain...
                Obtain Project Domain Checklists...

III.      Determining the Correct RFP Organization
                Learn why organization is so important...
                Obtain Business Workflow Checklists...

IV.      Use the Best RFP Question & Statement Format
                the Key to successful software implementation ...
                RFP Optimization Guidelines ...
                Feature Support Matrix...

V.       Requirements Definition Made Easy
                Common sense rules...
                Obtain Detailed, Ready-to-Use RFP templates...

VI.      Reduce Procurement Time using High-Technology
                The advantages of electronic RFPs...
                The Automated Product Evaluation System...

VII.     Vendor Response Evaluation Techniques
                Quantitative analysis Time-saving Tips...
                Weighted Grade Point scoring...
                Key Financial Ratios...

VIII.    The RFP as a System Implementation Management Tool
                Earned Value Management explained...
                Obtain EV Metrics identification tool...

I. Why Use a Request for Proposal (RFP)?

     A Request for Proposal (RFP) is much more than just a collection of software requirements given to vendors. The RFP impacts every phase of a software system's lifespan, from software selection and implementation to future expansion and on-going maintenance.
     Done incorrectly, an RFP is simply a waste of time at best. In many cases, a poorly done RFP is the underlying reason why:

     large cost overruns were incurred.
     software lacking mission-critical features was chosen
     slow or hard-to-use software was installed.
     redundant manual data entry is required.
     expensive, unplanned data conversion was required.
     Everybody has heard of people saddled with poorly performing software who
        must also keep a manual set of notes in their desk just to do their jobs.

        Hundreds, even thousands, of issues must be addressed during the selection of a large software system!

      When the RFP is developed correctly it brings many benefits to the table:

BENEFIT #1 - the RFP is the "translator" between non-technical business users, who know what will enhance their productivity very well but nothing about software, and the software professionals who must implement and maintain the software the business users rely on every day.

BENEFIT #2 - An RFP enhances the software system specification section of the contract between you and the vendor. An RFP with correctly formatted questions requires a vendor to make a more detailed commitment.

BENEFIT #3 - The RFP is the "bridge" that links a specific business procedure with the software features needed to perform that procedure more effectively. This is the first step to better software project management, since we now have a way of measuring the direct impact of a given software feature.

BENEFIT #4 - The RFP is the "bridge" that links completion of specific software implemetation tasks with specific vendor charges. This makes the RFP an excellent Earned Value Management starting point.

BENEFIT #5 - A properly organized RFP can be a very useful tool for identifying the metrics needed to utilize Earned Value Management (EVM) during the selected software system's implementation process.

    The rest of this guide is focused on explaining how you can achieve these benefits.

II. Pre-RFP Preparation Needed

    A key step in creating an RFP optimized for software selection is the development of a detailed Project Domain description for the new, planned system.
    What is a Project Domain? Simply put, it is the total environment the new, planned software must be used in. The information gathered here is vital to the preparation of an RFP optimzed for software selection.
    In general, a good project domain description must provide a brief overview of your business, and must identify the business procedures targeted by the new software. The project domain must also provide an overview of the business problems you are trying to solve.
    The detail information required in a Project Domain is highly dependent on the software applications involved, but will always include things such as:

         typical user demographics
         procedural interfaces with other departments
         workflow of the affected procedures
         data interfaces required with other databases
         information from third-parties

    It is lack of attention to the above issues that leads to data incompatility problems, manual data entry, large error rates, and higher than anticipated on-going costs in many new software systems!
     In addition, the Project Domain should identify those operational procedures whose improvement will give the best payback. This will determine the optimal installation schedule in terms of how to obtain the maximum Return on Investment (ROI) in the least amount of time. For example, what is the impact the proposed software will have on:
         sales prospects?
         the sales force?
         customers in any way?
         inventory levels?
         product/project completion/mfg time?
         Business procedure efficiency?

     Software that directly impacts sales, customers, or inventory probably is more important than something that simply provides a cosmetic benefit.
    This information is needed to adequately explain the circumstances the planned system must be used in, and by whom. This is needed by all vendors when they are planning the configuration, installation, and user training the new software system will require for a successful implementation.
    As stated above, the Project Domain is highly dependent on the mix of applications already in use. If you are pressed for time, you may obtain detailed project domain checklists here, sorted by application type.

III. Determining the Correct RFP Organization

     An effective software RFP begins with a common sense approach toward RFP organization. Vendors must know the specifics about your current situation in order to propose the best suited solution they can, and you need an organizational framework enabling you to compare proposals (RFP responses) "apples-to-apples" and analyze each vendor proposal quickly and consistently. A software RFP should be organized into the following sections for maximum effectiveness:

BACKGROUND -

     This purpose of this section is to provide vendors with a a description of your current operating environment and business situation. (See Project Domain above)

ADMINISTRATIVE -

     This section contains the administrative rules and deadlines. Good examples are Proposal Delivery Deadline dates and times, location, and the contact data of the person at your firm managing the project.

CONTRACTUAL -

     This section contains statements of fact about the terms and conditions you require. They are statements because there is no negotiation. The vendor either accepts it, or does not, in which case they are disqualified. It is not necessary to have the vendor's acknowledge (accept with Y/N responses) each statement provided a statement indicating default acceptance is present in the RFP.

     EXAMPLE: If you require a 60 day period following the software's
     installation during which you can request "no-charge" to the installed
     software, then that requirement is stated in this section.

REQUIREMENTS -

     This is the section that contains the actual business and software requirements needed for your project. Each Business Function identified in the Project Domain, as described above, should occupy it's own sub-section here.

      TIME SAVING TIP - Organize the REQUIREMENTS section into
     subsections that represent the major business procedures the new, planned
     system will address.

      USEFUL TOOL - Quickly identify the correct Requirements
     sub-sections and Earned Value Metrics for your specific application with
     these Business Workflow Checklists.

FINANCIAL -

     The initial and ongoing costs associated with the proposed software.

     It is important to bear in mind the above categories are not set in concrete, your needs may dictate different names or categories other than what is shown above. The purpose of any category is to group questions and statements relating to a common theme for scoring purposes during vendor response evaluation phase.

IV. Use the Best RFP Question & Statement Format

      The single biggest factor affecting the quality and usefulness of any RFP is the format of the questions and statements used to create it. This is especially true when optimizing an RFP for software selection.
     Incorrect RFP question or statement format is the main reason so many people have trouble evaluating vendor responses, i.e., comparing one vendor RFP response to another, or calculating their weighted grade point scores, or calculating the financial impact of each proposal. Using the CORRECT format is key to obtaining vendor responses that are focused, concise, and consistent - the key qualities needed for efficient proposal evaluation.
     The natural tendency of most RFP authors is to simply specify their requirements in a statement format, or ask questions that require vendors to respond with a YES/NO or a detailed, free-form explanation. This leads directly to several large problem areas insofar as software selection is concerned. Each of these is discussed briefly below:

ENDLESS TELEPHONE TAG - Vendors who do not understand a question or statement are forced to call you in an effort to obtain a clarification, and this in turn forces you to be very careful and consistent in the way you answer each vendor question. At best, this is a big time-waster, but it can lead to a lawsuit if one vendor feels their questions were not adequately responded to, or a vendor feels that one vendor was favored over all others.

UNCLEAR RESPONSES TO Y/N QUESTIONS - The vendors will try to present their responses to your RFP in the best way possible. This means that if their product does not offer a certain feature, they will try to present it in the best light. Instead of just answering with a NO, they answer with a "1st Quarter 2003" statement that implies the desired feature will be made available by then. But will it? Do you have a guarantee? Will it be bug free? More to the point, HOW do you compare this type of answer with other vendor's Yes or No answers? How do you score it?

UNCLEAR EXPLANATIONS - RFP questions that require detailed explanations in free-form text format from the vendors lead to two sets of problems. The first is comparison. Each vendor's response can be very different than the others in terms of length, form, and detail quality. There is no way a spreadsheet or other form of automation can be used to compare vendor responses when the vendors were permitted to answer with an explanation of their own creation. The only way this type of answer can be compared is manually - someone has to sit down and read each vendor response, then interpret the answers. What if that person has a question? Now the vendor must be called - more telephone tag! Obviously, the second problem is the time required to do this manual comparison. And there is NO way to score this type response on a quantitative basis, even manually!

DIFFICULT RFP RESPONSE EVALUATION & COMPARISON - As mentioned in the above, unclear and ambiguous RFP response anwers make it almost impossible to evaluate vendor responses (proposals) accurately on a quantitative basis. The reasons for this are lack of response consistency, and the inability to score or rank responses.

      There are RFP Optimization Guidelines designed to prevent the above problems, and they are as follows:

      First, all RFP Statements and/or Questions should be very well focused, and written in a clear, un-ambiguous manner. The rules of thumb to follow are:

• Each RFP Question/Statement MUST define a specific, documented need.
• Do NOT use SUBJECTIVE terms or statements when describing a need.
• Every question MUST require a quantitative response, NOT qualitative one.
• Organize all requirements/needs by BUSINESS procedure.

      Second, it is OK to mix the formats used in the various RFP sections. You can, and should, state your mandatory contractual and performance requirements in a no-nonsense, non-negotiable way. An example would be source code. If you want source code, then simply put this requirement in statement format. The vendor either accepts it, or rejects it and is dis-qualified. Other examples of mandatory requirement statements are deadline dates for certain deliverables, that the proposed software use or support a specific database.etc..
      Third, be sure the response format of each RFP question matches the complexity of the question topic. An example of what works is using a Y/N question to ask if the proposed software "provides for a 24 character customer name". This can certainly be answered with a Yes or a No. That is clear and concise, and all issues are addressed. All names are possible as long as they require no more than 24 characters.
     An example of a bad format match is using a Y/N question to ask if a customer lookup function is provided. A Yes answer does NOT address all the possible needs. What if the lookup function provided simply displays all customers in ascending order by name, and you have 1,500, 2,500, or 5,000 customers? You would have to scroll through endless pages of results to select a customer whose name begins with something other than A or B. This simple search will take forever and is clearly not acceptable, but the vendor could still answer Yes. What is really needed is an alphanumeric lookup search, but the question did not ask that specifically.
      Fourth, and perhaps most importantly, what about the cost, and RISK, associated with the proposed software, especially in those areas that require custom programming (scripting)? Because of this, and the problems discussed above, you may want to use RFP Questions requiring a Feature Support Matrix response. This type of RFP question requires a vendor to respond with one of the following answers:

           Fully Supported - meaning the proposed software provides all the
              functions normally associated with the feature or function referred
              to by the RFP question.
           Partially Supported - meaning the proposed software provides only a
              limited subset of the functions normally associated with this feature
              or function.
           Not Supported - meaing the proposed software does not address a
              feature or function at all.
           Free Enhancement - meaning the vendor is committed to providing
              the feature or function at no charge, as referred to by the RFP question
           Paid Enhancement - the typical billable software modification arrangement.

     The advantages of the Feature Support Matrix response type are many. If a vendor wishes to respond in the best possible light it requires the vendor to commit to Fully Supported, meaning a feature/function is supported in all it's possible manifestations throughout the proposed software. This is much tighter than Yes/No from a legal point of view because the vendor was given the clear cut opportunity to specify "Partially Supported" if there was a doubt.
      This RFx question format is a very good way of identifying BOTH system feature AVAILABILITY, and the DELIVERY METHOD a vendor must utilize to provide that feature, in a completely quantitative format. This is ideal for collecting data used to determine the suitability (weighted grade point score) of a proposed software system to your needs, AND data needed to assess the RISK of it's implmentation.
     If the vendor's product does not fully support the requested feature or function, they must reply with Partially Supported, Not Supported, Paid Enhancement, or Free Enhancement, as the situation dictates. Your RFP can then provide a follow-up question asking the vendor to explain just what is and is NOT provided if they responded with Partially Supported, or the COST if a Paid Enhancement.
     This type of RFx format is an excellent choice for RFIs & RFPs used to acquire enterprise-wide systems such as ERP, ERM, CRM software. The risk assessment is very important here because of the complex nature of the target environment and the amount of custom scripting or programming that is involved. The Feature Support Matrix provides you with the benefits listed below:

FINED TUNED COST TRACKING - The costs of the special scripting or programming needed for specific software functions can be monitored very closely.

EASIER EARNED VALUE METRICS IDENTIFICATION - The cost of all software functions required to implement a specific business procedure can now be determined, enabling you to accurately identify the Earned Value Metrics unique to your project.

IMPROVED PROJECT MANAGEMENT - Having more accurate Earned Value Metrics, and closer control over all costs and project milestones, leads to better project management.

    You can now obtain complete, ready to use RFP templates optimized for your targeted application set. Each RFP template fully uses the Feature Support Matrix and other techniques described in this document, and are fully documented.

V. Requirements Definition Made Easy!

     Identifying your unique system requirements is a straightforward task if you follow these common-sense rules:

A. The first basic rule is ASK questions! Send questionaires to all users, and ask them what is needed to make their jobs easier. Ask how much time is spent hunting for data, how much time they waste each day because they do not have quick access to certain information. This is very important because it will help you create a very accurate RFP, and it will enable you to cost-justify the project.
     Also, talk to vendors about what you are trying to do. Attend some software demonstrations. This is a very good (and free!) learning experience which will give you good insight as to what is involved, and will show you what you do NOT want as well.

B. The second basic rule is also simple: Software is acquired to simplify or improve business procedures, to help people do their jobs more quickly and efficiently. Software is simply a means to an end. Stated another way, you need faster, better business procdures that either save time and money, or generate more revenue, or both. Software can help you achieve these goals, but you do NOT need software in it's own right.

          EXAMPLE: You need software that is easily modified and easily
          expanded. You do not need Object Oriented Design (OOD)
           and Object Oriented Programming (OOP). OOD/OOP are just
          techniques that facilitate the creation of software that is easily
          modified or expanded.

C. The third basic rule is this: State your needs at the business level, i.e., state what business procedures or functions you need to do better and faster. Nobody knows your business better than you do. Tell the vendors that you need more efficient Order Processing and better inventory control, and place a question in your RFP about each component making up those business procedures. Then let the vendors propose translate that into the technological features & functions needed. Detail is the key!

          EXAMPLE: If you use General Ledger account numbers
          that are 24 characters long, then place a question about that
          in your RFP.

          EXAMPLE: If you have customers that have many "ship-to"
          locations, but just one central "billing" address, then a question about
          that capability must be in your RFP.

     As stated before, DETAIL is the key. You must create an RFP question about every important function or capability needed to perform a specific business process efficiently.
     Pressed for time? A complete, ready to use, RFP template optimized for your targeted application set may be obtained here. Each RFP template fully utilizes the Feature Support Matrix and other techniques expalined in this document, and are available here.

VI. Reduce Procurement Time using the Web

When to use it, when not to!

     The Web can be used to save time and effort in many ways when processing an RFP. It is much easier to distribute an electronic RFP as an email attachment rather than copying and mailing a paper RFP. Ditto for simply uploading an electronic RFP to your Web site and letting vendors download it to their computers, where they can create their response offline at their convenience. But what about creating the electronic RFP? What is the best way? What about a Web-based RFP, where vendors visit your Web site and then view and respond to the RFP questions through their browser while online? How does that fit into the big picture? There are several advantages and dis-advantages. First, lets examine the problems.
      In a nutshell, it is not practical to require a vendor to respond to a large RFP, such as those required for an ERP or document management software system, comprised of several hundred questions using their Web browser. It is too restrictive, to say the least. Many vendors use otherwise dead-time to respond to an RFP, such as sitting in an airport waiting for the next flight, or they do the work in the evening at home. They may or may not have reliable access to the Web in such environments. And in many situations, a vendor may need to have several different people, or groups, respond to different sections of your RFP. Again, not all people may have reliable web access.
      The above facts dictate the following rule of thumb: Large RFPs for complex products comprised of hundreds of RFP questions are best left in pure electronic form. On the other hand, small RFQ (Request for Quotation) and RFI (Request for Information) documents that are less than 5 pages long are ideal for completion on the Web through a Web browser. This opens the door to improving the productivity of a purchasing department in many ways, all of which will be discussed in future editions of the RFP_Advisor newsletter.
     If you have an ongoing need to issue RFQ, RFI, and RFP documents, then a product capable of generating them in BOTH pure electronic and Web-enabled form would save tremendous amounts of time. One such product is the Automated Product Evaluation System

VII. Vendor Response Evaluation Techniques

     Preparing an RFP that accurately conveys your needs to vendors is important, but being able to quantitatively evaluate the resulting vendor RFP responses (proposals) in a consistent fashion is crucial to success! The organization of an RFP, and the format of it's questions and statement, set the stage for the efficient evaluation of the resulting vendor responses.

TIME SAVING TIP #1 - Organize your RFP's REQUIREMENTS section into subsections that represent the major business procedures the new, planned system will address.

TIME SAVING TIP #2 - Distribute your RFP in an electronic format that will enable you to quickly distribute the RFP (email is much faster than copying, packaging, then snail mailing a 50 page RFP!), and then compare vendor responses when they are received.

TIME SAVING TIP #3 - Avoid spending hours doing data entry! Be sure your electronic RFP has the ability to merge each vendor response back into a database of some type - avoid data entry time and errors!

     The following describes how to quantitatively evaluate proposals from both the procedural and financial perspectives.

Side-by-Side Features Comparison

     The most basic means of evaluation is to compare RFP responses against each other and/or against a list of desired responses, weeding out the least favorable responses to narrow the field of competing proposals. In theory this sounds good, but in reality it becomes very cumbersome and confusing due to the large number of RFP questions involved in with many software applications. It is quite common for an accounting, ERP, or Document Management software RFP to have hundreds of questions, sometimes well over a thousand! These comparisons can become a paper nightmare if done manually, and keying the individual RFP answers into a spreadsheet can take forever. The potential for error is high.
     It is much easier, and more accurate, to compare responses using progressive LEVELS of IMPORTANCE. The first comparison is done with only the MOST IMPORTANT (sometimes called "Must Haves") features. This enables you to quickly eliminate some of the responses. You then do another comparison, this time at the MOST IMPORTANT & MEDIUM HIGH (sometimes called "Nice to Have") levels. Each comparison weeds out more proposals quickly and efficiently, but this technique also requires you to use a tool that can sort by Level of Importance.
      One such product is the Automated Product Evaluation System (APES). A comparison generated by APES, using all Levels of Importance, is shown below. Just click on this thumbnail image to see a full-size Side-by-Side comparison generated with APES.

Weighted Grade Point Score

     A highly effective method of matching a software system's features to your organization's specific business needs, i.e., prioritized task requirements. This is done by first assigning a SCORE to each software feature that indicates how well a given software system provides for that feature. For example, a YES answer could receive a score of one, (1.0), and a NO answer could receive a zero, (0).
     Once all the features have been scored, they are then multiplied by what is known as the Weight, which is a number indicating how important that feature or business task is to the final decision. For example, if Price will make up 30% of the decision, then a weight of .30 could be used. What is important is that this weight represent the relative importance of the criteria.
     It is this Weighted Score that actually communicates how well a given software product fits a specific set of needs. Each feature has been assigned a score, and that score has been multiplied by a weight indicating how much that score should affect the final decision, to produce the weighted score. For example, assume a certain software product supports feature XYZ, resulting in a score of one (1.0). Feature XYZ is relatively important, and it will account for 20% of the final decision, so it's weight is .20. The final weighted score for feature XYZ is 1.0 X .20 = .20.
     The above example is very simplified. In the real world the hundreds (thousands) of software features make weighted grade point scoring very complex, since each feature relates to an RFP question. To make matters worse, an individual software feature is just one of many making up a given software function or menu selection. And what about scoring Feature Support Matrix responses such as "Fully Supported", "Partially Supported", etc.?
     RFP evaluation software can automate this complex and time-consuming task. A good example is the Automated Product Evaluation System (APES). Just click on this thumbnail image to see a full-size APES Suitability comparison! (APES link)

Financial Ratios

     The major problem encountered when trying to compare competing software proposals is that they are ALL different! They all have different approaches to the same problem, different features, and different cost structures. One of the big benefits obtained from using an optimized RFP is the ability to compare software features and capabilities "apples-to-apples", but what about comparing their financial impact on your company? It is obvious the least cost system is not necessarily the best one to choose for many reasons, and simple Return on Investment (ROI) calculations do not take the "time value of money" into consideration.
     What is the time value of money? Basically, it is the concept that a dollar received today is worth more than a dollar received at some point in the future, because of inflation and the fact a dollar received today can be invested to earn interest. The "time value of money" becomes important when the relationships between a certain amount of money, a certain amount of time, and a certain rate of compound interest, are examined. For example, if two proposed software systems both cost about the same, how does one choose the better system? Or, when does spending money to acquire a new system become a bad investment over time?
     Clearly, better ways of analyzing the financial impact of a proposed system over it's useful lifespan are needed. Which is exactly what the ratios Present Value (PV), Net Present Value (NPV), and Internal Rate of Return (IRR), are for.
     The other big advantage of IRR, PV, and NPV is that they are very useful techniques for comparing competing software systems with different implementation schedules, platform requirements, and licensing plans, by making them all look like ordinary compound interest problems.
     Financial ratio analysis can be very beneficial, but calculating and comparing these ratios can be very tricky since each proposed system is different. Automating this complex and time-consuming task will save a lot of time. A good example is the Automated Product Evaluation System (APES). Just click on this thumbnail image to see a full-size Financial Ratio comparison created by APES!

VIII. The RFP as a Project Management Tool

     A properly written RFP is an excellent way of putting Earned Value Management (EVM), one of the most efficient project management techniques for software implementation, to work for your benefit. EVM is based on comparisons of actual and planned costs, the project master work schedule, and what are known Earned Value Metrics.
     Metrics are the aggregate collections of the discrete tasks associated with a specific project milestone and the estimated (planned) cost of achieving that milestone. Metrics are key to successfully using EVM, but are difficult to identify accurately because of the level of detail required. A simplistic example of Metrics is shown below for a conceptual software implementation project requiring a custom database, legacy database conversion, one primary business function, and one Web-enabled business function for users worldwide. The project milestones, and the discrete tasks required for each, are listed below. As you can see, the estimated cost for each Milesstone, or Metric, is simply the agregate cost of the individual tasks required to achieve that milestone. Of course, in real life one would have to add the initial costs of any hardware, software licenses, etc., but the concept is the same.

Sample Software System, total estimated cost = $34,000.00, broken out as follows:

      Milestone #1 - Database Installation, estimated cost = $8,000.00
          Project Completion = 10 %
          - Task 1, estimated cost = $1,000.00
          - Task 2, estimated cost = $2,000.00
          - Task n, estimated cost = $5,000.00

      Milestone #2 - Legacy document & database conversion, estimated cost = $3,000.00
          Project Completion = 10 %
          - Task 1, estimated cost = $1,000.00
          - Task 2, estimated cost = $1,000.00
          - Task n, estimated cost = $1,000.00

      Milestone #3 - Database maintenance procedures, estimated cost = $7,000.00
          Project Completion = 10 %
          - Task 1, estimated cost = $3,000.00
          - Task 2, estimated cost = $3,000.00
          - Task n, estimated cost = $1,000.00

      Milestone #3 - Business Function A, estimated cost = $10,000.00
          Project Completion = 40 %
          - Task 1, estimated cost = $5,000.00
          - Task 2, estimated cost = $4,000.00
          - Task n, estimated cost = $1,000.00

      Milestone #3 - Web enabled Business Function B, estimated cost = $6,000.00
          Project Completion = 30 %
          - Task 1, estimated cost = $3,000.00
          - Task 2, estimated cost = $2,000.00
          - Task n, estimated cost = $1,000.00

     EVM utilizes these metrics, the actual work completed, and the actual cost incurred to-date, to measure the actual progress made on a project. This is done by first calculating the actual work done, i.e., the project tasks completed, and total actual costs incurred, as of a specific date. A percentage completion of each Earned Value Metric is also calculated as of that date. This data is then compared with the project master work schedule and cost estimates to determine the actual Earned Value received for the actual expense incurred.
     Using our example above, lets calculate the Earned Value after achieving milestones #1 and #2, and spending $17,000 to get there. In our example, we have completed 20% of the project (see the Project Completion % for each milestone in the above example), and we spent $17,000 due to a large number of unanticipated inconsistencies discovered in the legacy document format, making quick scanning impossible. Manual corrections were needed in many places. The Earned Value calculates out as:
     Earned Value = $11,000 - the amount originally estimated what was needed. We have spent $17,000 to acquire $11,000 worth of the system. Another way of looking at this situation is we have spent 50% of the budgeted funds, ($17,000 out of 34,000) to acquire 20% of the project (see Project Completion % for each milestone in the above example). At this rate, it is going to take $85,000 to complete the project originally estimated to take $34,000 total. A detailed Earned Value management program would catch this problem early, if it were implemented.
     This all seems rather obvious, but is it? A real life project has hundreds of issues that need to be addressed, and many people in many locations. Given the hustle and bustle of each day, and the fact people are not in constant contact with each other, it might be a good while before everyone sits down to compare notes. It is not umcommon for top management to find out that 80-90% of the money has been spent, and that 60% of the project remains to be done, just 10 days before the project is due to go live! Earned Value has the ability to detect problem situations long before they become that drastic, but require a detailed baseline. This is where an optimized RFP comes into play!
     An optimized RFP is an excellent tool for identifying the Metrics pertinent to a project. Remember, the system requirements should be organized by business function (milestone). A Feature Support Matrix approach should be taken where necessary, forcing the vendor to commit to a cost if custom programming or configuration scripting is needed. These commitments, combined with a detailed costing matrix, allow the RFP to literally act as the cross-reference between time (and cost) and the software task (milestone) it should be applied to. This data enables a good Earned Value Management program.
     Going one step further, it is very reasonable to require the vendor to use time sheets that record time by project and project task, using the RFP Item number as the project where applicable. This allows you to actually monitor vendor progress independently, totally separate from vendor invoices. This advance notice of potential problems is an excellent tool for keeping your project on schedule!
    Earned Value Metrics vary by application set. A complete Business Process Workflow Checklist detailing typical business processes, with typical Earned Value Metrics, may be obtained here.