6.4. Identifying Project Requirements
Let's start with the most basic statement about your IT project's requirements. The definition of requirements is "something that is obligatory or demanded; something that is needed for a particular purpose." Requirements are what someone is going to hold you accountable for delivering through your IT project. That someone is the key here because projects have various stakeholders. As you just learned, stakeholders are those people who have a vested interest (of one type or another) in the project. For instance, users, corporate executives, and the project sponsor are common stakeholders. As you talk with stakeholders, your requirements will begin to form. As you begin to define your requirements, you may identify additional stakeholders.
If the project does not meet user requirements, the project is, fundamentally, a failure. Keep in mind that users are defined as those people who use or rely upon the results of your project; so the project must meet their needs, or it's a failure by definition. It's important to learn to listen effectively when talking with users (we're defining users here as those who will use the result of the project). The project should be solving the user's problem(s), which is not always the problem you think the project should solve. Keep that in mind as you develop project requirements. There's a story about a police mobile radio project where the police say there's a problem with the radio. The engineers look over the radio and the specs and find nothing wrong. They talk to a police officer who says, "The problem is that when I hit a suspect with the radio, it breaks and then I can't call for backup." Clearly, the mobile radio was not designed to withstand impact, but that was the reality of the situation. Sometimes when the police were caught off-guard and had nothing else handy, they'd use the radio handpiece to subdue a suspect and it would break, making it impossible for the officer to then call for backup. The manufacturer changed the specs for the handpiece so it could withstand greater impact. Regardless of your opinion about the use of the radio handpiece as a weapon of self-defense, the point is that the radio project had not fully taken into account the users' real-life application. The result of the project (the original mobile radio) did not meet users needs and was seen as a problem by the users. As you develop user requirements, try to suspend judgment until you fully understand the user's needs and expectations. Only then can you begin to develop requirements that meet user and business needs.
User requirements are not the only requirements a project has. Think of a situation with which many of you are familiarthe project in which users continually request/demand new features and functionality, even while the project is in progress (also known as scope creep). Hypothetically, you could spend millions of dollars and thousands of hours trying to meet changing or evolving user requirements and put your company out of business in the process. You have to balance the needs of the company, the market, and the users to find the right set of project requirements. Simply meeting user requirements is not adequate, but meeting corporate requirements such as profitability or time-to-market without fulfilling user requirements is a waste of time. You might think that we're talking in circles here, but we're not. The key is to identify and work with stakeholders to define the optimal set of project requirements. It's often helpful to differentiate between must-have and would-like-to-have requirements because users' wish lists can get rather long. Identify the must-haves as deliverables and keep the would-like-to-haves as optional components (sometimes you can include several desirable features along with a required feature with no extra effort). The two key groups you'll need to work with are the users and the project sponsor because we're assuming the project sponsor's requirements reflect those of the corporation, which include financial, timeline, and market requirements. The key is to define requirements as quickly and as efficiently as possible and then generate a list of requirements that are manageable and measurable. Figure 6.5 shows the iterative process you can use to gather and refine project requirements.
Figure 6-5. Iterative Requirements Gathering Process
Let's take a look at each of the steps involved. Again, if you're not a fan of flowcharts, you can read through the following text and gain the same understanding of the process.
We keep saying IT project management is an iterative process and here's a great example. You now have this wonderful list of user requirements. The question is, how have these requirements impacted your original estimate for scope, time, cost, or quality? Has the scope increased (or decreased) significantly? Has the amount of time required to deliver on these requirements changed? Most often, you'll find that things have expanded. If so, you'll have to adjust something. Remember, there is a relationship between scope, time, cost, and quality and if you modify one, something else has to change as well. If you increase the scope, you have to increase the time or cost or reduce the quality. Also, if something has changed, it's much easier to go back now and request more time or money (the two most common requests) because you now have a concise list of requirements rather than a more intangible "project concept."
6.4.1. Managing Requirements
The reason you gather requirements before you even get into the task planning stage is that the later in the project process changes are made, the more expensive they become. If you recall our discussion from Chapter 1, you know that an estimated 50% - 70% of the total cost of any project is due to errors, omissions and rework. Sound familiar? By doing a thorough job on the requirements gathering and by gaining critical agreement for the project's requirements, you can reduce the cost of your project simply by avoiding some errors, omissions, or rework. You won't avoid all of them, but any reduction at this point is a good thing and will translate to the bottom line.
126.96.36.199. Timing Issues
Another important thing to keep in mind as you're developing your requirements is that you will almost never have 100% certainty as to the project's scope, requirements, etc.. You may feel confident, you may feel certain, but you may never feel like you have everything in place to move forward. That thinking style is common in the analyst work style we discussed in Chapter 4. These kinds of people often allow uncertainty to stop forward progress. At some point, you have to fish or cut bait, so if you (or members of your team) have a tendency to wait for additional data before proceeding, you're going to have to manage this tendency. In business, there is rarely a perfect moment when you have 100% of the information you need to make a decision or to move forward. Some people use an 80% metricif you have about 80% of what you need, you can proceed. Waiting for perfect data can cause analysis paralysis and cause your project to sit in idle too long (or forever).
The flip side to that argument is that there are also times when it's best to wait. We can all think of situations where, in retrospect, we realize that if we'd waited we would have had a better outcome. This is typical for people in the doer category discussed in Chapter 4. These folks tend to jump in and get things going and if they plan at all, it's often after the fact (the popular "ready, fire, aim" technique). These folks probably have the most experience with the feeling of "if only I had waited a day or two." Sometimes data does evolve or come to light more slowly than we'd like. You'll need to find a balance between waiting for perfect data, which may never come, and jumping in too quickly without all the necessary information. Sometimes only hindsight will tell you if you made the right decision, but if you're cognizant of these two extremes, there's a good chance you'll find an acceptable balance.
188.8.131.52. Change Management Issues
We'll discuss this in more detail later, but this is a good place to introduce the concept of change management. We mentioned this briefly earlier in this section, but it bears repeating. Once you have agreement on the requirements, you should educate your stakeholders about the change management process. If you haven't yet developed your project processes (discussed later in this chapter), you can discuss the change management process in general terms. Stakeholders must understand the impact of change on a project. If you recall that scope is a function of time, cost, and quality, then you can help your stakeholders understand that if they increase the scope, something else will have to change to accommodate that increase. If they understand that the elements are interdependent, they can understand the implications of the changes they are requesting. While you may not always win, you will be better positioned to explain how requested changes will impact the project. Sometimes those changes will require that already-completed work will have to be scrapped. Other times it means those changes will delay other parts of the project. Sometimes requested changes are so significant they completely change the nature of the project. As the IT project manager, your job is to help stakeholders understand the impact their requested changes may have on a project and help the key people make decisions about how to proceed. Often these decisions are not yours to make, but you must facilitate the process of making smart, savvy decisions for the project IT department and for the business.
A long series of small changes can be as devastating to a project as one or two major changes, so don't allow small changes to be made to the requirements outside of the formal change management process. Educate both your stakeholders and your project team that the only changes made to project requirements are those that go through the formal change management or change control process. This helps you avoid situations where a casual conversation over coffee or after a meeting between a stakeholder and a project team member results in several changes being made on the fly. While both parties might think these changes are small and insignificant, they often can and do have a major ripple effect.
184.108.40.206. Categories of Requirements
Before we leave the topic of requirements, let's briefly talk about different kinds of requirements. It's possible that even after discussions with stakeholders and the project sponsor that there are additional requirements needed for the project. This is where your expertise and the expertise of the team come in handy. For instance, there are numerous examples of projects that may have legal, financial, regulatory, or technical requirements. Though we'll deal with project specifications separately, requirements might include such things as compliance with Sarbanes-Oxley (financial) or HIPAA (health care) regulations. Hopefully, one of your stakeholders has brought these to your attention, but this is a good time to step back and look for other requirements that have not yet been included. If you find any of these kinds of requirements, you should bring them back to your stakeholders for formal approval. This will ensure that you're not introducing complexity where none is needed, but also helps ensure the final project will meet all requirements. For instance, it's possible (though unlikely) that stakeholders and a project sponsor neglect to mention the requirement for HIPAA compliance in the software solution you're discussing. Perhaps they all assumed it was known because to them it was so obvious that they failed to mention it. If you discover requirements after the fact, go back through the process to gain formal approval for additional requirements. We won't cover all possible categories, but this list should get you started in your discovery process. Keep in mind that requirements are not specifications. To use a very tangible example, a requirement might be, "The car must stop within 60 feet of the application of the brake when traveling at 30 mph." A specification might be the thickness of the brake pads or the viscosity of brake fluid that will be used to meet the requirement(s). We'll discuss specifications later on. We'll also discuss functional and technical requirements in more detail in Chapter 9.
220.127.116.11.1. User Requirements
User requirements are often synonymous with stakeholder requirements since users are defined as those who will utilize the deliverables of the project. However, it never hurts to list user requirements so they're not forgotten. A good example of when user requirements are not part of stakeholder requirements is when corporate executives decide that the entire network infrastructure of the company should be upgraded and managed by a third-party company. The project that will make this happen may not take into account the front-line users who may have specific needs in terms of infrastructure. Perhaps users need wireless access or a simpler logon process. These may not initially be part of the stakeholder or project sponsor requirements, but they certainly come into play when planning the project.
18.104.22.168.2. Business Requirements
Clearly the project sponsor is the one who should be representing the business interests of the company, but there are times when that's not the case. Ensuring business requirements are met is an important element of your job as IT PM and whether your project sponsor covers it or not, make sure these are included in your project. Business requirements can also include legal, accounting, or other requirements that must be met by this project.
22.214.171.124.3. Functional Requirements
In Chapter 9, we'll discuss functional requirements in more detail, and at this point in your project planning process, you don't necessarily need to dig down into the details of functional requirements. The requirements you define are likely to be functional requirements because users (the typical majority stakeholder) often define project requirements in terms of what they need the result to do.
126.96.36.199.4. Technical Requirements
Technical requirements are often derived requirements because they are based upon the primary requirements set by the stakeholders. It's possible, though unlikely, that stakeholders will provide technical requirements. More often they'll define functional requirements ("we need it to do this") and your project team may then identify technical requirements from those. We'll discuss this in more detail in Chapter 9
Figure 6.6 shows the result of this step is a list of all agreed upon requirements and formal acceptance of these requirements. If the requirements are lengthy, they can be referenced in the project plan and attached as a separate document, but ideally the requirements should be clear, concise, and included in the body of the project document. It's possible you'll need to develop more detailed requirements (both functional and technical), but at this stage, high-level requirements should be stated and agreed upon. Once you gain agreement on these, you can develop additional detail and gather agreement on the next iteration, if needed.
Figure 6-6. Project Requirements