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.
“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
o;ered 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.
FILLING IN THE BLANKS
Even when project practitioners don’t have an
abundance of project data, modeling can help them
;ll 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. ;e
analysis was based on geographic region, the business segment, the module a;ordability, economic
zones and many other factors,” she says.
After ;nding limited data in text form online
from various sources, “trying to consolidate and
analyze the information was getting to be a chal-
lenge,” 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 cer-
tain software and other areas the com-
pany 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 ;owchart with hundreds of steps
or as simple as a tree diagram with two
or three branches. ;e project manager
must determine when to use a model,
“Just like a recipe book, you pick what you want
from the recipe and make it your own,” Mr. Gagné
says. PM
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.”
—Joy Beatty
SAMPLE MODEL: PROCESS FLOWS
Process flow models include process steps connected by directional arrows that indicate all possible paths. These models
have clearly defined starting and ending points. They can also feature other symbols, as seen below.
I
M
A
GE
C
OU
RT
ES
Y
OF
S
EI
L
EV
EL
