|
Troubleshooting Excel File Size Issues: We were surprised to discover that our initial build of ExcelerPlan version 7.1 resulted in a workbook that was more than 35 MBytes in size. We thought we’d pass on an Excel troubleshooting tip we learned in getting that file size back down (now closer to 5 Mbytes). First, rename your spreadsheet file to *.zip and open the resulting file with Winzip. Look in the resultant xl\media directory at the embedded graphic element sizes, and in the resultant xl\worksheets directory at the size of each individual worksheet. This will help you quickly pinpoint the cause of your large workbook, which is more than half the battle in reducing the file size.
|
|
|
|
Jeff Tyler and I have worked together selling estimation solutions for more than 17 years. He remained with CXG when I sold that company, but I’m now pleased to announce that he’s joined Level 4 to continue our legacy of working together to bring improved estimation processes and tools to the industry.
|
|
|
|
All times are Pacific Time!
Free WebEx
Estimating with ExcelerPlan
3/5, 11 AM-12:30 PST
3/19, 11 AM-12:30 PST
4/2, 11 AM-12:30 PST
4/16, 11 AM-12:30 PST
4/20, 11 AM-12:30 PST
4/30, 11 AM-12:30 PST
5/14, 11 AM-12:30 PST
5/28, 11 AM-12:30 PST
To register for demos, email:
Edward@portal.level4ventures.com
|
|
|
|
Three Day Estimation Training
We’ll be offering a 3 day estimation training class taught by William Roetzheim via Webex on 5/5, 5/6, and 5/7. Class runs from 9 AM – 1 PM Pacific Time each day, and the $1,495 fee includes a 6 month license to ExcelerPlan to use as a learning tool. (New customers only.)
To inquire about registration email:
Edward@portal.level4ventures.com
|
|
|
|
ExcelerPlan Next Release
I’m excited about some amazing new capabilities that we’ll be releasing in our April ExcelerPlan release (version 7.1), but even though that release is a month away, we’re already gathering features together for version 7.2. If you have ideas for features you’d like to see added to ExcelerPlan, drop us a line.
Edward
Director of Sales and Marketing
|
|
|
|
|
|
Sign up for a 3 day live Webex class, taught by William Roetzheim, to be conducted on 5/5-5/7, and receive a free 6 month license to ExcelerPlan along with your $1,495 class fee. (New customers only.)
|
|
|
|
|
|
|
|
 Estimating When you Outsource: One mistake many organizations make is to assume that if they outsource development, they do not need to do estimates. The assumption behind this belief is the fact that the outsource vendor(s) will be estimating the work as part of their responses to the task orders, and they have both the tools and the expertise to estimate the work better than us. There are multiple reasons why it’s necessary for you to independently estimate the work, even when working with an outsource vendor:
1. Governance: You will typically need to prepare budgets, develop feasibility or alternative studies, and justify funding prior to bringing a vendor on-board to create the estimates.
2. IOCEs: As part of your vendor oversight process, you must prepare Independent Organization Cost Estimates. For government contracting this is required whenever you will not be obtaining three valid vendor bids/estimates, which is often the case for specialized, follow-on, or change request work. IOCEs are also recommended for any high risk project as a method of reducing scope definition risk.
3. Organization Effort Estimates: Even if you do rely on vendor estimates for their work, you will still need to estimate work performed by others to support the vendor effort. Typical examples include vendor oversight, acquisition cost, business unit support (especially for requirements and user acceptance testing), and independent verification and validation (IV&V).
|
| |
|
William@portal.level4ventures.com
|
|
|
 |
|
|
|
|
ExcelerSize: ExcelerSize is a Level 4 proprietary high level object (HLO) catalog set designed to size IT projects excluding purchased other direct charges (ODCs) such as hardware and software licenses (which are covered using separate models). The catalog elements are grouped into five major categories:
- Project level sizing components that apply to the entire project.
- Application software sizing components.
- Data conversion sizing components.
- Data warehouse sizing components.
- Application support sizing components.
ExcelerSize project level components loosely consist of Consulting and applications/frameworks. Consulting is further broken down by the type of consulting that is performed: Configuration, Performance, Security, or Other. Consulting work that is required as part of other sizing elements is not separately called out, as it is incorporated within those other sizing elements. The Consulting HLO items are used in situations including small projects that involved advise and consult only; situations where the consulting required is more broad than the components being built in this project; and in situations where the consulting is expected to be particularly difficult for this project. The Consulting HLO elements may be placed within ExcelerSize, within the ODC-Other cost area, or both. The difference is that placing consulting within ExcelerSize assumes that the work will be performed by your development (software) team, while placing the work within ODC-Other assumes that the work will be performed by your infrastructure (engineering) team. So a performance issue could easily involve two Consulting-Performance entries, one to cover the software side and one to cover the hardware side of things.
Next month we’ll continue this discussion, talking about COTs and Frameworks.
|
|
|
|
|
[This guest column reprinted with permission from: “MINIMIZING THE RISK OF LITIGATION: PROBLEMS NOTED IN BREACH OF CONTRACT LITIGATION,” Capers Jones, July 2014. Full article available on http://Namcookanalytics.com]
[Editor: This column continues the discussion of litigation risk factors from last month’s edition.]
Problem 3: Rapidly Changing Requirements
The average rate at which software requirements change is has been measured to range between about 1% per calendar month and as high as 4% per calendar month. Thus for a project with a 12 month schedule, more than 10% of the features in the final delivery will not have been defined during the requirements phase. For a 36 month project, almost a third of the features and functions may have come in as afterthoughts.
These are only average results. The author has observed a three-year project where the delivered product exceeded the functions in the initial requirements by about 289%. A Canadian lawsuit dealt with a project that doubled its size in function points due to requirements creep. A recent arbitration in 2011 in Hong Kong dealt with a project that went from 15,000 to more than 20,000 function points at a rate of change that approached 5% per calendar month.
It is of some importance to the software industry that the rate at which requirements creep or grow can now be measured directly by means of the function point metric. This explains why function point metrics are now starting to become the basis of software contracts and outsource agreements. Indeed the governments of Brazil and South Korea now require function point metrics for all government software contracts.
The current state of the art for dealing with changing requirements includes the following:
- Effective mapping of business needs to the proposed applications
- Estimating the number and rate of development changes before starting
- Using function point metrics to quantify changes
- Using high-speed function point sizing on all changes
- A joint client/development change control board or designated domain experts
- Model-based requirements methodologies
- Running text-based static analysis tools against text requirements
- Calculating the FOG and Flesch readability indices of requirements
- Full time involvement by user representatives for Agile projects
- Use of joint application design (JAD) to minimize downstream changes
- Training in requirements engineering for business analysts and designers
- Use of formal requirements inspections to minimize downstream changes
- Use of formal prototypes to minimize downstream changes
- Planned usage of iterative development to accommodate changes
- Formal review of all change requests
- Revised cost and schedule estimates for all changes > 10 function points
- Prioritization of change requests in terms of business impact
- Formal assignment of change requests to specific releases
- Use of automated change control tools with cross-reference capabilities
Unfortunately in projects where litigation occurred, requirements changes were numerous but their effects were not properly integrated into cost, schedule, and quality estimates. As a result, unplanned slippages and overruns occurred.
In several cases, the requirements changes had not been formally included in the contracts for development, and the clients refused to pay for changes that substantially affected the scope of the projects. One case involved 82 changes that totaled to more than 3,000 function points or about 20% of the original size of the initial requirements. Although the contract did include clauses for funding “out of scope” changes, the defendant asserted that the 82 changes were merely refinements rather than changes. It is obvious that contracts need to be very specific about what constitutes “change.”
Since the defect potentials for changing requirements are larger than for the original requirements by about 10%, and since defect removal efficiency for changing requirements is lower by about 5%, projects with large volumes of changing requirements also have severe quality problems, which are usually invisible until testing begins. When testing begins, the project is in serious trouble because it is too late to bring the schedule and cost overruns under control.
One of the observed byproducts of the usage of formal joint application design JAD sessions is a reduction in downstream requirements changes. Rather than having unplanned requirements surface at a rate of 1% to 4% per month, studies of JAD by IBM and other companies have indicated that unplanned requirements changes often drop below 0.5% per month due to the effectiveness of the JAD technique.
Prototypes are also helpful in reducing the rates of downstream requirements changes. Normally key screens, inputs, and outputs are prototyped so users have some “hands on” experience with what the completed application will look like.
Next month: Poor Quality Control
Capers
|
|
|
|
 Dear Tabby: My girlfriend has been complaining about my performance. I’m starting to wonder if my hardware is below average. Should I see someone for a consultation?
signed, Poor Performance in Pittsburgh
Dear PPP:
Performance problems tend to require cooperative work by engineers and developers, so they will often involve consulting work by both. On the hardware side, the problem might be undersized capacity or configuration problems. These problems tend to show up as random poor performance, consistent poor performance through out the application, or time-outs. Software performance problems tend to be isolated to specific portions of the application, and they are typically classified as data configuration problems (e.g., a missing index or poorly structured query) or algorithm problems. Algorithm and indexing problems often represent the greatest percentage improvement opportunity, with improvements of 1,000:1 or greater sometimes possible.
signed, Tabby
|
|
|
 |
| ExcelerPlan 7.1 Sneak Peak:
We’re preparing ExcelerPlan 7.1 for release in April, and this month we’re providing a sneak peak at the Expert_Assist capabilities that will be introduced. In addition to the ExcelerCost wizard that was introduced in version 7.0, Expert_Assist provides an ExcelerLaunch workflow capability. As you work on various aspects of your estimate, you click on the appropriate launch button to access the appropriate screens. Estimate status is shown using check marks. Expert_Assist also offers access to manuals, video training, a support forum, and personalized support.
|
|
|
|
|
|
