| The problem with liquidated damages: Government agencies tend to be risk averse, so there is a temptation to use liquidated damage clauses to transfer risk to the vendors. Unfortunately, this strategy is seldom effective. Liquidated damage clauses present to significant disadvantages during acquisition. First, they limit competition because many companies or groups within a company have a general policy that they won’t bid on contracts with liquidated damages. Second, the vendors add significant costs to their bids in the form of increased rates; increased contingency budgets; and increased layers of management oversight. Perhaps these costs could be balanced by the reduced risk to the government, but the fact is that on information technology projects the blame for problems is always shared. So the liquidated damage clauses are seldom enforced. |
|
|
Level 4 was awarded estimation related contracts with the California Department of Parks and Recreation; the California Department of Social Services; Denti-Cal; and the Bureau of Alcohol, Tobacco and Firearms (ATF).
MB-Level 4 in Germany is pleased to announce the pending availability of a German language version of ExcelerPlan. |
|
|
All times are Pacific Time!
Free WebEx
Estimating with ExcelerPlan
11/6, 11 AM-12:30 PST
11/6, 7 PM – 8:30 PST
11/20, 11 AM-12:30 PST
To register for demos, email:
Edward@portal.level4ventures.com |
|
|
Free Training with Site License
Purchase any ExcelerPlan site license between now and November 30th and receive 10 seats for our self-paced video training program (a $19,995 value), plus a 2 hour live question and answer session with William Roetzheim.
To obtain site license pricing email:
Edward@portal.level4ventures.com |
|
|
We work hard putting together a newsletter with a lot of useful content, and we’ve been careful to only send it out once per month so that we don’t swamp your in-boxes. And many of you have written to express your thanks on both counts. But if you’d really like to thank us, what you can do is forward the newsletter to your friends and co-workers that might be interested so that they can subscribe as well. We’d certainly appreciate the support.
Edward
Director of Sales and Marketing
|
|
|
|
|
| Ten user self-paced training package free with the purchase of a site license during November, plus a bonus 2 hour live Q&A with William Roetzheim. |
|
|
|
|
|
|
 Benchmarking Denominators: Last month I discussed the difficulty of finding a suitable denominator to be used as a standard unit of production for information technology. The first major attempt in this area was source lines of code, or SLOC. IBM’s Albrecht wanted a more business focused measure, so he developed the idea of function points. The initial idea was to count the number of screens, reports, and tables; apply a weighting for each; and call that the delivered function points. Over time, true function points have become increasingly complex, eventually getting to the point where the function point certification exam was one of the tougher professional certification exams I’ve had to take; and the effort required to do a function point count of an application can be daunting. But the core idea behind Albrecht’s invention is both sound and simple. We want to identify business focused components that will be delivered by the project team, assign a weighting to each component type, and use the total of those points of delivered functionality to measure size. We’ve seen several of these sizing catalogs put forth, including RICE points for ERP implementations, test case points, story points, and many others. The concept is the same for each of these approaches. But one problem is that each measure tends to be an independent arbitrary measure of size. This works as long as you are only staying within that methodology, but it makes it difficult to do cross-method benchmarking, and using multiple methodologies on one project results in numbers that can’t be combined or compared. Fortunately, because the scale for each method is arbitrary, there is nothing preventing us from defining the scale to be equal to standard Function Points. I term the resultant measure Function Point Equivalents (or FPE), and they support benchmarking within a measurement methodology; across methodologies; and with standard, published benchmark data that is expressed in Function Points.
Next month I’ll talk about the three steps to information technology optimization.
william@portal.level4ventures.com
|
|
 |
|
|
|
Estimation Process (part 5), External Validation: External validation involves presenting your estimate to knowledgeable individuals outside the estimation team, answering questions about the estimate, and revising the estimate as needed based on feedback received. The validation stage serves two primary purposes. First and most important, it’s an opportunity for problems with your estimate to be identified and corrected. These problems might be areas that you missed or simply got wrong, or they might be areas where the project direction has changed but you were not informed. In any event, corrections to the estimate input parameters should always be welcome and they should not be considered as a threat to your expertise or abilities. Your unique expertise is knowing how to turn inputs into estimate outputs. But coming up with the right input values is a team effort where everyone may have a role.
Second, the validation review sessions are an opportunity for the various stakeholders to buy-in to your results. It’s important that the groups that will be impacted by the estimate in terms of cost (typically the customers or business units) and resources (e.g., the developers) have confidence in the estimate. This confidence is earned through the validation session(s).
Once an estimate has been validated, modified as necessary, and finalized, it must be archived. The estimate may be saved into your existing project management system (e.g., Clarity); it might be placed under configuration management in your existing CM tool; or you may store it in a shared corporate repository. In ExcelerPlan the repository is called the Control Center, and it was discussed in detail last month.
Next month we’ll discuss the pros and cons of an expert system approach to estimation.
|
|
|
|
|
[This guest column reprinted with permission from: “RETURN ON INVESTMENT (ROI) IN SOFTWARE PROJECT MANAGEMENT TOOLS AND SOFTWARE QUALITY CONTROL,” Capers Jones, July 2014. Full article available on http://Namcookanalytics.com]
The presence of a suite of project management tools is not, by itself, the main differentiating factor between successful and unsuccessful software projects. The primary reason for the differences noted between failing and successful projects is that the project managers who utilize a full suite of management tools are usually better trained and have a firmer grasp of the intricacies of software development than the managers who lack adequate management tools.
Bringing a large software project to a successful conclusion is a very difficult task which is filled with complexity. The managers who can deal with this complexity recognize that some of the cost and resource scheduling calculations exceed the ability of manual methods.
Managers on failing projects, on the other hand, tend to have a naive belief that project planning and estimating are simple enough to be done using rough rules of thumb and manual methods. These same managers tend to skimp on quality control and bypass inspections.
Tools by themselves do not make successful projects. Capable managers and capable technical personnel are also needed. However, attempting to construct large software projects without adequate management and quality control tools is not a safe undertaking. No one in the industrialized world today would dream of starting a large engineering project without adequate tools for project management. Yet software projects whose total staffing compares to many large-scale engineering projects are routinely started using “back of the envelope” planning and estimating methods. It is no wonder that failures are so common.
Software itself is intangible, but the schedules and cost estimates for software can be highly tangible. Software projects are still subject to the basic laws of manufacturing and software needs to be placed on a firm engineering basis. It is professionally embarrassing that software remains troublesome at this point in the 21st century.
Project managers are the primary key to software project success and failures. To a very large degree, the sophistication or lack of sophistication of the project management tool suite will determine whether software projects will succeed, experience major cost and schedule overruns, or fail completely.
Capers Jones
|
|
|
|
 Dear Tabby:
My girlfriend and I live together in a data center downtown, and we’re thinking of moving to a different data center out in the suburbs. But we’re not sure how much to budget for the move. Do you have any advice?
signed, Data Dave
Dear Data Dave:
You might think that the cost would be based on the number of servers that need to be moved, but it turns out that this is not a good predictor at all. The best approach is to estimate the size in function point equivalents of the application code to be moved. Sometimes this is known. Other times you can get an approximation using either backfiring or by counting and classifying the applications, then applying a typical size benchmark multiplier.; The size is then adjusted using the IFPUG Installation Site Configuration factor.; The adjusted size is then further adjusted using the COCOMO II reuse factors: IT, AA, SU, and UNFM (DM and CM are set to 0, and AA is normally 0 as well). The adjusted effort and time is then estimated using power functions calibrated to data center moves.
signed, Tabby
|
|
|
|
|
|
M&O Costs: When estimating maintenance and operations costs, you need to start with a clear understanding of what should be included in or excluded from the estimate. The categories are: Corrective maintenance (defect repairs); Adaptive maintenance (keeping the software working when the underlying environment changes); Perfective changes (meeting the same business needs but in a better or safer way); Enhancements (adding new business capabilities); Manufacturer’s maintenance and support contracts; Operations costs (monitoring, running batches, responding to events, etc.); and help desk support. Help desk support is divided into Tier 1 (initial conversation); Tier 2 (first escalation); and Tier 3 (second escalation). In ExcelerPlan you check off the areas that should be included in your total cost of ownership (TCO) calculations. These show up in the budgets as on-going costs, versus project costs that show up as one-time costs.
Next month we’ll discuss how and why we handle M&O costs as part of the project one-time costs.
|
|
|
|
|
|
|
