You have been given a user request to add a new field to a screen. You notice that the request is 6 months old. When you call the user to introduce yourself and let her know that you are going to be working on the request she tells you to cancel it! She found a way to record the needed information in the existing software and doesn’t need the new field afterall.
What do you do?? Post your recommendation for the analyst above.
13 Comments
You should still investigate. Is the user’s way a proper one or just a work around that shouldn’t be possible? If it’s a proper way then the problem is solved and an investigation of the documentation or training is in order to see if something was missed; if it’s a work around that is only possible through the improper usage of the software is it a bug or something that does not affect the whole system?
I would continue the conversation with this user and ask questions about the workaround being used in lieu of a new field, as these perceived solutions can sometimes have unintended yet adverse effects. For example, the user may be entering this new data in a field that feeds another user’s special report. That report may become skewed or even corrupt if this new data doesn’t fit the field as it should.
If the discussion reveals the user’s workaround may not be wise after all, then you’ve got a starting point on requirements toward a better solution. At the least, you’ve investigated a potentially bad practice in progress. It’s always good to know exactly how end users can manipulate the application, as they can expose holes in the most thorough test plans.
Close the ticket. Move on.
answer1: If time is of essence and there is other work to be done then I would just ask how she resolved the problem and if I’m satisfied she is not using some other field or messing up the application in some way then I’ll cancel the issue noting down that she asked me to cancel it.
answer2: If however I have time on my hands I’ll ask her but also at the same time find out if there is a better way of doing it. If so I will suggest it to the user-perhaps show her a demo/prototype to demonstrate how my method is better than hers and then take it from there.
I’d congratulate the user on finding a solution, then ask if she wouldn’t mind showing it to me. I’d investigate whether the work around is appropriate, i.e. that the proper fields are being updated, that the data entered as a result meets existing data requirements, and whether the solution is a one-off, e.g. will work for her but for no one else who may need this capability. I’d also confer with the development/technical team regarding the user’s solution, to make sure it is in line with their design/maintenance requirements, and future design/coding tasks. Perform an analysis and based on what is found, proceed from there. If the user’s solution passes this smell test, I’d bless it and close the ticket, otherwise I’d get to work on designing a solution, bringing the user in to make her feel a part of it so that she doesn’t feel her contribution was worthless.
I agree with Craig.
Capture the solution, inform the owner of the request. Confirm with the app owner / sponsor and your manager for approval. Then document, including approval and close.
Could be tricky here. On the face of it, if the user has established their own work around which works for them. Well, yipee!
However, is the workaround appropriate? Does it adhere to standards and policies? Is it supported? Does it impact anything else? Is the field being used referred to anywhere else? All relevant questions to ask IF you’ve the time to ask them, which is often not possible.
Often what happens here is that you have to close the request and move on, due to resource and time constraints.
A compromise may be to document what you’ve discovered, and ensure that this is appropriately made known to the correct people; the person’s manager, process owners, support desk (if relevant), and your own manager. The very fact that you’ve highlighted this workaround and why it’s come about may reveal that need for further action. Communication is ALWAYS the key.
In the best world (which doesn’t exist) you’d be able to fully analyse the original problem/need and recommend the required approach. If then, the approach being used satisfies this without negative impact – then all is good with the world.
So great to see so many replies and so many opinions! I do think that BAs demonstrate leadership and our value when we step outside our specific assignment to note opportunities and/or risks.
I would ask a few additional leading questions in an effort to determine whether the mechanism (field) she is using to capture the information is appropriate, and caters to indirect requirements such as reporting. If, for instance, it is something that needs to be reported on but is being lost in a free-text field with other information, then it bears further investigation and may need to be kicked off as a project despite the user indicating that she has resolved her problem. By asking leading questions, she may realise that her solution is not appropriate and may then request that you proceed. Users often don’t know what they don’t know.
The other side to that coin is to determine whether such a change is critical and a priority. If it is not and there are no indirect requirements, then I would suggest either closing the request down or putting it forward as a future enhancement (if deemed necessary).
Find out how the user is recording the information. You should ensure Data Integrity is not being compromised in the system by the users actions. Ensure the Business Understanding syncs up with what the System is doing with the data. User could think one thing and the system is doing something entirely different. Thanks, Tom
I would definitely have a conversation with the user to understand what he/she did to determine if the solution or workaround that is being used makes sense. It’s possible that the solution he/she devised might be cause one or more defects elsewhere in the application or in a downstream system. The workflow(s) that he/she are using as part of the workaround should be documented. It is still possible that a better solution can be developed but the analysis must bear that out.
I’m wondering why the project’s change control process has allowed this request to sit untouched for six months.
Anyway, I would do what the CCP tells me to do. If I am the person assigned to investigate the change, then that is what I would do, otherwise I would be taking it upon myself to break the process.
Regards,
Declan