As the number of features increases in a project, as does the coefficient of complexity in the application which much be represented in the project scope.
A complexity represents a nonlinear growth in overall development & QA time
Here, you can see how as the number of features grows, the number of connections grows even faster:
You can also view this image on the BrainLeaf Scoping Guide
This is a common misconception within information architecture development which can lead to a substantial misrepresentation of hours in the final work estimate. The increase in complexity is quadratic and is equal to n+(n-1) where n = the number of features in the system.
This figure increases at a non-linear rate and affects the hours required for:
- Project management
- Regression and user test development
- Quality Assurance (QA)
So when this increase is not taken into consideration, project managers and stakeholders are mislead as to the actual amount of time required to build the project.
This is a common mistake that I see regularly when helping teams analyze their projects. The misconception that development time will grow linearly is understandable. Without some experience building complex systems, it would be very hard to think ahead about other outcomes.
How Quality Assurance (QA) is affected
Quality Assurance is the top area affected by this concept and the primary point of failure when this is not considered. Here is an example of what happens:
If a developer changes one feature that has connections out to most of those other features, the team has to test every one of those connections. If that connection from the first feature to the second feature affects something within this feature, then I have to test the connection between the second feature and all the other features it impacts. For each feature affected, now you have to test that item, every use case of that item, and every connection to other features.
A case for automated testing
Very often during planning, as noted above, project managers, stakeholders, architects, and developers don’t consider the cost of testing. Since this cost is non-linear, eventually the time it takes to test becomes greater than the time it takes to build features.
Without automated regression and user testing, it soon becomes so overwhelmingly difficult to test that stakeholders either opt not to and create a product that is not supportable in the long run, or bite the bullet and spend the money to build automated tests. However, sometimes stakeholders either don’t know the power of automated tests or don’t understand them and end up incurring huge costs in lost money from improperly functioning systems or manual testing of every use case for every release.
Example: BrainLeaf.com
When we edit one system feature, even a somewhat isolated system, we have to go through and test the entire system. We have to test every single thing, or at least our critical protocols as well as build protocols for automatically testing that system in the future. If we didn’t have automated regression tests built, it could take one person a full week just to test the system, perhaps longer.
Applying this to scoping a project
So when you’re scoping an application, website, or even a small project, you always have to remember the quadratic or exponential increase in complexity as the number of features increases. As the number of features you’re building, connecting to, or adjusting increases, so must you increase your QA time, as well as your project management time. If you don’t, your project will inevitably end up over budget, late, with an upset client, and you’re going lose money.
So don’t let that happen to you.
If you want more on this one, if you go to www.Brainleaf.com/learn-project-scoping
