- Introduction
- B2B E-Commerce Primer
- Overall Function Point Counting and Estimation Methodology
- Benefits of Function Point Counting and Estimation
- Extensions to IFPUG CPM 4.1
- The Function Point Counting and Estimation Repository
- The Function Point Counting and Estimation Team-based Process
- Function Point Estimation Worksheet Example Segment
- Other Applications
- Internal Challenges at eSell
- Summary and Conclusions
- Final Questions to Ponder
This chapter is from the book
This chapter is from the book
This chapter is from the book
Other Applications
We have examined in detail how the four components of the eSell functional measurement program (CPM extensions, FPE worksheet, PDB, and process) are used in the most common application—namely to perform size, effort, and cost estimates at project kick-off to produce a realistic project plan. The following sections examine some of the other ways these techniques are being used during the sales cycle to improve eSell's traction with its customer base. These are
Pre-sales: The make versus buy decision
Post-sales: Project staffing
During implementation: Project control
Pre-Sales: The Make versus Buy Decision
Do not conclude at this point that the measurement and estimation process provides value only in the post-sales or implementation phases of projects. It is also a key component of the pre-sales environment. Here is a case in point.
When a corporate e-commerce initiative is established, the prudent response of the customer's executive management is to determine whether the solution should be built in-house (make) or purchased from an outside supplier such as eSell (buy). Most IT organizations instinctively look at these projects as make opportunities in which they can learn new technologies and keep their staff busy and productive. From a corporate perspective, however, developing these applications from scratch may not be the most fiscally responsible decision. More often than not, the custom development projects incur large hidden costs: learning curves for new technologies, the team's not knowing what it does not know, inability to manage scope creep, ongoing maintenance and support, and so on. These discoveries can be costly in time, effort, and competitive advantage.
With FP techniques, eSell formulated a quantitative analysis to estimate the cost of making product functionality in-house that was equivalent to what they could buy off the shelf. This showed clearly that buy's advantages far outweighed make's. This Make vs. Buy analysis became a formal sales tool. The analysis (described here) was trivial arithmetically but powerful in its objectivity and quantitative perspective.
A third-party-validated FP application count was done on each off-the-shelf (buy) product to obtain its exact functional Size in FP. In this example, the size of the complete product offering was counted as 3200 FP.
Industry-standard Productivity numbers (FP/Staff-Month or FP/SM) were obtained from various databases, and the average was used. In this example, the average was 10.0 FP/SM, the median between the identified extremes of 8.0 and 12.0.
Estimates of Effort (SM) were calculated, using the above two sets of figures, to show approximately how much time it would take an industry-standard project team to deploy the equivalent functionality (Effort = Size / Productivity). In this example, Effort was calculated at 320 SM or 26.7 Staff-Years (SY).
Industry-standard Loaded Labor Rates ($/SY) for comparable high-tech industries were obtained. These were estimated at $150,000/SY (per employee per year).
Estimates of labor-only Make Cost ($) were calculated by using the effort estimates and the loaded labor rates (Make Cost = Effort * Loaded Labor Rates). This was computed at $4M.
This labor-only cost compared quite unfavorably with the (buy) license fees of the already-released software products (in this case, Buy Cost approximately $1M). This factor of almost 4x was a clear and objective argument that, in this case, buy was a better value than make. Note: the $4M make cost did not, of course, include large, subtle hidden costs such as opportunity loss, time delay, and support and maintenance costs, relegating the make alternative to even lower attractiveness.
eSell's customers found this compelling. They might not have agreed with the exact numbers used, but they found the analysis and argument valid.
Post-Sales: Project Staffing
Another useful application of the FP sizing and estimation process is used in the post-sales time frame. Here the methodology helps the team managers (eSell's and the client's) better determine what skill sets and domain expertise (team roles) must be represented on the project team to have a successful project and how much their time will be impacted. Again, the PDB plays a central role, as follows:
After project kickoff and the FP estimation process, the project managers have an idea of the functional requirements, their size, and the effort required to implement them. In the FPE worksheet, they also have documentation of the productivity factors affecting each ability-to, including the technologies involved. The PDB contains accurate, actual historical data, including the team make-up for each past project. The project manager can cross-reference the estimate data of the new project with historical data in the PDB by finding one or more past projects that best match the new one. Previous efforts by role are used to determine the percentage contribution to the entire project by each role.
For example, for some projects, the Project Manager's contribution absorbs 20 percent of the overall project budget. The Java Developer contingent (this is Web, after all) is 35 percent, the ERP Developer 15 percent, and so on. From this historical data, staffing projections can be done for eSell, partner, and client resources based on role. The appropriate resource with the needed expertise for the required time can be allocated to the team in each case.
During Implementation: Project Control
The final application of functional metrics at eSell is in the area of project control and monitoring during implementation. A measurement process that takes the accuracy of its data seriously also recognizes that accuracy can be achieved only with constant monitoring, remeasuring, and iterative corrections. The project sizing and estimation process described earlier is done at project launch. At that point, there is only an approximation ("educated guess") of what functionality might be required. The sizing estimate for each of those ability-to statements will be fairly accurate (given a good understanding of the function). But even the effort estimate will be somewhat suspect since (a) the predicted productivity factors that influence the timing can only be guessed, (b) inaccuracies exist in the assumptions and risk assessments, and (c) functionality and understanding will mature during the project.
As explained earlier, these inaccuracies are constantly under scrutiny and being corrected, because the final, live project application is FP counted for actual size, and the actual productivity is computed from time-sheet data. But this corrective process is too late for the project itself. Monitoring must be done during the project at key milestones to check progress against the estimate, and then the estimate itself is refined.
Therefore, a pivotal process is used in eSell's project methodology: the Focus Group. At short intervals (typically 3–4 weeks), the project team is convened along with the client's customer representatives—the ultimate end-users. The development product to date is demonstrated for the team, and another pass is made at required functionality. Feedback from the client and their end-users at this point is vital to the success of the final deployment. The list of ability-to statements is revisited. Existing ones (from launch or earlier Focus Groups) are validated, rejected, or postponed, and some new ability-to statements are discovered. These changes dictate the need to recalculate the original sizing and effort estimate.
Another FPE meeting is convened on the revised set of ability-to statements, and a new size and effort estimate is obtained. A supplemental worksheet is used (one outside the scope of this paper) that enables the project team to re-estimate the new size, effort, and budgetary costs. New information such as the following is taken into account:
Some work is already completed and delivered and thus paid for.
Some work estimated but not started or completed has now been rejected (a cost savings).
Some new, unexpected work has been added to the mix.
In fact, some analysis reveals nine combinations of ability-to statements, in two dimensions of 3 X 3. These are Original Work Delivered, Original Undelivered, and New Work versus Approved, Rejected, and Deferred (by the client or end-user). The re-estimation worksheet provides a revised effort and cost estimate for the remaining work. The client can then apply the same line-item-veto process to the revised ability-to statements to assure the remaining costs fit the dollar, resource, and time budgets.
Thus, the fine-grained project-progress monitoring is facilitated by the FP estimation (and re-estimation).