Project Management - Sample Questions and Answers

 


1.1. On a multinational project, which factor is most critical to efficient work?
In the decreasing order of criticality:

1 Understanding cultural differences
2 Clearly defined expectations
3 A team-building focus
4 Common project lexicon.

1.2. What is the importance of requirements gathering?
It is not a requirement if you cannot afford it. Do not lock yourself into a set of requirements until you are sure you have a design that will satisfy them. On developing a return on investment (ROI) analysis for your system and its requirements, it is important to recognize that: An ROI analysis is based on both benefit and cost estimates. Benefits are best estimated from the requirements, which tell you what the system will do for the users, and how well. Costs are best estimated from the design, which tells you how the system will be built.

Requirements and their successful management are inextricably linked to the project success. Requirements are the foundation for almost all systems development activities to come. They are like an architect’s plans for a building: If the plans are wrong, the builders will construct the wrong building. But an architect’s plans can only be correct if he has gone to the trouble of finding out exactly what the building owner wants, and the building’s intended use.

We are using the term requirements to mean more than the requirements specification document. Most of the effort does not go into the writing of requirements, but into discovering them.

1.3. How do you test the requirements?
A requirement that cannot be tested is not a requirement. When you have a requirement along the lines of “the product shall be user friendly,” you must find a way of making it testable. Keep in mind that the requirements may be correct according to whoever originated it, but not stated in a measurable way to make it testable. Good requirements practice entails you test requirements to ensure they are within scope, testable, not frivolous, and meet whatever other quality measures you implement. Always test requirements before making them part of the specification.

Good requirements practice also means you write your requirements to include a fit criterion. A fit criterion is a measurement of the requirement that enables testers to precisely determine whether the solution meets, that is, fits, the requirement.

1.4. What are the reasons for investing in requirements?
Several reasons exist for investing in requirements:

• To build the right product.
• To shorten the delivery time.
• To find the right product for the long-term operational or sales success.
• To take advantage of the products of requirements engineering to help guide the project by making more informed decisions.
• To discover a better product.
• Good design is a requirement, for example, iPod design.

1.5. What are some of the risks related to investing in requirements?
The following are some of the risks related to investing in requirements:

• Not knowing the requirements
• Putting too much effort into requirements
• Being too formal with the requirements and the specification
• Being too casual
• Becoming bored with the requirements process.

About 60% of software errors are requirements errors.

1.6. What are the project groups’ major concerns about stakeholders in discovering and specifying the requirements?
Project groups’ major concerns about stakeholders are the difficulty of involving the right stakeholders in discovering and specifying the requirements. The most common problems are:

• Commitment - People with authority (business and technical managers) do not commit enough time/budget for requirements.
• Skills - Stakeholders do not have the skills necessary to participate in the business of gathering requirements; they describe solutions not requirements, and do not understand their work well enough to describe it.
• Discovery - We cannot discover all the appropriate stakeholders, and subsequently miss requirements.
• Maintaining involvements - We cannot keep the stakeholders interested and involved for the duration of the project.