Sales leads volume has increased lately. As such I am considering on possible modifications to the current operating process within the company to cater for a bottle neck that exist within this current business model of mine. Currently, I am doing all the architectural work as well as some parts of the programming work. The programming work I engage in mainly revolves around the creation of programmatic structure so as to impose a boundary on the areas of the codes an incoming programmer could modify.
My effort engaged in the establishing of such boundaries is hogging up resources that could be better spent else where.
Our recent adoption of workflow modeling coupled with hand drawn illustrations has proven extremely successful in providing the required level of clarity between us and potential clients prior to the commissioning of any project to ensure against any complications during the software development cycle.
Turn around time for projects handled via such a process and methodology is even shorter compared to the turn around time for projects handled via the original methodology employed by the company at the start of the year. Development cycle has thus been shortened from a one month period to a two week period.
Recently while further digging into the methodology employed by Bosh, my brother's company, I realized Bosh has been employing the use of UML extensively.
Just a moment ago while sitting in front of my computer and watching the first episode of Karei-naru Ichizoku (a drama about Japanese Conglomerates in the post WWII era) I had a sudden stroke of inspiration. For my next project, I will attempt to do an experiment. Around half of the UML document set has to do with the business modelling, while the other half of the UML document set has to do with technical modelling. I will attempt to tap on the analytical abilities on my counterparts overseas by just sending them the business modelling part of the UML document and ask instead they send me the technical document part of the UML document. I will be able to check and correct any problems in their programming architecture before they proceed to implement those documented changes in the systems to be worked on. Should this newly conceived methodology work as hoped, I will have thus relieved myself of one major bottleneck in our company's operating process.
This would also imply that the company would be able to further expand its through put volume. This would also mean a clear cut separation of system architectural work from software development work. This should make possible the kind configuration I have in mind for the eventual full time employees in the company, a team that does not involve its resources with programming - commodity.