Project Sizing

During one of the project discussions meetings, we were briefed that almost 80% of the IT project are failure. Key reasons were ‘ambiguous scope’, ‘non-participation/co-operation from business users’, ‘technological changes’, ‘competitive challenges’ etc. We eventually zeroed on ‘Time-commitment of project scope’ as one of the key reason. Seems to be technically correct, still far away from reality. To explain, let me dive into details of the “project scope”.

Project scope has three key qualifiers: Statement of the work (SOW), Delivery Time, commercials. If I have to divide stakeholders responsibilities – project owner (typically IT users) emphasis is on the unambiguous SOW definition with buy-in from business users. Procurement team’s focus is on ‘Make vs. buy’ decision. Vendor’s interest is to present best proposal with scope compliance and highly competitive commercials. What possibly gets missed here is the time compliance, which is of utmost importance for the business users. Among the entire process, there isn’t any guarantee meeting time commitment even if project executed successfully on competitive pricing. Commercial models are also evolved over time and try to address this aspect through service level agreement and fulfillment. Statistically, it has been observed that on average there is 50% time deviation w.r.t. committed time. This equates to huge business risk of not meeting stated/unstated project objectives. At times, organizations tend to loose out to competition especially if there is delay in the projects or the objectives are not met. This leads to undesired situation, where project objectives are met technically as per SOW & commercially. In terms of business objectivity, still organizations goals are not met.

We realized missing piece in the jigsaw puzzle is ‘project sizing’, which forms the basis of estimation. As most of the vendors, tend to estimate based on the customization/development requirement classification into simple, medium, complex requirement. This is the basis of most estimates, eventually leading to the project plan & commercials. There is no-way IT team has absolute measure of ‘project sizing’ and can confirm the same to the participating vendors.

Best way to avoid undesired situation, if IT team can benchmark ‘Project size’ to some standards. Issue is how & to what? IT industry has been working hard to come out with some standard either based on the line of code (COCOMO) or function point sizing (to express business functionality as measure of project size) and few others. Among these, function point seems to be more popular among the business users as it directly measures project size as function of tangible business requirements and absolutely independent of the underlying technology. COCOMO on the other hand, works very well on mature technology. However, since it is more dependent on LOC, it seems to be more technical. Hence not so popular among business users.

On the other hand, function point seems to be more correct and works very well both for the customer and vendor. In today’s world of outsourcing, vendor can use it very well to define/estimate function count across the applications. These estimates can be used by finance team to do cost-benefit analysis on ‘Make vs. buy’ decision. This gives benefit to the vendors to critically & positively evaluate project size and then estimate based on the project size. Additionally it assists procurement team to assess all vendors proposal on the same level playing field.

More-over with more accurate sizing, this can be basis of project estimation. This definitely minimizes the scope of time deviation and results in “best-case scenario” for business/IT users to complete project successfully with stated/unstated objective. In a nutshell, it is a ‘win-win’ situation for all the stakeholders. What is surprising is the limited number of IPUG certified (functional point) professionals available in the market. Maybe IPUG deliberately wants to limit number of professionals, unlike other certification bodies, where count is huge and increasing?

Let’s try to leverage on functional point sizing and use it for benefit/advantage situation for vendor, customer and customer’s customer as well.

This entry was posted in Management, Project. Bookmark the permalink.

Leave a Reply