WO2013061324A2

WO2013061324A2 - A method for estimating the total cost of ownership (tcp) for a requirement

Info

Publication number: WO2013061324A2
Application number: PCT/IL2012/050411
Authority: WO
Inventors: Ynon SHILD
Original assignee: My Single Point Ltd.
Priority date: 2011-10-23
Filing date: 2012-10-17
Publication date: 2013-05-02
Also published as: IL215873A0; WO2013061324A3; WO2013061324A8

Abstract

The present invention relates to a method for providing a Total Cost of Ownership (TCO) for a new demand or requirement of a business process, comprising the steps of: a) providing a client server for generating a local database containing a plurality of parameters related to each new demand or requirement and/or for other business related processes and optionally defining additional parameter to the mandatory parameter defined herby; b) providing a coefficient value for each business process represented in said local database; c) assigning a weight for each provided coefficient, thereby prioritizing said multipliers and coefficients among themselves; d) calculating multiplier and coefficient grades each by summing up the product of each coefficient multiplying the corresponding weight; e) calculating one or more multipliers according to the parameters stored within said local database; f) setting threshold values for a Miss ratio and a Hit ratio for each phase of each specific business process; g) allowing initializing said local database either by entering initial values for each business process or by entering said new demand or requirement; wherein after initializing said local database for every requirement that triggered a request for costing— calculating the multiplier and coefficient grades each by summing up the product of each coefficient multiplying the corresponding weight, wherein the results of this calculation denotes the suggested value per named "Delivery phase" and the multiplying coefficient for each requirement level; h) when the actual values of the work vested on a specific requirement is received, then comparing the grades for calculating a recommended value, wherein in case the difference between a proposed new Median value and the actual value is greater than the STD, increasing the Hit ratio for said requirement level parameters for each phase respectively, otherwise increasing the Miss ratio for said requirement level parameters for each phase respectively; i) if the requirement level estimation has been changed, then either approving or rejecting said calculated recommended value, wherein the approving result in replacing the existing recommended value for said task type with the Median value of the perspective's task type.

Description

A METHOD FOR ESTIMATING THE TOTAL COST OF

OWNERSHIP (TCP) FOR A REQUIREMENT

Field of the Invention

The present invention relates to the field of cost calculation systems. More particularly, the invention relates to a method for suggesting the Total Cost of Ownership (TCO) for new demand / requirements, based on a novel algorithm that calculates the amount of work for any kind of operative task that appears in the context of a business requirement that is assessed according to predefined affecting parameters.

Background of the invention

Several Total Cost of Ownership models (TCO) were developed to evaluate the true cost of ownership of assets such as information technology (IT) systems or manufacturing equipment. In such cases the rewards of ownership are typically evaluated against the lifetime costs of ownership to determine the Return on Investment (ROI), i.e., the product with the highest ROI was chosen.

However, the growing number, complexity, and diversity of these systems poses significant challenges to today's information technology (IT) executive, not the least of which is choosing the right technology and deployment options for their organization. Another challenge is providing users an optimum system configuration, which includes not only computing hardware, but operating system, software applications, network connectivity, and effective access to the information resources they require to be productive.

For example, in the field of software development effort estimation, published surveys on estimation practice suggest that expert estimation is the dominant strategy when estimating software development effort. Typically, effort estimates are over- optimistic and there is a strong over- confidence in their accuracy. The mean effort overrun seems to be about 30% and not decreasing over time. The strong over-confidence in the accuracy of the effort estimates is illustrated by the finding that, on average, if a software professional is 90% confident or "almost sure" to include the actual effort in a minimum-maximum interval, the observed frequency of including the actual effort is only 60-70% "Better sure than safe? Over-confidence in judgment based software development effort prediction intervals", Magne Jorgensen et al., Journal of Systems and Software, Volume 70, Issues 1-2, February 2004, Pages 79-93.

Most of the research has focused on the construction of formal software effort estimation models. The early models were typically based on regression analysis or mathematically derived from theories from other domains. Since then a high number of model building approaches have been evaluated, such as approaches founded on case-based reasoning, classification and regression trees, simulation, neural networks, Bayesian statistics, lexical analysis of requirement specifications, genetic programming, linear programming, economic production models, soft computing, fuzzy logic modeling, statistical bootstrapping, and combinations of two or more of these models. The perhaps most common estimation products today, are the formal estimation models COCOMO and SLIM. There are also estimation approaches based on functionality- based size measures, e.g., function points, such as "use case points" as disclosed in "Improving Estimation Practices by Applying Use Case Models" by Bente Anda et al., Lecture Notes in Computer Science, 2002, Volume 2559/2002, 383-397.

Drawbacks of the prior-art

Expert estimation is on average at least as accurate as model-based effort estimation. In particular, situations with unstable relationships and information of high importance not included in the model may suggest use of expert estimation. This assumes, of course, that experts with relevant experience are available.

Formal estimation models not tailored to a particular organization's own context, may be very inaccurate. Use of own historical data is consequently crucial if one cannot be sure that the estimation model's core relationships (e.g., formula parameters) are based on similar project contexts.

Formal estimation models may be particularly useful in situations where the model is tailored to the organization's context (either through use of own historical data or that the model is derived from similar projects and contexts), and/or it is likely that the experts' estimates will be subject to a strong degree of wishful thinking.

The most robust finding, in many forecasting domains, is that combination of estimates from independent sources, preferable applying different approaches, will on leverage improve the estimation accuracy.

It is an object of the present invention to provide a method which is capable of dynamically building the organizational specific pricing catalog knowledge base while providing the ability to compare to benchmark figures held in a remote server of a cloud computing.

It is another object of the present invention to provide a methodology that assures the algorithm is reliable, explainable and maintainable.

Other objects and advantages of the invention will become apparent as the description proceeds. Summary of the Invention

The present invention relates to a method for providing a Total Cost of Ownership (TCO) for a new demand or requirement of a business process, comprising the steps of: a) providing a client server for generating a local database containing a plurality of parameters related to each new demand or requirement and/or for other business related processes and optionally defining additional parameter to the mandatory parameter defined herby; b) providing a coefficient value for each business process represented in said local database; c) assigning a weight for each provided coefficient, thereby prioritizing said multipliers and coefficients among themselves; d) calculating multiplier and coefficient grades each by summing up the product of each coefficient multiplying the corresponding weight; e) calculating one or more multipliers according to the parameters stored within said local database; f) setting threshold values for a Miss ratio and a Hit ratio for each phase of each specific business process; g) allowing initializing said local database either by entering initial values for each business process or by entering said new demand or requirement; wherein after initializing said local database for every requirement that triggered a request for costing— calculating the multiplier and coefficient grades each by summing up the product of each coefficient multiplying the corresponding weight (as demonstrated in tables 1,2 respectively), wherein the results of this calculation denotes the suggested value per named "Delivery phase" and the multiplying coefficient for each requirement level; h) when the actual values of the work vested on a specific requirement is received (both in the "Delivery phase" level and in the overall requirement cost assessment), then comparing the grades for calculating a recommended value, wherein in case the difference between a proposed new Median value (deriving from actual provided parameters) and the actual value is greater than the STD, increasing the Hit ratio for said requirement level parameters for each phase respectively, otherwise increasing the Miss ratio for said requirement level parameters for each phase respectively; i) if the requirement level estimation has been changed, then either approving or rejecting said calculated recommended value, wherein the approving result in replacing the existing recommended value for said task type with the Median value of the perspective's task type.

According to an embodiment of the present invention, the method further comprises: a) generating and maintaining a remote benchmark database containing a plurality of global parameters, wherein said global parameters represent a plurality of business related processes or requirements, wherein the values of said global parameters capable of being updated from a plurality of client servers or from other information sources; and b) matching between data captured in the local database and in said benchmark database for estimating the TCO, thereby said remote benchmark database is used as a reference source for each client server.

According to an embodiment of the present invention, for each new demand or requirement performs the following tasks:

a) assigning one or more resources required for delivering the work estimation and task type of each perspective; and

b) validating that all of the requirement level parameters are populated.

According to an embodiment of the present invention, the suggested value is affected by: a) a "Task" level which is a breakdown of the requirement into the delivery process life cycle tasks, wherein said task level holds the actual suggested values per "delivery service" in accordance to the parameters that appear in the requirement itself; and b) a "Delivery service" level, which determines the multiplier parameters for the work estimate of the entire requirement by summing up the task level work estimations assigned to the requirement, wherein the only parameter that should be considered by an authorized person assigning work estimation is the notion of "How much net work would it take me to complete this task". According to an embodiment of the present invention, for every task and delivery service levels, providing default perspectives that are inherited from the beginning of the business process or requirement. The method further comprises permitting adding additional perspectives for every view. For example, the suggested value for the tasks can be generated according to a predefined lifecycle of each business process.

According to an embodiment of the present invention, the perspectives create a denominator that is multiplied with the requirement total work estimation and reflects the elements that produce relatively larger costs. The perspectives may appear in a cloud computing and are being referenced in order to generate a benchmark as baseline.

Brief Description of the Drawings

In the drawing:

Fig. 1 schematically illustrates a system for implementing a method for suggesting the total cost of ownership for new demand, according to an embodiment of the present invention.

Detailed Description of Preferred Embodiments

The Figures and the following description relate to preferred embodiments of the present invention by way of illustration only. It should be noted that from the following discussion, alternative embodiments of the structures and methods disclosed herein will be readily recognized as viable alternatives that may be employed without departing from the principles of the claimed invention. Reference will now be made to several embodiments of the present invention(s), examples of which are illustrated in the accompanying figures. Wherever practicable similar or like reference numbers may be used in the figures and may indicate similar or like functionality. The figures depict embodiments of the present invention for purposes of illustration only. One skilled in the art will readily recognize from the following description that alternative embodiments of the structures and methods illustrated herein may be employed without departing from the principles of the invention described herein.

Unless otherwise indicated, the functions described herein may be performed by executable code and instructions stored in computer readable medium and running on one or more processor -based systems. However, state machines, and/or hardwired electronic circuits can also be utilized. Further, with respect to the example processes described herein, not all the process states need to be reached, nor do the states have to be performed in the illustrated order. Further, certain process states that are illustrated as being serially performed can be performed in parallel.

The term "cloud computing" refers herein to the delivery of computing as a service rather than a product, whereby shared resources, software and information are provided to computers and other devices as a utility over a network (typically the Internet).

The terms, "for example", "e.g.", "optionally", as used herein, are intended to be used to introduce non-limiting examples. While certain references are made to certain example system components or services, other components and services can be used as well and/or the example components can be combined into fewer components and/or divided into further components. In addition, while certain user inputs or gestures are described as being provided via data entry via a keyboard, or by clicking a computer mouse or button, optionally, user inputs can be provided using other techniques, such as by voice or otherwise. The terminology as described herein is intended to be illustrative and exemplary, and in no way limit the scope of the invention as claimed.

The present invention relates to a method which provides the TCO for a new business demand (or other requirement). The method is based on setting the foundation for "Accountability", meaning that selected persons are set as role members, which are authorized for setting parameters or providing approvals according to the best of their knowledge. For example, such selected persons can be assigned as stake holder / Role members and/or as experts in a specified process. The data repository of such processes refers herein to a "Service delivery catalog", "process delivery" or "business process".

Referring now to Fig. 1, a system 10 for implementing the method for suggesting the total cost of ownership (TCO) for a new business demand is shown in accordance with an embodiment of the present invention. System 10 comprises a Benchmark Data Base (BDB) 1 which used as a global reference source for any connected client's database, such as a client server 2. The BDB 1 is a knowledge database that contains records of the global terminology that is commonly used in each specific area (e.g., prices commonly charged for a specific type of service in any field, such as the current global price taken for preparing a specific juristic document). The client server 2 and the BDB 1 can be connected via any suitable network such as the Internet (as indicated by numeral 3), either via firewalls (as indicated by numeral 4 and 5) or other securing network. According to some embodiments of the present invention, the connection is established via a cloud computing form. The establishment of BDB 1 occurs when the role member in charge of assigning the two databases (i.e., the client server 2 and the DBD 1) matches the factors that are in use by a specific company are matched to the terminology that is in use in the cloud computing. In addition, each of the local estimation parameters updates the BDB 1 on a timely basis and may even receive updates, if such applicable.

Once the matching was done, a timely procedure shares the data from those connected clients into the BDB 1, the data transferred includes all the matched data gathered within the local knowledgebase of each client server 2.

In order to prevent updates duplications of data, the BDB tracks who is the sender (i.e., the client server 2) and what differentiations where captured from the last update.

According to an embodiment of the present invention, every request for sharing information from the BDB contains the identifiers of the client server requesting the benchmark data. The requesting party cannot "pull" the entire BDB but rather per query receive the data relevant for the appropriate scenario. The same process that applies to the "private knowledge base" (on the client server) applies here.

According to an embodiment of the present invention, two main parameters are required:

The requirement level parameter - denotes the work estimation for the tasks required for each business demand according to the requirement lifecycle break down of each business process; and The multiplier parameter - is determined according to the delivery process the business requirement was assigned to, for example if a requirement is assigned to a SAP Project System (SAP PS) module it will multiply any assessment determined by the "requirement level parameter" by this determined multiplier. This reflects the amount of complexity and such that will create a slack in estimation. This process affects the pricing of the requirement level and is adjusted according to the number of hits / misses of values provided with respect to a given threshold level (as described hereinafter with further details).

The process is built gradually by updating the BDB 1. The BDB 1 contains parameters such as the following (with the ability to take additional parameters (or other parameters) into account):

Examples for multiplier parameters of a business process level:

Entity type (Project, CR, Defect, SR, etc.)— union by default value (union by as presented in Table 1 below indicates the X column);

Group by parameters:

• Process

o Process name;

o Process "age" (e.g., in months);

o Number of changes performed to the process per year (or per other period);

o New business initiation / change to existing business process;

• Risk

o Number of risks assigned in average to each business process;

o Number of risks assigned to each business process each year;

• Maturity

o Required software reliability;

o Documentation presence;

o Delivery life cycle contains feedback from the customer

(yes/no);

o Process Maturity;

o Skill Maturity; o Technological Maturity;

o Managerial Maturity;

• Complexity

o Size of application database (The Constructive Cost Model -

COCOMO);

o Expert level required;

o Technology (managing list of weighted values);

o Number of applications involved in the business process development (minor/major);

• Hardware attributes (COCOMO)

o Run-time performance constraints;

o Memory constraints;

o Volatility of the virtual machine environment;

o Required turnabout time;

An example for a business process level overlay is shown in the following Table 1. It is important to mention that the service owner "grades" every attribute per service, for example due to the maturity level of a SAP Business information Warehouse (SAP BW) every type of requirement should be multiplied by 1.1 in order to reflect the slack factor:

Table 1 In Table 1, the numbers in each cell represent the percent that needs to be added to 1 (i.e., to 100%, e.g., multiplier parameter = 1+0.5 = 1.5) in order to denote the multiplier parameter. For example, if only one perspective is available, than the multiplier parameter in the relevant cell will be in considered, if more than one perspective is available than every multiplier in each relevant cell will be weighted according to the priority of the perspective (see examples for several perspectives in the right column of Table 1, the priority is represented in Table 1 by the term "Pr"). Each perspective includes the perspective's type (e.g., release item, project, defect, etc.) and the process or delivery name (e.g., SAP PS, SAP BW, etc). Wherein, in this example the process or delivery name is the SAP BW which is a combination of databases and database management tools that are used to support management decision making.

Requirement level multiplier parameters:

Union by parameters

• Process name;

• Entity type (e.g., Project, CR, Defect, SR, etc.);

• Delivery phase (e.g., design, development, testing);

Group by parameters

• Risk

o Requirement risk grading;

• Maturity

o Documentation presence;

o Delivery life cycle contains feedback from the customer

(yes/no);

o Skill Maturity;

• Complexity

o Number of participating organizational units;

o Number of subcontractors involved;

o Fixed priced project (yes/no); o Overheads for large operations flag;

o A Gantt chart (or other form that illustrates a project schedule) is assigned to the requirement;

• Priority

o Category Type (type of demand / requirement)

o Customer Priority / Importance

o Delivery Priority/ Importance

The following Table 2 shows an example for the Requirement level structure overlay:

Table 2

Abbreviations for Table 2:

Pr = Priority

Hi = High

Reg = Regular

Lo = Low In Table 2, the numbers in each cell represent the actual recommended work estimation for the cross in the matrix. For example, if only one perspective is available than the number in the cell will be in place, but if more than one perspective are available than every multiplier in the cell will be weighted according to the priority of the perspective (as described hereinbefore).

The total suggested value = for each perspective with values, multiply the suggested value for each perspective with the perspective's weight; than sum the values from above to generate the weighted suggested value in the requirement level.

Process description

Set up steps (for example, this can be done by an authorized person— so called the "process owner"):

1. The following two "levels" affects the suggested value:

a. "Task" level, which is a breakdown of the requirement into the delivery life cycle task, for example: design, development, QA, etc. This will hold the actual suggested values per "delivery service" in accordance to the parameters that appear in the requirement itself, e.g. the parameters are dynamically built once a requirement is being assigned with work estimates;

b. "Delivery service" level, which determines the multiplier parameters for the work estimate of the entire requirement (summing up the task level work estimations assigned to the requirement). For example, if the work estimate is X and requirement belongs to a "delivery service" that has a multiplier of 1.5, the suggested work estimates would be (1.5*X). This multiplier represents the margins needed to be saved that are expected to affect the work estimations in order to prevent the situation in which the same factors are considered twice (once cognitively by the person assign estimation and by the process) - a clear annotation will indicate which parameters where included in the calculation process. The only parameter that should be considered by the person assigning work estimation is the notion of "How much net work would it take me to complete this task"; For every "levels", providing default perspectives that are inherited from the start (compulsory)— as described with respect to Table 2 hereinabove. The process permits adding additional perspectives for every view, wherein there are two types of perspectives:

a. Group by perspectives; and

b. Union perspectives.

- The process of the present invention generates the suggested value for the tasks according to the predefined lifecycle;

- The process related perspectives creates a denominator that is multiplied with the requirement total work estimation and reflects the elements that produce larger costs;

- These perspectives can appear in a cloud computing and can be referenced in order to generate a benchmark as baseline. For every level, defining the list of additional perspectives for the estimation process (could be endless number of factors); Optionally, matching / assigning the perspective added to the benchmark knowledgebase perspective in order to set reference. For example "type" - e.g. "views"; For each perspective, defining the possible list of values (e.g., list); Optionally, assigning the list values added to the benchmark knowledgebase list of values in perspective to the assigned perspective in order to set reference; 7. For every entry in the "Service Deliver" catalog, defining the process delivery owner, which is accountable to input for every delivery process the following tasks:

a. defining the mandatory phases by delivery phases list (e.g., design, development, QA, etc.);

b. defining threshold score for alert for hit and miss parameters; c. providing the data for all the "Factors" & "Perspectives" weights described in steps 2-6 (the following steps 8-9 are done by the algorithm process owner);

8. Prioritizing each list for each perspective, either by positioning (i.e., the relative position or order of each value in the list) or by using pair wise comparison, according to the number of list values; and

9. Prioritizing the perspective themselves so that each perspective received a weight (total weights sum up to 1).

Assessing the threshold value and count for re-assessment

In the prior-art there are several known methods to measure the average estimation accuracy. The most common measures of the average estimation accuracy are the MMRE (Mean Magnitude of Relative Error), where MRE is defined as:

MRE = I actual effort - estimated effort | / | actual effort |

There are other alternative measure methods, such as more symmetric measures as suggested by Y. Miyazaki et. al. "Robust regression for developing software estimation models", Journal of Systems and Software, Volume 27 Issue 1, Oct. 1994, Weighted Mean of Quartiles of relative errors (WMQ) by Bruce Lo et. al. "Assessing Software Cost Estimation Models: criteria for accuracy, consistency and regression", Australasian Journal of Information Systems, Vol. 5, No. 1 (1997), and Mean Variation from Estimate (MVFE) by R.T. Hughes et. al., "Evaluating software development effort model-building techniques for application in a realtime telecommunications environment", Software, IEE Proceedings, Volume 145, Issue 1, pages 29 - 33, 1998.

For example, according to an embodiment of the present invention, the method of the present invention can measure the average estimation accuracy using the known student t-distributed reading in order to support the model when estimating the mean of a normally distributed population in situations where the sample size is small and population standard deviation is unknown. In probability and statistics, Student's t- distribution (or simply the t- distribution) is a continuous probability distribution that arises when estimating the mean of a normally distributed population in situations where the sample size is small and population standard deviation is unknown. It plays a role in a number of widely-used statistical analyses, including the Student's t-test for assessing the statistical significance of the difference between two sample means, the construction of confidence intervals for the difference between two population means, and in linear regression analysis. The Student's t- distribution also arises in the Bayesian analysis of data from a normal family. The t- distribution is symmetric and bell-shaped, like the normal distribution, but has heavier tails, meaning that it is more prone to producing values that fall far from its mean. This makes it useful for understanding the statistical behavior of certain types of ratios of random quantities, in which variation in the denominator is amplified and may produce outlying values when the denominator of the ratio falls close to zero. The Student's t- distribution is a special case of the generalized hyperbolic distribution.

Every breach of threshold increases the miss count and updates the suggested value with the new mean value, once the count breaches the "count threshold". Every hit of the actual value to the suggested value increases the validity of the measurement (either requirement \ process level). In addition collaborative abilities allow exchanging verbal comments and explanations in order to convince the algorithm process owner.

Examples for statistics to be displayed

• Planned estimate work per skill per task type

o Median (deriving from actual values provided by the process owner);

o Average;

o STD (Standard Deviation);

o Prediction interval (PI) - Prediction interval;

o Count threshold breaches;

o New Value suggested;

• Planned estimate cost per cost item per category of cost items

o Median;

o Average;

o STD;

o Prediction interval (value for allowed deviation of planned vs. actual before the recommended value is overrun by the actual

Median value);

o Count threshold breaches;

• Actual estimate work per skill per task type

o Median;

o Average;

o STD;

Median value);

o Count threshold breaches;

• Actual estimate cost per cost item per task type o Median;

o Average;

o STD;

Median value);

• Recommended estimate work per skill per task type

o Current value;

o New Value suggested;

In conclusion, the TCO method of the present invention not only dynamically builds the organizational specific pricing catalog knowledge base, but also adapts methodology that assures the algorithm is reliable, explainable and maintainable in the application. Thus, the present invention provides a novel and efficient method for estimating the software development effort, which significantly improves the accuracy of the estimating process.

The Total Cost of Ownership system of the present invention, is a software based tool intended to provide the most probable overall program cost for a given task and to compare those costs either to an overall estimate of industry average (ERC) costs, via the benchmark database, for like- services, or, more effectively, to the user's existing or alternative program. The software uses recent historical data as the basis for the comparisons. In order to better match a user's situation, the software allows for controlling several of the major cost-driving "input variables" in related to the task field in each of several major cost generating areas.

While some embodiments of the invention have been described by way of illustration, it will be apparent that the invention can be carried into practice with many modifications, variations and adaptations, and with the use of numerous equivalents or alternative solutions that are within the scope of persons skilled in the art, without departing from the spirit of the invention or exceeding the scope of the claims.

Claims

1. A method for providing a Total Cost of Ownership (TCO) for a new demand or requirement of a business process, comprising the steps of:

a) providing a client server for generating a local database containing a plurality of parameters related to each new demand or requirement and/or for other business related processes;

b) setting threshold values for a Miss ratio and a Hit ratio for each phase of each specific business process, thereby maintaining the integrity of the current expected pricing for each phase; c) calculating one or more coefficients according to the parameters stored within said local database;

d) providing a multiplier value for each business process represented in said local database;

e) assigning a weight for each calculated multiplier and for each provided coefficient, thereby prioritizing said multipliers and coefficients among themselves;

f) allowing initializing said local database either by entering initial values for each business process or by entering said new demand or requirement; wherein after initializing said local database for every requirement that triggered a request for costing — calculating the multiplier and coefficient grades each by summing up the product of each coefficient multiplying the corresponding weight (as demonstrated in tables 1,2 respectively), wherein the results of this calculation denotes the suggested value per named "Delivery phase" and the multiplying coefficient for each requirement level;

g) when the actual values of the work vested on a specific requirement is received (both in the "Delivery phase" level and in the overall requirement cost assessment), then comparing the grades for calculating a recommended value, wherein in case the difference between a proposed new Median value (deriving from actual provided parameters) and the actual value is greater than the STD, increasing the Hit ratio for said requirement level parameters for each phase respectively, otherwise increasing the Miss ratio for said requirement level parameters for each phase respectively;

h) if the requirement level estimation has been changed, then either approving or rejecting said calculated recommended value, wherein the approving result in replacing the existing recommended value for said task type with the Median value of the perspective's task type.

2. A method according to claim 1, wherein for each new demand or requirement: a) assigning one or more resources required for delivering the work estimation and task type of each perspective; and b) validating that all of the requirement level parameters are populated.

3. A method according to claim 1, wherein the suggested value is affected by:

a. a "Task" level which is a breakdown of the requirement into the delivery process life cycle tasks, wherein said task level holds the actual suggested values per "delivery service" in accordance to the parameters that appear in the requirement itself; and

b. a "Delivery service" level, which determines the multiplier parameters for the work estimate of the entire requirement by summing up the task level work estimations assigned to the requirement, wherein the only parameter that should be considered by an authorized person assigning work estimation is the notion of "How much net work would it take me to complete this task".

4. A method according to claim 3, wherein for every task and delivery service levels, providing default perspectives that are inherited from the beginning of the business process or requirement.

5. A method according to claim 4, further comprising permitting adding additional perspectives for every view.

6. A method according to claim 3, wherein the suggested value for the tasks are generated according to a predefined lifecycle of each business process.

7. A method according to claim 1, wherein the perspectives create a denominator that is multiplied with the requirement total work estimation and reflects the elements that produce relatively larger costs.

8. A method according to claim 7, wherein the perspectives appear in a cloud computing and they are being referenced in order to generate a benchmark as baseline.

9. A method according to claim 1, further comprising a) generating and maintaining a remote benchmark database containing a plurality of global parameters, wherein said global parameters represent a plurality of business related processes or requirements, wherein the values of said global parameters capable of being updated from a plurality of client servers or from other information sources; and b) matching between data captured in the local database and in said benchmark database for estimating the TCO, thereby said remote benchmark database is used as a reference source for each client server.