Section 6.4. Identifying Project Requirements


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.

The IT Factor…
Square One: User Requirements

You might think that if you deliver a project on time and on budget that you've got a winner on your hands. Not necessarily. If the project does not meet user requirements, you've just spent a lot of time and money solving the wrong problem. When you're defining the project, the users (those who will utilize the project's deliverables) should be kept foremost in your mind. If not, your project may completely miss the mark. Then you'll have angry users/clients, a poor reputation, missed opportunities, and lots of wasted effort and dollars. A successful project is one that is perceived as successful by users, not one that simply meets the metrics and fails to deliver on user requirements.


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.

  1. Gather stakeholder and project sponsor requirements. We're assuming that the stakeholders are those who depend upon or will use the project's deliverables. Though we've identified three categories of stakeholders earlier, you don't necessarily need to involve everyone in this process. Typically, you involve the influential groups and perhaps key members of the involved group. Don't include any more than the bare necessity or you may end up with a large, unmanageable group that may never come to agreement. We're also assuming the project sponsor represents other key stakeholder interests such as executive or corporate requirements (profitability, time to market, etc.). The first step is to bring the approved project proposal to these stakeholders and gather a list of requirements. You may have to help user groups in identifying requirements, but avoid unduly influencing this group at this time. The optimal solution is an extensive list you can hone down to help you deliver a useful project.

  2. Compile stakeholder requirements. Compile all requirements so the project team can evaluate and discuss these requirements in an efficient, complete manner. Identify required versus optional elements (must-haves versus would-like-to-haves) so you don't get bogged down in unnecessary requirements.

  3. Review, evaluate, and select requirements. The project team should review and evaluate all project requirements. Begin with creating evaluation criteria that will help all team members make decisions based on the same factors. Also keep in mind that user requirements are sometimes "out in left field" if they don't understand the nature or scope of the project. You don't have to (necessarily) accept all user requirements, but you will have to defend your decisions, so make sure you are using clear, sound criteria for your decisions. Obviously, these criteria should be based on the elements already present in your project proposal including problem, mission, solution, target scope, timeline and budget.

    Once you've evaluated and sorted through all stakeholder and project sponsor inputs with the team, finalize the list of requirements you believe can be delivered in this project. Remember the four criteria we used in Chapter 2? They are logical, feasible, desirable, and affordable. Those can be used here as well. Are the proposed requirements logical? Are they feasible? Are they desirable? Are they affordable? While these won't be the only criteria you use, they can be helpful when deciding from among many choices. Also keep in mind that you and your project team likely have skills and expertise your users don't, which means you often have a better (or more realistic) view of what is feasible and what is not given a target scope, cost, time, and quality requirement. This is where your negotiation skills come in handy because you may have to educate or persuade your users to accept what is realistic rather than what they'd like in a perfect world.

    For requirements that don't meet the criteria you've established, you should decide whether these requirements should be put on hold (for further discussion, input, or future projects) or rejected for this project. Remember, none of this is etched in stone, but you don't want to revisit these decisions over and over again either. Place requirements either in the rejected or on hold category and be prepared to explain, negotiate, and justify your decisions to the stakeholders. Remember that the stakeholders are, by definition, the ones that will use or rely upon the outcome(s) of the project, so if you can't persuasively make your case for nixing these requirements, you may end up with a project that either fails to meet stakeholder expectations or is all over the map in terms of deliverables (too confined or too broad). Neither is a good place to land.

    Also in this step, you should gather all requirements that require further discussion, negotiation, or input from stakeholders and set a time to discuss these with stakeholders. When possible, ask very specific, closed-ended questions during this process. An example of a closed-ended question is, "How exactly do you use the toolbar in this application to find customer records?" This leads to a specific answer. An open-ended question invites further input, which at this point could lead you into an endless loop of additional requirements being added at each iteration. An example of an open-ended question in this case is, "What else do you need when finding customer records?"You may want this type of input and if so, ask away. However, if you got that information from the stakeholder during the first round of requirements gathering, asking again may yield different answers based on "wish lists" or a poor understanding of the IT process rather than answers based on what the stakeholder needs. This is a judgment call, but ask your questions with the end in mind so you don't invite a free-for-all discussion.

  4. Define primary and derived requirements. The primary requirements are those that were gathered from the stakeholders and agreed to by the project team, whether from the initial discussion or from subsequent clarifying discussions. The derived requirements are those that come from the primary requirements. For instance, a primary requirement might be data security and a derived requirement would be the storage of data in an encrypted format. You don't necessarily want to get into the detail of how you're going to ful-fill these requirements at this point, though there are times you might do that. For instance, if you know your data has to be encrypted and you're going to use the standard file encryption used in Windows Server 2003, you can add that to the requirements. Add derived requirements (even if they describe how) if they are clear, concise requirements for the project and stem from the primary requirements.

  5. Proposed project requirements. This is a document that should describe the proposed final project requirements. It's important to gain stakeholder agreement on this because this is what your project will deliver when it's all said and done. If you don't have agreement at this stage, you will likely run into scope creep, changing user requirements, and dissatisfied stakeholders during the project (you may run into those anyway, but at least you'll be doing what you can to avoid these pitfalls). If the stakeholders do not agree to these requirements, you'll have to go through another iteration of this process. While it might irk you to have to do so, keep these things in mind: first, business and markets change quickly and it's entirely possible some new data has come to light that should be included. It could be this addition makes your project far better than it otherwise would have been. Second, if you miss a key requirement (even if it's the fault of the stakeholder), it's better to know it earlier than later. You can incorporate additional or modified data at this point far more easily than you can once the project is underway. So, while you might cringe at the thought of another go-round in this process, keep the end result in minda successful project that you can be proud of. In Chapter 9, we'll discuss developing technical and functional requirements in detail and we'll look at the three rules of requirements: defined, discrete, and measurable.

  6. Modify or codify. If the proposed project requirements need further modification based on stakeholder needs, you'll have to go through steps 1 through 4 again. This time it should be shorter, but make sure you look at the proposed modifications alongside your current proposed requirements list. Avoid revisiting the same issues over and over and also try to recognize related issues. For instance, you might have a requirement for data security and a stakeholder wants to discuss user logins. These may be related and it might only take a modification or clarification to a current requirement rather than an entire review of requirements. If changes are made, check back with your original requirements to ensure you haven't inadvertently created a conflict ("add security, don't add security…")

    If the stakeholders agree, you should have them officially and formally sign off on this document (in whatever manner is appropriate to your organization). You may have to revisit these agreements later on and it's good to have this in black and white. Your job as IT project manager is to ensure that your project is meeting stakeholder needs and that your project is positioned for success. That means that not only do you have to lead negotiations on requirements, but you have to educate stakeholders about the process. You don't need to go into tremendous detail on how the whole thing works, but you should make it very clear to stakeholders that once requirements are agreed upon, it should take a major event to modify the requirements. You can help them understand this by explaining (briefly) how you create and manage the project plan as well as how changing requirements will impact scope, time, budget, and quality. You can also discuss with them your change control process so that if they do request changes later, they'll understand there is a formal process for doing so. It might not completely prevent changes to requirements down the road, but you can try to nip it in the bud. Later in this book, we'll discuss change management so you don't get run over by changing demands.

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."

The IT Factor…
Project Requirements Are Like A Healthy Breakfast

A project will get off to a much better start if you make a concerted effort to gather, manage, analyze, and document your project requirements. This is an often-skipped step that really is the foundation of a solid project for several reasons. First, if you know what your project must deliver, you clearly have a better chance of delivering it. Second, if you are clear about the project requirements, you can avoid (or minimize) scope creep later on. You will certainly have to negotiate, and that sometimes means taking some of the requirements and putting them on hold for a later revision or a separate project. The third reason is that a formalized list of project requirements that the stakeholders all agree to will help manage expectations ("Hey, I thought you agreed to include…") and increase stakeholder satisfaction later (no surprises, no gaps = happier stakeholders). While gathering requirements won't guarantee project success, it will certainly get it off on the right foot. And the opposite is also truewithout doing a thorough job gathering requirements, your project has a slim chance for success. You might like pie for breakfast, but you also know it's not the best way to start the day.


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.

6.4.1.1. 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.

6.4.1.2. 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.

6.4.1.3. 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.

6.4.1.3.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.

6.4.1.3.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.

6.4.1.3.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.

6.4.1.3.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

The IT Factor…
It's All About the Requirements

Successful entrepreneur and business owner, Chris Landi of Tekwork.com and BestJobsInTucson.com, is a firm believer in defining requirements completely before starting on project work. "If you define what the users need and what you can deliver and get agreement on that, you usually end up with satisfied users and a successful project," says Landi. "If you don't take time to agree on requirements, your project will miss the mark and your users will be dissatisfied. It's hard to recover from those kinds of mistakes." As a successful business owner, Landi's best practices include clearly defining user and business requirements and gaining agreement on those before starting project work.


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





How to Cheat at IT Project Management
How to Cheat at IT Project Management
ISBN: 1597490377
EAN: 2147483647
Year: 2005
Pages: 166

Similar book on Amazon

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net