Your budget is spent, and your new system is not even halfway developed.
The project overran, by a lot, and the reason for the overrun is factual and it makes sense. It is no-one’s fault, so where did it go wrong?
The answer is: RIGHT AT THE START!
In the last couple of years, we have seen many projects overrun with the main contributor being under estimation.
Many hours and meetings were spent to try and figure out how to solve this problem.
We implemented policies where templates, with a predefined list of features, were used that must be included in the estimation. We involved more technical people in the estimation process to try and identify unseen factors that may popup down the line.
We created a "two-factor approval" process to ensure that the process was kept within the policies, procedures, and rules.
Albeit that there was a drop in the overrun projects, due to the measures put in place, a few still proved to be problem.
So why do the projects keep being underestimated?
The answer is easy: Too little time and effort is being spent on the analysis of the system.
Because analysis forms part of the Systems Development Life Cycle (SDLC) and subsequently, the project, it is usually included in the total estimation of the project.
A better approach is to use the analysis phase to estimate the time and cost of the project.
More time than what was anticipated, is spent on the analysis phase because when the stakeholders start seeing and reading the design of the new system, new ideas kick-in. These new ideas become new enhancements and changes to the current scope, and so the snowball effect starts.
Please don't misunderstand, it is a great thing to bring better ideas to the table to enhance the system. It comes naturally to users who want to create a better system. A better way to budget for a project is to spent time on analysis and get all the juicy ideas and changes in a document, which we call the Business Requirements Specification (BRS), before estimating the cost and time of the project.
There is no need to mention the benefits of scoping the project with educated estimates, rather than not, but I am going to name a few:
More accurate Project budgeting
Better Project planning and timeline estimation
Enhanced team and stakeholder identification
Detailed architecture and design of the system diagram
Less technical debt.
That last item is a very important consideration for cost saving in maintenance of the new system.
Technical debt can be explained using a bank loan as an analogy.
When you take out a loan with the bank, it means you have access to funds earlier than saving for it. But that comes at a cost in the form of interest, in other words, you are buying time with the loan.
Developing a system works in a similar way.
It takes time to engineer proper code according to coding standards. Developers will engineer code that makes changes easier and quicker, but again, that takes time.
So, when a developer is being placed under pressure, that precious time is taken away (like buying time) and he/she is forced to develop in a rush, delivering less optimal code. The system still functions 100% as desired, but now, future changes and enhancements can take more time to implement, and time is money!
One can say that you are now paying back the interest of the loan (time).
First Digital have skilled Business Analysts who can analyse by means of workshop sessions with the users to create the BRS document.
Chat to us about our no-cost business analysis services. We’ll help you understand exactly what systems you need to build, and we will offset the full cost of this analysis when we build the solution for you.
Ts & Cs apply, as always. :)
Call us today so we can save you money.
Niel Steyn
Operations Manager : Innovation & IoT
Comments