Cost estimation software project planning

For larger, complex projects — team resources usually fulfill only one role to effectively move the project forward. Rough estimates of team sizes may include the following structural roles:. Unfortunately, it is not that easy. As mentioned earlier, some resources may play more than 1 role on a project. They may be needed to confirm coding is meeting design requirements, or be available to tweak the design, but full-time is no longer necessary. A project team should work like a well-rehearsed production.

Done well, necessary resources come on and off the project with no noticeable lapses in productivity. Now applying the cost of a team with the project time estimates from the chart above, we can finally come to a project cost. If the estimated cost is reasonable to everyone, then a more detailed quote can be generated, followed by a full project plan outlining the actual costs and milestones. To put this all into context we put together the following list of representative projects:.

Resolution of a known issue in existing software that we are maintaining. This assumes that the cause of the issue is known, and the issue affects a minimal number of objects. Often the first step for many startups, these projects tend to focus more on the look and feel of a new application and the possibility of achieving the desired outcome, more than providing functionality. Standalone application for iOS and Android.

Now you know the steps and factors that go into reaching a cost estimate for software development. As stated earlier, every project is unique and cannot be costed using an exact formula, but defining project type and size, team size and resource costing get you the basics when determining your budget range.

We have experience with projects at all levels of complexity and teams of all sizes. If you are in need of a custom software solution we can help you define and cost your project with no obligations.

Contact us to help you improve your enterprise software. We offer a free consultation to give you a cost comparison specific to your environment. Contact Us. Your Name required. Your Email required. Company required. Phone required. How many HoloLens do you need? Which package are you interested in? How many licenses of Dynamics do you need? Skip to content. How Time and Effort Differ. These things can include: The ability of a client to dedicate staff to work with the project team for requirements analysis, design checks and user testing What does it take to get database or system access, Is this a quick call to a DBA, or is there an approval process that has to get committee approval?

How easy is it to get firewall changes What needs to be done to get a cloud-based solution approved What is the deployment process? Type of Software Project From a high level, typical software development engagements tend to break down into the following types: New Software Development — new software, involving custom development.

Web Development — custom web-based software development Each of these types of projects typically has a different team makeup and requires a different amount of development effort. Size of Software Project The next step is to determine the size of a project. Generally, project sizes fall into the following categories: Small — A small project usually involves minor changes. Large — These solutions include more depth and complexity.

Enterprise — This level would be a large project on steroids. Development Team Size per Project Once the project is defined in terms of type and size, the next factor to be determined is the team size. Straightforward Estimate. For example, the effort of a tester is usually expected to be a percentage of the entire project. The cost of a tester is based on this percentage.

If your project requires a team, you are paying for a mix of skill sets. Scheduling and maintaining a dedicated project team is instrumental in completing the project most efficiently.

There is nothing more detrimental to a project than continually stopping and starting- it can be hard to regain the momentum to get the project back on track.

Features describe the attributes required in the software as per the user requirements. Constraints describe the limitations imposed on software by hardware, memory , and so on.

Interfaces describe the interaction of software components like modules and functions with each other. Project scope also considers software performance, which in turn depends on its processing capability and response time required to produce the output.

Once the project scope is determined, it is important to properly understand it in order to develop software according to the user requirements.

After this, project cost and duration are estimated. Lf the project scope is not determined on time, the project may not be completed within the specified schedule. Project scope describes the following information. Note that the project management and senior management team should communicate with the users to understand their requirements and develop software according to those requirements and expected functionalities.

The project planning process involves a set of interrelated activities followed in an orderly manner to implement user requirements in software and includes the description of a series of project planning activities and individual s responsible for performing these activities. In addition, the project planning process comprises the following. Project planning process comprises several activities, which are essential for carrying out a project systematically.

These activities refer to the series of tasks performed over a period of time for developing the software. These activities include estimation of time, effort, and resources required and risks associated with the project. Project planning process consists of the following activities. Once the project objectives and business objectives are determined, the project end date is fixed.

The project management team prepares the project plan and schedule according to the end date of the project. After analyzing the project plan, the project manager communicates the project plan and end date to the senior management. The progress of the project is reported to the management from time to time. Similarly, when the project is complete, senior management is informed about it.

In case of delay in completing the project, the project plan is re-analyzed and corrective actions are taken to complete the project. The project is tracked regularly and when the project plan is modified, the senior management is informed. As stated earlier, a project plan stores the outcome of project planning. It provides information about the end date, milestones, activities, and deliverables of the project.

In addition, it describes the responsibilities of the project management team and the resources required for the project. It also includes the description of hardware and software such as compilers and interfaces and lists the methods and standards to be used. These methods and standards include algorithms, tools, review techniques, design language, programming language, and testing techniques.

A project plan helps a project manager to understand, monitor, and control the development of software project. This plan is used as a means of communication between the users and project management team. There are various advantages associated with a project plan, some of which are listed below. Note that there are differences in the contents of two project plans depending on the kind of project and user requirements. Atypical project plan is divided into the following sections.

These plans include quality assurance plan, verification and validation plan, configuration management plan, maintenance plan, and staffing plan. Quality Assurance Plan. The quality assurance plan describes the strategies and methods that are to be followed to accomplish the following objectives. Verification and Validation Plan. The verification and validation plan describes the approach, resources and schedule used for system validation.

The verification and validation plan, which comprises the following sections. General information: Provides description of the purpose, scope, system overview, project references, acronyms and abbreviations, and points of contact. Purpose describes the procedure to verify and validate the components of the system.

Scope provides information about the procedures to verify and validate as they relate to the project. System overview provides information about the organization responsible for the project and other information such as system name, system category, operational status of the system, and system environment.

Project references provide the list of references used for the preparation of the verification and validation plan. Acronyms and abbreviations provide a list of terms used in the document. Points of contact provide information to users when they require assistance from organization for problems such as troubleshooting and so on. Reviews and walkthroughs: Provides information about the schedule and procedures. Schedule describes the end date of milestones of the project.

Procedures describe the tasks associated with reviews and walkthroughs. Each team member reviews the document for errors and consistency with the project requirements. For walkthroughs, the project management team checks the project for correctness according to software requirements specification SRS. System test plan and procedures: Provides information about the system test strategy, database integration, and platform system integration. For instance, if the comparability of previous work and the current project is assessed or adjustments to parametric estimates are determined.

Analogous estimating refers to the use of observed cost figures and related values in previous projects or portions of a project. In order to be accurate, the type and nature of these reference activities must be comparable with the current project. This technique uses historical data in the form of values and parameters to determine the expected resource requirements of a current project.

The historic values are adopted for the current work and can be adjusted for differences in scope or complexity. Analogous estimating is categorized as a gross value estimating approach.

In general, analogous estimates are used if a project has access to historical data on similar types of work while the details and resources for more accurate estimates in the current project, such as parametric or bottom-up estimating, are not available.

Parametric estimating is a statistical approach to determine the expected resource requirements. It is based on the assumed or proven relationship of parameters and values. Simple examples are the building cost per square foot in construction projects or the implementation cost per data field in IT projects.

The input data can be obtained from previous projects or external data sources such as industry benchmarks or publicly available statistics. In practice, this technique is employed with a broad variety of sophistication and accuracy. In projects that do not use an explicit statistical correlation analysis, some expert judgment is required to assess whether it would be reasonable to apply the historic parameters to the current project.

Complexities of projects and activities vary and may therefore require certain adjustments. For instance, building a highway in a mountainous region likely produces a higher cost per mile than in a flat area. IT development projects in complex IT architectures or systems tend to require more resources than a less complex environment. Another consideration concerns the expertise and experience of the project team.

If a previous project was delivered by highly skilled and experienced resources while the current team is just at the beginning of its learning curve, using unadjusted historic data may understate the estimated cost. Similar to analogous estimates, adjustments can be made to adapt the parametric estimates to the current project.

Depending on the quality of the input data and its applicability to the current type of work, the parametric estimation technique can produce very accurate figures. However, the higher the accuracy desired the more resources are needed to perform the data gathering and statistical analyses. Bottom-up estimation refers to a technique that involves estimating the cost at a granular level of work units. The estimates for all components of a project are then aggregated in order to determine the overall project cost estimate.

In practice, these estimates are often performed at the lowest level of the work breakdown structure WBS , e. While there is no clear rule on who should be performing this estimation, it seems to be a good practice in project management: asking those project team members who are operationally in charge of the respective work packages or activities to estimate there on work.

Thus, this approach to estimating costs often comes with significantly higher accuracy than top-down estimations. However, obtaining and aggregating these granular estimates normally requires some resources and can potentially become a political challenge, especially in large or complex projects. Three-point estimating is a technique that usually leverages on bottom-up estimates, analogous or expert estimates.

The concept requires three different points of estimates: the optimistic best case , pessimistic worst case and the most likely cost estimate. This can be done by assuming a triangular distribution, a PERT or beta distribution.

Read this article for further explanation and examples of this technique.