When you need to launch a website, you use a ready-made CMS system. When starting your own business, you can also speed up the process by utilizing franchises or using a requirements management plan.
When it comes to large and non-standard projects, programmers use frameworks, which are kind of constructors with ready-made functions that need to be adapted to the tasks set by the client.
Surprisingly, the same can be done in large businesses too. For this purpose there are complex sets of knowledge for launching projects, which can be adapted to your requirements, such as PMBoK.
What is PMBoK
PMBoK (Project Management Body of Knowledge) is an international comprehensive document that describes all possible nuances of any complexity project launching.
It is issued and maintained by the PMI (Project Management Institute). The official print and electronic editions are available in several languages, including Russian. The current version is the seventh.
Although the body of knowledge is often directly associated with the ANSI project management standard, this is not entirely true. The ANSI industry standard aligns with PMBoK only in terms of project management. The PMBoK guide contains much more information: over 600 pages in English and slightly fewer in the Russian translation.
The main thing to understand is that PMBoK is not a standard, it is just a set of rules. Being comprehensive and detailed, it is still only a document that can be followed or not.
Nevertheless, many large companies, including Russian ones, use PMBoK for planning management systems. It’s quick, simple, and in the end it is profitable.
Many ready-made business solutions developed on the basis of PMBoK are designed for use in Agile teams. PMBoK itself is not a methodology.
What is a Requirements Management Plan
The Requirements Management Plan (RMP) is part of the PMBoK manual and belongs to the planning process group.
RMP is the second section of the project management plan. Here are the general approaches reflected:
- who and how creates project requirements;
- how requirements are approved and agreed upon;
- how requirements are aligned with the project life cycle;
- how requirements are adjusted as the project grows and matures;
- how requirements are analyzed and documented.
Why is so much planning needed
The planning stage is generally the most important for any project. If critical errors are made at this stage, it can have fatal consequences.
A project can be formed by approximately this set of participants (everyone who affects it).
Different requirements may be formed due to the different views and varied understanding of the situation by each participant. To prevent this, it is logical to appoint responsible employees, assign their roles in planning, collect all possible requirements, as well as to analyze, categorize and prioritize them, test feasibility, develop specifications, documents, etc.
What types of requirements can be in the plan
Firstly, these are functional requirements, such as business functions or end-user requirements, if it is a specific product for consumers.
Secondly, these can be non-functional requirements: for example, quality requirements, ergonomics, efficiency, as well as limitations of use (compliance with industry standards and regulations, available budget, allocated implementation deadlines, and more).
Business requirements are formulated by customers, but it is important to realize that implementation is usually driven by more technically proficient specialists. Therefore, it is logical to formalize the relationship between the customer and the performer, and to conduct personal meetings or interviews in the presence of both parties to detect misunderstandings at once.
Regarding the balance of such requirements, an interesting analogy comes to mind. The result can be fast, high-quality, inexpensive, but you can choose no more than two options.
How requirements are collected
Briefs, surveys, and questionnaire systems are most commonly used to collect requirements from stakeholders. However, more sophisticated methodologies may be used in certain types of projects: brainstorming, seminars, focus groups, prototyping systems, associative maps, etc.
When collecting information, it is significant to determine correctly the circle of participants and rank their importance (priorities). The requirements themselves can also have a ranking system.
Before final approval, it is logical to optimize the requirements: find and remove duplicates, delete those that cannot be implemented, and so on.
The output of the collection procedure should include:
- requirements documentation
- requirements traceability matrix (RTM)
Requirements cannot include:
- specific architecture details
- implementation details in general
- project information (regarding the development process and team)
- testing and planning information
Please, note that the customer is not always the end user of the product. This needs to be taken into account and understood.
If you need more details, you can always refer to the original PMBoK. The primary manual is distributed for a fee, and can be found in bookstores or on the official PMI website.
How does the project requirements management plan align with Projecto?
It is easy. We have developed a universal project management system. Projecto is compatible with practically all methodologies. To confirm this firsthand, just take a look at the service’s demo version. It’s completely free!
