Connect with us
Advertise With Us

NEWS

Project Estimation: Practical Tips

Published

on

Despite the fact that responsibility for the numbers provided in the estimate rests with your dev team or software development partner, both you and your vendor are in charge of its accuracy.

To get an estimation goes beyond just having an idea and money to support it. Project owners must be able to express the project idea to the estimators, cast their vision, and plot the vector of the project evolvement. There are several considerations to make so as to avoid margin of errors and other forms of consequences that are generally not palatable.

Practical Tip For Project Stakeholders

This article is shedding light on some practical tips that can be used when you are putting together a software development project estimation. These tips will guide you to a reasonable estimation, help to avoid reviewing the budget repeatedly and overall, save your time.

Below are some tips to follow:

Highlight Your Goals

Starting a software project goes with stating your goals and commitments in writing. Have that in mind immediately after conceiving the idea for the project.

Your objectives in form of goals and commitments must coincide with the pressing needs of your business. You should also set a time vision of when you want your goal to be achieved.

This will help you assess if the business aim of the project is attainable considering the goals and time.

Have a Thought-Through Vision and Set of Requirements

A detailed requirement specification should be a document that contains requirement analysis, interface prototypes, competitor analysis, use cases, target users, etc. In other words, it reflects the exact vision of the expected product. The detailed specification enables the provision of a relatively fixed price and allows to envisage any risks related to the project.

The absence of a documented project requirements’ specification leaves you two options:

1. The first is creating a specification with the help of your development partner. You will need to provide them with all the available materials and have a set of discovery meetings and consultations.

Review and discuss the delivered specification to make sure you are on the same page.

2.The second option is managing a project with an agile development approach on a time and materials basis. Be aware that it can be a wild goose chase, especially if you are not working with a trusted IT vendor. Without the initial documentation to guide the project, an inexperienced

team can spend a lot of time and budget while making changes in the course of the project.

Consider the Non-Functional Requirements

Non-functional specifications serve a different use compared to the functional requirements that usually describe ‘what’ a system needs to perform. It is vital to consider the non-functional requirements, which expatiate ‘how’ the system should work.

With special reference to the nature of a project or business, non-functional requirements may have a different level of importance and relevance. Adopting non-functional requirements may also depend on the complexity of implementation.

A typical list of non-functional requirements may include such aspects as scalability, performance, high availability, security, usability, interoperability, and maintainability. Be ready to cover all these issues when discussing the project with your software development partner.

They are crucial for project planning and can significantly affect the estimation.

Collect And Compare Estimates From Various Sources

It’s of your interest to get bids for your project from different sources. There will always be different prices and timelines in the estimates you receive. However, the shortest timeline or most expensive doesn’t translate to the best.

Your final choice of vendor based on estimation must be well considered and justified. You should make a comparison of factors that have led to the estimated total such as:

Human resources: How many programmers will work on the project and what is their skill level.

Technology: What is the sophistication of technology employed for project development.

Work/Time frame: How long it will take to complete the project and what is expected to be

done.

Discuss The Assessment Of The Project

The estimation resulting from the discovery sessions should be discussed with the team that provides it.

Software development project estimation can be revisited to suit your expenses or meet the deadlines. Decide with the estimation team on what you can alter. You can both reach an agreement based on what is a priority and necessity as regards tasks for the project. A popular method of realising this is the MoSCoW developed by Dai Clegg of Oracle UK in 1994.

MoSCoW simply means:

M – Must have this requirement to meet the business needs

S – Should have this requirement if possible, but project success does not rely on it

C – Could have this requirement if it does not affect anything else on the project

W – Would like to have this requirement, but delivery won’t be this time.

Opt for A Team with The Relevant Experience

To avoid estimations made from trial by error, you should engage the services of a vendor experienced in the nature of your project. This will help you have a more realistic estimation as all the necessary assessment and consideration will be inclusive.

The experience of a good estimation team will be of great value if you have no requirements at all. In this case, the team will guide you through the requirements definition process and finally come up with a befitting estimation.

Man-Hours Vs Project Time Frame

This is a ratio that has a direct effect on the total cost of an estimation. You have to consider how soon you want the project to be ready. If you want the project delivery to be fast, then there should be more hands on the project, and that will increase man-hours and results to more cost.

A competent vendor with a skillful team might not necessarily need more man-hours as competence will regulate working speed. Competence will make the estimation to be minimal as both man-hours and project time will surely reduce.

Don’t be Ignorant of the Project Risks

All the projects of software production have risks involved and so they should be well analysed.

Mostly, software vendors include expenses to cover the risks in the estimation. Be sure to discuss possible risks with your vendor.

For example, the choice of third-party integrations can be a risk factor. Another form of risk is not adhering to regulatory policies relating to your project. All risks must be considered in the estimation to make sure the project plan and delivery eventually work out fine.

A Model Approach

Discovery Phase

The initial process is the discovery phase. It is a meeting between the expert team and the project stakeholders. The main objective of this session is to get a high-level understanding of the project. This can take more than one session depending on how big the project is or how

many details you can provide during the first session.

The vendor gets insight into the owners’ business, its goal, strategy, and operations process. This is achieved through specific target questions. In the course of the discovery phase, the vendor collects all your project requirements and details. This will help them provide an accurate outlook of the cost and timeline of your project, and create a competitive estimation.

Discovery session is irrespective of an available project requirement documentation. For establishing a level of trust, this session is preceded by signing a non-disclosure agreement (NDA) with a customer.

During this session, the following are considered:

1. High-level vision of the project

2. Identification of your business goals for the project

3. Discussion of project documentation

4. Elicitation of main project features

5. Detailing project scope

Presentation Of Estimation:

This is the last phase preceded by internal deliberations. The vendor in return meets with the client and reports the estimate. It is usually a ballpark estimation or a range. All the details of the breakdown arriving at the estimation total are explained with a justification.

Advertisement

MOST POPULAR

%d bloggers like this: