The specifications of the deliverables broken down to their most basic components.
Requirements are different than goals and deliverables. That is, they help define how we know the goal or deliverable was completed successfully. If our project involved building a new car model, for example, one of the requirements might be body style or paint color.
As you might have guessed, requirements are a further breakdown of the deliverables that describe very specific details regarding the deliverable. One deliverable could have multiple requirements, while another deliverable may not need a further breakdown since its description is adequate on its own. As the project manager, you'll have to determine whether you have enough information in the deliverable description to produce the product or service or you need more information to make certain you meet the project requirements.
Defining requirements, and defining deliverables as well, should not be done in a vacuum. This is not the sole responsibility of the project manager. In fact, requirements-gathering is primarily a user or stakeholder function. The project manager should facilitate the process, but you really need your customer or stakeholder to tell you what you're building.
Requirements-gathering should be a group effort. Sometime shortly after the project kickoff meeting, set up a meeting or series of meetings to determine and document the project requirements. Primary stakeholders and key team members are the folks who should attend. Reserve a conference room with a white board and give yourselves plenty of room to spread out.
Remember to set an agenda for the meeting. I'd also recommend sending a copy of the project charter to all the people who will be attending several days prior to the meeting. This will give them a chance to review the project objective and begin thinking about requirements. At this point, ask whether other stakeholders need to be identified and included in the process. Now is not the time to forget someone important. There's nothing more frustrating than to have progressed a third of the way through your project activities only to discover that you forgot an important stakeholder back in the beginning and now have a new set of deliverables to deal with and squeeze into the project schedule.
Conducting the Meeting
Once the meeting has begun, review the project charter with the group. Ask for questions and clarify any concerns up front. Make certain, to the best of your ability, that everyone has the same understanding of the goals of the project.
Next, examine the deliverables (if they were defined prior to this meeting). Provide everyone a printed copy of the list you've compiled so far. If deliverables were not identified prior to this meeting, this is your starting point. Ask the participants to name the major deliverables for the project (or identify missing deliverables from the current list) and start writing them down. This is a simple brainstorming session where everyone is encouraged to participate and say anything that comes to mind.
You can use several other techniques, in addition to or in place of brainstorming, to get the requirements process rolling. (These techniques are applicable to determining the major deliverables as well.) One technique is to send surveys to the key stakeholders prior to the meeting, asking them to list their requirements. Or you could use an interview process if there are only a few key stakeholders involved. One of my favorite techniques is the sticky note process. Everyone in the room is supplied with a sticky notepad and a marker. Ask the participants to place one, and only one, requirement or deliverable per sticky note, being as precise as they can. You'll act as facilitator and gather the sticky notes, placing them on the white board as they're turned in. Eventually, a pattern will emerge, and you can group similar requirements together, eliminate duplicates, and so on. Tell the stakeholders to not hold back anything. They should list everything they could ever want or dream regarding this project at this stage.
Note:Requirements are the lowest common denominator and cannot be broken down further.
Requirements are the last stop in describing the deliverables and cannot be broken down further. For instance, a requirement for one of the deliverables in our move project might read something like this, "All moving cartons must contain labels on the top and one side."
Some other examples of requirements for the Logan Street Move are shown below:
When you're defining requirements, make certain to take into account business rules and policies. Abusiness rule is something that must occur in a specific fashion or is a result of a policy or regulation. As an example, a business rule for a financial institution might state that all loan requests over a specific amount must be approved by a vice president. A business rule for the building move project might say that only the IT contract employees may move the computers.
Here's where the lines begin to blur between deliverables and requirements. Deliverables may already be broken down to the lowest level, in which case you could consider them either deliverables or requirements. For example, the deliverable we listed earlier called "Connect and test all telecomm and network equipment by 6 A.M. March 4" really can't be broken down any further. The "Provide boxes and labeling instructions to all employees by February 7" deliverable, on the other hand, may have requirements associated with it including, "All labels must list the owner's last name and room number in the new building."
Again, don't get too hung up on deliverables versus requirements. The main point is that you document what needs to be done in order for the project to be successful. Remember that deliverables are the specific items or services that must be produced in order to consider the project successful, and requirements are the specifications of the deliverables or project goals. As long as you've diligently tried to uncover all the deliverables and requirements and then recorded them, you're well on your way to creating better project planning documents. Believe it or not, I've seen projects kicked off and conducted on nothing more than verbal requirements. Should I tell you all the gory details about what happened to those projects and the project managers working on them? No, I don't think so. Document the deliverables and requirements even if the project is going to take you only a day or two to complete. It eliminates misunderstandings and saves your bacon when the stakeholder comes back and says, "That's not what I wanted." We'll talk more about that in a coming section.
Save Good Ideas for Phase Two
Constraints to the project that are determined by company policy or institutional regulation.
You may discover new deliverables during the requirements-gathering phase or requirements that are considered "nice to haves" but not necessary for the completion of the project. You probably do not have an unlimited budget or unlimited resources, so the next and last step in the requirements-gathering process is to determine which requirements are necessary to meet the goal of the project. All others should be weeded out. But don't throw them out the window. Document these requirements as the phase two portion of the project, or ask the stakeholders to keep them on hand and request a new project when this one's completed. You went through a lot of hard work to flesh out everything desired for the project, so don't let those efforts go to waste. You could also consider filing a copy of the additional requirements in an appendix of your project notebook. This is not something I'd necessarily publish on the intranet, but the additional requirements should be kept somewhere for future reference. Now on to more critical issues.
Critical Success Factors
critical success factors
The project deliverables or requirements that absolutely must be completed and must be completed correctly to consider the project a success.
You have one more thing to document regarding your deliverables and requirements, and those are the project's critical success factors. Critical success factors include project deliverables, but not all deliverables are critical success factors. You should gain consensus among your requirements-gathering team and the stakeholders regarding which deliverables and/or requirements are critical success factors and then either document them separately or somehow indicate which ones are the critical success factors.
Some of the things I consider critical success factors for all projects include the following:
Critical success factors should not be overlooked. If circumstances come up later during the project that are outside of your control, forcing a schedule, scope, or quality change, it's important for you to understand which deliverables must be completed and which ones could move to phase two if necessary. This is where your critical success factors list comes into play. When you're faced with this circumstance, review the critical success factors with the key stakeholders and project team to make sure they still are critical to the project, and begin making project plan adjustments and taking corrective action from there.
Some of the critical success factors for the Logan Street Move might include those shown in the list below. Keep in mind that this is not a complete list, just a sample to give you an idea of why these elements were chosen as critical success factors.
The deliverable below is not a critical success factor. Here's the reason:
Now, suppose the floor plan mentioned in the noncritical deliverable above was also being used by the computer specialists moving and hooking up the computers. In that case, this deliverable now becomes a critical success factor because the specialists are relying on the floor plan to determine where each computer gets placed. I think you're getting the hang of it. Don't, however, make the mistake of assuming that the computer specialists have a network diagram with all locations marked. And that brings us to one more piece of documentation for the scope statement: assumptions and constraints.
Project Management Related Tutorials
|Business Analyst Tutorial||Strategic Planning for Project Management Tutorial|
|Software Development Lifecycle (SDLC) Tutorial|
Project Management Related Interview Questions
|Business Analyst Interview Questions||Strategic Planning for Project Management Interview Questions|
|Network Monitoring Interview Questions||Software Development Lifecycle (SDLC) Interview Questions|
|Business process outsourcing (BPO) Interview Questions||Project Manager Interview Questions|
|PMP Interview Questions|
Project Management Tutorial
Building The Foundation
Developing Project Management Skills
Initiating The Project
Defining The Project Goals
Breaking Down The Project Activities
Planning And Acquiring Resources
Developing The Project Plan
Executing The Project
Controlling The Project Outcome
Closing The Books
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.