Value, Scope and Change Requests

Change requests are part of any development project.  Change requests are sometimes necessary as we learn by building and doing the work.   In my experience, change requests often are born from requirements we thought we understood, only to learn by working with the product or system that we really did not have enough understanding to be able to record this in the form of specifications.  We think we are making things better when we spend an abundance of time documenting the requirements, at least those requirements about which there is uncertainty. That is not to say this is not a worthwhile endeavor, we have been in product development long enough to know there are downsides to delivering a product that has no associated documentation.  The testing and manufacturing portions of the work will make use of these requirements documentation and the errant or lack of documentation makes the work of these areas and more difficult or nigh impossible.

It should not come as a surprise to learn that as we generate more requirements the risk of change requests also increases.  In fact, a study from Capers Jones, demonstrates that as function points for the software increases, there is an increase in change requests and this is not linear.[i]  Function points are a measure of content of the (software) product that eliminates the necessary consideration of the language implications.

What is a function point?[ii]

Function Points are an internationally standardized unit of measure used to represent software size. The IFPUG functional size measurement method (referred to as IFPUG 4.3.1) quantifies software functionality provided to the user based solely on its logical design and functional requirements. The resultant number is called a Function Point Count.  With this in mind, the objectives of FP counting are to:

• measure functionality that the user requests and receives;
• measure software development and maintenance rates and size independently of the technology used for implementation; and
• provide a normalizing measure across projects and organizations;
• perform IT Portfolio Management for C suite executives;
• perform benchmarking against ISBSG data (ISBSG is the acronym for the International Software Benchmarking Standards Group);
• collect and report on CMMI(R) capability maturity model data

Value, Requirements and Change

Understanding the past relationship between function points and project costs, allow us to extrapolate much like builders know the cost per square foot to build a house of a specific level of finish.  We do not need to document all the requirements (generally a bad idea unless the scope of the work is well understood and very small).

There is little value in change request. Any value there may be, is an after the fact, it is better to build the correct thing than what the requirements originally indicated. This represents waste or mura (definition below[iii]), via the over production of requirements that as it turns out were errant.

Mura means unevenness, non-uniformity, and irregularity. Mura is the reason for the existence of any of the seven wastes. In other words, Mura drives and leads to Muda. For example, in a manufacturing line, products need to pass through several workstations during the assembly process. When the capacity of one station is greater than the other stations, you will see an accumulation of waste in the form of overproduction, waiting, etc. The goal of a Lean production system is to level out the workload so that there is no unevenness or waste accumulation.

Mura can be avoided through the Just-In-Time ‘Kanban’ systems and other pull-based strategies that limits overproduction and excess inventory. The key concept of a Just-In-Time system is delivering and producing the right part, at the right amount, and at the right time.

Excess Scope not necessarily mean Value

It is possible to have an excess inventory of requirements, especially when those requirements are uncertain and may in fact end up representing rework, this is not just a software issue but extends to the hardware development as well as our approach to planning the work, for example spending too much time detailed planning too far into the future (another example of mura).

[i] Jones, Capers.  1997 Applied Software Measurement. McGraw Hill

[ii] http://www.ifpug.org/faqs-2/#One last accessed 10/25/2018

[iii] https://theleanway.net/muda-mura-muri last accessed 10/25/2018