6 IT PROJECT TOOLS
Purpose
Over the last ten years, there has been a proliferation of soft-
ware to assist in the management of IT projects and IT opera-
tional processes. New software has been introduced to support
all phases of the System Development Lifecycle (SDLC).
Although these tools can and do provide much needed support
for the application development process, it is important to
remember that the tools are there to support the SDLC process,
not to provide the process. As the Gartner Group emphasizes,
“Methodology before Technology – technology changes frequent-
ly, solid methodologies are flexible, adaptable and age well.”
Implementing automation into the SDLC process is a serious
commitment. Without a clear understanding of what it will take
to be successful, from the fiscal commitment to the resource
commitment, the software becomes shelfware.
There are a number of concerns regarding automation in the
SDLC, including selecting the right tool for the job and lack of
management support for the automated tool that is chosen.
Because the use of automated tools in the SDLC process is a rel-
atively new and expanding area, it often does not gain the atten-
tion it deserves until something goes wrong. Many agencies
lack effective automation architecture and the specialized com-
petencies required to implement and use the automated tools.
Adding new tools requires new skills, training, and expenditures
for the software and equipment, all of which drain existing
resources.
It is important, therefore, to address several key factors in the
automation of the SDLC, including:
◆ Senior management support
◆ Adequate resources with appropriate skills
◆ Clear and effective ownership and integration of technology
with SDLC processes
◆ Proper training
◆ Performance Measures
65
66 Section II:6 IT Project Tools
NYS Project Management Guidebook
6.1 TOOL SELECTION
Selecting the correct software to assist in the SDLC process is
the key to its effectiveness. Purchasing and implementing the
correct tool for the job is as important in application develop-
ment as it is in building a house. Defining the requirements and
functionality that the tool is expected to provide is similar to
working with the architect in the design of a new building. After
the building has been designed and agreed upon, you have a
better understanding of what tools to use. Using 10 laborers
with shovels is one way to dig a foundation. Bringing in a work-
er with a backhoe would be considered an automated way to dig
the foundation. For a house, a bulldozer would be appropriate,
for a doghouse, it would be considered overkill. With so many
tools on the market and so many companies buying each other
out and coming up with new ideas, it is important to accurately
define what is to be accomplished with the software.
When implementing automated solutions, keep it simple. If the
tool gets in the way, people won’t use it. The tool should be inte-
grated into existing work processes for Customer support and
documentation. Then purchasing software ensures that a defi-
nite business need has been defined.
There are many different types of automated software that
sound good, but will using them make the development faster or
the quality of the software better? The best idea is to start small
and build on successes.
When purchasing a tool, continue to refine and prioritize
requirements based on the initial round of investigation. Quiz
the vendors and read the literature, and narrow the list to no
more than three options. To evaluate the finalists, develop a list
of real tasks that the tool would be required to perform and
have someone who will be an actual user of the tool perform the
hands-on analysis. Other evaluation steps would be to find the
local user group and attend a meeting, determine the extent of
the on-line community for the tool and consider the stability of
the vendor (how long have they been in business?). Once the
selection has been made, a plan should be developed for intro-
ducing the tool. Make sure that training is available for the
users and that the effects of the change are considered. (from
Making the Right Choice–A “How To” Guide to Choosing Tools by Elisabeth
Hendrikson, [Link]. Automated Testing Conference, Boston,
MA. August 2001.)
Section II:6 IT Project Tools 67
NYS Project Management Guidebook
Six key ingredients to help avoid the chance that the tool will
become shelfware:
■ evaluate,
■ implement and deploy well,
■ use wisely,
■ overcome problems, and
■ reap the benefits!
Implementing an Automated Regression Test Suite by Lloyd Roden, Grove
Consultants Automated Testing Conference, Boston, MA. August 2001.
There are many tools, suites and packages to choose from.
Some tools are specific to the type of job you require, some tools
address all aspects of a particular phase in an SDLC, and then
there are tools that are comprehensive for an SDLC and are
packaged as a suite. If the need has been thoroughly identified,
it is easier to determine the level of tool to analyze. It will be
helpful to visualize the phases of the lifecycle and the deliver-
ables in order to determine which tool is required.
Some tools available are packaged to provide functionality for
both business and data modeling. For example, within System
Requirements Analysis it is possible that both a business mod-
eling tool, and a data modeling tool may be required. Tools that
can help capture information, perform modeling, and generate
test scripts can be especially helpful in keeping data in one
repository, and for tracking how it is processed.
To summarize, the Project Manager should determine if there
are any tools that will assist the Project Team in their SDLC
efforts. It is important to note, however, that many tools, and
especially tool suites, may require a change in the way work is
performed, which may or may not be beneficial. The final meas-
ure of a tool is how well it assists the Project Team in accom-
plishing the goals of the project. Knowing which tools provide
which service will allow you to select the right tool for the job!
