Hello PM Community. I am working on my first NON-IT project. I am implementing an On boarding and Orientation Program for Human Resources. I am in the requirement gathering stage of my planning process. I know many of you do not feel that is the right term for non-IT projects (requirement) however, I am at a loss of how to record and assure the needs of each department are met without defining the requirement? I am also at a loss of how to assure I am including ALL requirements as I am not familiar with HR and its processes. Thanks for any advice you have. Amy Saving Changes...
Sort By:
Wayne MackRetired| RetiredSouth Riding, Va, United States
You may be looking for Workflow Analysis and User Stories. Understand Who is doing the work and how the work is passed from role to role. Don't worry about capturing all the requirements - it will never happen. Just define how the work happens from beginngin to end. Saving Changes...
Elizabeth HarrinDirector| RebelsGuideToPM.comLondon, England, United Kingdom
Why do people have a problem with using the term requirement for non-IT projects? You still have requirements on other projects, otherwise how would you know what to deliver against? I haven't come across that concern over terminology before, so if it helps your HR program to talk about gathering requirements, then do so. I've always felt it makes most sense to use the language that the company and project team understand rather than what is 'correct' in PM terms. Saving Changes...
John ColePM II| County of RiversideRiverside, Ca, United States
I completely agree with Elizabeth...use whatever terminology your customers/stakeholders/end-users/team members are comfortable with. In IT, we tend to think of something as "creating a Word doc" (because that's what it is)...one of my customers thinks of it as a "generating a report." So in my meetings, I refer to it as generating a report...when explaining something to the internal IT team, we "create the Word doc."
I also agree that you shouldn't worry about capturing "all" the requirements. I've done many business process improvement engagements. In each case, the most helpful things to do are: 1. Create a process map or workflow diagram of the existing process. 2) Create a dictionary of terminology (HR does have its own language). 3) Let users describe how they would change/improve the process (this, simultaneously, provides process improvement, user requirements and your "to-be" workflow). Also, as you talk to more people, they encourage you to keep adding missing components and people.
By doing this, YOU do not need to be an expert...you let the experts tell you how it is and how it should be....and when the final product comes - you look like an expert! Saving Changes...
"If you have an apple and I have an apple and we exchange apples then you and I will still each have one apple. But if you have an idea and I have an idea and we exchange these ideas, then each of us will have two ideas."
