Learning Launch - When Shutting Up Helps Innovation 

 I am a Sr . Program Manager in a Finance IT shop for a very large corporation .   We help other Finance   teams through process automation or bringing them into the 21st century as I like to say .   I chose   Learning Launch as my tool because the theme of finding ideas to solve a problem and using unique   thought processes , data and experiments to confirm the solution is useful .   This type of design thinking   fits with a project I am currently working on .     The Challenge   A stakeholder directive to reduce headcount needs in a department which joined our organization last   year .   Within three months people would be moving to different organizations and contractors let go .    What I knew : they managed large quantities of data and interacted with a billing system in a manual   way .   What I did n’t know :   How exactly they spent their time .     I asked for a time / work study from the team director .   Mapping the team ’s time to their work functions   and flow , my initial thought(idea ) was we could automate inputting data into the billing system by   expanding a protocol we had successfully used in the past . This could not be a cookie cutter solution   though ; this team ’s work was performed in a system we no access to ( risk and possible disconfirming   fact ) . I had been told by the team director that previous automation attempts had failed because the   work was too complex ( risk and possible disconfirming fact ) .   This solution needed to go beyond the   standard elements of automation and be equal to or faster and more accurate then what the team   currently did themselves . This idea could meet the directive challenge and be better than the current   alternative .      I told the stakeholders ( Director and VP ) I had an idea to pursue . I was given a small development team   to explore its merits .   The target team director provided a resource ( and skeptic ) to work with us .     Brainstorming Optimization   I set up meetings with my developers - all with different skills and specialties . Generally , I am quite   verbal , which can mute the brilliant person who does n’t like to speak off the cuff .   So , instead of   directing the team in how I thought this problem should be resolved , I tried something different - I shut   up . As the curator , I gave the team a focus ( the specific need and the idea ) . I left space for others to   contribute , leveraging their expertise and differences .   The ideas flew - nothing was bad , it just may not   have been right as a solution .   It was a lesson learned for me and one I am trying to incorporate more   and more .     A workflow to shorten the time and attention it takes to consistently make correct , appropriate changes   to thousands ( and sometimes millions ) of customer accounts emerged .   The solution was scalable ,   addressed the work complexities and the client could view the process and make last minute changes if   necessary . On paper , if we could get billing system access , this solution could achieve the automation   and headcount savings being asked for .   Aha ! Design thinking !   We now needed to get stakeholder   approval to move on to designing and experimenting with the process .     Presenting the Solution   Our presentation was cobbled together .   We reviewed the workflow and showed pieces of other   projects that had some similar moving parts . We described how one section of work would flow into the   next and the ability the client would have to control the data . This was unlike work we had done before ,   but it could end up being a pathway for many other teams in the future .   Our napkin pitch was clumsy 

 but it did the job . The apprehensive client team director could see the possibility for success .   Our   leadership knew our capabilities and approved our next move - to build and test the idea .     Confirming the Results   We had reached Wow . We got the billing system access needed and what has been developed is being   tested for release next month .   Trials are showing we can take a large amount of data and using   automation input it correctly into multiple layers of a highly complex billing system .   We will reach the   headcount reduction requested and an even higher percentage of time savings than previously   predicted . If I was going to do something differently , next time I would ask for more client input upfront .    This would have helped sharpen the focus on the issue to be solved more quickly . 


EMAIL: 
ID_NUM: 
NAME_STUDENT: 
PHONE_NUM: 
STREET_ADDRESS: 
URL_PERSONAL: 
USERNAME: 

### Task: You are a PII (Personal Identity Information) Detection. Given a essays written by students, you have to identify ONLY the following:
NAME_STUDENT - The full or partial name of a student that is not necessarily the author of the essay. This excludes instructors, authors, and other person names.
EMAIL - A student’s email address.
USERNAME - A student's username on any platform.
ID_NUM - A number or sequence of characters that could be used to identify a student, such as a student ID or a social security number.
PHONE_NUM - A phone number associated with a student.
URL_PERSONAL - A URL that might be used to identify a student.
STREET_ADDRESS - A full or partial street address that is associated with the student, such as their home address.
### Input: Learning Launch - When Shutting Up Helps Innovation 

 I am a Sr . Program Manager in a Finance IT shop for a very large corporation .   We help other Finance   teams through process automation or bringing them into the 21st century as I like to say .   I chose   Learning Launch as my tool because the theme of finding ideas to solve a problem and using unique   thought processes , data and experiments to confirm the solution is useful .   This type of design thinking   fits with a project I am currently working on .     The Challenge   A stakeholder directive to reduce headcount needs in a department which joined our organization last   year .   Within three months people would be moving to different organizations and contractors let go .    What I knew : they managed large quantities of data and interacted with a billing system in a manual   way .   What I did n’t know :   How exactly they spent their time .     I asked for a time / work study from the team director .   Mapping the team ’s time to their work functions   and flow , my initial thought(idea ) was we could automate inputting data into the billing system by   expanding a protocol we had successfully used in the past . This could not be a cookie cutter solution   though ; this team ’s work was performed in a system we no access to ( risk and possible disconfirming   fact ) . I had been told by the team director that previous automation attempts had failed because the   work was too complex ( risk and possible disconfirming fact ) .   This solution needed to go beyond the   standard elements of automation and be equal to or faster and more accurate then what the team   currently did themselves . This idea could meet the directive challenge and be better than the current   alternative .      I told the stakeholders ( Director and VP ) I had an idea to pursue . I was given a small development team   to explore its merits .   The target team director provided a resource ( and skeptic ) to work with us .     Brainstorming Optimization   I set up meetings with my developers - all with different skills and specialties . Generally , I am quite   verbal , which can mute the brilliant person who does n’t like to speak off the cuff .   So , instead of   directing the team in how I thought this problem should be resolved , I tried something different - I shut   up . As the curator , I gave the team a focus ( the specific need and the idea ) . I left space for others to   contribute , leveraging their expertise and differences .   The ideas flew - nothing was bad , it just may not   have been right as a solution .   It was a lesson learned for me and one I am trying to incorporate more   and more .     A workflow to shorten the time and attention it takes to consistently make correct , appropriate changes   to thousands ( and sometimes millions ) of customer accounts emerged .   The solution was scalable ,   addressed the work complexities and the client could view the process and make last minute changes if   necessary . On paper , if we could get billing system access , this solution could achieve the automation   and headcount savings being asked for .   Aha ! Design thinking !   We now needed to get stakeholder   approval to move on to designing and experimenting with the process .     Presenting the Solution   Our presentation was cobbled together .   We reviewed the workflow and showed pieces of other   projects that had some similar moving parts . We described how one section of work would flow into the   next and the ability the client would have to control the data . This was unlike work we had done before ,   but it could end up being a pathway for many other teams in the future .   Our napkin pitch was clumsy 

 but it did the job . The apprehensive client team director could see the possibility for success .   Our   leadership knew our capabilities and approved our next move - to build and test the idea .     Confirming the Results   We had reached Wow . We got the billing system access needed and what has been developed is being   tested for release next month .   Trials are showing we can take a large amount of data and using   automation input it correctly into multiple layers of a highly complex billing system .   We will reach the   headcount reduction requested and an even higher percentage of time savings than previously   predicted . If I was going to do something differently , next time I would ask for more client input upfront .    This would have helped sharpen the focus on the issue to be solved more quickly .
### Output: 