We take your input so it works for you
Delivered as a tool for your business; not as an IT project
Training, pilots, device builds, on-site support included & integral to the process
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:
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.
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 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.
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:
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.
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.
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.
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.
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.
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.
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.
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.
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.
"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
We follow these principles: