The SMART criteria for defining a goal are useful when it comes to managing a technology project. Gathering business requirements may appear to be a simple job; simply ask the user what they want. However, this is often one of the most difficult and critical tasks a project manager has to undertake.
The quality and realism of the requirements gathering process is a primary ‘make or break’ project management task. If the requirements lack adequate definition, the project will fail to achieve its goals. That’s why we suggest using the SMART principles.
Communication Gaps Between Business and Technology Teams
Communications gaps that exist between the business-savvy sponsor and the technical-minded analyst often increase the complexity of defining business requirements. In many instances, neither party is willing or able to adopt the dialect of the other. This is why it is critical that that the project manager document a clear understanding of each requirement, couched in terms that all parties agree with and can understand.
The typical executive business sponsor will frame the request in broad terms, often phrased to coincide with the broader strategic goals of the organization. Sometimes, this phraseology is a result of not understanding how to define the key deliverables to others. This frequently happens when an executive instructs a subordinate to have IT develop a solution. What the subordinate perceives as the project definition may vary significantly from what the executive intends to convey.
To complicate the situation even more, the technology representative may have a different interpretation of the requirements. Unfortunately, in many cases, the technology representative enters the requirements gathering process with a preconceived (or pre-designed) solution and meets with the stakeholder out of courtesy. The technology representative agrees with the sponsor on the definition of the requirements, and then begins working on the pre-designed solution, disregarding the input from the sponsor.
The results of this situation are as predictable as they are historical. The sponsors do not receive a product that meets their needs and scope creep and poor design consume the project. For all practical purposes, the project fails.
Example: Wrongly Assumed Technical Agility
Some technology organizations like to consider themselves to be ‘lean and agile’. Consequently, they accept broad, generalized requirements statements. With this, is an expectation that the business analysts and developers will ‘flesh out’ the requirements to meet the needs of the organization. They feel it is too much work to gather and document this information at the beginning of the project.
In most cases, this represents flawed logic. There is an implied expectation for the analysts and developers to finish the requirements definitions based on historical activities. This negates any agility and innovation the organization may try to achieve. The technology department holds the organization captive to ‘how things have always been done’.
In many instances, this kind of thinking from the technology department represents laziness. Some technology managers have claimed that requirements gathering and planning require too much work. The developers think they should just begin coding because the requirements will change anyway. Or they might lazily go down the path of adopting inflexible solutions such as signing up to IBM or Amazon for web hosting.
Adapting the SMART Objectives Framework
In order to control scope creep and ensure that the project team is accurately capturing the stakeholder requirements to fulfill their expected needs, we have borrowed the SMART objectives definition from the human resources industry. They are applied to our requirements gathering and definition process. In this manner, every requirement must be specific, measurable, achievable, realistic and time-bound.
SMART stands for:
1. Specific – Requirements should specify what they are to achieve.
2. Measurable – The requirements should provide a metric whereby all stakeholders can determine if the objectives are being met.
3. Achievable – Are the requirements’ objectives achievable and attainable?
4. Realistic – Are the requirements realistic with respect to the available resources?
5. Time-Bound – When is the team to achieve the requirements’ objectives?
Using SMART Requirements, the intent is to engage in a partnership with the stakeholders in such a fashion to ensure that all parties agree on exactly what the deliverables are and how to measure performance to those deliverables accurately. Without any agreed upon definition of measurement, determining completion is impossible. One way to accomplish this is to use and enforce SMART Requirements gathering.
By asking focused questions relevant to each SMART component, the project manager can ensure that the needs of the business are documented and communicated in terms understood by all stakeholders. It creates a unified business administration activity that encompasses business requirements, technical capabilities and effective project management.
The project manager must continue to ask questions until the requirements of the deliverables are defined accurately in accordance with the SMART concept. One must be aware that there may be multiple distinct requirements for a single deliverable. Each requirement mandates documentation with the SMART concept as a unique line item.
Specific
We require that the stakeholder provide SPECIFIC definitions of their requirements. The project manager clarifies the requirements through a process of progressive elaboration. Remember that a single requirements deliverable may decompose into multiple work breakdown structure (WBS) tasks, each one possibly requiring its own distinct resource. The project manager must continually ask probing questions that force the sponsor to identify exactly what is desired. Without specific definition of the deliverable, delivery is impossible.
Measurable
Once defined, the requirements team must ensure that the requirement is MEASURABLE. This metric can relate to the bottom line, sales, performance improvements, or virtually any other aspect of the business that is quantifiable. There must be a method of determining when that requirement has been met. The project manager must define this measurement clearly in terms that all parties understand.
Achievable
One critical aspect of any requirement is that it must be ACHIEVABLE. If a goal or requirement is unachievable with reasonable resources, then the purpose of that goal or requirement is questionable. An unachievable requirement may result from lack of understanding the goal or the capabilities of the organization and project team. While unachievable requirements are questionable, some requirements that are unachievable in the present may become feasible in the future.
Realistic
The requirement must be REALISTIC. An unrealistic goal or requirement represents a waste of organizational resources and may run counter to the best interests of the business. Obviously, the project manager must cull unrealistic goals and requirements from the project portfolio. The organizational cost, time, resource, and quality constraints help define the realistic aspect of a requirement.
Time-Bound
Any goal or business requirement must be TIME-BOUND. That is, there must be a reasonable time or duration expectation for the performance and completion of that requirement.
Without a relationship to a time component, there is no sense of urgency and the deliverable assumes a very low priority among competing efforts. Open-ended requirements are a recipe for disaster. In many instances, the stakeholder and project manager or business analyst may be able to define a business time constraint.
However, in some cases, the developer will provide this time estimate. In this instance, it is preferable that the person doing the actual work be the one to provide the ‘most likely’ estimate of task duration. Using PERT or similar tools or software, the project manager and business analyst can provide the optimistic and pessimistic task duration estimates to bring the developer’s estimate into line, if necessary.
Benefits of SMART Approach
Using SMART project requirements can improve technology projects by:
- Clearly defining the work requirements to the team members. Each project team member must have specific knowledge of what is required and when it is needed.)
- Allowing the Quality Assurance team to understand the specific needs of the project. This helps reduce ‘gold-plating’ and QA-induced scope creep.
- Ensuring that the stakeholders have a document that outlines the original project requirements that they developed and agreed with. It is common for executives to experience an altered perception of the project deliverables as business needs change.)
While it may seem quicker and more efficient to use simple words and phrases to define the project deliverables, the easy road is the path to disaster. Project management and being a technology manager are hard work. By gathering and documenting SMART requirements early in the project, the project manager can avoid a lot of confusion, misconceptions, and misunderstandings through the life of the project.
By ensuring that the deliverables requirements gathering process is SMART, everyone involved with the project will have a better understanding of the requirements and be comfortable that they are Specific, Measurable, Achievable, Realistic and Time-bound. There should be fewer surprises and less wasted time and effort.
Remember that planning omitted from the beginning of the project will exact payment later in the project lifecycle. This is in terms of cost and schedule overruns and scope mutation (an extreme version of scope creep). You will also have a project that fails to deliver what the sponsor needs. A simple rule of thumb is that a minute of planning saves a quarter of an hour of unnecessary project work.