What Really Matters in Software Development

What Really Matters in Software Development

Article image

What Really Matters in Software Development

  • Add To Interests
  • PDF

  • Related Articles
    In This Article
    • Software development is playing an increasingly critical role in many industries, yet few firms have mastered the art.
    • The proper organization and approach for driving results are key to successful software development.
    • There are three must-haves for a successful project: a dedicated cross-functional project team; strong, empowered leadership that is accountable for results; and clear, shared requirements that are understood by all stakeholders.

    Software is playing an increasingly critical role in many industries. Analysts estimate that in the automotive sector, for example, nearly three-quarters of future innovations will be software driven. Companies are investing accordingly. Some now employ more software developers than do dedicated software businesses. Many have software development processes whose sophistication rivals—or even exceeds—that of major software players.

    Yet few businesses are fully satisfied with their return on software development spending. And for good reason. Many software projects arrive late, over budget, short on quality, or off target, resulting in a litany of woes that include product launch delays, product recalls, and higher-than-expected support costs. The lack of transparency and accountability often associated with software-related spending adds to the frustration.

    When we attempt to diagnose causes of weak performance in a company’s software development, we frequently start by asking the following question: How does the organization decide on and make tradeoffs among features to be included, time to delivery, and resources needed for each release? If the process for making such decisions is unclear, makes excessive demands on senior management’s time, or results in changes to priorities late in the project cycle, the company’s results will likely be unpredictable and disappointing.

    Common remedies for such problems, such as well-defined milestones and rigorous stage-gate reviews, are valuable and necessary, but they are not sufficient to produce software that truly delivers on its promise. What’s typically missing—and is the linchpin to successful software development—is the proper organization and approach for driving results. To that end, three actions are essential: dedicating an empowered cross-functional team to the project to bring together all the capabilities necessary for success; establishing strong leadership with the skills and authority necessary to make critical decisions and drive the process end to end across functional boundaries; and developing clear, specific requirements that create an unbroken chain of purpose for all involved parties, from concept through delivery.

    Consistent application of those practices is the foundation on which successful software development rests. If they aren’t in place, other remedies for poor software-development productivity will have little impact. (See the exhibit “Three Fundamental Practices Drive Successful Software Development.”)

    Dedicating a Cross-Functional Team

    Software development requires effective and coordinated contribution from a broad set of functions—such as marketing, product management, development, and testing. It’s not feasible for a single product manager or business analyst to fully “spec” a complex piece of software at the outset of a project. For example, product managers may understand what’s needed by customers, but developers know what’s possible with technology.

    The key to leveraging those different perspectives is a single cross-functional team that has clear ownership of the project. This team must have genuine autonomy: once assigned to the project, each team member should be accountable primarily to the project and the project leader, rather than to the overall manager of his or her respective function. This clear delineation of roles and territory removes ambiguity and greatly increases efficiency, as it prevents functional managers from meddling in project decisions.

    Strong functional management will still play an important role in the project’s success, of course. The leader of the development function, for example, will continue to set development standards, define shared architecture, and hire, train, and retain the right developers. But the project team is the direct and final arbiter, responsible for wisely deploying those resources against business objectives and directing them toward project-specific goals.

    Within the project team, each function should be represented by a leader who has the authority to make project-related decisions on behalf of his or her respective function. Each leader should be chosen at the project’s concept stage. There should be representation from every function—including such downstream areas as implementation and support—from the very beginning so that the needs of all the functions are heard early and often throughout the process.

    Once the project is under way, team meetings should be held frequently, and all representatives should attend in person. This approach dramatically increases transparency. The entire team will become immediately aware, for example, of proposed changes in the project’s direction, such as a “rescoping” of features. This high level of awareness, in turn, will facilitate a thorough assessment of impacts and timely communication to all affected parties. In our experience, the type of intense, rapid, and iterative collaboration across functions that such a team structure generates is a prerequisite for great results.

    Establishing Strong Leadership

    Successful software development demands a strong leader with the skills and authority necessary to make decisions and drive the process to completion. For the duration of the project, that leader will oversee all the functions, from requirement specification through support: gathering and prioritizing input from stakeholders; establishing a course; driving critical tradeoffs on features, time, and budget; and ensuring that the effort stays on track. He or she will need to exercise keen judgment about when to refer issues to more senior management and when to “just get on with it.”

    Getting the right person in place is therefore critical. The ideal candidate is someone with a general-manager mentality and the ability to view decisions from a business perspective. He or she will have the ability to articulate the objectives of the project in a compelling way and be able to foster collaboration among team members: a “Napoleon” is definitely the wrong person for the job. The leader must also be able to create an atmosphere of candor and transparency. Someone who is known to “shoot the messenger” will cause the project to suffer in the long run; “surprises” need to be unearthed and addressed sooner rather than later.

    The leader must be given the necessary authority to complete the task. And, most critically, he or she must be held accountable for the outcome. It’s common in best-practice organizations, in fact, for a large part of the project leader’s compensation to be tied to the project’s business results. The definition of results varies: for commercial software development, results means revenue and profit; for applications created for internal use, it means delivered business value for end users. Project quality, cost, timeliness of delivery, and conformance to requirements are all important indicators of effective software development. But the ultimate measure of success should always be the project’s impact on the business.

    Empowering a leader and holding him or her accountable in this manner will give management a high degree of clarity about the overall process. In contrast, when accountability is spread over multiple functional silos connected only by process “handoffs,” the root causes of project failure can’t be clearly determined. Development blames marketing for misunderstanding the customer’s needs; marketing blames development for failing to build the product as it was designed. The quality and timeliness of the finished product inevitably suffer as a result.

    Developing Clear, Shared Requirements

    For a software project to succeed, all relevant parties must understand and sign off on its requirements. To facilitate success, requirements must have three characteristics: they must fully and accurately capture the needs of the intended users, they must be described in detail and in language that all stakeholders can understand, and they must be rigorously prioritized. Absent this, the project will likely suffer a high degree of requirement volatility, or changes to the project’s goals after the initial specifications have been established. Requirement volatility translates directly into poor quality, rework, missed deadlines, and overspent budgets—and should be minimized at all cost.

    Capture user needs fully and accurately. Seek input on requirements from a broad base of stakeholders, including both end users and customers. Capture functional requirements—that is, what the software would ideally do for the user—and desired levels of technical performance, including standards for such factors as reliability, security, and cost to deploy. Conduct structured research and build a strong fact base to support the identified requirements. The fact base will be useful in preventing individual stakeholders from disrupting the process by insisting on “pet” features that aren’t justified by the research.

    Describe requirements thoroughly and in a common language. Document all requirements through use cases, which describe the roles of specified users of the software, the tasks those users are seeking to perform, and the steps necessary for them to do so. Use cases constitute a powerful common language that can be fully understood by all participants in the development process, including customers, developers, and support representatives. This common language is key to cultivating understanding and purpose throughout the process.

    At the concept phase of the development process, a small number of high-level use cases that capture the most essential aspects of the requirements should be created. Those more general cases should be extended and filled in with more detail through the specification and design phases. All stakeholders should contribute to, review, and approve the use cases. The use cases should also be reviewed by and tested with target customers and end users in an iterative process. Catching errors in requirements at an early stage is dramatically less expensive than correcting them later in the process.

    Prioritize rigorously. Requirements must be prioritized so that any decisions that arise concerning trade-offs on features, schedule, and budget can be made quickly. Some development organizations simply put requirements into priority “buckets,” categorizing them as “must have” or “nice to have,” for example. Best-practice developers, however, rank requirements more stringently: they list the entire set in order of priority, from most important to least important.

    Think of each project as a train pulling away from the station. The requirements are the passengers. Once the train leaves the station, new requirements can’t get on. This discipline allows the train to roll unimpeded and at full steam. Stopping the train to let on new requirements is expensive and will delay arrival. Tearing up the tracks or rerouting the train to a new destination is even more disruptive.

    Using the train metaphor as a model for development is a powerful way to limit requirement volatility. But for the approach to work, the trains must run at the right frequency. That is, you must break your development efforts into chunks that can be delivered to the target audience quickly enough to meet its evolving needs. This may mean smaller, more incremental releases delivered more often. If there is only one release of the software per year, it will be very difficult to resist the pressure to introduce new features during the later stages of the process.

    Software development is a source of frustration at many companies—but it needn’t be. Dedicating a cross-functional team, establishing strong leadership, and developing clear, shared requirements can remove ambiguity, restore accountability, and maximize the return on each and every project you pursue. It’s well worth the effort.

    To Contact the Authors
  • Add To Interests
  • PDF