Back to Basics with Five Methodology Imperatives

By Scott R. Sargent,

and James P. Behling

The paradox today of systems delivery is that as the business and technology environments become ever more complex, the methods that drive delivery must become ever simpler. Accenture believes a back-to-basics approach to methodology emphasizing five imperatives is vital to business success.

1. Rely on an enterprise-strength methodology

At the core of the back-to-basics approach is a methodology capable of supporting systems that are truly critical to the functioning of the enterprise. It must be one that is robust enough to serve as a standard methodology across an enterprise, one that promotes a consistent set of roles and skills, and one that gets everyone on the same page, using the same language and focused on the same deliverables.

The “what” of a good methodology includes adequate descriptions of the work breakdown structure; clearly defined deliverables, along with supporting templates and samples; and distinct roles and responsibilities for all personnel involved.

The “how” of a good methodology applies disciplined project management to integrated techniques for implementation, including detailed process descriptions, job aids, checklists and guidelines on the proper use of the methodology and related development tools. It should also include integrated training. Underpinning both the techniques and the training are standards and common terminologies, without which it becomes increasingly difficult to coordinate work over time and distance.

Another aspect characteristic of an effective methodology is the ability to maintain the project management control that was so prized in past development, and at the same time capitalize on the benefits of iterative development processes. Iterative development is an excellent technique for proactively managing risk, showing stakeholder value earlier in the process, demonstrating the viability of the architecture and identifying opportunities for reuse.

2. Keep it simple

While an enterprise-strength methodology must be comprehensive, it need not be so much complex that it becomes cumbersome. Like a piece of exercise equipment, the “best” methodology is the methodology that is actually used, and no matter how good a methodology is, it will be used only if people can quickly find what they need. Here are some ways to avoid costly complexity.

Reduce the number of layers. Does your methodology require you to drill down four or five layers to find the project-level information you need? If so, then you may have a robust methodology that no one can (or will) use, which isn’t much better than having no methodology at all.

Use intuitive and accepted terminology. Verbal creativity interferes with basic communication within a project team, especially when several vendors are working together. A methodology should use terminology that is common in the industry. For example, the Unified Modeling Language provides the basis for many of Accenture’s deliverables.

Use a mental map that is easy to understand and remember. For example, the high-level mental map of Accenture’s integrated methodology for systems delivery is complete and yet simple enough to keep everyone communicating and working together toward common goals. Thanks to clear transition points, the “givers” from one stage know exactly what they need to produce; the “receivers” at the next stage know exactly what they’re going to get.

3. Use a flexible methodology for different development styles

Precisely because today’s business and technology environment is so complex, companies must be able to develop all types of systems using all types of development styles, ranging from custom to packaged, from portal development to data warehousing. Accordingly, Accenture has found a way to accommodate these different styles effectively, making the methodology both flexible and customizable to individual user needs.

We call this a “library of methods.” Imagine a library’s reference section, where you find books that contain general knowledge. Many people use these books for basic information. That’s the way we think about our “core methods.” A library also has many sections devoted to specialized knowledge.

For mainstream systems delivery, the core methods will take you most of the places you need to go. But for other kinds of custom work (such as portal development or data warehousing) or specialized development (such as SAP or PeopleSoft installations), a specialty methodology-which, because of the common framework, can be integrated easily into the core methodology-would be more appropriate. With this approach, you can operate with a broad set of methods that provide coverage for all types of development.

4. Integrate new development and ongoing systems management

Even though systems development methodologies typically address designing, building and testing information systems, they rarely address the unique aspects of supporting and maintaining those same systems. Even with methodologies that address both of these considerations, there is often a serious lack of integration between the two. The result: different terminologies, different approaches, fruitless turf battles and, ultimately, a difficult transition from developing the system to managing the system. By contrast, Accenture’s goal has been to define one consistent and integrated methodology with a common structure and common terminology. Some other principles of an integrated methodology include the following.

Design for operability. The demands of operating an information system must be considered during development-not at the last minute, when applications are being handed over to operations.

Start training now. By involving your training function earlier in the development process, you achieve two benefits: The training is ready to go when the system is, and the system itself is more likely to be embraced by the user community, because its members have been involved during the entire process.

Prepare the part of your organization that will receive the system. The best example here is the service level agreement (SLA), which should be established as early as possible in the systems development process. Companies almost always wait too late to develop an SLA. Instead, discussions about these agreements need to begin back in the requirements stage.

5. Enable a distributed, multisite approach to delivery

Today’s systems development environment is a far cry from the situation that existed in the days when scores of developers worked together at the same site. Instead, work may progress in several countries simultaneously. In this kind of working environment, it is critical that the methodology be consistent across the multiple development sites. Making this happen means following some of the principles we have mentioned previously.

Use simple and consistent terms, allowing your people across development sites to speak the same development language and use the same deliverables. Such an approach can prevent needless delays and rework.

Establish clear transition points, with agreed-upon entry and exit criteria. These criteria define what must happen before work is handed off to the next team, which may be at a different development site. A receiving team can thus be assured that certain steps in the development process have already been accomplished.

Agree upon standard deliverables. This point follows from the previous two. At the transition points, the giving team knows what it’s producing; the receiving team knows what it’s getting. Having clear expectations for deliverables gives everyone a better chance of success.

About the authors

Scott R. Sargent, Accenture’s chief systems engineer, is the managing partner of the company’s Solution Delivery Excellence program. He has extensive experience in the planning, design and implementation of distributed systems, client/server systems, data communications and the application of new technologies. Sargent, who is based in Chicago, has coauthored books on net-centric and client/server computing.

James P. Behling, a Chicago-based associate partner, is responsible for the Accenture Delivery Methods initiative. A methodology architect with more than 10 years’ experience in component development, program management and project management, Behling has helped numerous clients develop and deploy software development processes across their organizations.

This article is adapted from “Back to basics” originally published in Outlook journal, Vol. XV, No.3, an Accenture publication. Copyright 2003 Accenture. All rights reserved. Used by permission.