The field of Software Engineering is relatively new and introduction of scientific approaches for software development has been a recent phenomenon. As software use proliferated in late 70s and early 80s, and as programming languages evolved from assembly languages to higher level procedural and object oriented languages, software development experts in industry and universities started looking for ways to improve quality and reliability of their products. The result was introduction and refinement of Software Development Life Cycle (SDLC) and other formal development methodologies that were based on SDLC.

Today most of the big corporations and military organizations either follow industry standard processes or their slightly modified versions to guide their internal development. Rational Unified Process (RUP) is an example and is one of the most widely used development process, though more and more companies are experimenting with Agile Process that promotes faster development cycles. Readers can search for SDLC on the web to get more details on different stages of SDLC and the importance of each phase. While big corporations recognized the importance of SDLC and adopted it early, the Small and Medium Businesses were not really aware of the changes. The reasons were obvious. Either they were too small to need any automation that software brought, or if they needed any software they bought it off the shelf rather than developing it internally.  Understanding SDLC was not really of any use to them. The exception to this was any SMEs that were specifically developing and selling software to other companies.

However, the technology landscape started to shift earlier in this decade and more affordable software development platforms started becoming accessible to SMEs. We covered the popularity of open-source technology stack in an earlier blog and how it helped SMEs adopt new web based software. SMEs are now increasingly using web based applications and mobile applications to run their daily operations. In this environment where more software systems are becoming part of their business operations, it is becoming important for SMEs grasp the importance of Software Development Life Cycle and why they add value to their business.

It is important to note that most SMEs still are not developing their own software. They do not have internal development resources to do so but they are increasingly partnering with outside providers to develop internal systems. Understanding SDLC principles will better equip them to select and sustain better relationship with their outside software development partners. They would better understand different phases of development and what to expect after the provider finishes each of these phases. Completion of each phase can formally require a document that would need to be signed off by both parties. For example, if the provider mentions that it has finished the testing phase, then the customer can ask for formal documentation, such as written test plans, that would indicate that thorough testing has been performed and the results have been added to those test cases. In addition, SMEs would also better comprehend what their responsibilities are in making these software projects a success.

Documenting requirements would force them to think hard about what exactly they want in their product. Discussing test plans would also make SMEs aware of the importance of formal testing, both on the provider side and also on the customer side. We have seen, quite a few times, when SME owners driven by cost or time pressure, insisted on rolling their projects or changes to their existing systems to production environment without going through their own acceptance procedures. While life as an SME owner can be chaotic, it is imperative that they grasp the importance of following processes, since these processes will actually reduce chaos in their operations and will serve them better down the road.

Moreover, SDLC, is not a technical document – rather it’s a process document. So, as such, it is not a very technically challenging read and most readers should be able to understand the basic concepts of phased approach to software development. Time and effort they put in understanding SDLC would definitely be a worthwhile investment for their businesses.

This case study is inspired by the behavior of two Small and Medium Enterprise (SME) owners who had very similar back office support requirements but displayed a very different approach to back office support model adoption. Let’s call the two individuals “Bob Doit” and “Joe Skeptic”. While, it is understood that the difference in behavior may be partly driven by circumstances unknown to the service provider; nonetheless, the difference in approaches hold lessons for SME owners in how, and how not to approach back office support.

Understand the Challenge

Most SME owners start thinking about back office support when they are up to their ears in work and Bob and Joe were no different. The difference, however, was in how both approached the issue. Bob did his research about the pros and cons of a back office located overseas and how to make the best use of it. He also recognized the efforts required to make this arrangement work and therefore, created a priority list and allocated time accordingly. Joe on the other hand, was excited about the potential but never fully comprehended the effort required to make the relationship work.  Offshore back offices, if utilized properly, can reduce your cost and let you focus on your core business. However, they are not a silver bullet that will solve all the problems that SME owners face.

Takeaway 1: Excitement is not enough. Understand the Effort Required.

Relationship Development

Two weeks later, Bob has successfully outsourced his first task. Both Bob and the provider are now refining the process to maximize the value gained. Bob is open to new ideas and is willing to try something different. He proactively makes suggestions and tends to drive the initiative. This helped to create a positive momentum to the effort. This initial success has stimulated Bob’s imagination about the possibilities! On the other hand, things are not going so well with Joe. He is getting frustrated with the learning curve idea and thinks that the back office team should understand his business right from day one. Consequently, he is rushing everything which in turn is producing unfavorable results. These initial hurdles go on to reinforce his skepticism about the viability of this back office support model and he puts a temporary stop to this outsourcing effort.

Takeaway 2: Drive the effort. Sort out the Hurdles and Issues

Think Outside the Box

Bob and his team have been working together for three months now and have prepared a list of tasks and functions that will be handled by the back office team. Top on that priority list is the online marketing piece. Online marketing is a knowledge driven area and falls under Knowledge Process Outsourcing (KPO); therefore, Bob first quizzed his team to gauge their ability to manage this critical requirement for his business. Once Bob felt comfortable, he tasked his team to develop his online marketing strategy with an implementation plan. After a few iterations the plan was ready for implementation. In three short months, Bob has a back office team of two associates managing administrative and online marketing tasks.

Takeaway 3: Be Creative, Organized, and Open to Ideas

Explore Possibilities

Six months on, and the online marketing effort is now settling down. During this period, the project had few issues but both Bob and his team worked through the issues. Back office help has reduced Bob’s workload but he is not sitting on his laurels, instead, he now wants to offload tedious but necessary bookkeeping function to his back office team. As usual, Bob was methodical in his approach. The appropriate bookkeeping platform was selected and the assigned associated was tested to make sure he or she has the skill to perform the desired function. Initially, only transactions were entered, then accounts were reconciled, and eventually all reports were now prepared by the back office. As Bob was progressing through this new paradigm shift and rationalizing his cost structure, Joe once again contacted the provider asking to restart the effort.

Takeaway 4: Build Momentum. Focus on Solutions not Excuses

Sustain the Momentum

It’s now over a year and Bob’s team is functioning smoothly. This allowed him to move to the next item on his list. Bob’s web application has grown to the extent where it needs to be migrated over to a newer more advanced platform and would require regular support. Bob decided to task the back office team with redesign and development of the new application that will integrate his Customer Relationship Management (CRM) and other tools. The service provider had the necessary skill set and the process capability to develop and maintain large applications. Bob initiated the process by developing the Software Development Life Cycle (SDLC) document. The required skill set was added to his back office team and the development work started. Joe, by now, has offloaded a few admin tasks that required formatting documents, managing spreadsheets, and a few other basic tasks but has not embarked on a larger initiative.

Takeaway 5: Challenge the Team. Employ their Brainpower

Equilibrium Reached

Two years on and Bob is now putting 10 hour work days – down from 18 hours when he initially started the services. He has more than doubled his online marketing efforts and cut his bookkeeping and application maintenance cost by more than half. His revenues have also increased substantially during this time. In short, he has fundamentally altered his cost structure and thus, significantly increased his market share and profitability. Bob has now implemented an online project management tool to keep track of his back office team that has now grown to six or seven associates. Daily huddle meetings and weekly and monthly staff meetings are now a regular feature to keep everything on track. Knowingly or unknowingly in this two year journey, Bob has moved to a back office support model called Office Of the Future (OOF) where a team of dedicated skilled associates supports the main office.

Conclusion

Bob’s case highlights the enormous benefits that can be achieved through this model, but at the same time it underlines the dedication it requires, from both sides, to make the effort successful. Time and again, Bob, treated his offshore associates as part of his corporate team, provided initial training and guidance, and expected results from them – just like he did from his onshore team members. Once the offshore team understood his business processes, he gave them an opportunity to push the envelope and provide suggestions to improve the processes. Joe, on the other hand, started the process with “us” vs “them” mindset that divided his onshore and offshore resources. The initial training and transfer plans proposed by the provider were considered waste of time and money and were not accepted as an investment in the future. The result was that Joe was never able to maximize the benefits that he had envisioned when he started the process.