Masthead Image

Our standardised delivery approach ensures a successful delivery every time

Collaborative

We take your input so it works for you

Whole Life Approach

Delivered as a tool for your business; not as an IT project

All Inclusive

Training, pilots, device builds, on-site support included & integral to the process

Our Delivery Approach

With Hillwalk’s use of proven open standards background technology the design aspects of the vast majority of our customer builds and configurations are associated with translating business processes, integrating with back-end/office systems and presenting usable and compelling user interfaces.

To achieve this Hillwalk has a team of mobile technology specialists with over 20 years’ experience of delivering successful designs to thousands of end users. With this experience the team can advise on the best options for implementation as well as being able to anticipate and quickly resolve any issues that may arise.

Hillwalk’s process is based on the Light Agile Development (LAD) method and delivered with Hillwalk’s cross-functional triad resourcing model. (The Agile Manifesto & Principles are available below)

Starting with requirement and design capture workshops, preliminary story boarding and wire framing the process includes prioritisation, “show and tells”, retrospectives and, for service systems, the in-life upgrades. At each iteration Hillwalk apply a series of design rule checks, recorded from lessons learned over the company’s lifetime, to ensure that those lessons are carried forward as best-practice in new systems and services.

By breaking the task into small increments; minimal planning, and governance overhead, is required. When delivering the initial pilot version on mobile workforce application projects, Hillwalk usually use four two week iterations. Each iteration involves one of our cross functional triads working in all functions: analysis, architecture, design coding, unit testing, and acceptance testing. At the end of each iteration a working prototype is demonstrated.

By working in this way we find that:

  • Service investment is directed on productive creative tasks rather than on pre-sales demonstrations, presentations, prototypes, mock-ups, overheads and libraries of transitional documentation
  • Demonstration of the incremental releases to stakeholders minimises the overall project risk and allows the project to adapt to changes quickly. This supports the underlying process of continuous, never-ending delivery of value
  • Frequently delivering reliable results facilitates constant engagement with the end users, producing a sense of shared ownership and better mutual understanding of each other’s objectives and constraints. This also ensures that the focus of effort is constantly directed on the key business activities and mitigates against the omission of key process loops and associated technical functionality
  • Working software within weeks rather than months allows early benefit realisation which often funds future enhancements to further increase your return on investment

Hillwalk is specifically structured to provide this model of service with decades of LAD experience and the depth of expertise to apply hand-picked techniques from a wide range of practices to suit different situations and environments. The flexibility of the Hillwalk approach is underlined by the many and varied successful releases delivered in this way. From the initial configuration to in-life enhancements Hillwalk has the experience and expertise to quickly, reliably and effectively deliver your solution.

Each build cycle’s capacity is sized in terms of the optimal delivery capability achievable based on; device technology, integration complexity, mobile workforce size and business process complexity. The cycle contents are determined by selecting the sized requirements based on customer priority until the full capacity of the cycle is exhausted. Those contents then become the committed delivery by Hillwalk for that cycle.

Collect & Replay

Process Flow Snippet

At project kick-off Hillwalk will instigate a formal project and commence the requirement and design capture activities to build a prioritised list of required functionality for the build cycles. This is initiated with a day’s Collection Workshop where the customer’s current processes and desired processes are recorded.

The Collection Workshop output is used to determine the data elements required within the customer’s business and, vitally, the specific relationship between them. From this the customer specific database schema is drawn up and forms the core of the Replay Workshop.

At the Replay Workshop the schema is walked through by Hillwalk’s analyst in line with the good and bad process scenarios collected at the initial workshop, in addition to any new scenarios that become visible during the design and replay processes. Also the Replay Workshop is used to present initial thoughts and layouts for the field and back-office applications.

First Build

Process Flow Snippet

First Build is usually an eight week, four iteration, build cycle that takes the core application, configures the specific customer functionality required for Go Live. The result is a deployable back-office release for pilot and a customer field application with all the core functionality enabled.

At two week intervals during First Build, Hillwalk host ‘Show & Tells’ via web meetings to demonstrate the current state of the applications, obtain feedback and ensure that they are heading in the right direction. Depending on timings and logistics the final ‘Show & Tell’ is often a longer, more detailed review held face to face.

Of course some projects have requirements that are more complex or are larger in number than average. In this case additional iterations are required to address these to the standard required for Pilot.

Pilot

Process Flow Snippet

The Pilot phase is specifically targeted at the field application. This puts the new application in the hands of field users with basic back-office UI functionality and potentially manually loaded business data.

A Hillwalk team member will be on-site or with a Pilot field user for the duration of the Pilot.

The exact duration of the Pilot and number of field users engaged depends on such factors as:

  • the nature of the sites to be attended; for instance, a Hillwalk specialist may be able to ride-along
  • geographic variance; for instance, are the work types and patterns different by region or geography and needing representatives from each variant to be part of the pilot?
  • the overall complexity of the application
  • the customer’s own objectives for Pilot

Training

Process Flow Snippet

Hillwalk has as much experience in the practical deployment of mobile applications to mobile workers as they do with the ‘nuts & bolts’ of the technology although simple common sense underpins much of the process of gaining the acceptance and confidence of the end users.

The Training phase runs in parallel with final internal system testing so isn’t the final Go Live version. With MDM it is possible to deliver the Go Live application version and clear any training jobs off the devices seamlessly and remotely prior to Go Live.

The approach to be adopted for training depends on factors including; the total number of users - field and back-office - and the logistics for Go Live – big bang or migration – the customer’s own training resources and policies.

Hands-on training of groups, no larger than 10, with realistic data and scenarios is an absolute must for these applications so Hillwalk will ensure a hands-on training system is available for both field and back-office users during the training period. Except for extenuating circumstances Hillwalk have found that allowing the field users to leave the training session with their built device and data to work with facilitates retention of the training messages. An application user guide is also made available at this stage.

Hillwalk include an allowance for two training days in the standard package which accommodates direct training of smaller or centralised workforces or providing internal trainer training and initial on-site support. This can be extended if it is preferred for Hillwalk to deliver all the training. If the new system will be delivering any business process change it is essential that a customer representative is also present to be able to respond to business change questions not specifically related to the system.

A typical field application course would last 2-3 hours. After a walk through of the application by the instructor the devices are issued and then a simple scenario is walked through by the class on their devices in-step with the instructor. Often then a simple objective is set for the class to perform on their device whilst the instructor mingles. This cycle is then repeated to cover the more complex and unusual scenarios until each member is confident in their own abilities. During the course device husbandry will also be covered and usually a high-level overview of the back-office capabilities will be demonstrated.

Prior to the Training phase, Hillwalk will have created and tested the device profiles on the MDM system so that it is possible to issue built and managed devices at the training sessions,

When training back-office teams on their web applications, Hillwalk has found that also giving hands-on experience of the mobile application is of great benefit in creating an overall understanding of the solution. Given that the back-office applications are web based, training usually consists of a high-level overview followed by a series of scenarios practiced in real-time. This is backed up by on-site mentoring and support at go-live followed by the availability of remote web meeting support thereafter. For the back-office user documentation is usually provided through contextual help rather than specific user guide.

Go Live

Process Flow Snippet

Once the devices start being used in production ongoing support becomes important. During the initial days of Go Live Hillwalk will discreetly collocate staff at the location of any back-office system users to both provide support of the back-office users and to monitor the operation of the mobile application in real business scenarios.

The field users’ device metrics will be monitored to ensure that devices are being used correctly and that the applications are performing as expected.

Where business critical automation is present this may be initially configured to be manually initiated, thereby enabling back-office review of the intended actions. For instance, a work scheduler would initially be set to produce a report of the intended work for review followed by a manual dispatch.

Operate

Post roll-out the delivering of further iterative development cycles ensure all user community feedback is captured and acted upon which helps to further build the user engagement and acceptance of the mobile system.

Hillwalk will operate the system elements of the solution as part of their service to the customer. This will include the daily information systems maintenance tasks such as back-ups and applying security patches as well as having in place and maintaining disaster recovery policies and processes.

In line with their prioritised iterative development process the Hillwalk operations team will undertake low frequency data setup and change tasks with internal tools. For example, changing a field user telephone number. Mutual operational experience then guides the prioritisation of customer facing data modification tools for incorporation in future development cycles.

Remediation

Process Flow Snippet

A Remediation Release is always planned for two weeks after Go Live. This release is intended to pick-up any visible, easily addressed and annoying issues. Previous Remediation Releases have included patches for Gaelic characters, a user interface for instigating reactive call outs and the addition of extra reason codes.

In some cases, planned lower priority, low risk application features may also be delivered in this release.

Reporting

Process Flow Snippet

With reports being dependent on the presence of real data in some volume and with reports being at the ‘edge’ of the system architecture Hillwalk find that the quality of an initial report delivery can be improved by deferring this to a small release a number of weeks after Go Live. This enables the reports to be developed and tested using real data.

This release should also deliver any remaining features agreed as required for in the initial workshops.

Optimisation

Process Flow Snippet

This release is the achievement of a steady state and is often significant in that desirable new features identified as a result of introducing the new system are delivered as well as many quick-win ‘nice to haves’. A recent 1.0 release included a major feature upgrade for buddy, or assist, jobs as well as a simple feature for the back-office to leave back-office only marker notes against sites. This is in addition to an optimisation of a number of the data flows and ensuring that the system is running on the latest stable versions of its dependent packages.

The delivery of this release is taken as an opportunity to perform some field and back-office update training and to retrospectively review the project with the customer’s senior stakeholders face to face.

Maintenance & Enhancement (Business Change) Releases

Process Flow Snippet

As a continual process Maintenance & Enhancement (M&E) releases are planned on an annual basis for each deployment. This enables the system to be brought up to date to ensure that it runs on the latest long term supported (LTS) versions of its dependent packages, databases and operating systems.

In addition, any changes or enhancements due to developments in the customer’s business environment can be accommodated. As an example, with geo-located Eircodes having become available in Ireland the next M&E Release for an Irish customer will include the incorporation of the Eircode database and enhancement of their mapping features to extend the existing work planning and scheduling tools.

Fix on Fail Releases

Notwithstanding the planned releases any necessary ‘fix on fail’ changes are delivered as soon as a stable resolution is available. This also applies to any security patches required for the dependent packages.

The standard Hillwalk SaaS Agreement includes a service level agreement which contains a matrix of response and resolution times for support services.

Ad-hoc Changes

The design of the system seeks to avoid the need to have to make releases for each business data related change, as HMACS keeps reference data on the field application updated as business as usual. However, there are often occasions where external factors determine cosmetic changes are required; the change of a disclaimer text, additional signature refusal reasons are typical. These types of change can usually be accommodated within the standard service in a timely manner.

Manifesto for Agile Software Development

"We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value"

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more


Principles behind the Agile Manifesto

We follow these principles:

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  4. Business people and developers must work together daily throughout the project.
  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  7. Working software is the primary measure of progress.
  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  9. Continuous attention to technical excellence and good design enhances agility.
  10. Simplicity--the art of maximising the amount of work not done--is essential.
  11. The best architectures, requirements, and designs emerge from self-organising teams.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.