I had an interesting discussion today with someone who voluntarily inherited the challenge of integrating over 50 separate pieces of IT capability into one cohesive unit. The organization's decentralized IT strategy has now, under my friend’s advocacy, become a centralized IT strategy – a new software development group.
Of course, the pieces of IT have very little in common with each other, apart from a shared employer. Historic technology choices, current practices and levels of effectiveness are all over the place. Our conversation focused on just one part of my friend’s problem - software development.
Now, if you have read a few of my blog posts, you know that I generally focus on issues that relate to better measurement and process improvement. In talking to my friend, I started to make my typical points about benchmarks, measurement roadmaps and the value of using CMMI concepts as a template to address his more immediate issues. However, my friend (a very experienced individual) stopped me in my tracks.
"You're right," he said. "All of those things are what we should be talking about, and I believe in them. But, how am I going to get to the point where any of that is meaningful? What choices should I be prioritizing now, so that I have a functioning software development group in a couple of years that can be measured?"
Hmm. Good point! Clearly, there needs to be a transition plan for most of the pieces of IT, but a plan to transition to what? It’s almost a green field site. What's the best software development strategy to choose today? First, there are some key questions to be addressed:
- Leadership: We quickly agreed that leadership is highly important, and my friend knows that he will need to find the right person to lead the new software development group.
- People: A new culture needs to be established - that is partly a leadership function, but other things are needed too, such as new processes and training. It will also be important to seek input from the existing people – finding out from the staff in the previously separate IT units why the change is difficult. This is the first step in overcoming those difficulties – they are in the best position to know where any issues may lie. The most effective way to get this information is to talk to them. My friend will need to find a way to delegate this sensitive but time-consuming task.
- COTS and Outsourcing: Software development is not a core business function for the organization, so why bother doing any software development? COTS and outsourcing will be part of the solution, but this organization does some unique things that will always require some development/customization/configuration, and, as my friends says, "You should never outsource your problems - it doesn't work."
- Integration: How many of the applications need to be integrated versus remaining as stand-alone point solutions? How urgent is integration – do the legacy applications need to be integrated now or can integration wait until a new technology application is ready to replace the legacy? An integration strategy needs to be determined.
- Methodologies: Standardizing practices around a few methodologies will help develop a common culture and vocabulary, but which ones? The need to develop discipline and repeatability suggests using more traditional methodologies, and one of these should be included; however, the organization has a lot of customer-facing applications, so there may be a role for Agile development in the future. My concern would be that, in some ways, Agile requires more discipline, and I'm not sure that the organization is ready for Agile yet. Perhaps the new software development group could be seeded with a new Agile team focused on innovative projects?
- Technologies: .NET/J2EE, COTS/in-house, client-server/web, etc. Again, a strategy must be in place.
This conversation forced me to think back to my previous experiences of walking into very immature software development shops. The first thing I focused on in those cases was repeatability. If you are not capable of doing the same thing the same way twice, then there is no point in measuring it and no way to implement process improvements (because there is effectively no process). This repeatability has to be achieved for everything – from coding and testing to architectural decisions.
Given that my friend needs to start with repeatable strategic decisions, I would be inclined to borrow a tool from our IT Governance practice and start by defining what decisions need to be made, who will make them (an individual) and how they will be made (i.e. who gets input, when are the decisions made, what metrics are needed to inform the decisions, etc.). This list can be extended and reprioritized indefinitely – the most important decisions will always float to the surface.
Another early step would be to take the patient's temperature – how many of the blobs have evidence of repeatable processes? As I check back in with my friend, I'm sure we will touch a number of strategic decision points in the software development arena. Help me out here – what would you prioritize?