How identify our process.

It’s important to note that I am talking about the process we apply to single set of changes, not the high level process we might apply to a complete project. I have referred to this in the past as a “Ticket Process”, other people have used the term change set. However it can be any sort of change or piece of work.

Remember the objective of the Lightweight Ticket Process is to have a process that is as simple as possible, but no simpler. Some of the issues to investigate:

1. What is the desired final outcome, purpose or product from the process. e.g.
   1. The creation of a review document notes
   2. The fixing of a bug in the current development
   3. The generation of revenue by implementing a custom feature
   4. Asking a question
2. Where in the Application lifecyle was it initiated and by whom e.g.
   1. Project Initiation
   2. Production support
   3. User Acceptance testing
3. What pieces of work need to happen to create the desired outcome? e.g.
   1. Code changes
   2. Rebuild of software
   3. Change in specification
   4. Change in budget or other piece of project documentation
   5. Deployment onto a production environment
   6. An update to a build system configuration
4. What role is responsible for performing the work. e.g. developer, project manager...
5. What reviews and approvals need to occur before and after the work is complete, e.g.
   1. Review of cost, benefit, impact and risk
   2. Approval by Change Control Board
   3. Code review
   4. Sign off by Quality Assurance team
6. What roles are responsible for performing reviews or authorisation.
7. Any process requirements from the customer or other external entity e.g. the FDA

Make sure that you cast around for the following sources of information

1. This projects current processes, documented and undocumented
2. Organisational processes and standards
3. Similar projects in the same organisation
4. External standards such as ITIL

Now comes the hard bit.

You have followed the activities above and come with a beautiful complete process. Unfortunately it is far too complex. So now we simplify, which can be difficult to do.

1. Cut out "information" steps and roles
2. Determine which of the outputs from each process step are useful. What are they used for? Nothing obvious? Then cut it out
3. Be brutal and cut out any thing that not essential and be severe with your definition of "essential"

It is better to start with too simple a process and improve it as the team understands more, than to start with something hard to use. Unfortunately it is very easy to give a team the the latter as the siren call of "complete process" is highly seductive.