Article Overview
In product development and project management, we use tools for building and tracking projects. Keep reading this column to find out more about the definition, selection and discussion about these tools.
Table of Contents
- Tools or Talent (or Tools and Talent)
- Tools
- Talent
- Tools or Talent
- Conclusions
People work with tools to accomplish some objective. We use a hammer to put in a nail (and the claw side for removing a nail), a Phillips head screwdriver to put a very specific screw into the wall. Specific screw type and size, will require a specific sized screwdriver. You cannot effectively use a flat-headed screwdriver to install a Phillips screw. Not every tool item works, it is a poorly designed tool or a poor understanding of the problem it is intended to solve. Additionally, tools can be very selective in what it is able to perform, or a ‘unitasker’ (per Alton Brown Good Eats), by ‘unitasker’1 we mean can do only one thing.
Product development and project management likewise have tools. We may use a tool for building and tracking the project schedule, perhaps we choose a Gantt chart. We may have a time reporting system that tracks the hours applied toward some specific work breakdown structure element. For product development, we may have defect tracking as well as configuration management tools. The definition of these tools can be variable and adapted to meet the specific needs of the team, the project and the organization. It is even possible to find a tool that can perform many of the functions above such as product lifecycle management tools. Tools that cover a wide range of capability, may add complexity and certainly increase the amount of time and effort to integrate into the workflow.
Tool Selection
Optimally, the tool selection process should include the various departments or teams of the organization that will be expected to use the tool. It probably won’t be possible to meet all needs, a goal of 80% or better should be realistic. The goal is to define the attributes of the ideal tool from the range of users expected to use the tool, for example, is this tool a project management tool, a team tool, or a department level tool? All of these? Those that are part of the tool use should have some representation in the selection process. Experience indicates tools dictated from the executive or management level without a close knowledge of the workflow and work activities will be a tough sell to the stakeholders.
In fact, it is possible to experiment with a range of possible tool solutions as part of the selection process. We can use the Shewhart (Deming) cycle of Plan, Do, Check, Act (PDCA) for example. In this case, we select a tool from a prioritized list of probable solutions. We will Plan the introduction of the tool in a small trial, we will then use the tool for some time as part of the workflow (Do). Then, we will check the results of the execution. Are the results what we desire or is the tool inadequate? If the tool is acceptable, we will enact (Act) the change and introduce the new tool.
Complaints about Tools
We have been in twitter chats that say the team should be the sole arbiter of what tool to use. We think there may be times wherein this approach may be true, but to say this is always true, is myopic. A single team, where the work begins and ends, may be able to define the tool without any other team members of intersession from a corporate member. However, if the work continues in some way beyond that team, for example from design and development through manufacturing and aftermarket, the team’s perspective may be too localized to adequately select the appropriate that must apply across various work entities where work is shared.
Tool selection should start with desired outcomes, with input from all the potential users, working to understand the present workflow, and the desired end state workflow, which may be identical. What information should be reported, tracked? What format should the outcome be in? Discussion may lead to the best tool is a platform that has an enterprise focus and where modules can be added to meet specific departmental needs.
Figure 1: Process Flow - Supplier, Input, Process, Output, Customer - SIPOC)
Ultimately, the thread or workflow can appear like below, where the work is handed to another, then that customer will become the supplier to another part of the organization, building upon what was delivered to them by a preceding part of the organization. For example, the systems engineering group produces systems-level specifications (vehicle system interactions and performance), those specifications are then given to the component level engineers (for example and transmission controller) who write specifications for that individual system component.
Figure 2: Process Flow does not stop at one point in the organization.
Tool Support
It is important to note that there is more to the use of a tool than the purchase. Tools are supported by processes within the organization, either selecting a tool that works within the organization as is, or altering the organization in a way to allow for the maximum benefit. Failure to adequately address this the use, may result in errant use or more likely, lackadaisical use or no use of the tool at all.
Management has to commit to a critical key for Tool implementation. From the Quality world, PDCA Plan appropriate training, conduct the training (preferably hands-on), check the training worked, and take any corrective actions. Successful implementation is possible when having the users are involved from beginning to output. Thus, becoming talented with the tool.
Poor tool introduction is as bad as a poorly selected tool and in the end, we may end up with comments like this tweet: "*is* the work of satan, so this does not count as argument". Disclaimer: The view expressed in this tweet are not those of the authors. It is simply used to illustrate a point.
Talent can take years of experience to develop, which can be a large investment in time and effort. This experience is unique from individual to an individual especially when we think about the learning from this experience. For example, two people may have similar experiences, but the conclusions and specific learning or development can take radically different forms.
We assert, that without talent, any tools used will only provide a modicum of success or repeatability. Talent, trumps tools in our view, as talent can create tools or determine ways to execute with a suboptimum tool or even without tools).
Recently we were on a call with a potential client that provides a good example regarding tools or talent. The discussion was about specific tool availability. We said we do not have that specific tool, but, we have multiple team members with decades of experience in that specific tool, and the use of that specific tool, including setting the tool up and determining how best to apply the tool in the service of product test and verification work, which was essentially the scope of the work.
The assumption here is if the tool is physically here and available, we would have the talent to use it. But, during the call the client did say they had mixed results from other organizations, implying they may not have been using the tool appropriately. The other issue mentioned was that one organization had the tool (and apparently the talent) because they had a long lead time for availability.
Our bottom line is that tools are just objects developed to increase productivity but without talented individuals using them, the potential of successful outcomes is low, And given a group of talented individuals capable of using a particular tool, the sky is the limit.
Organizations are unique though there may be some commonality within an industry or domains, organization structure, philosophy of operation, and range of organization distribution and workflow can be quite unique from organization to organization. Tool selection is non-trivial, and implementation also requires considerable thought so not to alienate those that will be working with the tool. It is often said, that people are our greatest resource (we prefer talent to the word resource or asset), but the organization often acts contrary to this. The talent within the organization has a larger influence on the outcome than a tool.
Pick a good tool, implement it well, then the team’s work-life may become less stressful and more productive. However, do either of those things poorly, the results will not be as desired and the talent may take a hit to morale making the outcome worse than when started.
References:
[1] https://www.npr.org/sections/thesalt/2015/12/23/460833325/the-unitasker-kitchen-gadgets-alton-brown-loves-to-loathe last accessed 5/20/2020