The Application 100 Day Review

Introduction

In 2013 Group Applications introduced the "One Hundred Day Review" concept. The idea was to have an approach to deal with "phase 2" items from a green fields application development and feedback post go live feedback on the application. To do this in a structured and organised approach so the original project closes, the project team moves to new work and there is not a list of outstanding tasks, improvements, on hold tickets that just falls into limbo. It was first used on the Volunteer Application. This went live in March 2013, in early July we went back to the business and asked them what they wanted changed and fixed. This was captured and carried out. These reviews are also planned for Study Options (February 2014) and FindAThesis (July 2014). As such they appear on the Group Applications Resource planning for 2014.

Background

Name and Address Register & the Yellow Line

Over 10 years ago I worked as the PM, BA, Co-Developer, Test Lead, etc with one other Developer and a Business SME (Subject Matter Expert) to build the Building Consents application for Manukau City Council. As we were pushed for time as a small team working on an existing code base and database that was left over from the first failed implementation, we made some very pragmatic decisions. One of the areas of the original application we did not change was the name and address register. We had used a model borrowed from another project that was not used in any other applications. The outcome was the process by which names, addresses and roles were added, edited and deleted seemed slow and clumsy to us. We thought users would hate it. However we did not have time to rebuild it and placed it first on our list to fix post go live. We went live on the 13th November 2003. When I left council in mid-2011 we still had not changed it. There was no need, no one complained, the users all found it easy to use and no one ever asked us once in 8 years to change it.

One of the modules we developed was the consent tracking page. Users could see the location of the consent and who was working on it. Users complained that they could not see the location without having to look at it in detail and read the entire screen. So we added a css and code change that highlighted the current location of the consent on the page with a bright yellow background. This background was ugly, it was so bright you could see it standing three feet back from the PC. The users loved it. It was so easy to see and use. So the term "the Yellow line" entered into both the Business and IT vocabulary.  We referred to the current location of a consent as the consent the yellow line was on. The Current Location report became known the Yellow Line report. It was simple and effective.

What's the Lesson?

The lesson is until you use an application thoroughly and frequently you won't fully understand what works and what does not. Deciding in test phases what needs to be changed, enhanced or improved may not be needed post go live and other areas which seemed okay may suddenly be a pain point. The example above is interesting as the Name and Address Register was infrequently used so no one minded the extra step or two to use. The consent tracking page was used heavily every hour of the day. In needed to be more user friendly. Ironically "fixed" with a bright yellow line.

Once an application is released there is a real temptation to ask for early changes. If there are urgent fixes this is a differently story, these need to be resolved. Non-urgent fixes may not need to be resolved or may become unimportant and can wait. Give the application and users time to use the application and ask them to capture feedback and discuss among themselves.

What's Included?

• Any tickets that have been left over from the original development, inclusive of bugs, improvements and wish-list items.
• Any current non-urgent fixes.
• Any changes which will make the application easier to use and maintain. 

Plus any requests from the teams responsible for support and maintenance. They may have ideas on how to improve it.

A lot of the requests from the first Volunteer Project 100-Day review were changes such as adding new fields to pages, adding a validation rule in, resolving an issue with an alert appearing in the log files, make some fields and input boxes bigger. Mainly small items which make the application a lot easier to use.

What's the Process?

The process is relatively simple.

• Before you commence development of the original application explain this concept to the business. Any ideas, improvements, etc that occur late in the build and in UAT can wait for 100 Day Review for inclusion.
• Complete and release the application, flag tickets remaining from the project in JIRA as required to be reviewed. Inform the business to start their 100-day review list.
• About 3 months later arrange a meeting with the business and discuss the list. There will need to be conversations around funding, priority against other activities and timing.
• Discuss what items need to be built, what bugs need to be fixed and if any of the existing bugs are so trivial the tickets can be closed. Be pragmatic.
• Stand up the review as a small project and apply normal SDLC rules and standards until completion.
• Close out the project as per normal.

What Happens if there are LOTS of Changes and Bugs?

This is likely to be outcome of the original project not capturing the requirements correctly, poor development, poor testing (including UAT) and possibly an unrealistic 100-day list. The projects stood up by 100-day reviews are meant to be small. If the volume of change is significant then you may need to consider a refactoring type project or build a completely new application.

Further Changes

Further requests for changes will come as the application is further used. Business processes are not static and the application will need to change to meet any changes in process. Users will find further ways to improve the application and may uncover bugs that are deeply buried in the application. There is no hard and fast rule to standing up projects to deliver these changes. This is something that should evolve over the life cycle of the application.

Closing Thoughts

The review does not have to be exactly 100 days, especially if you release 100 days before Xmas. I would not make it a shorter period, but a longer period of one to six months would be okay.