Enterprise Services
Showing results for 
Search instead for 
Do you mean 

Project Tooling

‎01-06-2014 05:06 AM - edited ‎09-30-2015 07:00 AM

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.

About the Author

James_Jim_R

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.

Comments
AMartins
on ‎01-07-2014 04:08 PM

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

on ‎01-07-2014 06:38 PM

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

on ‎01-08-2014 11:44 PM

Nice to read it.

on ‎01-12-2014 06:47 AM

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.

on ‎01-27-2014 08:43 AM

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

on ‎01-30-2014 03: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.

Events
Each Month in 2016
Online
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
Sep 30
Seattle, WA
OpenStack Days Seattle
OpenStack Days Seattle, September 30, is the largest gathering of OpenStack users and prospective users in the Pacific Northwest region.
Read more
View all