What does not work -duration

Besides wasting time planning out many months into the future as if we could see and control that far ahead, there have been studies over the years that have established an inverse correlation between the length of time a project runs and project success rate.  Perhaps this does not sound so odd, given the more tasks we have or the more work we must do, the greater the risks. Consider a product and the opportunities for failure, the more parts, the more opportunities for failure or more failure points.

There is no silver bullet when it comes to product development. However, there are some things that studies tell us what does not work.

Duration

First, the planning and long-term project or treating the job like we know the details 6 months to 3 years in the future.  There are studies from the Standish group that illustrates the project s longer than 6 months in duration have a higher failure rate than projects less than 6 months.[i]

Project Duration and Success

Function points

Like the project duration, the number of function points is another leading indicator the project is to deliver has an impact on the project success rate.

Function Point Analysis (FPA) is a sizing measure of clear business significance. First made public by Allan Albrecht of IBM in 1979, the FPA technique quantifies the functions contained within software in terms that are meaningful to the software users. The measure relates directly to the business requirements that the software is intended to address. It can therefore be readily applied across a wide range of development environments and throughout the life of a development project, from early requirements definition to full operational use. Other business measures, such as the productivity of the development process and the cost per unit to support the software, can also be readily derived.  The function point measure itself is derived in a number of stages. Using a standardized set of basic criteria, each of the business functions is a numeric index according to its type and complexity. These indices are totaled to give an initial measure of size which is then normalized by incorporating a number of factors relating to the software as a whole. The end result is a single number called the Function Point index which measures the size and complexity of the software product.[ii]

In summary, the function point technique provides an objective, comparative measure that assists in the evaluation, planning, management and control of software production.  The more function points we have, the more change requests, and generally speaking change requests represent rework which is waste.  The graphic below illustrates this relationship[iii].  This waste has an impact on the timely project delivery and cost.

Function Point and Requirements Changes

[i] Jim Johnson, et al. 2000. CHAOS in the New Millennium. Published Report. The Standish Group

[ii] http://www.ifpug.org/about-function-point-analysis/ International Function Point User Group last accessed 10/2/2018

[iii] Jones, C. 1997. Applied Software Measurement. McGraw Hill.