I can bet that almost every software development project faces with a dilemma of questioning some of the business requirements that actually come from the very business that you are trying to systematize. This is arguably the most dangerous zone for any software development manager to get into as your suggestion would inevitably be considered as if you are questioning the business people's core skills. But you can't just accept it by its face value without critically analyzing the requirements. After all, in the current business environment, neither the business nor the technology independently drive the company's future. Now the sixty four thousand dollar question is, how would you do it in a methodical way? The answer lies in the word "Triangulation". This exists in other disciplines for long time and can be used in software development management.
Let's see a usage of Triangulation in other discipline. Triangulation is used by your Global Positioning System (GPS) device. There are at least three GPS Satellite that sends the positions of your device that help the GPS device to accurately pin point your location within a few feet range.
Let's see a usage of Triangulation in other discipline. Triangulation is used by your Global Positioning System (GPS) device. There are at least three GPS Satellite that sends the positions of your device that help the GPS device to accurately pin point your location within a few feet range.
 | |
|
You can use the same methodology to check if a business requirement is justified to be taken into the project. Take a typical business software project. Use the following triads to justify the business requirements: (1) Project Business Objective, (2) Minimum Viable Product (MVP) and (3) Total Cost of Ownership with perpetual cost of maintenance
(1) Project Business Objective is the first filter you have to let the business requirement go through. If the requirement doesn't align or contradict with the project's objective, the chance is very high that there are other motivation hidden behind the requirement that needs to be unearthed
(2) Minimum Viable Product is the Lean concept where it encourages the validated learning through early delivery of the viable software with a minimum set of features. Put that requirement to the test of MVP and see if it passes or fails
(3) Finally, there's no cost free feature in a software. Even for a feature that's working without adding a single line of code can have high maintenance cost. There are several types of cost, such as: now you have to make sure that in every upgrade you do or every new feature you add, the no-code-feature has to be tested to make sure that it functions as is; if you find a better technology/algorithm to implement in that software which would stop that no-code-feature to function, then you either have to stick to the inferior technology/algorithm or now add code to make that no-code-feature to work
Finally, never forget to identify the true need of the business (sometime referred as "problem statement") behind that requirement. You would often find that the true need may be actually vastly different than the very requirement is trying to solve and the requirement may be a solution that the business person came up with to solve that true need. Knowing the true business need would allow you to come up with a true solution of that problem which may be much simpler to implement. Undoubtedly, the simplest solution is the best solution and you would need a complex thought process to come up with that simplest solution.
(1) Project Business Objective is the first filter you have to let the business requirement go through. If the requirement doesn't align or contradict with the project's objective, the chance is very high that there are other motivation hidden behind the requirement that needs to be unearthed
(2) Minimum Viable Product is the Lean concept where it encourages the validated learning through early delivery of the viable software with a minimum set of features. Put that requirement to the test of MVP and see if it passes or fails
(3) Finally, there's no cost free feature in a software. Even for a feature that's working without adding a single line of code can have high maintenance cost. There are several types of cost, such as: now you have to make sure that in every upgrade you do or every new feature you add, the no-code-feature has to be tested to make sure that it functions as is; if you find a better technology/algorithm to implement in that software which would stop that no-code-feature to function, then you either have to stick to the inferior technology/algorithm or now add code to make that no-code-feature to work
Finally, never forget to identify the true need of the business (sometime referred as "problem statement") behind that requirement. You would often find that the true need may be actually vastly different than the very requirement is trying to solve and the requirement may be a solution that the business person came up with to solve that true need. Knowing the true business need would allow you to come up with a true solution of that problem which may be much simpler to implement. Undoubtedly, the simplest solution is the best solution and you would need a complex thought process to come up with that simplest solution.
