Applications Services Blog
Get the latest thought leadership and information about the role of Applications Services in an increasingly interconnected world at the HP Blog Hub.

Focus on Fundamentals (#18): How to introduce new project tools

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.

 

Previous Focus on Fundamental blogs by Jim Hughes:

 

Previous 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.

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.
Search
Showing results for 
Search instead for 
Do you mean 
About the Author
Jim has been with HP for 33 years and currently leads a global Strategic Capabilities Management team, with a specific focus on Business Ana...


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation