Software Development: Making Software Development Centers Work
Last time I shared a bit about the concept of Development Centers for software development. Because we effectively use this model at my firm – we call it “The Intertech Way” – I thought I would share the best practices for making it work.
The fundamental criteria for an effective Dev Center model is using defined methodology (and following it, of course!). I recommend several levels of leadership to ensure that the younger professionals (think of them as apprentices) are supported at every project level and, most importantly, that clients or end users (if you are interested in using the Dev Center model within your corporate IT department) receive quality software on time and within budget. Levels of accountability within your Dev Center might look like this:
- Delivery Manager to ensure a standard process is followed on all projects and that quality standards have been met before project delivery.
- Director of Consulting to ensure that each apprentice is paired with a dedicated senior professional
- Dev Center Manager to mentor, help bolster technical skills, and to ensure all apprentices can operate at a consistently high technical level.
Maybe you will want a slightly different organizational structure in your Dev Center, but the key is to ensure you have more than simply a senior professional paired with an apprentice. The other roles are necessary to ensuring that younger team members develop consistency in their skills and the overall process they use to make software. We have found this model is working well and consistently results in turnkey solutions.
When I began this series of posts on the perils and challenges of software development, I lamented the high level of failed IT projects and my theory that offshore development is largely to blame. I noted that instead of providing a cheap, fast turnkey solution, offshore software projects frequently are bedeviled by poor management, confusion about team roles, and quality standards well below what U.S. companies (and consumers) expect. (In fairness to lower-paid offshore IT professionals, language barriers, and time zone and cultural differences are tough hurdles to overcome.)
And yet many are holding tight to the offshore model hoping to save money. Ironically, instead of cost savings, we’re now seeing costs shift from the actual development work to the writing of requirements and quality assurance – and development takes longer because of the time lag in communication when team members are located around in the world and in different time zones. Also, not surprisingly, people writing such detailed requirements must be more advanced (i.e., expensive) to anticipate issues a lesser-skilled developer might face during a project.
The only true benefit with off-shore development is that it forces business leaders to think holistically about what they expect from an application on the front end. That helps to prevent costly changes in mid-stream. But the negatives of off-shore development still outweigh the benefits.
I’m convinced that guided learning and mentoring, in the matrixed leadership approach I described above, allows younger developers to be exposed to every aspect of a project (a good way to build your department’s expertise) while providing the guidance from deeply experienced IT professionals – and the level of accountability necessary for quality outcomes. With an offshore model or a completely outsourced model, however, there is no accountability at the individual level where it matters most.