Is 'as-is' a good approach for software implementation ?

I consider this approach is typically the one that will kill innovation from software vendor or service company added value, or even internal IT department, when implementing new technology. Any technology has its own constraint. Renewing the technology on an "as-is" basis will break the innovation and, at the contrary, bring new constraint to resulting Information System. The result of such a strategy is simply a regression. This startegy applied to BPM or ACM will lead a company to fail in adapting its information system to market standard and innovation. Please react!


Opened by Antoine Fournier, Head of ECM, Input and Output management, Zurich Insurance
Jun 10, 2012.

recommanded this debate

Participate in the debate




Martin Goetze Senior Consultant, ISIS Papyrus Europe AG
Jun 12, 2012

recommanded this answer

Care to elaborate what exactly is meant by an 'as is' software implementation approach ?
Are we talking about a software implementation methodology like XP, DSDM, Agile and the like or rather about project management methodology (e.g. Prince2, PRiSM) ?

Any (successful) approach either combines suitable methods or frameworks as the mentioned ones for project and implementation, when they have been proven to be of help, or (better) dynamically forms adhoc a productive combination of project- and implementation methods through efficient stakeholder communication. Any chosen 'implementation approach' would need to address some core components like roles/responsibilities, flexibility, customer/user communication, change-management etc. pp. - and thus either the involved people are experienced and well-teamed up enough to go without a framework, or they move along a path given by established methodologies...
Comment on this response

Antoine Fournier 67 Antoine Fournier Head of ECM, Input and Output management, Zurich Insurance

Jul 11, 2012
By 'as is' approach, I was referring to business functional scope. Whatever methodology you use, you'll need to fulfill requirements. When an existing application is in the business scope that your project targets, and if the technology that you are implementing will REPLACE this app, it is an easy way to define as a first step that your technology should "at least" do what the application is actually doing.
I"ve seen in lot of requirements the 'as is/to be' approach (that is fine as an high level definition of business case) being drill down to detailed requirements, removing the value proposition of the chosen technology.
I prefer that new platform is installed, parametrised with the software vendor in order to get the value proposition into the organization, and establish the gap analysis from this proposal to a new business target that takes advantage of the software power and innovation.