Animals, Technology and Limitless Complexity
The title for my story is Animals, Technology and Limitless Complexity. However, I could have just as easily called it "e-health for the animal kingdom". As we approach the provincial election that may have got more interest! My story is about a very troubled project that I was asked to recover several years ago while working for a large systems integration company.
The project involved the development of a single, global application to provide cradle to grave electronic health records for animals around the world. The users of the system included zoos, aquariums, researchers, and biologists in 600 institutions across 70 countries. The functionality contemplated for the system involved population management, genealogy, clinical medicine and international transfers between institutions – like moving elephants from Toronto to California!
If the size and breadth of the user base doesn't strike fear into the hearts of any project managers in the audience, the complexity of the functionality should! However, the handsomely rewarded sales executives who inked the deal with the association representing the users treated the web application project with about the same level of diligence as was likely for the Toronto Zoo's website - something that offers information and limited transactions related to membership, ticket purchases, opening hours, and directions.
I mentioned the interesting user base of 600 institutions across 70 countries. These user stakeholders posed several challenges that could have likely been anticipated such as:
1. The users were scientists, veterinarians, clinicians and zookeepers. They were not used to articulating their "business" requirements. Imagine what the use case looks like related to euthanizing a giraffe!
2. The users were not IT savvy and had no experience in a development project. They had also never dealt with an IT vendor working on a fixed price contract model.
3. The users typically required approval from their board for all decisions – right down to field layouts on a web page. Users were therefore reluctant to commit in requirements sessions. Further, board meetings were held monthly or quarterly resulting in some pretty major schedule impacts to required decisions.
4. Finally, the entire project and the sponsoring association were funded by the stakeholder organizations which meant that their lack of approval for anything had significant implications. This drove an unprecedented level of effort to secure stakeholder buy-in.
Beyond the challenges of the user base, I also mentioned that the functionality of the contracted system was far more complex than your average web application. I can likely best articulate this complexity and improve my audience ratings by talking about sex. In this application the contemplation of sex went well beyond male and female. For example:
There are seven different sexes of frogs.
Some animals have parts of their body as one sex and other parts that are another sex.
Some animals breed asexually sometimes and sexually other times.
Some animals change sex as they progress through their life cycles.
Lastly, reproduction could involve situations where the mother and father were either known, suspected or identified as being from a general group.
These complex requirements made the capital markets applications in my bank seem very straightforward by comparison! The impact of all of this was pretty significant:
The team size of the vendor increased from a planned 15 to 98
500 subject matter experts participated in requirements gathering
Ultimately, the application involved 1800 screens and over 1 million lines of code
The project duration extended from a planned 24 months to 4 years
Finally, the project went from a revenue opportunity of a few million dollars to a loss in excess of $5 million
So, what are the lessons learned from this tall tale?
1. Recognize that there is no upper limit to complexity and factor this into how you manage your project.
2. Develop a plan to manage stakeholder engagement taking into account their level of knowledge, frame of reference, and motivations. Ensure that stakeholders align on what "done" looks like early in the project and agree on what constraints will govern how the project is delivered in terms of scope, schedule and budget.
3. Lastly, recognize that "perfect" can be the enemy of "good". Had the users compromised on an 80% solution early in the project, we would have collectively delivered value in ½ the time and for ¼ of the cost!