You’re going to begin a new initiative – developing a custom app for your organization. Congratulations! Are you ready to begin? Where will you start?
To begin this discussion, let’s set a few basic assumptions in place:
- We’re discussing a core, business application that has strategic value to the organization, external or internal-facing.
- The development time and effort is expected to be relatively significant but not excessive for strategic apps in many mid-sized organizations – Four months or longer, at least 3-4 team members depending on project phase, skills required, etc., full-time involvement throughout the project and at least on-going maintenance after implementation.
- Organization has at least a few technical resources available (manager-level or within IT) but the focus of the organization itself may or may not be technical in nature.
- The decision to develop a custom app has been made and there is a general understanding throughout the organization around the goals and value of the initiative.
With that baseline in mind, imagine you are a member of the management team responsible for initiating and running this new initiative. At least part of your initial discussions are going to be around these basic questions:
- Can we do this project with in-house resources or do we outsource?
- Do we have the resources, skills and bandwidth to do the project in-house?
- If we outsource, how do we select a vendor and under what conditions?
- What are our assumptions of time, effort, and cost from the beginning?
- Does our budget match for either in-house or outsourced?
- What time constraints do we have? Consider both existing commitments and those imposed by the project.
Of course, there will be many other points depending on the organization and there may be some constraints that color the discussion, but whether they are implicit or not – these questions are a common starting point. Depending on the size and focus of the organization, the people in that meeting may or may not have a technical background, but in most cases, there will be a mix of business and technical resources in the discussion. Whatever the mix or the constraints – the point is the same: Can/Should we do this project in-house or will we outsource?
It is a critical question because regardless of the final decision if the project stalls or fails – no development team (internal or external) is going to want to pick up the pieces and try to make a success out of work another team has failed to complete. As a general rule, the new incoming team will end up dumping all or most of the work of the previous team and even if they are able to use some of it, the code review and ramp-up time will be significant. Efficiency will suffer. It isn’t a pretty picture. Making the decision isn’t and shouldn’t be easy – it is a make or break situation.
The Advantages of an In-House Team
Regardless of other considerations, there are some significant advantages in using existing staff. They are known quantities. You know their skills, experience and background. You generally have an understanding of their personality and how they fit in the organization. You can communicate with them directly. They understand the organization, priorities, direction, technical structure, technical stack, the technical team and the processes, procedures and methodologies they use. There may be blind spots but, for the most part, you are more comfortable with what you know about your own team than an outside vendor. And of course, they are an existing cost. There will be offsets against other work and priorities, but they represent a sunk investment in personnel costs, organizational efficiency, knowledge and retention.
The Advantages of an Outsourced Team
An outsourced team brings a different set of advantages. They are generally available to begin immediately or in a relatively short period of time. They usually come with a wider set of skills and experience than internal teams because of their recent work in many situations for many clients. Their teams are generally already integrated with a knowledge of the other resources involved in their side and they come with a set of expectations and experience around development methodologies, processes and procedures that your organization may not have. They don’t (or shouldn’t) have competing priorities so the project itself is their sole focus. They represent a known cost factor, even though the actual effort to do a given task is unknown. And finally, the responsibility for having the right resources with the right skills and experience on hand and ready to provide productive work is not yours – it is the responsibility of your vendor by contract.
Of course, if we had the right people with the right skills sitting around, ready to go to work, the choice would be easy, but generally, that is not the situation. In most small-to-midsized organizations, core software development projects are not an on-going activity. There may have been one or two in the recent past, but most of the on-going work is in maintenance and enhancement of existing applications. There may be several small, office productivity and IT service projects over the course of a year, but few if any requiring more than one or two developers and full-time attention. In larger organizations, there will be more resources and more significant projects, but there will also be a significant amount of on-going maintenance and enhancement. Except in cases where the core focus of the organization is technical with both external and internal facing services that are based primarily on internally-developed applications, the flexibility to quickly shift work to a new core initiative just doesn’t exist.
On the In-House Side
What this leaves you with on the in-house side is a need to make some basic assessments:
- Do you know what you need? Can you clearly define the mix of skills, experience, responsibility, adaptability and teamwork necessary whether you are picking from existing resources or hiring new positions? It is a critical question, not regarding what you know about your staff, but in plain terms, what the requirements of the project at hand impose on you.
How much time do you have to bring a team together? You may have a team of resources that could come together after finishing existing projects and shifting priorities – but how long will that take? Six months? Nine? Could other issues derail plans before they can actually begin? If you have to hire new resources, how long will it take and when will they be ready to begin productive work? At a minimum, most companies say it takes more than three months – but that doesn’t include any time to integrate them into the organization and get a feeling for how they fit. Including a reasonable ramp-up time and some productive work for them to do as they begin their assimilation, you can expect at least nine months of lag time before you can expect a productive resource to be available.
- Is your in-house team able to architect, specify, develop and maintain a full, core app successfully? This may sound like a dumb question at first, but it is very important to consider. If you have many custom applications under your belt, an in-house technical architect, DevOps-based team and structure, no problem – but relatively few organizations are in that position. When the application is ready for implementation, it must be production-stable, scalable, extensible, integrated and maintainable using technology that not only fits your current stack but will remain able to provide services efficiently over its lifecycle. This isn’t a minor bump in the road.
- Is your internal team experienced and familiar with Agile-based methodologies and Scum? If your group normally does a number of smaller, informal projects and maintenance, you’re probably not there – even if the team tries to use agile concepts regularly. A sustained effort takes considerable communication, collaboration and feedback throughout the project, across both stakeholders and the team itself. If this environment is new to them, the project will require more management overhead and oversight. A team that is unfamiliar with agile will generally take considerable time to get to efficient code production and may never be able to take full responsibility for mapping tasks, work backlog and planning effort.
- How will your budget and costs impact the decision?
There are two levels of costs to consider on the in-house side: The fully-loaded personnel costs for the project at hand and long-term costs. If you are going to the trouble and expense of direct hire, you need to understand the impact of costs over the long run. How long can you retain an individual with the skills set you need? Is there an advancement path for them in your organization? Is your location a good fit for them over the long run (leisure and family life, continuing education, etc.)? After the bulk of the development work is completed, will the amount work in the area of their special skills continue to require them? Would it be more cost effective to use an outsourced team considering the total cost of engagement (TCE)? Remember that a simple comparison of hourly rates vs the loaded costs of in-house resources is not a realistic assessment. There are always additional costs in the process of collaboration between teams, oversight, in-person meetings, travel and more. And if you can’t easily assess the actual skill levels and efficiency of the outsourced team, there may be hidden costs you won’t see until the project is underway. But on the other hand, if you are bringing new hires into your existing team and you don’t regularly develop full-scale applications, you should consider the costs of licensing fees, certifications, training, equipment, etc.
There is one more point on the in-house side that you need to consider very carefully. If you regularly use temporary contractors to fill requirements, part of your assumptions might be based on their continued use and availability. Whether they have a history with you or they come from an agency you regularly contract with – you should remember they aren’t in the same position as your regular staff. They are free agents and can come and go at will. Team stability in strategic projects is an important point and of course, falls on your plate for any contractors you bring in. There are many things you can consider to lower the risk, but regardless – there is a reason they are contractors and not staff.
In many organizations, outsourcing is a tricky subject. Across their careers, people are likely to have had good and less than successful experiences in outsourced projects. It isn’t unusual for costs to come in over budget, both on the cost of the contract itself and the additional costs when you consider the total cost of engagement. If your past experience is with offshore teams in Asia and India or with other variations that are more than a couple of time zones from your location, you know that communication can be difficult, time-consuming and opaque no matter how careful you are. But let’s step back from those experiences and just look at some of the issues:
- Do you know what you need?
Yes. We are right back where we started. Most companies don’t have a team composition in mind. They give the vendor a general idea of the type of project and scope they have in mind, answer a few questions and ask for suggestions. In most cases, there is nothing wrong with this approach. After all, it is the vendor who is going to take the responsibility and contract to do the work. A comprehensive set of work and team requirements wouldn’t really make any difference. The vendor is taking part of the risk. If they come back and say no, we need an extra QA and 32 weeks instead of 20 – your choice is to ask why or say no and move on. In the process, you will probably lose some of your assumptions and perhaps change some of your ideas about what you need. If you can’t reach a collaborative decision on the project with them, it probably wasn’t a good fit anyway. The process of finding the right vendor takes time to search, prepare documents and presentations, interview, and assess your options. You need to remain positive and open to suggestions. They may have ideas of how to approach your project you haven’t considered. Before you contract with them it only costs your time to hear them out. They may know something you don’t. And you need to consider their basic business model. Are they primarily a body shop trying to look like they have more comprehensive offerings? Are they a full-service vendor offering their own in-house resources or are they assembling teams on the fly from contractors? Where are they located? What kind of terms are they offering? How much can you hold back for completion? Will they be able to offer on-going resources for maintenance and support if you need it or to train and assist your in-house team? We will have more on picking a vendor in a later post, but you get the point – picking a vendor for a core project is not a process of just sending out a bunch of RFPs out to a list of vendors unless you have a pool and do it all the time. You need a partner that will share responsibility. Someone you can depend on, that is flexible and committed to finding answers that fit your situation.
- Cost should not be your primary driver. It has been said that 76% of outsourced projects go over budget. Most cost comparisons and breakdowns are too thin to really be sure you know what you are looking at. When you are quoted a “blended rate,” do you know the team composition? How many juniors vs. mid-level and seniors? Do you know where the critical skills are? Are most skills concentrated in one or two resources with everyone else learning as they go? If cost is a primary factor for you – can you compare apples to apples with in-house teams or new hires? Are the skill levels and experience comparable? How much of your quote includes intermediary supervision? Those are the project managers, team leads, assistants and translators that get between you and direct access to your team. In some cases, you may never speak directly to a team member because they work in opposite day segments and English is not their primary language. All these little things add to your time and expense. If cost is your primary driver, it makes it very hard to spend time on things that really matter – a team with the right composition, good processes, procedures and code, an understanding of your situation and a willingness to shift their assumptions to fit your needs.
- Strong, real-time communications are worth something.
No matter where you look, having a team that can work within the same day segment your team does, comfortably in your language (written and spoken), and as peers – will cost more. There are many factors – where they are located, comparative living costs, the size of the resource pool, their experience, and more. But regardless, being able to collaborate directly with individual developers on your team to clear up understanding, set priorities, and give feedback before tasks are marked as complete, makes a lot of difference. The risks of rework, redoing a bit of functionality that is technically correct but not what is needed, are greatly reduced. The opportunities for going off track and “polishing” minor functions or creating unnecessarily complex interpretations of concepts can be eliminated if the product owner and key stakeholders on your team are playing their roles correctly. If you are working with a team in opposite day segments, it is likely you are working with someone on the vendor side as an intermediary. They receive feedback and pass it to someone who works with the team. It might be the team lead or shift manager – but only rarely is the feedback given to the developer involved directly because you don’t know who that is. It might not even be the exactly the same team one day to the next. There might be translation involved. Communication fidelity is lost. If the feedback is not fully understood, you have more opportunities for another error. If your outsourced team has a question, it may be forwarded but at least sometimes the intermediaries will jump in and answer to keep things flowing or avoid bothering clients with what appears to be a simple question with an obvious answer. Barriers in communication are always costly in the end.
- An understanding of what quality means and how results will be managed and measured should be discussed and negotiated up front.
Everyone, on both the client and the vendor side, will pledge their commitment to quality before and during a project, but what the term actually means and how it will be assured is often a somewhat nebulous subject. An outsourced team that has procedures and processes to assure quality, can discuss how they work and the role your team will play without hesitation. They should be flexible so they can adapt their approach to something you are comfortable with. If they seem to have a lot of overhead in quality without a clear line of responsibility in the developer role, it should be a warning sign. QA loops, when a developer reworks a task multiple times without reaching completion, are wasteful and indicate a lack of communication. Tasks that are marked as complete but turn out to be missing a significant point can result in significant productivity losses because of the time required for developers to refamiliarize themselves with feature context. These are issues outside of relatively straightforward “bug-chasing,” but are certainly quality issues nonetheless. They will have an additive impact to productivity that will eventually show itself in an increasing backlog or surprises when you don’t need them.
- Your outsourced team’s methodology is not just a box to check. Agile and Scrum are industry standards for a reason. Your team should be practiced in their own implementation but able to modify their approach to accommodate your needs. The values of team self-organization, transparency, responsibility and the framework that these methodologies are based on should be easy to recognize regardless of their implementation. It requires a lot more adaption for a remote team, working in an opposite day segment, to be truly agile but it can be done. Whatever the situation, like quality, this is an area to discuss and understand on both sides before you begin a relationship.
An outsourced team can bring a lot of value to a project, especially when your team does not have the kind of experience in projects of the type you need. Stability, transparency, knowledge, experience, quality – these are all things you should expect and evaluate before you sign on the line. And there is one more thing you should consider – flexibility. There has not been a project where unexpected needs or issues never surfaced. A vendor that is a true partner, invested in your success, should be able to handle the unexpected without raising the “negotiation” flag every time. If they are rigid and difficult to bring into a give and take discussion, it will be a problem eventually.
We’d like to help you to develop your custom app
This is where we say, “Yes – we would like to offer our help.” Scio provides end-to-end engineering services in a collaborative partnership to ensure that your team is an integral part of the solutions you require. We can offer a wide range of skills to make up a team that you can depend on – and work with directly. And when you need something more – we’re flexible. From helping to assess your needs to developing, implementing and maintaining solutions, we can offer as much or as little help as you need. Our teams can work with you virtually or on your site – but most companies need some type of combination of the two and we’re more than happy to find that blend too. If you think that sounds interesting – Contact Us. We’re ready.
And, we’re providing a series of articles to our readers under the title: “Refuse to Fail” They are quite insightful about this and other subjects related to digital transformation and the strategies behind it. If you think you might be interested – sign up. It costs nothing and you can opt out at any time.