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
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.
Until we master the force . . . the next best thing is a user requirements document. Coming up next . . .the journey to good user requirements.