Smashing Bugs

 As I wrote about last week, I have a project that went live.  While I am really excited about this, I am now dealing with the downside – bugs and additional desired functionality that was never brought up while developing the specifications.

 

Bugs 

To be fair, not all of the issues are really bugs, some are just a matter of users using the system in unintended ways.  As a system analyst and the designer of the project, I am also trying to shield the developers from the multitude of user noise, gain an understanding of the problem, and relaying this information to the developers.  For me, this is a great way to learn how the users are using the system and helps me understand what other enhancements might be beneficial in streamlining the work and removing waste from the value stream.

 

The first report that we received was that a user couldn’t save their input because the entire page wasn’t loading.  As we are handling transactions for multiple employers and the line number request system is only needed for one employer, I was somewhat surprised to get a report from a user for the employer that does not need to have account numbers assigned.  I submitted a ticket and spoke with the developer.  It turns out that there was a bug in the code.  Somewhat simplified, the front end got to the point where is was displaying the data for a line number and the back end said, “I don’t know what you are talking about.”  The front end said, “That’s okay, I have all of eternity to wait…” and so it did.  According to the developer, this was an easy resolution but it came up again a few days later.  Crossing my fingers that it is fixed, even thought I didn’t code it, I am the face of the enhancement.

 

The second report that came up was due to a user being unable to save data.  This was definitely a user error as the user had the transaction set to void when she was attempting to save the data.  The system doesn’t like this status and refused to go along with the user’s request.  I don’t know if this issue was pre-existing or part of the new code.  Regardless, it seems to me that the user should get a warning or error message in this scenario and I have added it to the future enhancements list, ranking it right up there and probably trying to incorporate it into our data validation project.  As data validation has been started, we may wait for the next iteration of that project to include a message for that error as well as a similar error where the same datum was left as null.

 

Of course, there is the issue that was directly my fault, I take full responsibility for picking the wrong field for a data validation point.  I try to make my projects as ready to code as I can for our developers.  This includes detailed diagrams, telling them which fields in the database to reference or write.  One critical piece of information is displayed in two different areas.  It turns out that the area that I picked isn’t always populated, making it worse, the other area that this information exists in isn’t always populated, either, but it is a critical piece of data as a line can’t be assigned without one.  As it is only a binary, y/n, flag, we may just add the ability to select if the data isn’t available in the requisition.  It is an important lesson for me to validate the fields better than I did with this example.

 

Then we come to my favorite two issues.  The lack of a batch process and the lack of emails for the recruiting team to track their process with.  As it turns out, nobody said anything about the need to be able to request lines as a batch.  It is a well-known need, but it didn’t come up at all while we were doing our needs analysis and workflow documentation but it happened, a recruiter sent me a message with 30 reqs.  She wanted to know if she had to request each one individually or if she could just email the list to the transactions team that processes the line requests.  I had to remind her that the purpose of the project was to eliminate the emails due to the volume of emails and the amount of missing information.  She wasn’t pleased but I did offer to devise a method for this to be addressed in a future release.

 

My other favorite issue was from the same individual.  She said that she relies on the email communications to track when thing were requested and when they were completed.  She specifically cited the value of the time/date stamp on the email.  For me, this is an easy fix, let’s produce a report.  I explained to the user that we have audit logs in the system and I could easily develop a report for her and have that set up in the system so that she can pull it on demand.  We worked together to figure out what the most pressing information was and developed a prototype.  She was okay with the sample and I am now waiting for her okay to publish the report in the system.  Alternatively, if she requests me to pull the report for her again, I will just have it published in the system.

 

While none of these were major issues, they are inconveniences for the users and my goal and intent is to make things easier for all users involved.  While the teams that I am working with are very supportive of what I am trying to do, I hate that we can’t simply release such an enhancement without the issues.  I am sure that, as I get better at what I do, we will get better at publishing projects that do not have these issues.   We should find out soon because another project that I am working on will have it’s first phase go live next week and we can cycle the bug reporting challenges all over again.

It went to production!

It took a while. The prework, the process development, the waiting for development, the development process… but it finally went live, and my simple little process is now in our production environment.

The Problem

The problem was a simple communications problem. In our recruiting process, we need to assign accounting line numbers to our job requisitions. These are usually requested by the recruiter from our transaction processing team once the candidate has been selected but has not yet started. Unfortunately, the communication around this process was email based and frequently became confusing and challenging for both the recruiting team and our transaction processing team. Having witnessed the issue firsthand, I set out to find a solution. What if they could just push a button on our web interface?

 

Too much email, too little detail

For a line to be assigned, we need certain information. This information is collected in the job requisition, but is does not always get passed along with the transaction processing team.  This creates additional communications (lean concept: waste) between the transaction processing team and the recruiter. The required information is:

• Requisition Identification Number
• Job Title Identification Number
• Job Title
• Department Identification Number
• Department Name
• Full Time Equivalent (FTE)
• Pay Basis
• Account Number(s) where the expense is allocated to   

For the application, we needed additional information:

• Request Date
• Requestor
• Recruiter

With this information, we can automate the request process. Just a push of a button and the request can be made. With this information being in the system, the system can call this information and pass it to the request processing team for processing. The transactions processing team can then see the requests on their dashboard. Of course, sending the transaction processing team a notice that action is required and a confirmation to the recruiter that the process is in motion helps with the human factor until we can fully automate the line selection process.

 

What does this process look like?

In conjunction with representation from recruiting and the transaction processing team, we developed this flowchart to show what the process looks like. I am the rare bird that gives the development team flowcharts and identify the necessary database attributes, but they seem to appreciate it and it makes the coding process more efficient than trying to otherwise explain what we are trying to accomplish.

Request-A-Line Flowchart

There were changes in the development process after coding started that were not captured in the flowchart. My favorite improvement came up from recruiting where it will display the required codes and inform the requestor to cancel out of the confirmation notification to make any changes if any of the information is incorrect.

 

How is it working?

It is too soon to tell. I wrote up a brief how-to document for the recruiting team and the communication to the team is being managed by their leader.  The members of the recruiting team that engaged in the project’s development were quite excited and wondering what else we could apply similar logic and processes to.  The transaction processing team is small and even more instrumental in the development of the process. All-in-all, everyone is excited about the rollout and understands that things might not be perfect, and we will make updates to improve the process, as needed. In my opinion, the bigger win was helping people see that the don’t have to be satisfied with the system in its current state.  If they have an idea to improve the processes and pitch the improvement. Seeing people open their eyes to the possibility of change is more magical that we can ever do with these magical boxes of sand  silicon.