It' s critical that you clearly understand the project requirements and write them down so that they are as clear to any other project stakeholders as they are to you. Your requirement definitions will, in turn, contribute to all the other project documents we' ve spent the last four chapters on and thus need to be very accurate, precise, well understood, and well documented. If they' re not, then the project is going to suffer from a poorly formed scope document and, in turn, the scope will creep because project needs aren't accurately being met. In this section, we' l l spend some time discussing the ramifications of analyzing your project requirements.
We' ve talked about success criteria (called metrics in this exam objective) a bit in earlier chapters. When dealing with such measurements, you' re asking the question: "What objective outcome can I expect once the project is finished and the system has been deployed?"
Suppose that your project will create an e-commerce system. Internet customers will submit orders using an XML-based order-entry page in your online catalog. The orders will then live in an enterprise-class relational database management system (RDBMS) as the database repository. What would be some of the metrics you might expect to be able to measure as a result of this project?
Well, if there never was an e-commerce site prior to the implementation of this project, perhaps one of your measurable goals would be to reduce by 30 percent the amount of telephone ordering that your company experiences. Since you don't have to staff your website with real-time customer service personnel, such a reduction in phone calls could bring about real savings through the reduced need for manpower and telecommunications hardware.
On the other hand, if you have an e-commerce site already, perhaps your metric might be to increase the speed of each transaction, from 5,000 to 10,000 transactions per minute, or to reduce the transaction processing cost, from $25 per transaction to $15.
When assessing outcome and success criteria, you ' re looking for specific, measurable things. In order to do that, you can lean on the customer for the information you' re looking for. Get the customer to be as specific as possible about what this system will do given certain conditions. Also, be certain that the metrics you' re using are accurate. Your ultimate goal is to formulate success and completion criteria that give you honest signals as to whether the project is complete and was successful.
Gathering customer requirements and fleshing them into a concise document with good objective outcomes you can measure is foundational to a great project. There are several components to a requirements document, and it should include some detail about how you arrived at each. By including these inputs to the requirements document, you are able to validate the information that has been given and spot any gaps in the project' s scope. In our Prestige Hotels case study, recall that one requirement is being able to get airline tickets from the qLines airline by using the Prestige website. But the customer ' s expectation was that you' d be done with the website in 180 days, and you were skeptical about the airline ticket deliverable because it might take you longer to work with a vendor who, despite having a strong relationship with Prestige, was still an outside party with unrelated interests. So you had to take into consideration the validity of the requirement relative to the estimated length of the project—an instance of the requirement helping define the scope.
Assumptions Remember that these are the things that you presume are true and will happen. Some examples of assumptions include the following:
■ Key project members will perform adequately.
■ The project plan is accurate.
■ The critical components will be delivered on time. Expectations An expectation is something that ' s typically customer- driven. The customer expects that this will happen or that will be an outcome of the project. In our Prestige Hotels case study, the customer had an expectation that the project would be done in 180 days.
Technical issues Depending on the nature of the project, your requirements document may be positively rife with technical issues. In the IT genre, you' d especially expect to run into technical issues if you were developing a project plan for a new software program or a new hardware offering—something that had not been ventured before. Along these lines, it' s possible that a technical issue might also find its way into an assumption as well. For example, you might have a technical issue that says, "The software created will be able to run on all Palm OS devices." The assumption that goes along with this technical issue would be "A Palm device lab is required for testing the software. The lab must be equipped with at least one of every Palm OS device." Industry issues Again, this is a very relevant topic in the IT world. Within this requirements document section, you point out items that pertain directly to your project and that are being affected by the industry. Perhaps one of the best-known examples in the IT world would be the effort to come up with wireless devices and software that are compatible with the Bluetooth standard. The industry has been slow to get involved with Bluetooth, so the computing public ' s acceptance of Bluetooth-compatible deliverables must be considered. It ' s really great if you' re one of the early-adopters of this standard, but the computing public may see your deliverable ' s Bluetooth compatibility as ho-hum.
Additionally, there may be other elements that you need to put into your requirements document that I haven ' t mentioned here. One of the primary elements is the issue of security. If, for example, your project involves creating an e-commerce website, one of your requirements issues will be to gather as much security-requirements information from the customer as possible. But the customer probably won' t have much of an idea about what might be important security-wise, so it' l l be up to you (or the SME assisting you) to develop proper requirements and then obtain approval of them from the customer so they can be built into the requirements documentation.
In a well-written requirements document, you want to distinguish the "nice-to-haves" that the customer is talking about from the "need-to-haves." This could be very challenging, because even if a requirement sounds good, it may be well out of scope for a given project.
I think it' s easy to get into this situation, especially when putting up a website. Perhaps the customer brings you a requirement that says something like: "Our database is updated nightly from www.similarcompany.org, and therefore we' l l have a linkage that will update our customer databases." Um, yeah. I've been in IT a long time, and this kind of requirement sounds like a maintenance nightmare, even if you can overcome the obstacles of getting it done, because you re relying on a linkage to a site that may or may not be up—that may or may not even exist. Listen, if it looks like a skunk and smells like a skunk, it' s probably a skunk. Be sure to keep a sharp eye out for requirements that could easily push the project out of scope.
There ' s no crime in noting things like this in the scope document as well, so that if someone brings it up later on, you ' ve already said that the scope would be inappropriately enlarged.
Can you develop tasks and activities based on the requirements list that you have? A good way to test the requirements document is to see if you can derive project tasks from the list. If not, your requirements are too vague— back to the drawing board.
We can talk about one step of a process acting as an input to another step—for example, requirements-gathering in the initiating phase is an input to the planning phase. Because of this, requirements that are poorly detailed or assumptions and expectations that are not correctly fleshed out can lead to disastrous results. In these cases, at a minimum you ' re guaranteed to deliver a product that doesn' t do what customer had hoped it would. The customer might want you to build a four-door SUV. When you drive up in a two-door sedan and hand him the keys, the look on his face will tell you right away that you didn' t understand the requirements. But it' s a little late then, isn' t it?
It' s wise to reinforce, with the sponsor and stakeholders, the importance of requirements definition. A clearly elucidated requirements document gets everybody singing from the same song sheet. Document the assumptions and constraints and share them with the project team. Distribute them to everyone on the project' s information distribution list.
A project kickoff meeting initiates the project meetings to follow. You should identify the value of the project and its expectations and justification here. You should be able to clearly get across to sponsors, stakeholders, and users the value of the project.
If you cannot specifically state what value the project has, then there' s a big question mark as to whether the project should go forward. By the time you' ve gotten to the requirements definition and have worked through the specifics of the project, if there isn' t a warm, fuzzy feeling in your bosom about the project, how can you expect others to feel warm and fuzzy about it? That ' s the whole point behind project management—to identify those projects that are worth considering and to conduct those worth implementing. Wondering about a project' s worth late in the game should prompt you to ask more questions. Don' t bury your doubts; get the information that will resolve them—or in an extreme, the information that will help you recommend that the project be shelved.
Having gone through an elaborate requirements-gathering process and having come out the other end demonstrating the project' s value should be the convincing point that others need to go forward with the project (barring, of course, matters outside the project' s control: in-fighting, politics, and such).
Was this article helpful?