By Syed Mamnun Quader, Managing Director & CEO, Southtech Group
This paper addresses the difficulties of estimating and budgeting software projects for government entities in Bangladesh.
Thereafter, it outlines a framework that practitioners in the IT Industry can use to arrive at their own estimation and costing depending on their internal processes and pricing strategies.
As this paper focuses on government projects, it is important to understand that certain constraints exist in government administration. It is highly important to understand these constraints to avoid errors of judgment.
The primary constraints are:
- A budget has to be fixed before any project can be initiated
- Requests for budget are mostly not fully approved, e.g., where 500 workstations are required for realizing the full potential of automation, only 100 are approved resulting in partial fulfillment of automation benefits
- Lack of sufficient IT expertise within government entities during project scoping
- Usually during budget preparation, hardware is given a much higher priority and allocation of funding than software applications, whereas in reality the difficult and more costly part is in the development of bespoke software applications and data conversion,
- There is always a weighting on the financial offer from the bidders and so all bidders try to be most competitive in terms of cost
- There is usually no arrangement of allocating an adequate number of procurement entity personnel to engage during solution development. Architecting the data conversion process can become a huge hurdle and can become a more time-consuming task than the development of the software itself
- Budgets mostly do not include the cost of departmental personnel required to take over the system when the project turns into “business as usual”
- Hiring IT professionals or consultants or even data entry personnel follows a separate departmental process which is mostly very time consuming
- Once an automation project is deployed after much struggle, many projects fall into disuse because of (a) lack of ownership (b) tenders mostly require financial offer to include post-implementation support up to a certain time but no further budget is allocated after contract expiry
Realistically speaking, it will be very difficult to make significant changes to the above-mentioned Points 1, 4, 5, 7, and 8 in the immediate future.
However, the other points mentioned may perhaps be taken up by A2i and BASIS to bring about the necessary changes in the short to medium term.
In the context of the above, it is also important to discuss software development methodologies (e.g., waterfall, incremental, V-model, iterative, agile, etc.) where each methodology follows a particular life cycle and involvement of stakeholders in order to ensure a successful outcome.
Each of these methodologies has its own system development life cycle (SDLC) and software testing life cycle (STLC); I am assuming here that the STLC is incorporated in the SDLC process. Regardless of the methodology chosen, there are generally six phases in every SDLC, which are: (a) Requirements Gathering and Analysis, (b) Design, (c) Implementation or Coding, (d) Testing, (e) Deployment, and (f) Maintenance.
In government projects, the budgets are fixed before official tendering. Vendors are required to bid for projects with a financial offer and winning bidders are held responsible to complete the project within set deadlines and within their financial offer. Since every phase of the entire SDLC process has cost involvement, estimation and availability of financial and other resources at various stages of the project are vital for successful delivery.
It should also be recognized that not all methodologies can be applied in government projects, e.g., agile methodology requires close involvement of knowledgeable project owners at the end of every 14 or 30-day sprints, a requirement almost impossible to fulfill currently. Most often, therefore, scope and budget are difficult to reconcile.
Government departments usually have a mindset for the waterfall methodology. Their focus is to arrive at an “accurate” budget and schedule before publishing a tender. They normally believe that to do so, a “comprehensive” list of requirements has to be prepared without realizing that these requirements are actually very brief for the purpose of development and therefore each requirement branch out to many other requirements. Furthermore, the schedule is not based on how complex the project is but by the pressure imposed on them by high-ups to implement certain objectives within an arbitrary deadline.
Software practitioners know that determining the scope of a project is the most critical and time-consuming exercise of the SDLC process. Technical architecture, component design, coding, testing, training, documentation and resource allocation at every stage of the project’s work breakdown structure (WBS) depend on this scope.
Unfortunately, most projects are not properly scoped, even though it is a known fact that poor project scoping leads to spectacular project failure at worst or partial success at best.
As the remaining phases of the SDLC process are left to the vendor to complete without any mention of specific involvement of the procuring entity’s personnel at different stages of the SDLC process, costs can suddenly escalate unexpectedly and inordinate delays may result causing overall financial loss to the vendor.
Furthermore, as the budget and schedule are “official”, any opportunity of refining the requirements or proposing re-engineering of processes to achieve better results, are not easily approved due to budgetary constraints, ownership issues and accountability concerns in the procurement entity’s chain of command.
The absence of any Change Control Board (CCB) in government contracts often leads to scope creep (without proper remuneration) which has become the usual but unfair practice of the day. The escape route for vendors is, therefore, a tendency to compromise on the quality of deliverables to reduce costs.
Fixed-price bids and contracts are bad ideas for both the vendor as well as the procuring entity although sadly that is how government contracts are structured at present. Procuring entities think that they are reducing the entity’s financial risk with a fixed bid, but the reality is that it forces them into a position where their money is almost always wasted and for the vendor it almost always motivates them to compromise the delivery quality due to the realities of the “iron triangle” comprised of scope, resource and timeline.
Given the state of the situation where the scope is not so well defined.
one of the strategies that can be adopted is as follows:
- Ask as many penetrating questions as possible during the pre-bid meeting. From the answers received, one has to develop a model or framework of the solution sought and estimate the gaps in the procurer’s understanding, since many questions are not properly answered. Unless the person asking the questions has sufficient understanding of the domain, he or she is unlikely to extract enough information to determine the gaps
- The major components of the deliverables should be identified and a high-level architecture designed with an estimate of the number of processes, user interfaces and reports of the software solution. The bidder may or may not include this cost in the final financial offer (this will depend on the bidder’s internal policy and the cost may not be recovered if the bid is lost). [Let us call this A]
- Determine which method of man-hour estimation you will apply (e.g., expert judgment, poker planning, COCOMO II, function point, etc.). For example, if you choose the function point estimation technique, estimate the minimum and maximum number of function points and multiply that with the internal costing of each function point of your organization (factors that come into play are the salaries, infrastructure cost, and other overhead costs, etc.). This should give an estimation of the lower and higher boundaries of the production cost of the solution under normal circumstances. [Let us call this B]
- Estimate the time and cost that will be required to verify the understanding of the requirements as determined in Point 2 above with the user community of the procuring entity (when the tender is won). [Let us call this C]
- Add any other costs not related to production (outside the WBS). If the tender includes data conversion responsibility, then the huge time, effort, and cost must be added. [Let us call this D]
- Add your Organization’s Error Factor based on previous experience (this is a percentage of A+B+C+D+E). [Let us call this E]
- Add your own margin based on your policy/strategy. [Let us call this F]
- Your financial offer should then be: A+B+C+D+E+F
As can be seen, the constraints and consequent methods adopted to overcome these constraints can lead to a “hit or miss” situation.
Consequently, many government entities and vendors have suffered enormously in the past. While procuring entities have often “imagined a QE II initially and got a dingy at the end”, many vendors have also come out much poorer with a feeling of
“ছেড়ে দে মা কেঁদে বাঁচি”!