Requirement-based Project Management

Almost all projects have requirement challenges to some degree, but some are more severe than others. If your project needs to cater to different groups of users, and the project requirements are not very clear to you, you are better off managing it as a requirement-based project. If you don’t have a systematic way in place to manage project requirements at the outset, all actions you take after the project begins can be described as reactive and unsystematic. Once project requirements get out of hand, your project will be on the verge of failure. Many project managers who cannot manage project requirements well encounter project failure because they underestimate the difficulty of managing project requirements at the beginning of the project. When project requirement management is in great confusion, they start to lose credibility and the trust of user groups and team members, which in turn causes other project requirements to get out of control and ultimately lead to the failure of the entire project.

All requirement issues can be attributed to people and communication. For example, if a project’s user base is adversely affected by a recent organizational merger and does not cooperate, the management of project requirements will become more difficult. In this case, personnel issues will adversely affect the effectiveness of requirement communication in the project. If there are no personnel issues or the issues are manageable, you can use advanced project management software such as  PPM to systematically manage the project requirements. In project requirement communication and management, the key point is to write each requirement in the right amount of words, add the number, and determine by everyone how to test the requirement before it is completed. The advanced project management software such as PPM can help you achieve these.

Common project requirement management problems:

1. Bad requirement

What is the definition of bad requirements? Requirements are bad if they are ambiguous, incomplete, unverifiable, etc. If stakeholders give you bad requirements and you document those requirements, you will end up with a system that is incomplete in many important aspects.

2. Conflicting requirement

When your project has more than 3 stakeholders or stakeholder groups, their needs must be managed. Since these stakeholders or stakeholder groups have different needs and represent different interests in the business, problems of aligning their needs always exist. For example, the business director wants the client to log in permanently (except for the client self-logout and the user idle timeout; the user stays logged in but does not set the idle timeout period), while another stakeholder on the project, the IT security director, suggested setting the idle timeout to 2 minutes. All these requirements cannot be met at the same time because of the conflicts between them.

3. Undocumented processes

You have to face the fact in one organization or another. Inadequately documented processes and procedures are a way of life for some companies. C-level executives think that everyone is doing their jobs in an orderly manner, but that is not the case. The actual details/steps of the process will vary from user to user.

4. Change priorities

For lack of a better word, I used the term "change priorities", but to put it more bluntly, "stakeholders keep changing their minds". This is a very common and rampant project demand phenomenon. A stakeholder presented a set of requirements, and next week, they will change the requirements.

5. Lack of access to end users

This challenge stems from customers and management who take it for granted. For example, stakeholders and IT managers may "think" they understand what will happen when the final product finally hits the market. Therefore, they do not allow you to access end users directly.

requirement management permits you to (i) identify and number each requirement, (ii) clearly identify who proposes and is responsible for each requirement and its priority, (iii) reach a consensus that needs to pass those tests before the requirement is fulfilled and (iv) setting a requirement baseline. Whether you are using agile, PMBOK or other methodologies, these 4 things are essential for requirement management, especially (iii).

1. Bad requirement

Use to make a list of functions and tests. It is a good idea to check this checklist for each requirement to ensure that all project requirements can be smoothly completed.

2. Conflicting requirement

Use to document and publish stakeholder requirements, schedule meetings with all stakeholders involved, and resolve issues when conflicting requirements are clearly understood.

3. Undocumented processes

Proper documentation is key. Use to note down all existing business processes and differences between different users. Provide the information to relevant stakeholders and higher management. If possible, within your job responsibilities, create and maintain an up-to-date library of existing business processes and operating procedures.

4. Change priorities

You need a change management process to document and publicize every requirement change and impact. If you don’t have a systematic process for handling requirement changes, you will end up with more changes because each change does not cost stakeholders anything and indirectly encourages them not to think so carefully in advance. Changes in requirements are not entirely avoidable. But you have to get people to think carefully at the beginning of the project and do their best to limit changes after the requirements are signed off. For unavoidable changes, you must use to accurately document and publish their impact so that project stakeholders understand the benefits and costs of the change.

5. Lack of access to end users

To deal with this challenge, you use to record and publish the resulting requirement data, and your powers of persuasion will come in handy. Show your case to project sponsors and convince them why it is critical to observe real users at work and understand how each activity is performed. Doing so gives you a clear picture of the types of problems your users face in their day-to-day work.