Intelligent Enterprise

Better Insight for Business Decisions

RSS
Webcasts
Whitepapers
Subscribe
Home

July 18, 2003

Faster, Better, Cheaper?

Strategic business application development: The only constant is change

by Sanjay Murthi

Continued from Page 1

This last question demands that organizations think through some hidden dangers. What if, as a strategic application is enhanced and improved over time, you discover that someone mistakenly embedded proprietary business logic within an open source product, or extended the open source code in a proprietary manner? Developers may not realize that the open source license for the product might specifically require that such modifications and extensions be made available to the open community — and that includes competitors!

Product support and enhancement have other wrinkles. Because commercial needs don't typically drive the development of open source products, customer requirements for enhancements can have a longer delivery cycle. Frequently, no party is truly responsible for support and guidance. The open source community is helpful — but it's not the same as a vendor's support representative who gets paid to keep customers happy!

2. Distributed development. Coordination, communication, and cultural discontinuity are the biggest challenges in distributed, multinational development, especially if your organization traditionally uses a single team in one location. Offsite teams may not understand completely the importance or applicability of certain requirements. Without face-to-face feedback from the customers or the application's users, remote teams risk running blind.

Today, not many project managers have experience with the coordination and communication challenges of distributed development. Issues that could have been easily caught and resolved in traditional face-to-face meetings are much harder to handle when people are not all in the same physical location. They need to be clear with written communications, being careful not to provide too much detail. People might just skim the contents without realizing that major issues are addressed deep within the document or email. Problem escalation policies, reporting formats, and standards need to be revisited to make them work efficiently and effectively with distributed teams.

Dependencies between different project deliverables can mess up schedules if some deliverables are delayed or don't work as expected. Companies that have gone with distributed development find that this problem crops up frequently and needs to be addressed by better, more detailed planning up front. Time and resources must be budgeted for productive, face-to-face meetings — which can introduce coordination headaches.

3. Shorter project cycles. Agile development methods can be hard to manage and control. The shorter cycle means less time for necessary and detailed analysis, design, and requirements collection. To meet objectives, the projects must accomplish these necessities and yet still provide deliverables in a matter of weeks or months.

Unless the project requirements are well understood up front and have a very clear scope, teams will have to use agile development principles to have any chance of meeting deadlines. With shorter cycles and agile methodologies, requirements are fluid and the software evolves in quick iterations; unfortunately, management often doesn't have a good handle on what needs to be done, how much time it will take, and how much it will cost. Senior management must grow to trust agile development teams — and know to escalate problems to the right levels so they can be solved as quickly as possible. For everyone, time and effort in training and guidance are critical if the agile methods are to work.

With shorter development cycles, estimates need to be very good; you don't have much wiggle room for slippage. The good news is that the managers and developers will know within a matter of weeks or months whether deliverables will be met. With more traditional methodologies, it's not uncommon to miss project deadlines by several months, even though all the paperwork seems in order! There's a human tendency to cover up or underestimate major issues in reports, especially if the potential impact is considered months away.

With agile methods, the functioning applications are the deliverables. You will know quite soon whether they work. On the downside, however, distributed development and agile methods may clash; agile methods are for small teams that work closely together and with customers. What if instead you have scattered teams that are unable to work closely with their customers? Also, cultural issues can stand in the way of enabling agile teams working together as one.

Vendors may resist using agile methods because they worry about the potential lack of audit trails, as well as responsibilities and requirements that change. How do you bill for the work? Do all requirement changes need approval by the stakeholders — and by which ones? What financial issues does a vendor face with short, agile projects vs. the stability of long projects that might last for years? Vendors must determine the answers to these questions before making successful use of agile methods and short development cycles.

Rate This Article

Comments:

Optional e-mail address:

Dreaming the Impossible

Thanks to these three trends, strategic applications that once seemed impossible may now be feasible, even for smaller organizations. However, change introduces new challenges, and will surely bring more than I've mentioned here. Your managers and development teams will need new skills, organizational structures, and processes. However, the upside may be worth it: faster, cheaper, and frequently higher quality delivery of applications that better meet strategic business objectives.

Sanjay Murthi [smurthi@smglobal.com] is president of SMGlobal Inc. He has more than 14 years of experience in the software industry in a variety of roles and responsibilities. He now helps companies review and improve their software definition, development, and delivery process.