Until We Master the Force . . .

The Jedi Knights use the Force to guide their actions.  “It’s an energy field created by all living things. It surrounds us and penetrates us; it binds the galaxy together.” – Obi-Wan Kenobi

SW blast shield
“But with the Blast-Shield down, I can’t see!”

I am amazed by the number of people who believe the Force is the best method to implement software.  With nothing visible in place to direct project activities, I can only assume they are relying on the force.  Unfortunately, I have not run into implementers / developers who have mastered the Force, dooming them to long, and frequently unsuccessful, projects.

A good set of requirements can go a long way to guide our actions during the project.  Unfortunately, this is frequently skipped or inadequate.  Why?  Here are some of the excuses I hear:

“There is no point; it will change during the project” 
All the more reason to have the blueprint established.  This is the vehicle that should be used to lead a discussion on the consequences of making a change.  Is this really a change from what was already agreed upon?  Will the change result in rework?  Does it add time/cost to the project?  Is it a “must-have” or a “nice-to-have”?

“I don’t know how”
An understandable dilemma.  This is a skill-set not many people have.  In fact, I find it interesting there is not a standard approach.  Other skill-sets on a project have a fairly standard set of techniques established; e.g. Project Management.  Even after working in the industry for so long, I couldn’t point a person in the right direction to gain such knowledge.  I hope this blog will address that and provide a practical method to establish a requirements document.

“We do not have time”
The most prevalent (and lamest) reason I encounter.  How could you afford not to have a requirement document in place?  Having no plan in place that describes the final solution is a plan for failure.  You would be crazy to hire a contractor to build a house without blueprints, so why hire a contractor to build a software system with no plans?  I believe this excuse is typically a different version of “I don’t know how”.  Generally when I hear this excuse and I provide some coaching, I am able to show the benefit.


“No more training do you require. Already know you that which you need . . . One thing remains. Vadar. You must confront Vadar.”


Until we master the force . . . the next best thing is a user requirements document.  Coming up next . . .the journey to good user requirements.

Management Must be Crazy


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.

gods must be crazy cliff

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.