Development of a method is really difficult. Henderson-Sellers (1995) formulated it as follows:

“An appropriate lifecycle methodology for developments must contain ALL of the following components:

• a full lifecycle process for both business and technological issues;

• a full set of concepts and models which are internally self-consistent;

• a collection of rules and guidelines;

• a full description of all deliverables;

• a workable notation;

• ideally supported by third party drawing tools;

• a set of tried and tested techniques;

• a set of appropriate metrics, standards and test strategies;

• identification of organizational roles e.g. business analyst, programmer;

• guidelines for project management and quality assurance;

• advice on library management and reuse.”

Additionaly, to have a well-implemented method, it is necessary to do more, such as embedding it in the existing environment with examples, best practices, internal and external communication, training, links to other methods, acceptance in the organization, Wikis, content management and knowledge systems, maintenance plans and a lot more.

Unfortunately, much of the literature on methods gets bogged down in the “WHO does WHAT WHEN” question. With regard to the “HOW”, usually some examples are given and the remainder is left to the reader’s imagination. It can serve as a good introduction and overview, but it will not be sufficient for the design and construction of complex information systems.

Moreover, a process of technology convergence has been under way in the market for some considerable time. It is already fairly common to see a combination of an Open Source infrastructure, an Oracle database, an SAP back-end and a Microsoft front-end. Open Standards make this possible and make solutions cheaper or faster to implement. This naturally has consequences for the process of development and implementation. Each technology often also entails a specific approach. SAP has ASAP, Oracle has OUM, IBM has RUP and so on, including the smaller suppliers. This makes the methodological landscape very diverse, often with a lot of small differences under the hood.

It is therefore better to draw a distinction between the method ("WHO does WHAT" and "WHEN") and the techniques and associated tools ("HOW is it done' and "WITH WHAT"). This results in a convergence of the various technologies, leading to cost savings, solutions to communication problems and employee flexibility.Well, now for the solution. A good way to start is to see a method simply as an ordered list of intermediate artifacts (eg. design-documents) leading to the implemented application without going into to detail about “HOW” to make the artifacts. In fact to construct a method the question “WHO does WHAT WHEN” is enough where the “WHAT” points to the making of the artifact. The “How to make the artifact” is treated separately and consists of the guideline, template, master example and best practices. This gives the opportunity to implement or even design a method specifically for a project without changing the craftsmanship of making artifacts.

Conversely, (the making of) artifacts can be changed, enhanced, removed, added without altering the basic principles of a project given a certain functional or technical environment.For instance, an extremely high pressure on the time-to-delivery for an application, might lead to the choice of a method like onshore Scrum instead of offshore RUP. That doesn’t necessarily mean that all artifacts with their guidelines and standards from RUP are completely useless. We can probably just skip a few due to the closer communication between business and IT and add a some others to better keep track of advancing insights during software development. Also a use-case in a bespoke environment shouldn’t differ that much from one in a package situation like SAP or Oracle.

This approach will dramatically improve acceptance for new ways of working, steepening learning curves, and even more important, reduces time spent and costs.

Be first to comment this article

Write Comment
Name:
Comment:
Code:*