reason. What impact would this kind of nebulous requirement development capability have on your project?
A. Little capability of validating the success or completeness of the project
B. Lack of confidence in the completeness of the project' s deliverables
C. Inability of the project sponsor to sign off on the completion of the project
D. Reduced stakeholders ' commitment to a timely project implementation
The critical path is the series of consecutive activities that represent the longest necessary path through the project. You use up 5 days with Task A, then 7 days with B, 10 days with C, and a final 5 days with Task E, for a total of 27 days. Even though Task D cannot fire off before Task A is completed, A D E only uses 13 days.
It does not appear that the customer' s correct size has anything to do with the screen and doesn 't belong in the list of requirements, unless the client would like to refine what the requirements are for this project.
You ' re missing certain requirements. Dor example, should the client be able to search on first name, last name, or both? Further, what are breakdowns on purchases and what percentages will you apply? Dor example, are you going to give a 5% discount for all purchases between $1 and $100, or are you going to give 10% for the same range? You have no idea what range the client is thinking about. Additionally, you haven' t identified any metrics by which you can measure the successful completion of each requirement. Further requirements refinement is needed before this project can proceed.
This requirements list is on the right track. The list denotes metrics by which you can describe the success (or lack thereof) of each requirement. There seem to be requirements that you ' re missing, though. For example, what does the client want the user input screen to look like? Should there be reports? What buttons should be on the screen? You can probably think of others. This is a good start, but needs refinement.
This requirement falls into the "impossible to verify" category, simply because there' s so much lag time between the time a customer moves and the time that he or she changes their address with you. The customer may not, for example, recognize that she must tell you she used to be a customer with you when she lived in a different location. There may be a practical problem with searching the database for a given name—for example, "Mary Jones"—finding an instance or two of Mary, and then validating that the person you have on the phone who now lives in Beaverton, Oregon is the same Mary that used to live in Tuscaloosa, Alabama.
Tasks A, B, D, and G represent the longest dependent path through the project, so the critical path requires 41 days.
You first identify project risks. Next, you attempt to quantify their affect on the project in some form of quantification method, and finally you develop a response to the risks.
Functional requirements are those that the computer system (in the IT project world) can perform, whereas business requirements are those business functions that the system can perform. Obtaining demographics data for a user, providing a web reporting screen, and even improving customer response times are all functional requirements (though improving customer response times falls a little bit in both camps).
The customer approaches you with a project. You are trusting the customer' s ability to correctly formulate and diagnose the requirements that he or she wishes to put into the project. You would not necessarily question the customer s sense of the area of business that they re involved in.
All of the action answers might help in redefining the project ' s requirements and goals. If you cannot apply a metric to a requirement, then the sponsor is likely to question how you can validate that you' ve achieved it. Likewise, if she cannot understand the importance of a requirement in context with the project, then you need to refine there as well. Requirements that don't play an essential role in the project should be considered for deletion, but this probably wouldn ' t change the project' s priority.
A periodic project requirements review process is a great thing to go through at regular intervals because it helps keep the project management team as well as the stakeholders and customers on track. You examine intended product' s delivery date, the product' s performance thus far, and the
budgetary requirements that you have left. The product ' s usefulness and deliverables should ve been ascertained at requirement development time, not as you re working through the project.
Clearly defined requirements allows you to focus in on what the project is really about, which in turn clarifies the project ' s purpose. The importance of the project or its perceived value isn ' t usually an outcome of the requirements formulation.
The critical path is the series of consecutive activities that represent the longest dependent path through the project. Since a risk to a step in the critical path could potentially increase the time it takes to get the step done, it can directly affect the project ' s completion date.
Periodic requirements review is a great idea because it matches your project activities up with what the original requirements were developed to be. You can quickly see where (or whether) you ' ve gotten off track.
The project ' s value—that is, how important it' s perceived by management, stakeholders, and perhaps even the corporate body at large—contributes to the team' s effectiveness, simply because team members feel like they ' re working toward something that ' s held in high esteem. No one wants to work on a project that doesn t mean much to anybody. That being said, picture yourself as a project manager for a project that' s going to update the internal piping in a sewage treatment plant. Chances are the overall corporate body isn t going to recognize the importance of your work, but stakeholders certainly are aware of what you' re getting done.
With poorly formed requirements, you' l l probably still know who the project sponsor is. However, without metrics to
measure your success, you have no way of knowing when the project ' s complete or how successful it was (though you might think you know). Nor is it necessarily possible to know who the stakeholders are. Stopping a poorly developed project in mid-stride can be painful to a company, but letting it proceed without correcting it can be even more painful.
You may never know all of the end users that going to be using the system, so you don t develop requirements that are designed to denote that particular feature. You are, however, concerned with well-developed requirements, because they can tell you when you' ve successfully completed a project and exactly what you' re going to do when you ' re in the midst of the project.
You ' re striving to develop requirements discrete enough that each represents a single step in the project plan, and each assigned some sort of metric to signal when it' s complete and how successful it was.
Risks are risks. If you' ve identified a risk but one that' s unlikely, you would be smart to document the risk as well as go forward and develop a suitable risk response should the risk actually happen.
The project ' s requirements and scope could be worded in such a way that the project sponsor could sign off on the project, and yet you still can 't identify any well-defined requirements.
Was this article helpful?