Listening for needs, not requirements, to implement PLM/IT Projects.

When I first started running IT/PLM projects, over 10 years ago, I would often hear the software application does this and not that. Fast forward to today, I still hear the same comment from a different company, different people and a different implementation. The software requires engineers to do their job the way the software wants. For a long time, I did not know how to listen for needs.

Engineers, tech writers, quality engineers, buyers and/or even IT staff, when it comes to using applications, we don't know how to express our feelings, needs, and requests. And business analysts and project managers are not trained to listen for feelings, needs and requests. How can we change our approach to deliver better workflows/processes for the people using the software application?

On the right, I have outlined a three step process to successfully capture customer needs, not requirements.

If you would like to implement this process, please contact us. 

NVC IT/PLM Project Implementation Training

1. Learn how end users feel. Run through the current process for one week so you can truly appreciate what you are trying to solve. In every project I implemented, I released parts, drawings and I even did meshing (CAE) of a part. This allows me to see the steps and clicks and how data flows and I learn how the end user feels and where they are trying to get to.

2. Listen for people's needs. As you walk through the process, ask the end user or yourself, what is the need in this process? For instance, in PLM, designers have the bad habit of checking out files and not checking them back in because they don't want others to change their file. The person that releases the files to production needs the files checked in. So what do they need?  Designers need assurance their files won't be changed without their knowledge.  Change Specialists need the ability to verify all files are checked-in before they start the release process.  This process must be capable of doing this for 1 or 50 parts in seconds.  Does your process do this?  My implementations do.  

3. Listen for a request. Whenever we, IT, hear the words "I hate the software because it does not do this", we immediately become defensive and say "tell me the requirements, not the solution". Our focus should be trying to understand how the need in step 2 relates to the request in step 3. This is a request.  Customers have a need they are trying to satisfy with this request. Please focus your mind on reflection of what was asked from the application. If this is Friday morning and you need to release 100 drawings for the company by the EOB, you probably need everything to work with one click and perform actions in masses. When you hear a request from the end user, embrace it and find ways to make sure you understand the "need"!