What to establish before taking over a K2 application

A K2 application takeover begins with an agreed view of the current solution. Review the people, systems and documentation it depends on before making changes.

Start with the application people actually use

An inherited application may have years of changes behind it. The original specification can be useful, but it may no longer describe how the application operates today.

We begin by discussing the current process with its users and owners. What work depends on it? Which issues occur repeatedly? Which changes are needed next?

Identify the important dependencies

Forms and workflows are part of a wider environment. We examine connected systems, data structures and the documentation available to explain them.

Access to a source system, a particular account or knowledge held by another supplier can be essential to the work. These dependencies need to be understood before a delivery commitment is made.

Separate investigation from implementation

A request to fix a slow form may require investigation before the appropriate change is known. A proposed new field may have consequences for several workflow steps or reports.

Treating that investigation as a defined first task gives the customer a clearer basis for deciding what to do next. It also avoids presenting uncertainty as a finished estimate.

Build an agreed baseline

Before changing the application, agree what must continue working and how it will be checked. Include the important exception paths and integrations, not just the first successful submission.

Documentation can then be improved around the parts being reviewed and changed. This creates a useful record for continued maintenance.

Web CheckIn can assess an existing K2 solution and discuss its maintenance or further development. Start with the current application, available documentation and the problem you want to address.

Explore our application maintenance service and the Nintex Automation K2 platform.