The company has financial experts, economic experts, and software engineers. These are the primary decision makers that take up of most of the labor cost. (I.4)

The company relies on industry expertise and experience. (I.4)

Their revenue comes half from consulting and half from license sales (I.4)

Software development team focuses on feature enhancements that they want to get for next version of the software. (I.4)

They focus on software critical needs add on. (I.7)

Estimate how much revenue that the product plans to bring in for the company (I.8)

Estimate and determine how many software developer they can afford within the budget (the number of hours software engineer can work that determine how much work they can do for the project) (I.8)

They come up with a list of features they want to add and prioritize the features on the list. (I.8)

Create 6-month version schedule for software. (I.8)

They use Microsoft Project to track schedule (I.9)

Base on the experience it is harder to estimate products being developed than the existing products (I.10)

Currently they use estimation system in which they double the estimated hours require by software engineers (I.26)

The historical data is critical for estimate time frame for current project (I.11)

Current system cannot take into account the relative skill levels of software engineer. They want to add this feature for their system. (Skill levels: beginner, intermediate, expert) (I.12)

It is hard to split tasks among multiple people since they have to set up precedence. They have to complete one task before they move to the next task so they put all people on every task and it is hard to get too detail or hard to see which resource is working better or worse than planned. (I.13)

Before they have the first version out, they have no constraint, and they focus more on creating new products (I.14)

Now they have the first product out, they have to get every enhancement justified (I.13)

Since the first version is out each feature has more realistic estimation (close to the reality) (I.10)

They involve software engineer into estimation process before going to the management (I.15)

They evaluate how much existing codes can be use in order to keep costs down (I.15)

Developers, clients, managers negotiate to agree on which feature to be added (I.15)

They sell pre-packet software and once the first version is out they receive clients’ inputs and they create next version every six months and they take into account competitors’ product features also (I.16)

They use waterfall model development for software estimation (I.17)

During the development of the first version they don’t receive inputs from clients (I.14)

They don’t receive critique interface until the next version comes out (I.14)

The manager gives developers requirements and developers write up what they think the manager’s requirements are and the manager reviews them (I.17)

Sales person involves in the development process. He gets information from clients and tells developers what clients need (I.27)

The clients concern about their financial data therefore they want to have password protection. (Currently they don’t have security feature so they rely on the operating system) (I.22)

They have unpredictable uncertainties so they need to allow padding (I.14)

Sometimes it becomes iterative development even if they don’t want it to be (I.24)

Development requirements come from product consultants, software engineers, and sales person (I.27)

They do two major software estimation and a few minor one a year (I.31)

There is no budget for each project and the cost is staff that his allocated per year (I.29)

Ask specific questions of the developer to find out what software will be newly developed, what will be reused with no changes and how much software will be modified.

In sizing the application be flexible so you are able to accommodate any new technology.

Use your historical data to provide insights about how the organization has assimilated changes in the past and what your current capability is today. Look at your new situation and apply some professional judgment backed up by empirical evidence.

Set reality expectations – be on the conservative side in your choice of estimation assumptions.

Bound your estimates with probability analysis – This quantifies the amount of uncertainty in the estimate consistent with the quality of the input assumptions.

When appropriate present alternative estimating scenarios (add more people, reduce function, etc.).