Implementing software can create an experience for users much like the characters in the film The Gods Must be Crazy. The gist of the movie is that a remote tribe suddenly encounters modern technology.
“Lately strange new things appears in the sky . . . noisy birds flew without flapping their wings. One day something fell from the sky. It looked like water, but was harder than anything else in the world. He wondered why the gods had sent this thing down to earth.”
The “thing” was an empty Coke bottle.
Sound familiar? What about this version?
“Lately these strange new consultants have been passing through . . . they are very noisy. One day they dropped in this new software. It looked interesting, but it was harder than anything else in the world to use. He wondered why management had sent this thing down to them.”
In the movie, the tribe is puzzled by this technology. They invent uses for the bottle, none of which are for its intended purpose:
- Curing snake skin
- Making music
- Decorating cloth
- Milling grain
- Opening goads
While the bottle was seen by the tribe as a great technology, it caused fighting and arguments leading the elders to decide it must be returned to the gods. This sends one of their members on a trek to the end of the world to return the bottle.
Users, while initially enamored by new software become frustrated when they do not understand it. Many time we see users make the best of situation, using the system in non-productive ways. In the most extreme cases it is dysfunctional enough that management will abandon the system; a colossal waste of time, money, and employee goodwill.
In my 20+ years of implementing software, I typically hear blame placed on poor project management, lack of training, inadequate management support, and inaccurate setup/configuration. Rarely do I hear the root cause discussed: “we did not have a good method of confirming the business needs were understood and using them to guide the rest of the project.” Having a solid set of requirements will mitigate the typical issues I mentioned above.
Often the task of defining requirements falls on someone with a title like “Business Analyst”, “Solution Architect”, “Implementer”, or “Business Consultant”. Frequently I find professionals in these roles to be well trained in the technology, but lacking the ability to synthesize system requirements in a way that is useful for all stakeholders. There is the further challenge that different functional areas are unable to effectively integrate their requirements.
I want to change that. I have developed a holistic approach to system implementations that provides a method for understanding business needs and leveraging that to ensure success for the rest of the project. This blog is devoted to explaining that approach and helping others to become Implementation eXperts.