Enterprise Services
Showing results for 
Search instead for 
Do you mean 

How to introduce new project tools

James_Jim_R ‎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.

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.

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
January 2016
Software Expert Days - 2016
Join us online to talk directly with our Software experts during the online Expert Days - see details below. Software experts do not monitor this foru...
Read more
See board event postings
Vivit Events - 2016
Learn about upcoming Vivit webinars and live events in 2016.
Read more
View all