Part of the Process

This post is the story of a personal journey. It starts with a legacy product. Both powerful and flexible having grown to meet needs over time. But it is my view on steps to improve the process in my context - so your mileage may vary. Phase 1: Transactional DB as source Started with looking at the transactional data. Some things were obvious, one option in the UI is recorded as true/false in the DB. Some were more complicated and required more investigation. To back this up we conducted a user survey. Followed up by a workshop to find the most important user journey to concentrate on. This highlighted three related journeys. The key characteristic of activity in this phase was mining different structures of data. The format of the data coming from custom reports. Getting to the questions to ask was guided by a user survey to almost the whole user base, a smaller workshop looking at the "job to be done" for the platform. Other than that the skills needed where accessib...

One hot topic that you often get when you have project teams delivering functionality for user acceptance testing while support are testing ad hoc fixes for production issues is "Who owns the environment and how do we stop support and project work from interfering with each other?". I feel that all code changes and deployments to customer facing sites should have some kind of change management paperwork raised. Because of this you are able to catch scheduling/work conflicts in the change advisory board. A good change control process should help you think about the risk to your project and also help flag to other stakeholders that they might have a risk to consider. A very basic rule of thumb for deploying anything to production in a manually controlled environment is don't expect that no other changes to have been made since you took your base to work on and always check before merging in . Here I think a "manually controlled environment" is somewhere that d...