Home | About | Recent Issue | Archives | Events | Jobs | Subscribe | Contact Bookmark The Sterling Report


   

Will the enterprise market spend significant IT budget on Windows Vista in 2007?

Yes

No


Mergers: A Change Agent for Software Development

By Chris Barbin, Senior Vice President of Business Operations, Borland Software Corporation

Growth through acquisition has always been a leading business strategy for the world's largest software companies. What is new, however, is that many acquirers no longer just want small pieces of technology to integrate with existing portfolios. Oracle acquired Siebel Systems after its expensive battle to win control of PeopleSoft. Then Adobe merged with Macromedia to "own" the digital media market. Soon to follow was eBay's acquisition of Skype. The list goes on... but each merger comes with a major challenge: How to best manage distributed development environments?

Growth through acquisition has always been a leading business strategy for the world's largest software companies. What is new, however, is that many acquirers no longer just want small pieces of technology to add into existing portfolios. Software powerhouses desire to avoid building new applications from scratch and instead seek to acquire large, core software applications with strong user bases. A case in point is Oracle, a company acquiring Siebel Systems after its expensive battle to win control of PeopleSoft. Then there is Adobe's merger with Macromedia to "own" the digital media market and eBay's acquisition of Skype Technologies. The list goes on, but one thing is certain that with each one of these software mergers, comes a major challenge and a tremendous opportunity, which is how, going forward, these companies will manage their distributed development environments.

In the past, discussions around distributed development tended to focus on the location itself. Where was the best location to have business analysts? What distance was ideal between developers and testers? Could off-shoring and outsourced partners in other countries effectively be added to the team? But times have changed, and today software companies need to look beyond location to the three core components-people, process, and technology-required to make today's distributed software development team successful.

Skills Training for Success
For management, mergers can be a "change agent", providing an opportunity to reevaluate development team skill sets and ensure that appropriate skill development strategies are put into place. For distributed teams, this not only means training people on the new processes they must follow for their particular role, but also training them to understand how their role fits into and affects other roles-project managers, architects, analysts, developers, testers-throughout the entire software development lifecycle.

The so-called "soft skills" are critical to organizational change within development, and addressing them up-front enables distributed teams to be more effective in both understanding and meeting the new business objectives. In addition, companies may establish very senior governing bodies that help the development organization tie software development initiatives back to business objectives, that may include improving time to market, improving quality or reducing churn.

Leading with Process
Although, executives in the acquiring company may think it easiest to have everyone in the development organization simply standardized on its existing processes, a merger, like a compliance mandate, is an opportunity for both organizations to re-examine existing processes and choose the processes that will work best for the distributed merged entity. For example, the acquired company, using agile development, may have processes in place that allow it to release new code in three month increments, while the acquiring company uses a waterfall approach and releases only patches between major yearly updates. Whatever the scenario, companies should evaluate the merged company's new business goals (are they time to market, quality, or cost-related?) and then leverage process best practices within both organizations to meet those objectives.

Adding process, however, does not mean that an organization must immediately sign-up for capability maturity models. What it does mean is, that management must think about transforming its software development process as seriously as it considers reengineering a customer's insurance claims process. As the merged organization moves into the future, its distributed development must be handled like any other business process in the company. Companies must put in place the same types of stringent managed processes they have for their supply chain and customer relationship management in order to maximize the value of their software. It is no longer advantageous for companies to allow distributed software development teams to simply function with ad-hoc processes. Those that continue to do so incur added development time, expenses and hassles, including the inability to reuse code or benefit from project lessons learned.

Efficiency Gains Through Technology
Standard best practices in software development are facilitated by appropriate underlying technology. For merging organizations with distributed development challenges, it is often helpful to first consider only new development projects for the standardized platform. While other projects can be converted over time, taking trained teams and allowing them to utilize the new development processes with existing or new application lifecycle management (ALM) solutions for requirements management, modeling, configuration and change management, testing and more, can serve as a way to establish a center of excellence within the new merged organization. Within the center of excellence, there should be clear roles and responsibilities with thought leaders continually collecting best practices that will move the organization forward.

Before rolling out a new standard delivery model, organizations may pilot a variety of projects with a different characteristics to be sure its approach works for the majority of scenarios. Yet, even when an approach is solidified, all projects may not fit exactly, requiring organizations to be sure they have trained staff, flexible enough to modify best practices for successful outcomes.

...back more...



  Home | About | Recent Issue | Archives | Events | Jobs | Subscribe | Contact | Terms of Agreement
2006 The Sterling Report. All rights reserved.