How To Create Great Project Specifications

Great specifications are the cornerstone of any successful project, but people seldom see eye-to-eye on the best ways to create them. Since the topic tends to be a bit controversial, I asked technology veterans Steve DelGrosso, director of IBM’s Project Management Center of Excellence and a board member of the Project Management Institute, and Bob Japenga, a specifications aficionado and founder and president of Connecticut-based software firm MicroTools, to share their best practices for creating great specifications.

DelGrosso’s Tips

Follow a Consistent Process: While specifications should be customized to fit each project, the creation process shouldn’t change. Otherwise, project managers may overlook critical details and developers may end up building a tool that doesn’t meet stakeholder expectations.

“The key to creating great specs is following a methodical process to capture the requirements and build the specifications,” says DelGrosso. “Also, don’t use a separate process to build the technical specs. Employ a holistic methodology that involves the entire team and encompasses all of the components.”

Establish Goals: The parties need to agree on the project’s goals and objectives before anyone creates the specifications or writes a single line of code. Team members should review the goals during meetings to prevent scope creep and to make sure the technology meets its intended target.

DelGgrosso: “Chart the major goals first and don’t proceed until all the parties agree, because great specifications always flow from the objectives.”

Create Informal Relationships and Formal Agreements: If you use an informal process and a variety of sources to gather requirements – like brainstorming sessions with stakeholders, customer focus groups and market research – consolidate their ideas and solicit the team’s approval before creating the specifications. If you follow an agile process, don’t make changes to the technology based on oral agreements. Write down the suggestions, send them to the team and note their responses in the documentation.

Build a Requirements Traceability Matrix (RTM): An RTM ensures that the project’s scope, requirements and deliverables remain intact throughout the twists and turns of the development lifecycle. “The only way to validate the specifications and deliver the technology that people said they wanted is to map the requirements to the design points and the design to the requirements.”

Japenga’s Tips

Define the Terms: “Technical organizations use generic language to describe the attributes of great specifications, because every project is different, and it’s up to the leader to define the terms and hold everyone to the documentation standards,” says Japenga.

For example, there’s no room for ambiguity if developers are building medical software that impacts lives, he says, but they need less detailed specifications to build a CRM app. Nevertheless, a specification that seems vague to one person may seem perfectly clear to another, so unless project managers define the terms and provide examples of appropriate language and documentation, the team will argue about the specs all day long.

Set Priorities, Boundaries and Limitations: Project managers have to balance speed with creativity and the cost of updating the specifications, as well as communicate priorities to their team.

“The developers need to know if they’re required to document every change, which may slow down the process and stifle innovation,” says Japenga. “Or, are you going to give them the freedom to make changes, let the code evolve and serve as the documentation?”

Test, Test and Retest: Even if the specs seem ironclad, intermittent testing and ongoing quality control assures the development of precise technology. Japenga often asks outsiders to test the software because developers and stakeholders may be so busy looking at the trees, they miss the forest. “While great specs are important, you still need to continuously test the product while it’s in development and seek external opinions,” he says. “Unfortunately, that doesn’t always happen and so we exist in an industry where imperfection reigns.”

Author

Leslie Stevens-Huffman is a business and careers writer based in Southern California. She has more than 20 years’ experience in the staffing industry and has been writing blog posts, sample resumes and providing sage career advice to the IT professionals in our Dice Community since 2006. Leslie has a bachelor’s degree in English and Journalism from the University of Southern California.