Granularity is an often overlooked subject in the IT world. The world of scope definition is only as good as how granular you can define that scope. Too many times in the IT world people overlook granularity. It is extremely easy to print off a website and take a highlighter / red pen to the print offs and submit your requests for changes. What you forget is that every stroke of your writing utensil has consequences in the form of an end dollar that you have to pay. Not to mention the number of times a new change is made. The less you want to pay, the longer it takes, and the fewer levels of business analysis, the more the costs run up. In whatever combination you want to stroke the utensil’s, realizing this granularity is exponentially important.
Defining a contract or agreement and a set definition of scope for a particular project is important. But true definition of scope does not only include the breadth and size of the project, but also the level of detail. This common flaw is why we need Business Analysts and Systems Analysts. So many times it is easy to encapsulate the entire set of boundaries, but twenty thousand times more often do those detail specific requirements ever get recognized. Granularity is the devil against Scope Creep.
Some project managers use granularity to their advantage, particularly when projects are set for fixed price. Project Managers can and do milk granularization to the point that they can capture every single dollar amount out of a company / consultant (no bad blood… ?). Granularity must be contained while conducting business, otherwise it will drive a business into the ground. I learned early on when I heard of my College Professor who gave a fixed price of $30k for an application, all the while spending 2 years on the project. How can you live on $15k a year?
All of this said, Business and Systems Analysts are hard to come by. First off, how hard is it to find a programmer in your world? Second, how much more difficult is it to find a Business or a Systems Analyst that has the technical capabilities? Who can understand the complex logistics of system architecture? More times than not, if they can understand it, they are programming it. And all the other people are pretending to fulfill the roles of Business and Systems Analysts. It’s almost as if the BA / SA role as an intermediary role to programmers are literally translators. You know what, they are. But my expectations are too high. That’s my issue. BA / SA roles need to understand more, be more complex, stop bothering the programmers. They need to figure out the logic first, and then the programmers will make it.
But, this is all ideology. It does not happen in the real world. That is why we come up with terminology like “Agile Programming” or “Iterative Development” where the developers develop first, and then the requirements people come in afterwards to document what’s already been created. I mean, what the F! There are so many dependencies on the people that create and there are so many “falsified” positions that exist simply out of necessity. Inefficient is what I call it.
We need true business and systems analysts roles in this world. But they do not exist. If they do have the talent, they typically move to a programmer / developer role. Maybe 90% of the time. BA and SA’s are the ones to identify our granularity in life. They must understand the application and use of the software that is to be developed. Further more, they must understand the technical abstraction and complex inter-workings of how a system is put together. BA / SA… please… show me I am wrong. IBM — You have showed me how good you are… the rest of the world…, …