Avoid Another Budget Blowout

1
Avoid Another Budget Blowout

• Presentation on a better method to control
  software project budgets

2
Introduction

• Software projects normally over budget.
• There are several common causes.
• per function point approach counters many of
  these causes.
• As a result, projects complete on budget.

3
A Poor Track Record

• Most software projects over budget.
• Some projects never complete.
• Plenty of evidence for this.
• This trend has not changed yet.

4
Dismal Success Rate
Source The Standish Group International,
1997 www.standishgroup.com\chaos.html
5
Problems with Requirements

• Most common causes for software project budget
  overruns are
• Lack of user input
• Incomplete requirements
• Changing requirements
• Lack of executive support
• Technology incompetence
• Unrealistic expectations

6
Attack These Causes

• Commission software on a per function point
  basis and red line
• Lack of user input
• Incomplete requirements
• Changing requirements
• Lack of executive support
• Technology incompetence
• Unrealistic expectations

7
What is a Function Point?

• Measure of software functionality provided to
  users.

Users
Inputs
Outputs
Internal Data
External Data
Input
Other Software
Output
Software Being Acquired
8
What is per Function Point?

• Function points measure the output of a software
  project, software functionality.
• A per function point price links the price of
  the project to its planned output.
• Working with the developer, the customer
  specifies the functionality.
• Customer pays developer a price based on the
  total functionality specified.

9
Typical Compared to southernSCOPE
10
Transfer Technology Risk

• Developers quote per function point on
  specified technology
• Developers decide prices from their technical
  capability, which combats
• Technology incompetence.

11
Setting Realistic Expectations

• Accurate function point measurement needs a
  detailed requirements specification, which
  combats
• Lack of user input
• Incomplete requirements
• Direct link between functionality and budget
  combats
• Unrealistic expectations

12
Managing Changes Well

• per function point approach includes procedures
  for close monitoring of changes, which helps
  combat
• Changing requirements
• Customers felt per function point approach
  provided good way of controlling change.

13
Likely to Stay On Budget
14
Stay on a Controlled Budget
15
Need to Meet Objectives

• It is not enough for a project just to complete
  within budget.
• Customers of /FP projects have stated that
• The projects were good at meeting their
  objectives.
• The projects achieved all important requirements.

16
Need to Get Good Value
17
Conclusions

• Using normal methods to acquiring software, the
  project will
• Most likely go over budget.
• Provide unclear/poor value.
• With the /FP method, the project will
• Most likely complete within budget.
• Achieve its objectives.
• Be done to a competitive price.

18
The Support Toolkit

• Method Documentation
• Presentation to Managers (used here)
• Case Studies
• Overview Flyer
• Computer Based Training Package