Helping Hand, Reaching Back, Sharing
The most common testimony of companies with successful Metrics programs is that they got Help to get started. Many successful individuals and companies would like to help others, but do not have the time to tell their stories over and over and over.
So we are starting this new service to Reach Back and help others by allowing anyone a forum for telling their success stories.
Add a success story.
Risk, posted October 24, 2002 by M.G.
Quality, posted June 24, 2002 by Marianne C
Quality Changes in the COTS Selection Process, posted April 10, 2002 by L C
Savings Through Quality in Maintenance, posted April 10, 2002 by S S
Saving 40 People, posted March 6, 2002 by J T
Why Baseline, A Third Opinion , posted March 4, 2002 by B H
Why Baseline, A Second Opinion , posted March 2, 2002 by B H
Why Baseline?, posted March 2, 2002 by B H
Can you help with Boundaries?, posted February 15, 2002 by Bill Hufschmidt
Backfire Can Backfire, posted February 15, 2002 by Bill Hufschmidt
Testing an OO Design, posted January 28, 2002 by S M
Unit Cost Pricing, posted January 6, 2002 by C L
31% Annual Productivity Gain, posted December 27, 2001 by B K
Naming IFPUG and Gaining Respect., posted November 26, 2001 by Bill Hufschmidt
Forecasting Work Effort, posted November 19, 2001 by Charley Tichenor
Multimedia, posted November 19, 2001 by Bill Hufschmidt
Bylaw Changes, posted November 19, 2001 by Bill Hufschmidt
Saving $2M, posted November 16, 2001 by John K
New Business Organizations, posted November 16, 2001 by John K
Function Point Counting of Algorithms, posted November 8, 2001 by Charley Tichenor
Bottom Line Customer Satisfaction, posted October 27, 2001 by D W
Outsourcing Issues, posted October 25, 2001 by C C
Return on Investment, posted October 24, 2001 by Rich P
Measuring Maintenance, posted October 24, 2001 by Bill Hufschmidt
Estimating and Funding Measurements, posted October 24, 2001 by Bill Hufschmidt
Function Point Analysis Super File Rule, posted October 12, 2001 by Charley Tichenor
IT Balanced Scorecard, posted October 1, 2001 by J K
| Risk | Risk
Three words that will stop any hard-charging manager „Ÿ "High Risk Solution." How do measures and Function Points help us to understand Risk?
What is the biggest system in your shop? Most companies know their biggest system. But how big is it? What is the second biggest system? How big is it? How much bigger is the biggest than the second biggest? If the biggest system is twice as big as number 2, does it get twice the resources? Should it get twice the resources?... We ask these questions wherever we go. Only once have managers even agreed on the two biggest systems and no one has ever understood the relative difference in size.
In reviewing systems with over 200 clients, we've found small systems are usually less than 1000 FP (IFPUG CPM 4.2). Medium-sized systems range up to 2500 FP and major systems are above that.
What can we say about a system of 10,000 FP? It is equivalent to four major systems. So what? If senior management is alerted to this fact, they may view it differently. For example, a major Eastern company was migrating all of their systems from old to new technology (a four-year $100,000,000 project). The scope of the project was migration, not enhancement, except for the sales system which was the heart of their business.
By measuring existing systems and new systems after design they saw how much growth (enhancement) was occurring. Growth over a certain percentage was allowed in cases where old systems were replaced with new packages. This often occurs with Financial, Human Resources, Inventory and similar types of systems. Growth was also allowed where tools provided extra functionality at negligible cost (read "free") to management.
After review of all systems, three important facts emerged.
1) Fully 42% of all systems for this company became packages. When installed and maintained in "vanilla" form, significant savings in development and maintenance occurred. 42% is higher than any company we know and allowed management to concentrate on their core business functions.
2) One business area didn't get the message. After design, the new system was five times (5X) bigger than the old. This was immediately rejected by management.
3) The Sales system, the heart of their business, was totally revamped. Costs were reduced to a point of giving the company a significant cost differential over their competition. This in turn provided increased flexibility in product customability. The one problem - the system's size was 10,000 FP. This is equivalent to installing four major systems on one day (read "high risk"). In addition, for various business and technical reasons, conversion had to occur all at once with no turning back.
The measures helped management understand the risk, allocate resources and prioritize issues throughout the entire business, not just the Sales and Systems areas. With full management understanding came full management commitment and involvement. They could not afford to fail. Result: complete success. By understanding the risks, Users, Management and Information Systems all celebrated an on time, within budget, satisfied customer installation.
| | M.G. of NY, NY
|
| Quality | Quality
What's a defect? How consistently do companies measure defects?
Unfortunately, consistency in definition, measurement, analysis and meaning between companies, even between departments within the same company, is, at best, very, very, very weak. However, within a single department consistency from Year 1 to Year 2 is pretty good. So quality measures at a department level can be effective.
What if defects go up by 20%? Is it good or bad? On the surface it sounds bad. But what if the size of the system doubled and the corporate impact increased 500%? Both trends would be down as desired. What if the severity were an average 20% less severe and what if the fixes were 20% faster? Function Points bring a normalizing factor to allow companies to analyze and compare trends instead of incidents.
A major eastern bank tracked IT production abends for one full month, tracking every conceivable time and material cost to come up with an average cost per abend. At the time they were running a production abend rate of approximately 1.7%. Through a concerted multi-year effort they reduced errors and production abends to .3%, saving an estimated $.5M.
When I heard the presentation from the Operations Manager I had two questions. First, did management really believe their savings? The answer delivered with a skeptical and nervous stare: "Yes, they have been very supportive and it had become a "CEO Bragging Right." Second, did they realize their savings were drastically understated? The answer delivered with relieved and heightened interest: "What do you mean?"
I explained we had measured their functionality and over the years many systems had grown 20%-100%. Therefore, they were successfully delivering much more functionality with much more reliability with much more impact (leverage). They immediately returned to combine their Operations and Systems data to provide much more and much better Management Information.
Does Quality pay? Of course, so why not prove the real pay off? Our experience is that Quality programs with measures are much more successful and we don't know of any such program that has ever been Outsourced.
| | Marianne C of East Coast , NY
Major Bank
Phone: 262-789-9190
Email: Bill.Hufschmidt@functionpoints.com
|
| Quality Changes in the COTS Selection Process | Solutions using COTS, Common Off the Shelf, Software
The fastest most efficient and effective way to do anything is to do it once. This includes purchasing and installing packages. As the 17th largest school district in the nation, with over 100,000 students and 20,000 employees, we needed a new student record system. We needed it done on time and we needed it done right.
To enhance the process, we measured our existing applications and quantified their requirements. We then utilized the new RFI/RFP process, rooted in Functionality, to speed selection with increased consensus. We utilized a small team of four experts, application expert, user expert, quality and functional expert and management rep.
After quickly narrowing the field, we invited in three vendors. They all made good sales presentations and when asked about details they all said they could make their packages meet our needs. We then traveled to their sites to measure their packages, 1-2 days each. In the measurement, we saw all of their screens, files, and reports. We also got “under the covers” of their technical and functional expertise and support.
Results: First, we determined the three different solutions ranged from 60% to 140% of our needs. Second, we determined the package cost range was X to 1.4X, a 40% differential. Third, the Unit Cost ranged from $333 down to $200, with the lowest unit cost being for the greatest functional solution. Fourth, team consensus was unanimous and productivity, quality and elapsed time of the installation were our highest ever.
We highly recommend the process and hope it can help you as well.
| | L C of East Coast, US
17th Largest School District
Phone: 262-789-9190
Email: Bill.Hufschmidt@functionpoints.com
|
| Savings Through Quality in Maintenance | We are a financial institution. For us, maintenance is fixing undiscovered bugs. The first time we measured we found that maintenance hours over the previous year had increased by 9%. This was over 9% too high. Business was good and expanding, so it was easily overlooked. However, 9% represented lost profit and gave us a “black eye” with senior executives. We knew we had to improve our processes, but we also needed to understand the context of our 9%.
Upon closer inspection, we found that overall Functionality had increased by 7%, which meant maintenance per functinality had only increased by 2%, not 9%. In addition, total business had increased so that Maintenance Hours per Leveraged Functionality had actually decreased by 19%. This is good. Furthermore, our biggest development effort had been to increase efficiency and reduce processing costs. These benefits were achieved, so our Maintenance Cost per Leveraged Business Impact decreased by 21%. This is even better.
Having the numbers allowed us to manage User and Sr. Management expectations. It also provided proof of benefits as other Quality Process Improvements were made.
| | S S of Midwest, US
Major Bank
Phone: 262-789-9190
Email: Bill.Hufschmidt@functionpoints.com
|
| Saving 40 People | Saving 40+ People
Like my fellow managers, I was skeptical of Measurements and Metrics until Bill proved our increased Productivity.
He started in one of our CIO staff meetings. He had analyzed tools we were utilizing by simply going to Tech Support and recording who was using which tools and how often. Then he interviewed the people, including myself, who were using the tools the most and asked us how much time we were saving. If a testing tool was supposedly saving us 10% of our testing time, he would rephrase questions to be sure we were not inflating our results. For example, he would say, “So if you were testing all week, it saved a full morning?” Whenever someone would say, “No probably only 2 hours, or 5%.” Bill would take the conservative savings.
The department was 350 developers at the time. After interviewing key developers, that management respected, he did a blind survey. This allowed people to state their savings anonymously. After compiling the surveys he compared them with interview results and again used the conservative savings.
Then he multiplied the savings times a percentage of the usage. Result. He was able to report that our Productivity Index was conservatively saving 320 hours per week (8 FTE). But his presentation of the result was really a ploy. He was educating us and just getting us comfortable with the process. He took a lot of kidding about saving 20 seconds here and 20 seconds there. Then he told us he only counted savings of ½ hour or more. We were silenced. We weren’t gung ho and we weren’t totally sold, but he had accomplished his goal of getting our attention.
Over the next nine months, he reported many numbers in various ways providing business insights. He would also remind us of the original savings process. Then he delivered the final coup de grace. Calculated the same way, the updated Productivity Index proved saving of 1750+ hours per week (>40 FTE). These numbers were key in getting more tools and even more people. We now have over 1000 developers.
Ever after, the CIO questions were not “Could we afford a tool?” The questions were which tools would we get next. He knew Bill would prove the savings. One time the CIO nervously asked Bill if there were any duplication or overlap in the tool sets. It was obvious he was being pressured about something. Bill responded, “Yes.” Pause. “But we have calculated that product maintenance fees are far less than retraining costs. Plus multiple products reduce the risk of depending upon one vendor and allow subcontractors to be productive faster.” The CIO was relieved and we all learned to look at problems a little differently. His button “You Can’t Manage What You Can’t Measure” is true.
| | J T of Midwest, US
Services
Phone: 262-789-9190
Email: Bill.Hufschmidt@functionpoints.com
|
| Why Baseline, A Third Opinion | Why Baseline III
There are only three measures that transcend every part of every business: Time, Money and now Software Functionality. Using Time and Money, Management already has and uses a perception of the system base. It is 100 people and $10,000,000. The perceptions are probably correct 80% of the time (management 80/20). The big money comes from learning things you didn’t know.
The whole purpose of measures is to provide information that management doesn’t know, thereby replacing opinions with facts. If your measurement program doesn’t do this, what is its and your value added? Post project productivity and quality rates are fine and interesting for two minutes, but “what have you done for me lately?”
Let’s start thinking like a CEO. Would you invest $20,000 or $2,000,000 of your pension money in my business? No? Why not? Probably because you don’t know what I do. CEO’s often don’t know what IT really does. They know they need technology, but they don’t know how much is the right amount. They spent multi-millions on Y2K and what did they get? What if they could reduce the IT budget by $1M? That could become a bonus for them. Why should they invest in IT? What is the ROI of the IT budget?
Fully one third of all new CIOs come from outside IT, either from other parts of the business or outside the business all together. This is an IT failure. For some reason IT couldn’t convey its Value Added. Now imagine the new CIO. How can he/she get his/her arms around the “Goliath.” One way is to ask the BIG and BEST Questions.
If I were in charge of a Measurement program, I would take the initiative and report on the BIG and BEST Questions.
What is our biggest application?
What is our second biggest application?
How much bigger is our biggest than our second biggest?
If our biggest is twice as big as our second biggest, does it get twice the
resources? Should it get twice the resources?
Which project has been our biggest success? Which project is 2nd? …
Which team has the best Quality? Which team is 2nd? …
Which team has the best Cost or Revenue? Which is 2nd? …
Which system has the biggest Business Impact? Which is 2nd? …
Which team has the best Customer Satisfaction? Which is 2nd? …
Can you quantify the biggest Risk? What is 2nd? …
How many major systems (>2500 FP) do we have? …
Senior Management doesn’t want, or need, all the answers all at once. But, if your management can’t answer these questions, it is in “trust me mode” and it is no wonder there is a new CIO. Why Baseline? By Baslining you can start to answer they questions. And it won’t hurt your career to be the person associated with new information and knowledge.
| | B H of Denver, CO
IBM
Phone: 262-789-9190
Email: Bill.Hufschmidt@functionpoints.com
|
| Why Baseline, A Second Opinion | Why Baseline II?
Credibility and Business Insight. Ever want to impress the boss? Address a tough issue.
Are you Overstaffed, Understaffed or Properly Staffed? Can you prove it?
Here are three departments.
Dept Staff
A 25
B 40
C 60
Which department is properly staffed? Let’s look further.
Dept Yr Staff FP Base FP/Per Chg
A 1 25 50,000 2,000
B 1 40 80,000 2,000
C 1 60 90,000 1,500
Now which department is properly staffed? Be careful. Don’t shoot yourself in the foot.
Dept Yr Staff FP Base FP/Per Chg
A 1 25 50,000 2,000
2 25 55,000 2,200 10%
B 1 40 80,000 2,000
2 36 88,000 2,444 22.2%
C 1 60 90,000 1,500
2 62 92,000 1,484 (1.1%)
Dept A’s total functionality supported increased by 10%. That is good.
Dept B’s total functionality supported also increased by 10%, but they did with 10% fewer people.
Dept C, where we added two people last year because they made a good budget presentation, also increased total functionality, by 2000 FP. But their FP/FTE ratio actually decreased. Why?
An important point about this ratio is that different systems have different rates of support and that is all right. What is most important is how things are changing.
As the above shows, if you had made decisions based upon the simple ratio, you would have ignored the major improvements occurring in Dept B.
There is a story behind every number, and we recommend getting both before making any staffing decisions. However until now there was never any comparability, never any way to even ask the question, “Are you overstaffed, under staffed or properly staffed?” Until now, staffing was determined by personality and salesmanship. Now management can factor in existing “actuals” and changing priorities.
This report can be utilized immediately by BASELINING.
In addition and even more impacting is the ability of management to establish clear, concise, simple and equal goals to all departments. For instance, as CIO, I would give all departments the same challenge. Improve your numbers by 20%.
| | B H of Denver, CO
IBM
Phone: 262-789-9190
Email: Bill.Hufschmidt@functionpoints.com
|
| Why Baseline? | Why Baseline?
Why Baseline? There are many reasons and benefits of Baselining. Lets start with Bragging Rights. Bragging Rights are provable facts, good enough to brag about. They are usually overlooked until a good measurement program is installed. CEO Bragging Rights are so good they get escalated to the CEO.
The first “CEO Bragging Right” of Measurements is that we are measuring 100% of our productive time, not just development, which is obvious.
100% includes:
New Development
measured via Delivery Rate = FP/WM
(where 1 Work Month =130 applied hours).
Enhancements over X hours (usually 3-6 Work Months)
also measured via Delivery Rate.
Maintenance, Small Enhancements, Support,
measured via Support Rate = Hours/IFP (Installed Function Points).
Maintenance, Small Enhancements and Ongoing Support raise fears of adding overhead to your processes. However there are many benefits:
1) Measuring 100%. Imagine a 500 person staff. Assume a 50:50 mix of Development, Enhancements vs. Maintenance, Small Enhancements, Support. It is essential in gaining credibility with Sr. Management and Staff to be able to measure 100% of our productive time. If we only measure Development, we are saying that measurement of 250 people isn’t important. In addition, half the staff will lose the opportunity to “prove” their value.
2) Productivity gains in Maintenance are often better than Development. Therefore, we will hurt ourselves if we do not collect and report this.
3) Collecting data is often very easy, using proven “Fastpath” techniques. A major system (in our experience a threshold around 2500FP) can be counted in a day. The largest applications, often a group of major systems, will obviously take longer. 5000-10,000FP should only take 2-3 days max.
4) Measuring will not impact scheduled staff activity. For example, one group of 21 people, representing 21 applications, spent 1 day in training and 1 day counting. None of their project schedules were impacted.
5) In measuring projects, we have to count files. Therefore approximately 20% of the effort is already done.
6) Counting the Baseline in a concentrated effort increases consistency and reliability of the data. Counting the Baseline helps educate the staff to the benefits such as:
a. estimating,
b. proving productivity and quality, and
c. proving staffing needs.
7) Baselining provides a larger frame of reference for management to identify best practices on issues of:
a. Staffing,
b. Revenue,
c. Costs,
d. IT Alignment,
e. Value and more.
8) Sooner or later you will Baseline. The most successful companies started sooner and gained the benefits immediately. Many of their stories have hard multi-million dollar provable savings, helping to manage their business.
| | B H of Denver, CO
IBM
Phone: 262-789-9190
Email: Bill.Hufschmidt@functionpoints.com
|
| Can you help with Boundaries? | Setting boundaries is like all of Function Point counting, do it “logically” vs “physically.”
The following guidelines and questions are taken from a letter I sent to the CPC in 1990. Many clients say these have helped when issues seemed less “black and white.”
1. Document any assumptions or guidelines used.
2. Consider the business function of the data.
3. Consider the reporting needs of the data.
4. Consider the organization of the company.
5. Consider time reporting and/or administrative needs. AVOID OVERHEAD!
6. Try to avoid double counting or excessive interfaces that “inflate the count.” Systems that ‘talk to’ each other do so via interfaces and/or transactions. For example, an ILF read by another boundary will be counted as an EIF in the second boundary. An EO from one system is counted as an EI in the second system.
7. In terms of the smallest subsystems to break out for counting, defer to the system experts.
8. In terms of reporting, defer to management needs.
9. Note the technology platform, hardware/software/architecture/network... Different platforms can have different delivery and maintenance rates.
10. Are batch and on-line viewed by the user as one or two systems?
11. Does the same team support batch and on-line?
12. Are there multiple users?
13. Is it a package, customized code, or combination of both?
14. Is a package supplemented by locally developed subsystems?
15. Does the system have significantly new user or operational requirements?
16. Can application ID’s be used to differentiate boundaries?
17. Does the system mostly utilize existing files? If yes, maybe it should be aggregated with an existing system.
18. Was development done outside the systems group or even outside the country?
19. If there are half a dozen small but related systems, should they be aggregated together?
20. Keep it simple (KISS).
Don’t waste time arguing about boundaries. Make decisions and proceed. Boundaries can be changed later with little effort. “He who hesitates is lost.”
21. Update: Set boundaries at the lowest level meaningful to the user.
| | Bill Hufschmidt of Elm Grove , WI
Deveopment Support Center
Phone: 262-789-9190
Email: Bill.Hufschmidt@functionpoints.com
|
| Backfire Can Backfire | “Backfire” can Backfire
This was the title of the article by Alex Lubashevsky, published in IT Metrics. The following includes his comments and some of my own background experience.
Alex pointed out, it was originally “inviting and convenient, … to assume a one-to-one correlation between FP and LOC.” The idea, first put forward by Capers Jones and SPR, always carried strong warning messages, and today is no longer advocated. Actually we owe Capers extra recognition for his public endorsement of the IFPUG FP model as it has evolved and counting consistency across organizations has improved.
Backfiring was based upon early function point counting (the original 313 Guideline document, also known as Albrecht 84 or version 1.0) versus physical lines of code of 31 IBM MF Cobol projects. By definition, counting had to be done by inexperienced people. Once published, it became the foundation for hundreds of other languages, based upon their language “level.” However, due to abuse of the “averages” the tables have been withdrawn.
As Alex said, “Unfortunately … the margin of error using the backfire method ranges from 25% to more than 200%.” Alex noted similar studies, by Paul Lusher, Naval Surface Warfare Center, John Barnes Consulting (UK) and AT&T, also reported wide disparities. Additionally the “averages” were never updated to reflect the 26% change from IFPUG CPM 3.4 to CPM 4.0.
As Alex summed up, “All the above mentioned data underlines a lack of direct correlation between the FP and LOC metrics due to the unreconcilable differences between the logical and physical methods of implementation. Extreme caution should be exercised in using the backfire method for anything other than a ‘bulk’ guess-timation of the size of a software project.”
It is now possible to “Estimate any project, sight unseen, regardless of technology, in two minutes, with a guarantee, as early in the life cycle as gleam in your boss’s eye.” Using FP audit procedures, we once saved a client $1.4M in one day on a critical Vendor RFP. So why adopt an out of date idea?
| | Bill Hufschmidt of Elm Grove, WI
DSC
Phone: 262-789-9190
Email: Bill.Hufschmidt@functionpoints.com
|
| Testing an OO Design | How do you test an OO Design?
You do a peer review or a walkthrough. That’s good. But peers are busy and they tend to only look at their particular issues. And Projects still go over budget. “Is there anything else I can do, at design time, when changes cost $1 vs. $100 post implementation?”
Yes, a Function Point count. Sounds too simple, but it works. We are a company that makes the machines that test the chips. We were getting ready to make a major investment in new processes, utilizing new software technology. We had the tools and expertise for the upgrade, but it was a major major system of more than 8500FP (larger than 3 major systems) and we were concerned with the estimates? The complete set of existing requirements was the existing system and code. In addition to the new features of the system, we wanted to insure that none of the existing requirements were missed.
Bill arrived after the peer reviews had been “passed.” After an initial review and Fastpath training of the chief OO designer, we dug in and began counting the existing system. We looked at all of the screens, files and reports, and documented them in the FP count. As we did this, the OO designer frequently interrupted to check the new OO design to see if the function was in the new design. All too often it was not, especially the more “mundane, taken for granted” functions. Also missing were some critical functions that had originally been built and represented by people who were no longer at the company.
Results: An estimated $100,000+ savings, by getting all the requirements right before construction, without incurring any delays in schedule. Net Costs: The measures were free.
| | S M of Silicon Valley, CA
Withheld
Phone: 262-789-9190
Email: Bill.Hufschmidt@functionpoints.com
|
| Unit Cost Pricing | It was hard for us to understand just what we were getting when a principal Software Supplier billed us for projects. It seemed like minor enhancements cost as much as the original purchase and installation of a major package. We utilized Development Support Center to learn how to do Metrics. Then we sent Bill off to train our supplier, also a Fortune 50 company. We then met (ourselves, our supplier and Bill) to establish their unit costs, based upon completed projects that had been paid for.
We determined a Unit Cost per Function Point for Development, Enhancements, Support and Help Desk.
The very first project, after establishing the rates, was estimated by someone inside our company to be only $300,000. The vendor came back with $600,000 estimate. Before the screaming, shouting and finger pointing got out of hand, we were able to show that based upon the Unit Cost of previously completed projects, the supplier price should have been $900,000.
Result: Our users shut up. The Supplier was happy. The measurement program was paid for with the first project. Win, Win, Win!
| | C L of Withheld, USA
Major Computer Manufacturer
Phone: 262-789-9190
Email: Bill.Hufschmidt@functionpoints.com
|
| 31% Annual Productivity Gain | The following highlights are from a company that has collected data for five years.
IT Software Balanced Scorecard
Total Increase in Functionality Available to Users
(50,000FP to 128,000FP) 156%
Staffing Increase 0%
Average Annual Productivity Gain (FP Supported/FTE)
(625FP/FTE to 1600FP/FTE) 31%
Average Annual Maintenance Rework Reduction
(.65HR/FP to .32HR/FP) 20%
% of Functionality running on Mainframes (98% to 52%)
Based upon the weak economy, the company has drastically reduced or eliminated all Capital Investment budgets with one exception. Due to the IT Productivity Gains, proven through their Metrics Program, the company approved the Capital Investment budget to continue upgrading of distributed infrastructure and purchase tools to assist in mainframe tuning.
| | B K of Midwest, US
Telecom
Phone: 262-789-9190
Email: Bill.Hufschmidt@functionpoints.com
|
| Naming IFPUG and Gaining Respect. | In the Spring of 1986, when I was just getting into Metrics, management was more lip service than commitment, much like it still is in many companies today. I was often pushing upwards trying to get support. I was often kidded and not taken totally serious by middle managers.
So I asked my management if we could host a group meeting of FPUG. They said okay, without thinking too much
about it. Three days before the September 86 meeting, I received a call from England asking about the group. It was the first international call from outside North America. After the call I jumped up and told the administrative assistants to hold the presses on the proceedings. Since those were the days when COBOL and mainframes were king, I changed the cover page of the proceedings to "IF PUG, THEN PRODUCTIVITY." The name stuck and lives to this day.
Then I published a memo to all of my company management telling them of the meeting and listing the 75 companies that were planning on attending. The impressiveness of the
attending company roster caused my company President to alter his schedule and show up for Welcoming remarks. Ever after, the kidding never stopped, but it was out of respect and I was always taken seriously.
The message is you can use a simple idea like hosting a CASMA or other topical group meeting as a tool to "sell" yourself, your ideas and your Value.
| | Bill Hufschmidt of Elm Grove, WI
Development Support Center, Inc.
Phone: 262-789-9190
Email: Bill.Hufschmidt@functionpoints.com
|
| Forecasting Work Effort | My I offer an editorial regarding the debate I often see about whether
function points should be used to forecast work effort. I believe that
there is enough theoretical and practical precedent to successfully argue
that software size can strongly correlate to work effort, given certain
conditions. Not only "can," but "must."
In a previous life, I was a production supervisor for a small national
brewery. Customers (beer distributors) would place their orders with the
Sales department, and Sales would forward those orders to Production. The
standard unit of size in the brewery business is the "case" of 24 bottles.
Customers placed orders in terms of cases, Sales arranged for billing and
transportation in terms of cases, Accounting completed the monthly legal
regulatory forms in terms of cases, and Production would fill those orders
in terms of cases.
For Production, it was critical to be able to forecast the number of raw
materials needed for each order, the duration of production time to fill
each order, and the number of staff hours of labor to fill the order. This
allowed us to try to optimize overall productivity subject to available
resources. By far the most important factor for these forecasts was the
size of the order. Even with random factors such as unexpected equipment
failures, staff illness, raw material breakage, etc., we all knew that in
our facility an order of 10,000 cases took just about twice as long to
produce as an order of 5,000 cases. Production planning was a
straightforward matter.
The same situation applies to software development. The software life cycle
begins (approximately) when customers place orders for standard units of
software -- function points. Good software project managers know their
productivity rates in terms of average number of days to develop a function
point and average cost to develop a function point. Once the software
requirements are known or at least estimated, then it is a straightforward
matter to convert those requirements into function points and then forecast
duration to produce and cost to produce. In principle, there is no
difference between planning for a brewery production run and a software
production run. Only the industries are different.
Earlier I gave a caveat "under given conditions." Here is what I mean. In
the brewery, we had several bottling production lines. One was a high-speed
line, one was a moderate speed line, and we ran a low speed line until it
was phased out. The productivity figures for the high-speed line were
certainly different than those of the other two lines, so we used different
formulas depending on the line. We also used different formulas for a
fourth line depending if it was running 8-ounce bottles or quarts.
Likewise, one must adjust the software development productivity formulas
depending on the production conditions. Those conditions can be affected by
language, team skill sets, work week duration, etc. (The commercial
software development estimators like KnowledgePlan, SLIM, and SEER-SEM all
require software size inputs to start, but they also require inputs
regarding those team productivity characteristics.)
In my organization, we have a very strong knowledge of our productivity
rates. We have a single large team producing software under two main
languages. We have very strong correlations between software size and work
cost and duration. For example, over the last two years our forecasts have
been running within about plus or minus 15% of actuals when using function
point analysis. This has been a huge improvement over expert opinion and
previous contractor attempts at using lines of code. This is one of the key
reasons we use function point analysis -- it facilitates much better
business decisions. Function point analysis has more than paid for itself
here in terms of dramatically improved budgets and reduced frustration
levels.
I would like to add one more item. We sporadically run into a nebulous
counting situation -- the IFPUG CPM can not anticipate every counting
situation possible --and develop an in-house counting rule to address it.
We currently have 11 of these local rules for a portfolio size of around
130,000 function points. In each case, the rule was formulated with the
intent of improving the correlation between functional size and work effort.
We recently had an honest difference of opinion on how to count a few
potential ILFs. We resolved that by calculating which approach had the
higher function point to work effort correlation. As a by-product --
should multiple media be counted as more function points than a single
media? I think so and we count it that way. Not only is it written that
way in CPM 3.4, but also at least in our situations multiple media require
more work effort than a single media does.
My overall editorial point here is that function points should be used
largely to improve business value and return on investment. Software size
does strongly correlate to productivity when properly formulated. I also
believe that any counting rules discussions should produce results that
serve to equal or exceed the strength of Dr. Albrecht's original statistical
formulas.
Charley
| | Charley Tichenor of Washington, DC
DOD
Phone: 262-789-9190
Email: Bill.Hufschmidt@functionpoints.com
|
| Multimedia | The following is reprinted from FPASM_Forum #61.
We count following all of the published standards. In our experience, IFPUG
CPM 4.2 rules apply to 98% of all the situations we run into. Conventions
and practices of CFPS, like multimedia apply to only 1% of the situations
and company specific interpretations apply for the remaining 1% of
situations.
Whenever we feel outside the 98% we always include a comment for subsequent
follow up if the CPM should make a rule. What if they are two different
users with two separate requirements? Is the multimedia capability part of
the application or part of middleware? If it were to significantly affect a
"count," we might place a sub boundary around it. Gene said it is easy to
create multimedia. So what? Should IT be penalized because we have tools
that will increase our productivity? Would people be happier if we made it
difficult?
Actually it all sorts out with a change in the Productivity Rate of the
estimate.
Remember my trick question, "Which weighs more, 1000 pounds of gold or 1000
pounds of chicken feathers?" They weigh the same, but as soon as you
mention gold, people think of money. However, if you are a FedEx person
trying to get either across the country overnight, you have two distinctly
different business problems. But in either case, you have to know the
weight to calculate the amount of fuel to put on the plane. Actually the
chicken feathers are more valuable, in terms of money, if you are Exxon and
you need to get the chicken feathers to an oil spill.
Lets take another example. A package has 100 unique reports with totals
(EOs). Assuming they are all average, that is 500 FP. In modern times I
might buy a package. It comes on a CD. I can install the package in less
than 1 hour. Let's further assume with meetings and requirements
gathering... the total time expended is 1 work month. The productivity rate
is 500FP/WM.
Compare that with 10 people expending 10 WM each to develop the same
functionality. The productivity rate is 5. Which is the better business
decision to meet user requirements?
Remember, Business Decisions for Business Reasons.
What's next?
| | Bill Hufschmidt of Elm Grove, WI
Multiple companies
Phone: 262-789-9190
Email: Bill.Hufschmidt@functionpoints.com
|
| Bylaw Changes | The following is reprinted form the FPASM_Forum Digest #61.
First Issue: Bylaw changes
Like many others, I assume when the Board asks for something they understand
the ramifications. So I am generally supportive. There are valid reasons
for the change, but we seem to be caught in a transition period and ex-post
facto stuff.
In the case of Mary and Dave, both have contributed endless hours and both
deserve the Thank You of every IFPUG member.
Thank You Mary and Thank You Dave!
Knowing the many hours required just for Board work, I assumed they have
been serving their committees in a less direct more advisory manner. And
the Bylaws say nothing about how the committees are to be run.
I recommend the committees continue to utilize both Mary and Dave in an
advisory role, if they have the time. Based on the CPC consensus voting
requirements, where one vote can stop anything, I don't see how much would
change. Neither Mary nor Dave are obstructionists.
Due to the immense implications of ISO, I further recommend that the Board
and ISO committee continue to utilize Mary's expertise in any way possible,
advisory or member at large. However, I also recommend grooming some backup
members as a pure safety measure.
| | Bill Hufschmidt of Elm Grove, WI
Development Support Center, Inc.
Phone: 262-789-9190
Email: Bill.Hufschmidt@functionpoints.com
|
| Saving $2M | Once I attended a presentation of Operational Savings by a major Midwest manufacturer. They had tracked every expense associated with defects for 1 full month, to generate an average cost/defect. By increasing the reliability of their Operations process and procedures, they had reduced their defects and outages, thereby saving $1M.
When the presentation was done, I had two questions. The first question made the speaker very nervous, "Does your management really believe these savings?" He responded that they had been very supportive and did believe the savings. The second question blew his mind. "Do you realize you have understated your saving?"
Unbeknownst to the speaker, we had measured the company’s associated functionality, we could demonstrate the increased functionality combined with the increased usage actually provided twice the savings, with more than a 100% increase in their Value Index.
This is an example of the right facts (see New Business Organization below) providing insights never before available.
| | John K of Metro Chicago, IL
Midwest Manufacturer
Phone: 262-789-9190
Email: Bill.Hufschmidt@functionpoints.com
|
| New Business Organizations | Successful business Org Charts look more like wheels than triangles or pyramids. The hub is information and insight that provide for better business decisions. The spokes are managers and the rim is the staff. Observations:
1. All managers, even CEOs, gravitate to the hub. In lieu of facts, they must accept “trust me” opinions. It is in everyone’s best interest to replace opinions with facts. Metric Maniacs have or can get facts.
2. I have an old bike. The front wheel is missing 3 spokes. Yet every spring, I can pump up the tires and go for a nice ride. Sr. Management has learned they can also ride with fewer spokes. They will always rely on the managers with the best facts. Metric Maniacs constantly seek the right facts to provide insight that can make a difference.
3. The tires, my staff, just take the wear. But when pumped up, they always respond and provide the Value I seek. Metric Maniacs can measure pressure.
4. Outside the wheel are bumps and roadblocks to be avoided. Sr. Management views people as part of the solution (wheel) or part of the problem (bumps).
5. Along the road are bodies of people who resisted facts needed by management. Sooner or later, and lately it’s been sooner, they are run over and become “roadkill.”
6. Where do you fit in your organization? | | John K of Metro Chicago, IL
Midwest Manufacturer
Phone: 262-789-9190
Email: Bill.Hufschmidt@functionpoints.com
|
| Function Point Counting of Algorithms | The function point analysis methodology of the International Function Point Users Group (IFPUG) "Function Point Counting Practices Manual" can be directly used to measure the size and complexity of many algorithms inherent in modern software, especially real time. Examples of these algorithms include those for controlling a nuclear reactor, calculating complex pricing arrangements, finding the shortest routes for telephone calls in a metropolitan area network, etc. The paper "Measure the Size, Complexity of Algorithms Using Function Points" (published in "CrossTalk The Journal of Defense Software Engineering," February 2001, http://www.stsc.hill.af.mil/) offers experienced function point counters a paradigm for recognizing embedded algorithms, counting many of them according to the IFPUG rules, and improving the quality of their function point counts. The authors hope to dispel some of the perceptions that new methodologies are necessary to perform this kind of software metrics.
| | Charley Tichenor of Arlington, VA
Defense Security Cooperation Agency
Phone: 703-601-3746
Email: Charley.Tichenor@osd.pentagon.mil
|
| Bottom Line Customer Satisfaction | Bottom Line Customer Satisfaction
Volumes have been written on Customer Satisfaction. The important thing is that feedback is solicited, received, evaluated and acted upon.
Is all customer satisfaction equal? No! Is it more important to concentrate limited resources on the smallest or largest customer? Largest, obviously! How do you determine smallest vs. largest? Measure it!
The management 80/20 principle implies that your perception of size vs. reality of size is probably the same 80% of the time. Measurements pay for themselves in the 20% range of misinformation. This is where too much or too little resource is applied to a business problem.
Suppose I have four systems. All have been queried for Customer Satisfaction and all are 3 on a 1-5 scale. What if the average of Customer Satisfaction goes from 3 to 3.25. Is that an overall 8% increase? Let's look at two scenarios.
Sys CS CS CS Chg
Yr1 Yr2-1 Yr2-2
A 3 3 4
B 3 3 4
C 3 3 4
D 3 3 1
Avg 3 3.25 3.25 8%
What if I add a size parameter? See the chart below.
Weighted
Sys CS Size CS Yr1 CSYr2-1 CS Yr 2-1 Chg
A 3 1000 3000 4 4000
B 3 1200 3600 4 4800
C 3 2500 7500 4 10,000
D 3 10,000 30,000 1 10,000
Avg 3 44,100 3.25 28,800 (35%)
Weighted
Sys CS Size CSYr 1 CS Yr2-2 CSYr2-2 Chg
A 3 1000 3000 3 3000
B 3 1200 3600 3 3600
C 3 2500 7500 3 7500
D 3 10,000 30,000 4 40,000
Avg 3 44,100 3.25 54,100 22%
Weighting systems by simple functionality measurement can reveal two totally different conclusions. (Our experience has shown that systems under 1000 Function Points are perceived as small. Systems up to 2500 Function Points are perceived as medium and above 2500 Function Points are recognized as major. System C and D were both recognized as major systems in this company but no one had any idea of "how major" D was.)
In the first scenario, we did nice things for many people but did we maximize our value to the company? It appears not. The overall average 8% increase was not believed because the largest user was very unsatisfied. The 35% decrease did reflect management's perception.
The second scenario is a big success story that is under-recognized in the overall average 8% increase. Weighting the systems is enhanced when leverage or supplemental metrics are also included. For example, the second scenario also resulted in increased usage and reduced unit cost in the user area. The 22% increase was actually viewed as a very "conservative" representation of the increased size, leverage and value the system now provides.
Customer Satisfaction is exceedingly useful in corroborating other issues. For example, if maintenance is reduced by 20%, is that good or bad? If Customer Satisfaction remains the same, it is good. If customers are unhappy, it is bad.
Like all measures, Customer Satisfaction needs to be understood as a valuable but single measure within the framework of the full seven dimensional Metrics model.
| | D W of Chicago, IL
Telecom
Phone: 262-789-9190
Email: Bill.Hufschmidt@functionpoints.com
|
| Outsourcing Issues | Staffing and Outsourcing
Are you overstaffed, understaffed, or properly staffed? The answer is yes, but can you prove it?
Will you invest $10,000 of your personal money is my business? Maybe you could take out a loan against your home or pension fund. Sound crazy? Why? Because you don't know anything about my business. So what does your CEO know about your IS department's budget versus value received? If the answer is nothing or very little, then you are perceived to be overstaffed. Next step is downsizing or outsourcing!
How can you control or lead staffing discussions? By measuring and proving our own productivity (+22%), quality (+45%), and staffing ratios (+190%), we set the agenda and the goals for future improvements. (Numbers in parentheses are actual, achieved results from multiple companies.)
The goals are then applied to other business areas as well as outsourcing agents. If others can show better results, let's learn from them. If they can't, we become a "CEO Bragging Right."
Suppose the company needs $1M. To be "fair," senior management decides to reduce the budgets of Marketing, Information Systems and Widget Production by $333,333.33 each. Did they help or hurt the company?
Now suppose instead that the company has three $1M outstanding Treasury notes. One earns 20% from 1980. One earns 12% from 1983 and one earns 3% from 1993. Would you recommend being fair, cashing in all three notes and taking $333,333.33 from each?
What's the difference in these two scenarios? Money is measured. So is staffing. The difference is measurement by perception vs. measurement by fact.
What about Outsourcing? Your CEO has read about or received a call about Outsourcing. In a world of 999 IS departments, 499 will be above the median, 499 will be below. Which are you? Can you prove it? Without measures, you're just another opinion! Without Proof, you are an Outsourcing cnadidate.
| | C C of San Ramon, CA
Pac Bell
Phone: 262-789-9190
Email: Bill.Hufschmidt@functionpoints.com
|
| Return on Investment | Return on Investment
If the corporation takes $1M from the Information Systems' budget, what's the bottom line effect? A $1M reduction in expenses and a risk free $40,000 in income (assuming 4% rate on savings accounts or treasury notes). So what do you deliver if they leave the $1M in your budget?
In the Widget Department, a $1M reduction would translate into X fewer widgets produced. We produce functionality. We can measure our functionality and the impact of any reduction. We can also measure the corporate impact (leverage) and value index to better explain the complete effect of any budget reduction (see chart below).
The Widget Department has a goal of increasing their production by 20% without adding to staff. Assuming they are working at full capacity, they must change the way they do business. They must modify their mix of Hardware/Software/People/Requirements (H/S/P/R). They currently have a 1000 FP system with a usage factor of 100 (possibly users or stores or branches or wire centers...) and a Customer Satisfaction rating of 3 on a 1-5 scale.
How will the Widget Department increase production by 20%? Let's examine a proposed $1M project. The project will increase unadjusted functionality by 100 FP (10%) and the Adjustment Factor (14 General System Characteristics) by 10% for a total Function Point Increase of 21%. This means the user will have 21% more tools at their fingertips.
Existing Change ROI
1000 Unadj. FP 10% 1100
x1.0 Adj. factor10% 1.1
1000 Function Pts. 1210 21%
x100 Usage 5X x500
100,000 Leveraged FP 605,000 600%
x 3 Cust.Sat +1 x 4
300,000 Value Index 420,000 800%
This alone may not solve all production issues, but we have met our own commitment and 21% is greater than 4%. Now the system rollout increases usage from 100 to 500. The total corporate impact (Leverage) is 600% and 600% is greater than 4%. In addition, our project plan, agreed to by the Widget Department said that if we delivered as planned they would give us a customer satisfaction rating of 4. The increase in the value index is 800% and 800% is greater than 4%. Plus our other metrics show that we increased our own productivity by 20% (from 25 FP/Work Month to 30 FP/WM) at the same time.
Although not technically a financial ROI, from a pure accounting view, it provides management with numerical and measurable goals. Besides, not all corporate decisions are based upon pure accounting ROI.
So what's the ROI of the entire System's Department? If all our productivity rates go up by 20% and all our maintenance/support rates go down by 20%, we can logically argue that our ROI is 20%. However, as shown, our Leverage and Value Indices can be utilized to demonstrate a more complete picture.
| | Rich P of Albany, NY
GE
Phone: 262-789-9190
Email: Bill.Hufschmidt@functionpoints.com
|
| Measuring Maintenance | Measuring "Maintenance"
One of the first "CEO Bragging Rights" of any measurement system is that we are measuring 100% of our productive time, not just Development which is obvious.
100% Includes:
New Development measured via Delivery Rate = FP/Work Month
Enhancements over X hours (often times > 260 work hours)
also measured via Delivery Rate
Small Enhancements, Maintenance and Ongoing Support
(also known as "steady state" or "Ready to Serve")
are measured via the Support Rate = Hours/IFP,
Installed Function Points.
Small Enhancement, Maintenance and Ongoing Support are often the hardest to comprehend because of fears of adding overhead to the process. Let's discuss.
Benefits:
1) Measuring 100%. With 500 people on staff, and assuming a 50%:50% mix of Development vs. Maintenance/small enhancements, it is essential in gaining true Senior Management and Staff creditability to be able to measure 100% of our productive time. If we only measure development we are saying that measurement of 250 people isn't important.
2) Productivity gains in Maintenance are often better than development. Therefore, we will be hurting ourselves if we do not collect and report this data.
3) Collection of the data is often very easy. We counted one system, a 91 year development effort, in two counting days.
4) Measurement does not impact scheduled staff activity. For example, one group of 21 people, representing 21 applications, spent 1 day in class and 1 day counting. None of their project schedules changed because of this.
5) To accurately measure Development or Enhancements we have to count the existing files. Therefore, approximately 20% of the counting work is already done.
6) Staff support of any Measurement process is essential. If we do not count the Base, half the staff will lose the opportunity to "prove" their value and contribution. This is quite unfair.
7) Counting 100% of the existing systems under a concentrated effort will increase consistency and reliability on all of the data.
8) Counting the existing Base systems is an important step to educating the staff on the "positives" of measurement such as its uses for:
¨ estimating
¨ proving productivity and quality rates
¨ proving staffing needs.
9) Knowing the size of systems allows management to compare systems and identify best practices based upon:
¨ size
¨ staffing needs
¨ costs
¨ corporate contribution
¨ value.
10) Sooner or later you will count your Base. The most successful companies started sooner; so they gained the benefits of having the data immediately. Many of their stories have hard multi-million dollar provable savings. These have been influential in managing their businesses.
11) We can establish Return on Investment (ROI) data immediately. We can even create retroactive data so trends can be established and reported.
12) YOU CAN'T MANAGE WHAT YOU CAN'T MEASURE!
Approach:
The goal is to understand the overall growth in user functionality. It is essential to insure low overhead data collection in both the initial count and ongoing reporting. Here are five proven techniques.
1) Grouping all of the enhancements together as a single comprehensive "set" concentrating on the added functionality over a 3, 6 or 12 month period. One company, with 16 support FTE's, expended 1 work day/16 work years to maintain their "base."
2) Subgrouping enhancements as a "release." Measuring each enhancement at "turnover" into production is the goal. If measuring becomes overhead, then get rid of it. Going to "releases" will reduce overhead.
3) Updating the count once per year by counting the entire system again. This "recounting" should only take one quarter of the time for the original count.
4) Utilize an alternative Staffing Support Rate = FP Supported/Person. This will show productivity and quality gains in basic required (mandatory legal, regulatory corporate or political) support.
5) Take advantage of supplemental metrics like leverage, quality or customer satisfaction. For example, one company had a 9% increase in maintenance hours on projects less than 40 hours. However, their supplemental metrics proved a 7% increase in total functionality, and a 3% decrease in total operating costs. Another company proved a 6 fold (6X) increase in functionality and a 42 fold (42X) increase in a system's corporate impact.
Result:
Remember, companies do Business Projects for Business Reasons! Maintenance Measurements must complement the business reasons and remain low overhead or they become counter productive. The above approaches can assist in the Productivity, Quality, Leverage, Staffing, and Value dimensions of a complete Measurement program.
| | Bill Hufschmidt of Elm Grove, WI
Several
Phone: 262-789-9190
Email: Bill.Hufschmidt@functionpoints.com
|
| Estimating and Funding Measurements | Estimating and Funding Measurements
Your company can immediately utilize the estimating and estimating verification features of Function Points to potentially save millions of dollars.
Success Stories:
A major manufacturer checked a vendor estimate against their own internal measures. They found the vendor bid $1.4 million too high. They still did the project and they used the same vendor. But, they saved the entire amount in just one day.
A major utility spent 18 work months (6 people working for 3 months), $180,000, just to estimate the cost of a project. Management asked, "How do we know the estimate is correct?" They were able to validate the estimate for the full development in just one day.
A major manufacturer validated their 75 work month estimate in one day. The presentation to management allowed them to assign "insurance resources" to a "drop dead" project before it was "too late." Results were a big success for Management, Information Technology, and the Company.
A retailer checked a $6,000,000 project estimate in two days, thereby increasing Information System's credibility.
A project team saved over $200,000 of rework after an internal Function Point review.
A successful measurement program will more than pay for itself many times over. So if funding is an issue, it is usually an indication that management is still not looking at the complete picture.
Measurements are management tools. The higher the level, the greater their impact, even if they are not used every single day. They are also a giant disaster avoidance insurance mechanism as the above case studies prove.
| | Bill Hufschmidt of Elm Grove, WI
Multiple
Phone: 262-789-9190
Email: Bill.Hufschmidt@functionpoints.com
|
| Function Point Analysis Super File Rule | A “function point” is one standard unit of software size and complexity. Most software is decomposable into function points, which can then be counted, giving its size and complexity. Standards for sizing software using function points are in the International Function Point Users Group (IFPUG) Function Point Counting Practices Manual.
This function point methodology recognizes and defines a wide variety of user-required functionality in general, and two types of database file in particular. The first type are those files maintained within the user's application and are called "internal logical files" (ILFs). The second are those files belonging and maintained elsewhere, and accessed on a read-only basis. These are called "external interface files" (EIFs). The standards have procedures on how to measure the size and complexity of these files.
Some perceive a gap in one part of the current IFPUG sizing standards. According to current standards, high complexity software database files containing from 50 to 100 unique fields are considered having the same size and complexity as database files of more than 100 unique fields. These “super files” may contain up to 1000 unique fields or more. This gap renders it impossible for software developers to forecast their super file development costs using a repeatable, quantitative method. The situation is like an otherwise excellent office supply store trying to sell “very large” file cabinets without being able to define “very large.”
As a remedy, function point counters may want to consider using the "Super File Rule" from a previous Counting Practices Manual, version 3.4. This rule states that if either an ILF or EIF contains more than 100 data element types, then each record element type of the file is counted as a unique and separate ILF or EIF -- assuming all other counting rules apply.
The Super File Rule is academically sound and is statistically significant. As the size and complexity of super files increase, their statistical significance measured in terms of the F statistic increases towards infinity as a limit, while the current counting standards F value decreases towards 0 as a limit.
The dissertation detailing this finding is available by email.
| | Charley Tichenor of Arlington, VA
Defense Security Cooperation Agency
Phone: 703-601-3746
Email: Charley.Tichenor@osd.pentagon.mil
|
| IT Balanced Scorecard | IT Balanced Scorecard
2001
Total Functionality – See Note 1
Completed Count Available for Audit
(4,123 Files + 20,186 Trans) X [1.25] =154,000FP
Estimated (Count In Progress) = 8,000FP
Total =162,000FP
Increase in Portfolio 2001 < 1%
(Total Functionality available to Users)
Churn – See Note 2 = 99+%
Average Functional Application Expertise =704
Productivity (Maintenance and General Support Rate)
16,000 Hrs/162,000FP = .1 Hrs/FP
Usage (Clients 416 to 461) =+11%
Staff Size = - 8%
Staff Support Rate = 13,500/FTE - See Note 4
Actual Cost – See Note 5 = -15%
Unit Cost ($/FP) – See Note 6 = -15%
Importance Level (14 of 25) – See Note 7
Leverage (162,000FP X 461Clients) = +11%
– See Note 8
System Response Performance Monitor =+21%
- See Note 9
TOP (Team Overall Performance) Index =+70%
- See Note 10
Note 1: Function Points (FP)-An independent, objective, quantified, consistent, auditable measure of the size and complexity of Business Application Software from a User’s perspective.
Function Points encompass the screens, files and reports of an application. Most files or tables of data are worth 7 FP. A transaction that generates a report is usually worth 7 FP.
Based upon Expert Experience,
0-1000 FP = Small System
-2500 FP = Medium Sized System
+2500 FP= Major System.
A major system is one whose Acronym and general business function is known by Users, Management and IT. This SAP implementation equals 60+ major systems.
Function Points are in the process of becoming an ISO Standard. All measurements followed the current IFPUG 4.1 Standard.
Note 2: Churn is the amount of work expended for changing existing functionality and very minor enhancements. Formula: Churn = 1 – (FP added/FP worked). Example:
Churn = 1 – (50 FP added / 250 FP worked) = 1 - .2 = .8 = 80%.
In this example, 80 percent of the work expended is just changing existing functionality, without adding new user capabilities (that might improve productivity), even if they are Mandatory (Legal, Regulatory, Corporate, Political).
Note 3: Expertise is a derived calculation based upon knowledge, experience and total functionality supported. The calculation can then be compared with other staffs. This is a very high level. For details see Bill Hufschmidt.
Note 4: Published Benchmark Targets and Expert Experience of Staff Support Rates in successful major IT installations = 400 to 2000 FP/FTE.
*This company is in the stratosphere thus explaining why churn is 99+%.
Note 5: Actual Costs ($) were 17% less than Planned Costs ($).
Note 6: Unit Cost = Total Actual Costs / Total FP = under $100.00/FP. This is very conservative, since the functionality of additional technical and end user support has not been counted. If you consider only SAP application costs, this number is significantly lower.
Note 7: To determine Importance, we used a “luncheon assessment process.” It considers only five reasons for doing any project. SAP was evaluated on a 1-5 scale.
Mandatory (Legal, Regulatory, Corporate, Political) 5
Increased Sales or Market Share 0
Increased Efficiency, Cash Flow, Reduced Cost, Cycle Time… 3
Increased Customer Satisfaction 4
Future Investment 2
14
Note 8: Leverage measures a particular system’s impact, not importance! The usage factor (in this case, client workstations) will not always apply to every system. Whatever the usage factor, it must make sense from a business perspective and be an independently verifiable number (e.g. number of stores for a shoe company, number of branches for a bank or number of total transactions).
Note 9: Reduction in daily average response time from 800+ms to 635ms, a 21% improvement.
Note 10: TOP Index was defined to be:
+Increases in total functionality 0%
+Increase in usage 11%
+Reduction in staff size 8%
+Reduction in actual cost 15%
+Reduction in unit cost 15%
+Reduction in average response time 21%
70%
| | J K of Elm Grove, WI
Food
Phone: 262-789-9190
Email: Bill.Hufschmidt@functionpoints.com
|
|
|
