If you've been in the integration business for a while, you have probably developed a series of methodologies - project implementation, staff training, client support, cost estimations, and so on. It may surprise you to learn that these methodologies, if properly handled, can be a major factor in differentiating yourself from your competitorsBrian Keane, president of US-based integrator Keane, feels vindicated by the injunction that a Texas court issued in April. Keane had argued that a rival consulting firm used portions of its methodologies, without permission, in marketing materials and on a Web site, as well as in proposals to clients and prospects. The court agreed and ordered the other firm to return "misappropriated confidential and proprietary methodologies and information belonging to Keane".
In what some observers referred to as "a public flogging", the judge further mandated that the consulting firm post a conspicuous message on its Web site for 60 days, acknowledging wrongful use of the Keane methodology.
Jennifer Beck, a principal analyst with Dataquest's strategic marketing and service partnership division, observes that the injunction also set a crucial precedent. For the first time, IT-services methodologies were legally recognised as intellectual property.
The process of recording and documenting "best practices" of how to do something - methodology creation - hasn't changed since the early days of business-process consulting. What has changed is that US law now regards methodologies as sufficiently differentiated to be ascribed the protection that is afforded trade secrets.
What's undeniable is that integrators are increasingly taking a page from companies that do "pure" consulting, building and then leveraging their methodologies in marketing materials to differentiate themselves from competitors. Market analysts such as Dataquest and IDC note a sharp increase in the number of "branded" methodologies - those given brand names by integrators and based on unique company experience.
As marketing vehicles, Beck says, methodologies are high-octane.
For such an important concept, it's unfortunate that "methodology" is such a ponderous word. Keane even admits that clients "cringe and frown" at it. The negative feelings evoked by the term, he says, are based on perceptions of methodology "as a 12-volume set of 3in binders that sit on a bookshelf and are never read".
To many solutions integrators, however, methodologies are eminently practical, describing project steps and providing invaluable guidelines for success. "There's a separate volume," Keane quips, "for tips, best practices, and experiences."
Simply put, a good methodology is a process - one that can be defined, measured, improved, replicated, and used as a training vehicle. Integrators are, after all, in a tight labour market and cannot afford to be person-dependent. They need ways to document organisational experience and best practices and then to disseminate the knowledge.
"When you have a process," Keane explains, "you can significantly increase productivity, you can measure and benchmark, and you can use [the methodology] to successfully deliver products to clients better, faster, and cheaper."
In fact, some integrators consider methodology to be the "price of entry" into enterprise-class integration. Methodology goes a long way toward reassuring corporate customers that you can deliver what you've promised. "Customers should never go with a provider that lacks a methodology," argues Keane. "The integrator would be just throwing people at a project."
This argument is self-serving, of course, but it's a suitable bridge to another important competitive advantage: marketing. To the extent that an integration firm is a service company, it offers an intangible product. Methodology makes those services seem tangible.
Savvy integrators introduce methodology early in the sales cycle and discuss it in more detail as they approach the close of a deal.
They know it's more reassuring for a prospect to hear how you'll do something, rather than simply what you'll provide.
"It's even more effective than hearing a portfolio of past projects or current products and services," agrees Beck. Interestingly, she reports that many solutions integrators are actively seeking analyst endorsements for their methodologies, although "they aren't buying me lunches at expensive restaurants just yet".
Many integrators feel that all methodologies do essentially the same kind of work, segmenting a project into phases and then assigning particular activities and deliverables to each phase. Tim Nelson is one such integrator.
As chief scientist with US-based MCI, Nelson views methodology as "the best thinking of a company on how to do a project that produces a result". To him the important distinction is best practices - not specific tasks.
"The reality is that every project is different," he explains. "Managers using our methodology need to identify the tasks that are relevant to a specific project."
In this approach, methodology is used to structure a project and supplement individual thinking with company thinking. This framework is crucial when the project manager is new.
"Let's face it, an experienced project manager can draw up a project plan without a formal methodology. A less experienced PM can draw up the same plan by using our methodology", Nelson says.
Other integrators concur that some methodologies do embody extensive project experience that gives them practical value. The mature ones are the culmination of extensive history and testing. Nelson adds that seasoned methodologies help make projects predictable because they can highlight risks.
Risks to watch for
Experienced project managers know, for example, where the risks are and can ensure that they won't be overlooked when costing the job. In this sense, methodology is "a fixed-price-contract enabler", says Nelson.
But sophisticated enterprise customers aren't always bowled over by methodology, however well orchestrated. In fact, some integrators have encountered a backlash from the CASE-tool push, much of which failed to deliver on promises.
It is best, advises Nelson, not to assume everyone you talk to is an IS professional versed in all the diagrammatic techniques and data models that are part of a methodology. "Summarise the technical fine points for business people," he cautions.
Obviously methodologies are much more than a marketing ploy. But how much more? They've been called a repository of corporate wisdom on technology delivery, a model useful in identifying risks and improving estimation functions, and an enabler of fixed-price contracts.
"But the notion that even the best methodology will ensure project success is ridiculous," declares Dataquest's Beck. "Methodologies can't deal with politics; they're just tools. They also can't compensate much for inexperience, because they're too generic." Even methodology zealots like Brian Keane agree. "Methodology is no guarantee of success," he cautions. "You also need effective project management and communication between project teams and clients, or you will fail." If no methodology can ensure project outcomes, is it really necessary for integrators to have one?
"Projects aren't simple," answers Beck. "They're multidimensional problems with everything rolled into everything. Depending on your preparedness, they're either painful ordeals or high-risk adventures." IT projects do share many common elements, however. Integrators with sufficient project experience can, and should, identify these common components in a methodology, she urges, and "use it to make reliable predictions about those components that are predictable".
A method of study
Methodology creation doesn't have to be black magic; the Web can shed some light.
Methodology means money to integrators with proprietary project-management processes for building solutions.
Not surprisingly, integrators don't readily share their process details.
Fortunately there's the Internet, but unfortunately there are as many methodologies as there are software development kits. Be prepared to spend lots of time at sites such as (www.geocities. com/SiliconValley/Pines/1814/wmethod.htm) for a comprehensive discussion of software development models, from object-oriented to the classic lifecycle.
Another excellent resource is none other than that veteran of many large-scale integration projects, NASA. NASA maintains a comprehensive database of methodology-related resources, and many NASA-generated or commissioned documents, studies, and reports can be accessed via the Web at NASA TechTracs (ntas.techtracs.org).
Once you've absorbed the theory, it's helpful to see it applied.
Austin Data Systems offers a detailed breakdown of a phased system-development project at (www.ausdata.com/vbasic/stds_method.html).
Generic examples can help you understand your project needs to a point, but you must bring imagination, critical thinking, and ample project experience to methodology development.
For those lacking this background, MCI Systemhouse offers something of a workaround.
The Systemhouse Web site helps prospective customers articulate integration or development requirements and offers an automated process that relates components of past Systemhouse projects to the prospect's needs. Presumably this process is similar to the tools that inexperienced Systemhouse managers use to build a project plan from "corporate experience".
Check out (www.shl.com/solve).