Skip to main content

Factors that may impact your estimation, Significantly

Listed below are the key factors that are to be considered while starting estimation for an application, as they may have significant impact on cost as well as overall schedule. Level of impact will vary based on the nature of the team that is going to carry out the development. Even though we can think that some of these factors are any way considered for estimation implicitly, they are listed here explicitly to ensure that they are not missed. So when we get a RFP to respond, keeping a ‘special eye’ on these factors will help us in arriving at a reasonable ‘ball-park’ figure.

Even we can allocate a percentage against each of this factor to indicate the level of impact each one has on overall estimation. After the execution of the project, these percentages can be verified with the actual figures and it can be used as benchmarks in subsequent estimation for similar types of application developments. There could be multiple factors that are related to these percentages. Once these factors are well documented, it will help in arriving at reasonable percentages upfront. It will help in arriving at reasonable assumptions when estimation is carried out with the limited availability of information. Also, it will help us to put required, relevant questions to clients before starting the estimation so that the ‘ball park’ figure will be close to actual one. 

  1. Nature of Integration with the legacy systems / other home grown internal applications / COTS applications / Partner integration
Some COTS products are service enabled so that it may be comparatively easy for integration. Same thing is applicable for SOA based applications. But when you have to deal with proprietary APIs or other types of integration like watching a particular folder for files based on some naming conventions and pre-defined templates, then it will impact the schedule. Similarly, in the scenarios where there is a need to integrate with partner systems like consuming partner web services , generating data in a pre-defined format, interacting with proprietary systems of partners etc. then additional time will be required because of the effort involved in learning.

  1. Proposed Architecture style of the application
When the proposed architecture of an application that is to be build is based on ‘client server’, then it will be comparatively less time when compared with that where a multi-layered, multi-tiered architecture is proposed. Development has to happen across multiple layers and similarly also the testing. In addition to that, system has to be tested in a distributed environment. All these will impact the schedule

  1. Nature of development platform
If the application development is proposed on a ‘homogenous’ platform then it will need less time when compared to a development where it has to be carried out on  heterogeneous platforms. Testing related to ‘interoperability’ issues will add time in addition on other normal tests.

  1. Significant Non-Functional requirements
Usually as part of ‘system requirement specification, non-functional requirements will be specified. In some scenarios, there will be a special demand on a particular QoS attribute. Say for example, in banking domain, the applications will be subjected to lots of security vulnerability tests like litmus testing, smoke testing, sanity testing, penetration testing, etc to ensure data, application, infrastructure and communication security. This is not a common requirement in general app. development scenarios. So in case of such special ‘Non-functional requirements’ extra time is required towards these additional tasks. These things may not be explicitly specified by clients. Based on the application nature, only the estimating professional should identify the need of such special tasks as part of development cycle and accordingly budget it. Also, they have to educate the customers as well to avoid any miscommunication.

  1. Life of the application / product
If the life of the application is going to be long, then lot of efforts will go towards good design so that the application does not need to undergo frequent fixes & changes. Similarly, if the final product is like a ‘app. Development framework’ based on which further applications will be developed in an Enterprise, then lot of time has to be spent to ensure that the framework will include all common functional and infrastructure components .

  1. Compliance to regulatory requirements
Additional learning curve and development effort to deal with industry standard data formats like FIX/SWIFT etc., to design the system to make it comply with regulatory requirements like SOX impact cost and schedule.

  1. Multilingual Capability
If an application need to be developed targeting multiple languages, then testing effort will increase based on no. of target languages. That too, if data need to be stored in database in different languages, it will add more cost when compared to the scenarios where only a multilingual display is required.


Popular posts from this blog

Lambda Architecture on Microsoft Azure

Gone are those days when Enterprises will wait for hours and days to look at the dashboards based on the old, stale data. In this fast world of BYOD, fitness gears and flooding of other devices, it is becoming super important  to derive out “actionable” information from huge volume of data / noise that is generated from these devices or any other data sources and act proactively on them  in real-time, to stay competitive. At the same time, the need for having dashboards and other analytical capabilities based on the quality, cleansed, processed data still very much exists. With the emergence of more data types and need to handle huge volume, shift is happening from the conventional data warehouse practice to cloud based data processing & management capabilities where high volume batch processing is possible at the optimized cost. Business scenarios demanding the need to process the data in real-time    More  

Heterogeneous Cloud Integration

Heterogeneous integration is common scenario in the Enterprises where their IT portfolio is based on heterogeneous platforms. Various solution approaches such as message broker, messaging middleware, SOA – service based integration were employed to address heterogeneous integration challenges.   These solution approaches were good when the integration happens on premise, with in the data centers of an Enterprise. Problem here is non-availability of “elasticity”.   With the Enterprises started leveraging cloud platforms extensively for various solution aspects such as elastic computing, storage, it opens new capabilities that can be leveraged for heterogeneous integration. Also, similar to existing on premise scenario, Enterprises are also leveraging multiple cloud platforms to address their business needs. This scenario will pose same integration challenges as those that were faced within on premise datacenters   Within datacenters / on premise, integration product

SharePoint 2013 Architectural Trade-Offs

When planning for deploying SharePoint 2013 based Enterprise workloads, it should be done with the consideration / awareness of impact of various architectural decisions what we make. As SharePoint 2013 is a flexible platform providing lots of options in terms of configuration of the existing OOB features and development of custom development solutions to address specific business functional needs, care should be taken when making a particular decision and its impact on overall solution. Even though SharePoint is a matured product, the effectiveness of various business capabilities such as Enterprise Social, Enterprise Search, BI, Document Management, Web Content Management, and Enterprise Content Management that will be delivered based on it, in terms of addressing the business requirements depends on architecture planning. Effectiveness here means performance, security, up-time and other architectural qualities like Scalability, Reliability etc. more ...