Discovering Requirements - Project Management

requirements

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 Process

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:

  • All labels must list the owner's last name and room number in the new building.
  • All computer equipment must be packed in specialized containers by the IT contractors.
  • Managers must indicate office furniture placement on designated forms.
  • All employees must update their ID cards by February 22 in order to access the new building.
  • Computer cables for each computer must be placed in a plastic bag and marked with the computer's identification number.

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

business rule

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:

  • Understanding of and consensus regarding the project goals by key stakeholders, project team, management team, and project manager
  • Well-defined scope statement
  • Involvement and buy-in from the stakeholders as evidenced by sign-off of the project charter and scope statement documents
  • Well-defined project plan (this includes all the documents you'd normally see for projects, such as the project schedule, risk management plan, budget and cost baseline, communications plan, and change control procedures.)
  • The use of established project management practices

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.

  • Move telecomm equipment, network servers, switches, printers, and desktops the evening of March 3 starting at 5:01 P.M.—This is a critical success factor because the goal of the project is to perform the move without disruption to customers. Normal business hours are 8:00 to 5:00; therefore starting at 5:01 prevents disruption. In addition, this task must start at 5:01 or the team will not have enough time to complete this deliverable and meet the criteria of the next deliverable.
  • Connect and test all telecomm and network equipment by 6 A.M. March 4.—This was chosen as a critical success factor to meet the goal of moving the employees without disrupting service to the customer. All equipment must be tested and up and running prior to the employees reporting for work the next morning. Since all company data, customer contact information, customer files, and such reside on the company servers, it's critical that employees have access to the server, via their computers. Equally important is the telecomm equipment being set up. Customers call in to the company, so the equipment needs to be up and functioning in order to place and receive calls.
  • Computer cables for each computer must be placed in a plastic bag and marked with the computer's identification number.—This critical success factor will assure that the computers are set up in time for employees to report to work because the cables and cords will all be kept together with proper identification so that the installers know which cables go with which computers.

The deliverable below is not a critical success factor. Here's the reason:

  • Obtain floor plans from the management team by February 1 showing employee placements.—This is not a critical success factor because it doesn't prevent the move from occurring. Furniture and boxes may end up misplaced and on the wrong floors, but since everything the employees need to access the customer accounts resides on the company servers, access to their books and belongings is not critical to the completion of the project. It may irritate some people if they don't have their things right away, but it isn't critical to providing customer service.

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.


All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

Project Management Topics