Now you see it
when gathering requirements gets murky, visual modeling can clear the way.
BY ALMA BAHMAN
PORTRAITS BY NICK SIMONITE
Joy Beatty, Seilevel, Austin, Texas, USA
As project managers determine the requirements needed to get a project from inception to completion, what may seem simple enough at first can quickly grow into a tangled morass of requirements and their myriad dependencies. Visual models can streamline those complicated details, turning them into a discernible, easy-to-follow story.
Visual models—whether tables, flowcharts, maps, matrices, tree diagrams or others—turn overwhelming amounts of intricate text into readily analyzable images. They thus shorten projects’ development phases and increase productivity, says Shilpa Gnaneshwar, PMP, project manager at GE Aviation, a PMI Global Executive Council member, Bengaluru, India. When presented in text format, relationships among requirements can remain stubbornly opaque; modeling makes them apparent. “If done correctly,” Ms. Gnaneshwar says, “modeling will remove redundancy and ambiguity in data.”
“If done correctly, modeling will remove redundancy and ambiguity in data.”
—Shilpa Gnaneshwar, PMP, GE Aviation, Bengaluru, India
What's at stake is much more than a simplified project management process, however. A model that clearly illuminates a project's requirements has a direct impact on its chances of success. Almost 40 percent of unsuccessful projects fail primarily due to inaccurate requirements gathering, according to PMI's 2015 Pulse of the Profession®: Capturing the Value of Project Management.
IMAGE COURTESY OF SEILEVEL
“The value of a picture is that it's a neutral, agnostic language,” says Howard Podeswa, CEO of Noble Inc., Toronto, Ontario, Canada. “It draws a logical connection between things.”
“The value of a picture is that it's a neutral, agnostic language. It draws a logical connection between things.”
—Howard Podeswa, Noble Inc., Toronto, Ontario, Canada
Modeling might seem like an extraneous, timeconsuming activity, but spending a bit more time up front can save time in the end. “When people think about models, they sometimes think, ‘I don't have time, I can barely get the requirements done,’” says Joy Beatty, vice president of SeiLabs at Seilevel, Austin, Texas, USA. “But you should take that time to do it now, instead of having to do it later.”
A visual model doesn't have to be a great work of art. “You can use templates and frameworks,” Ms. Beatty says. With each initiative, project managers can customize those templates.
Rather than using the standard term “requirements gathering,” Ms. Beatty prefers “requirements elicitation.” The word “gathering” suggests that requirements are sitting out in the open, she says, like berries waiting to be picked. Requirements elicitation means posing the right questions to get the needed information. Visual models can help project practitioners understand what those questions should be—and which stakeholders should answer them.
Ms. Beatty likens the process of eliciting requirements to building a house. “You can build a house without talking to the people who are going to live in it, but you'll build a better house if you did.”
A project doesn't have to be reduced to just one visual model. While every house, for example, has the same basic components—four walls, a roof and a door—a feature-tree model could diagram residents’ specific needs. The model's trunk represents the house while a branch represents each bedroom, with smaller branches describing the room's size, the type of flooring and so on. From there, a process-flow model could map out the steps for the contractor, from hiring subcontractors to applying for permits to procuring materials. Even blueprints are a visual model, Ms. Beatty says: “Here's the floor plan, here's the electrical, and everything is in the blueprint and laid out on top of each other.”
“When people think about models, they sometimes think, 'I don't have time, I can barely get the requirements done.' But you should take that time to do it now, instead of having to do it later.”
IMAGE COURTESY OF SEILEVEL
If visual modeling relies on the old adage that a picture is worth a thousand words, Ms. Beatty finds another number equally useful: seven. Based on the work of psychologist George A. Miller, PhD, Ms. Beatty uses this concept to explain the useful role of visual requirements models. As Dr. Miller showed, people's short-term memory can absorb about seven new things at a time, give or take two. Ms. Beatty often sees this play out on projects.
One such project aimed to build a game-like simulation for a government contractor. “The customer handed us their list of 2,000 requirements, and said, ‘Help us figure out if we're missing anything,’” Ms. Beatty says. Not only would parsing through the list of 2,000 items take the project team too much time, but Ms. Beatty still wouldn't have been able to figure out everything the project needed.
“As I was reading through, somewhere around number 10, I forgot what number one was about,” Ms. Beatty says. “Reading through is impossible for comparing requirements and looking for redundancies or missing pieces.”
Ms. Beatty and her team mapped the list of requirements onto models: requirements mapping matrices, process flows and context diagrams. “When it was just a list, no one really could understand the essence of what the system did, but these models tied the requirements together,” she says. “They helped the project by organizing the requirements to tell a story.”
The team also discovered missing requirements and project areas that had no written requirements at all.
“As I got more involved in the up-front aspects of projects, I realized that these models, if drawn at the beginning of a project, would reveal to me missing requirements.”
ON THE SAME PAGE
Visual models can help ensure that all project team members share the same understanding of the project's requirements—especially since different people see the same things differently, Mr. Podeswa says. While team members might grasp only their respective project components, a model displays the whole picture.
“Not everyone thinks at the same level,” says Pierre Gagné, president of Insurance Frameworks Inc., Quebec City, Quebec, Canada. “Some think close to the ground and some think strategically.”
And some team members can get so mired in the technical details of a project that they miss critical pieces of information.
When a Canadian regional government had to update its human resources software, Mr. Podeswa was brought on to help select and purchase a new system. He started modeling with a group of business analysts who had already been working on the project. Minutes into the conversation, Mr. Podeswa says, the group members realized they had missed a vital piece of information that would inform the new system: the fact that employees could belong to more than one union.
IMAGE COURTESY OF SEILEVEL
“As I got more involved in the up-front aspects of projects, I realized that these models, if drawn at the beginning of a project, would reveal to me missing requirements,” he says. Modeling helped strip away the technical steps from the software and offered a clear look at requirements and rules, Mr. Podeswa says.
Like Ms. Beatty, Mr. Podeswa said that clear view helped him know what he required from the project's stakeholders. “Missing elements in the diagram pointed to questions I still needed to ask my stakeholders,” he says.
“When it was just a list, no one really could understand the essence of what the system did, but these models tied the requirements together. They helped the project by organizing the requirements to tell a story.”
FILLING IN THE BLANKS
Even when project practitioners don't have an abundance of project data, modeling can help them fill in the blanks. While working on a software project, Ms. Gnaneshwar used models to make sense of a complicated competition analysis.
“I was doing a market analysis on the possible modules for a software product expansion. The analysis was based on geographic region, the business segment, the module affordability, economic zones and many other factors,” she says.
After finding limited data in text form online from various sources, “trying to consolidate and analyze the information was getting to be a challenge,” she says. “Trying to transform it to a format that I could deduce from was not easy either.”
To bolster the analysis, Ms. Gnaneshwar relied on visual models. Plotting data onto line graphs helped identify customers’ inclinations toward certain software and other areas the company intended to invest in. Maps visually highlighted relevant regions and displayed customers’ levels of interest. Modeling the data revealed the trends Ms. Gnaneshwar was looking for more quickly than if she had parsed through each text document.
“It is like a jigsaw puzzle,” she says. “You have bits and pieces of information, and you are trying to build a picture out of it.”
A model can be as complicated as a process flowchart with hundreds of steps or as simple as a tree diagram with two or three branches. The project manager must determine when to use a model, what model to use and how detailed to make it, Mr. Podeswa says.
“Just like a recipe book, you pick what you want from the recipe and make it your own,” Mr. Gagné says. PM
MAY 2015 PM NETWORK
PM NETWORK MAY 2015 WWW.PMI.ORG