Enterprise Services
Showing results for 
Search instead for 
Do you mean 

How to introduce new project tools

‎03-25-2014 05:59 AM - edited ‎09-30-2015 07:02 AM

By:  James (Jim) R. Hughes, Global Business Analysis Capability Leader, Hewlett Packard Company


old and new light bulbs.jpgIn previous blog postings we identified four principles which should guide project teams considering the use of tools (Project Tooling) and considered why it is important that we apply these principles (Why Use Standard Project Tools?).


However, someone is sure to ask, “If software development project teams should only use the organization’s approved standard tools, how can new tools ever be introduced into an organization and applied on projects?”


The use of new tools can be proposed by project teams, and by anyone in the organization. However, the proposed new tools need to be assessed for demonstrated business value and their introduction should be managed. Project teams should not use non-standard tools instead of standard tools, without having first worked through their organization’s tool approval process.


Assessing Proposed Alternate Tools

Organizations should follow a disciplined process to assess new or alternate tools for project management, analysis, design, development, testing, and configuration management. The process should be similar to what we would use to identify and select a COTS product for business users (see, How to Pick the Right COTS Product).


The currently approved standard tool should be included among the alternatives, and assessed objectively as a potential candidate. Organizations proposing the introduction of a replacement tool should also consider factors such as the life-expectancy of the current and proposed tools. Obviously, if a vendor is planning to discontinue enhancement and support of a current tool, that would be an important factor in a tooling decision. Alternatively, if the vendor is planning major upgrades to the tool in future releases, that may provide an added business reason for maintaining the current tool as the standard.


Once the assessment of potential tools is complete, a business case should be prepared. The business case should include all the costs of moving to an alternative tool such as: training, configuration, interface development, conversion, expert support, and deployment. The benefits of moving to a new tool should significantly outweigh the costs, since the cost of churn introduced into projects or an organization by switching tools can be significant. Teams are also likely to experience a temporary productivity loss as team members change their habits and learn new processes and tooling skills


It is also important to distinguish between tools used with emerging technologies and those used to support disciplines which are more mature. For example, tools used to simulate mobile devices for development or testing or to develop robotic software may be changing quickly, whereas tools used for project scheduling, requirements management, and web-services development will be considerably more stable. It is reasonable to expect, and permit, more flexibility in tool selection in emerging domains but to recommend (or require) that standard tools be used in core, stable domains.


Managing New Tool Introduction

Organizations should also follow a disciplined process for managing the introduction of new tools. This should include:

  • Configuring the tool to instantiate the organizational processes.
  • Developing interfaces to other tools in the organization’s suite of project support tools.
  • Running a pilot implementation of the new tool in a demonstration mode and on a live project; with a subsequent refinement of the configuration.
  • Developing conversion processes and utilities.
  • Training personnel on new projects starting up with the new tool, and providing just-in-time training for personnel on projects which will convert to the new tool.
  • Scheduling conversions at appropriate project milestones (e.g. end of phase).
  • Ensuring that there is sufficient enabling support experts (e.g. through a help desk) until the new tool is widely adopted.


There will be good reasons for introducing new tools for project use. However, their introduction must provide demonstrated value for the organization and it must be managed. And, we must realize that rarely can tool-related problems on projects be directly attributed to projects not having access to the ‘best’ tool for a particular job. Invariably, tool-related problems are the result of project teams not using the available tools properly. My message to these projects is to use the tools as they have been configured.


Other blog postings by Jim Hughes, which address the challenges that limit applications solution delivery success, and how to overcome them:



Blogs in the Producing Quality Software series by Jim Hughes


Other blogs by Jim Hughes:


About the Author


Jim-150X210.jpgJames (Jim) R. Hughes, Global Strategic Capability Leader, Hewlett Packard Company

Jim has been with HP for 33 years and currently leads a global Strategic Capabilities Management team, with a specific focus on Business Analysis and Configuration Management. Jim also manages a team within the US State, Local, and Education division of HP.  He was a member of the IIBA committee that created a Business Analyst Competency Model and he participated in the development of IEEE standards.  Jim graduated from Harvard University, the University of British Columbia, and Ottawa Theological Hall.  He currently lives in Toronto, Canada.

0 Kudos
About the Author


Jim has been with HPE for almost 35 years and leads a matrixed global Strategic Capabilities Management team. His specific focus is on the Business Analysis capability. Jim is also a member of a team within the US Public Sector division of HPE, responsible for delivering application software to Federal and State governments. He was a member of the IIBA committee that created a Business Analyst Competency Model and he participated in the development of IEEE standards. Jim graduated from Harvard University, the University of British Columbia, and Ottawa Theological Hall. He lives in Toronto, Canada.

Nov 29 - Dec 1
Discover 2016 London
Learn how to thrive in a world of digital transformation at our biggest event of the year, Discover 2016 London, November 29 - December 1.
Read more
Each Month in 2016
Software Expert Days - 2016
Join us online to talk directly with our Software experts during online Expert Days. Find information here about past, current, and upcoming Expert Da...
Read more
View all