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.

Project Tooling

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


tools.jpgAuthor’s note: My blogs address the challenges that limit applications solution delivery success, and how to overcome them.



I can’t count the number of times I have heard of projects reporting problems related to tooling—problems such as:

  • the reports are not being formatted ‘correctly’
  • inability to find subject matter experts to assist with deployment
  • poor training
  • integration challenges
  • poor performance
  • double data entry
  • defects not being addressed by the tool vendor
  • missing functionality

Sometimes the tooling problems are blamed for project delays, employee morale issues, cost overruns, and poor quality.


To blame the tools used on a project for ineffective or inefficient delivery performance is bogus! Tools do not make a person into a good Project Manager, Business Analyst, Developer, or Tester. Tools do not make for a successful or unsuccessful project. Good people use the best tools they have available to their advantage, but they never become slaves to their tools. Good carpenters who make fine cabinets can drill holes with a hand auger if necessary, even if they would prefer to use an electric-powered drill press. A good doctor can make a general assessment of a person’s health with a stethoscope, an otoscope, and a tongue depressor, and rarely needs to use an MRI scanner. Likewise, good PMs can plan and track even a large project in Excel if that is all they have available to them.


Successful PMs, BAs, and Developers apply the following principles with respect to their use of tools. They …

  • Use the best tool available. The key operative word in the preceding statement is ‘use’. They actually use the tools. They make them work. They don’t complain about having to use the tools and create artificial reasons for why they can’t or won’t use them. If necessary, they invent work-arounds so that they can get their work done using the tools.
  • Use standard tools. They don’t assess and select different tools each time they begin a project. And they’re not concerned if they don’t have access to the latest ‘hot’ tool or version. Rather, they use the standard tools which their organization has selected and in which the organization makes an investment. One project I was involved with didn’t like the ‘corporate’ standard tool for managing agile sprints and decided that it had to use a different tool. Of course, as they got into it, they discovered that they had little experience with their new tool, couldn’t find expert users to assist them, and ended up with additional costs. Using standard tools allows a team to start up quickly, apply consistency across projects, and obtain resources familiar with the tool and its nuances.
  • Keep it simple. They don’t create complex ways of using the tools. For example, they don’t utilize a number of project-specific custom fields to track progress or to classify entities. Instead, they use the standard configuration and workflow supplied by their organization.
  • Avoid ‘tool wars’. They don’t allow the ‘techies’ to get into debates about which tools the project should use. They silence discussion when people raise the topic of their favourite tools and make comparisons among tools, unless a person has a constructive way for improving the application of a standard tool.


Tools do not make or break a project! Intelligent, focused, skilled, and experienced PMs, BAs, Developers, and Testers are what make for project success. Using a suitable tool only improves their efficiency and effectiveness. After all, the Parthenon, a high-quality structure, was built with hand tools!


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.

AMartins | ‎01-08-2014 12:08 AM

Good one, Jim!


The "right tools" are certainly needed more and more these days, but no one should use the lack of a tool as an excuse for not doing a good job. That certainly doesn't fly....

Srinivasan Desikan | ‎01-08-2014 02:38 AM

Good Article Jim. More than the choice of tools how we use them matters a lot to projects and organizations. Could have been great if you toched upon standard metrics for BA also in this post. What I liked most in this blog is when you said "Tools do not make or break a project! Intelligent, focused, skilled, and experienced PMs, BAs, Developers, and Testers are what make for project success".


Very true!. Please keep writing...

Ernie | ‎01-09-2014 07:44 AM

Nice to read it.

Doug Flor | ‎01-12-2014 02:47 PM

Liked the article. Thanks.


My experience in IT (I was in the ES Americas PMO at HP), a quality assurance director, and as a family therapist tells me that it is human nature to push the blame on the tool (or even child or spouse) than taking personal ownership of being the problem.


But there is also the likelihood that it can be the tool. In addition,  it could be the processes or procedures. Lastly, it could be simply a training issue, as highly engaged and intelligent people who know how to do the job and have great tools, dont always follow processes and procedures well.


So it is a complex thing to access for quality. Again, thanks for sharing.

PM Hut | ‎01-27-2014 04:43 PM

Hi James,


"(Project managers...) use the best tools available" - the question is, what are the best tools? Who can say which tool is the best tool or which tools are the best? If you feel that there are some tools that are the best in the market then would it be possible to add them here?


In my opinion, one tool that sucks for one project manager is the best for another. Many people hate Excel, but there are some others who think it's the best PM tool. Same goes with MS Project. This is purely subjective.


Thanks for sharing and for the opportunity to express my opinion...

James_Jim_R | ‎01-30-2014 11:21 AM

Use the best tools available ... means to use the best of whatever tools are provided/avaialble to them.

We must balance this with Avoid ‘tool wars’.

The key message is not to let the lack of you favourite tool become an excuse for abdication.

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.
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
Top Kudoed Posts
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.