Dealing with Complexity: the Opus Project

opus.ucla.edu

This is the longest task flow I've ever done.  It outlines the steps of a university faculty review.  

 Let's take a look at one section of it: the blue box above.

The system should:

  • create a department committee
  • allow the department administrator to edit the committee
  • send the committee members documents
  • log committee member votes

 

Let's go further down the rabbit hole.  To create a department committee, we need to figure out what faculty members are allowed to be on it, per university policy.   We also need some information from the user about what their specific department policies are.   Here's a flow chart of how this dynamic form would look:  

Yeah, it's complicated.  

The project didn't seem this complicated when we first started.  The original requirements fit on one sheet of paper.  The charge was to replace the current paper system, and not change any process or policies that were already in place.  Of course, when you get deeper into the project, a kind of design quantum physics occurs, and the requirements change when we look at it.  Each layer reveals another level of complexity underneath it.  But the project has to end at some point!  There's no time or budget to capture everything.  

So what do you do?  One thing we learned to do was balance was complexity vs. functionality.  A voting system for committee members and an automatic committee-maker would have been nice.  But as we see above, it's going to take a lot of work to get there.  

So what did we end up with?  Once we showed our sponsors the reality, everyone agreed that this would be easier.  The department administrator logs the votes:

What did I learn?

  • Complexity causes the project to change.  Sometimes by observing something you change it fundamentally.  
  • Put a spotlight on the complicated and unnecessary.  For the mental health of your users and your engineers, avoid complexity whenever possible.
  • Humans are storytelling, visual animals.  Show them a diagram or an image instead of pages of text. When we showed people the giant task flow above they suddenly understood how cumbersome the current process was.   
  • Sometimes you start behind the starting line.  There's far more behind the curtain than anyone realizes.
  • Don't get lost in the weeds.  Balance complexity vs functionality and be willing to cut scope.