Nikhil
BAN USERNote : Since you are sure schedule is impacted, it is an issue and not a risk. Pardon me for being too technical with the terms, but just in case you are wondering why I'm calling it that.
Here's what I'd do :
* Check what activities in your WBS are causing the schedule delay
* Check if those activities can be corrected by adding more team members/resources (a.k.a crashing)
* If it can be corrected by crashing, check the budget impact - crashing for majority of instances will increase your budget.
* In your risk/issue meeting, let your team know about this issue and the options you have thought of. Check if your team has more options.
* If crashing is still the only option, involve relevant stakeholders for the budget & communication.
* Log lessons learned.
* If crashing is not an option and this is an inevitability do the following :
* Can scope be cut to meet the schedule ?
* Else, inform the delay to the stakeholders respectively - technical team, project sponsor, et. al.
* Re-baseline the project
* Log lessons learned.
Note : In some cases you might have to re-visit if this project should even continue further.
Hope this helped :)
:) Love this question.
- Nikhil July 18, 2014Before going into designing the whole solution, here are my thoughts.
If I were blind :
1.) The most difficult thing would be putting the card into the slot
2.) Secondly - locating the keypad
3.) Thirdly - is someone watching me while I'm entering my pin or standing too close to take the money when it comes out and & runs away
IMP : Confirm above assumptions by observing a blind person use a normal ATM today. Surveys should also be used to know what their biggest concerns/issues are.
What's the budget btw ?
Assuming - no constraint.
Design
* When someone approaches the ATM, the camera detects and asks to raise either arm if they are blind
* If blind, guide them to an approximate location closer to the ATM via sound beeps.
* Ask if it's o.k. to deploy a temporary enclosure (wish I could draw)
* Move the card tray nearer to the person - detect torso and hand location. Users usually raise their dominant hand, so use that info. Card can be just placed in it, no inserting, etc. required. Make it big enough to avoid dropping the card. There are a few edge cases over here, about dropping a picked card, but tabling them for later.
* Read the card, ask for confirmation that this is the card they want to use
* After confirmation, move the keypad closer to the person (let them know this is being done)
* Use braille embossing as Vimarsh suggested above. I have another idea since pins are digits today. The keypad can have just 2 keys - press the first one number of times (twice for 2, etc). The second one is a spacing key, denoting digit entered. This method seems easier to me, but need to verify with users, plus would need educating users. Outstanding question How do you do that for people from other countries ?
* Things get interesting if the pin isn't correct - how do you communicate what they entered only to that person . Just saying "Pin is incorrect" isn't that useful. How about tracking ears and directing sound into them directly, so only they can hear ? Headphones doesn't sound like the correct solution here.
* If everything goes fine transfer money to the same keypad (can't draw here)
* Use the keypad to give the card back (i.e. use that same arm - less moving parts = less maintenance = long term saving)
* Everything is guided by sound.
* At any time, the user can raise both arms or say something to that affect (tbd) to un-deploy the enclosure
Didn't expect the answer to get this big.
Again, great question.