Coping with Ambiguity

Situation

    Ambiguity is a way of life in a public agency.  Often projects come to me with vague ideas, goals that are conflicting and an outcome demanded with no idea how to get there.  I have tried sending the projects back asking for clarification.  I have even tried developing a checklist of questions that need answers before I will accept a project.  All that works … not at all.  The reality is that from the federal government down demands are set with no clear idea of how to get from where we are to their goals.  Superintendents know they have to improve teaching practice but have no idea how so they turn to technology to give them the answer. 

     A recent project that I was involved in is a perfect example.  Indian education (IE) needed a way to identify students that needed services.  Current process was to call staff in the districts and ask them to “guess” which kids might be affiliated with a tribe or have a Native American background.  IE approached me asking for access to our student management system for the districts we serve giving the goal that they needed to have more information about the students’ the district was giving them.  Easily, I could have gotten the required permissions and giving them what they asked for.  However, experience told me that what they were asking for probably was not what they needed.

Eliminate or Deal?

     After visiting with the department coordinator, I was able to get her goal of identifying students needing services.  Not being computer literate, she was not able to tell me how that was supposed to happen.  Typically, I would have designed a process and fulfilled as many of those pieces as I could with a program of some kind.  However, in this case I was asked to turn it over to our programmer without clear direction.  In other words, ignore the ambiguity and allow programming staff to deal with it. 

     This project should have taken less than 30 days.  Almost six months later, I was made aware that there was still no resolution to IE’s problem.  The solution arrived at by the programming staff was hard for IE to understand and use and she feared she was not communicating her needs to the development coordinator.  I stepped in at that point and took on a role of liaison between IE and development. 

     I took them all back to square one to set parameters, i.e. eliminate ambiguity.  Together we worked through what was needed and identified the tools we already had.  I was able to utilize some of the programming that was done already and steer it towards simplicity.  The final solution wasn’t going to be able to do everything IE was hoping for but it was a solid foundation for them to start developing processes and deciding where, truly, they needed to go with their Program. 

Lesson Learned

     I often find that dealing with the ambiguity and finding a clear road from the start of a project to the end makes for many more successful projects especially when dealing with my “geeks.”  I also learned on this project that just because it is said with conviction doesn’t mean the speaker understands what they are asking.  Communication is key to eliminating ambiguity.  The IE department knew what they had to have but since they did not speak the same “language” (geek-ese) as our programming staff they were not able to clearly define that need.  Since the programming staff did not understand IE’s language (non-geek-ese) what they thought they heard wasn’t anywhere close.

     In the end, the project was successful although it took much longer than it should have.