Many executives and leaders make this mistake…
They ask their project teams for a project plan and timeline for a brand-new project.
Not an unreasonable ask; however, in many cases, teams are asked to plan projects without fully fleshing out the project goals, scope, and requirements.
Unfortunately, all too often, project requirements aren’t properly gathered, collected, vetted, and understood, which introduces huge risks to the project, and even increases the risk of project failure altogether.
When planning a project and ensuring you are gathering not only the correct requirements but complete requirements, there’s a lot to think about. There may be a long list of stakeholders to speak to, there may be unique acceptance criteria, and so on.
So what is the best way to get around this?
As part of the project planning process, ensuring that you are gathering requirements accurately is key. In this article, we will provide some tips on how to do just that. Here are some tips for how to gather requirements accurately to ensure sufficient project planning—and project success.
Defining Project Requirements
According to the Project Management Body of Knowledge (PMBOK) Guide, Seventh Edition by the Project Management Institute (PMI), a requirement is defined as “the condition or capability that is necessary to be present in a product, service, or result to satisfy a business need.” And while any good business analyst will routinely say they follow the acronym SMART (Specific, Measurable, Achievable, Relevant, and Time-bounded) there are other worthy considerations. Requirements can be very high level or incredibly detailed. Regardless of depth, requirements should be 4C-TV…
- Clear - Requirements are clear and cannot be interpreted in different ways.
- Concise - Requirements are written and communicated in as few words as possible.
- Consistent - Requirements do not contradict one another and are clearly documented and communicated through the project plan.
- Complete - Requirements represent the entirety of the project and business needs.
- Traceable - Requirements are represented by unique identifiers.
- Verifiable - There are clear ways to verify that requirements have been met.
However, before you can begin assembling focus groups and interviewing stakeholders, you first must define your project requirements. In fact, in many cases, gathering requirements might involve analyzing data, observing and auditing processes, and reviewing defect logs.
Anything less than this process introduces uncertainty and biases, and increases the risk of failure.
4 Tips for Gathering Project Requirements
Here are some tips to ensure you are gathering the right project requirements:
1. Begin with what is known and unknown.
It’s very common for project requirements to be unknown or incomplete, especially early on. Make a list of all the requirements that are known and those areas that are unknown. You can use a Requirements Traceability Matrix (typically used in waterfall) or a Product Backlog (typically used in agile). Then, make notes on how you will verify those known and unknown requirements.
For example, when speaking specifically about product or software development, stakeholders might take an “I’ll know it when I see it approach.” In these cases, developing a prototype or just a wireframe (I’ve used napkins to do this) might be necessary to help determine any unknown requirements.
2. Develop a requirements management plan (and supporting artifacts and documentation).
Gathering and collecting requirements is a huge step in managing and organizing any project, but all your hard work can go to waste if you aren’t properly managing them. The lack of a solid requirements management plan often leads to scope creep, which can open a can of worms.
A requirements management plan details how requirements will be managed throughout the project, including specific tactics and techniques for doing so.
Here are some of the different artifacts and documentation that you can start using today:
- Assumptions Log - a chronological list designed to record all assumptions and constraints throughout the project. This simultaneously also helps reduce the risk of bias. An assumption is anything we accept as true without evidence.
- Change Log - A comprehensive chronological list of all changes submitted over the course of the project.
- Issue Log - A British colleague of mine once told me I should use the British Issue Model which he described as “if you’ve got an issue, here’s a tissue.” All joking aside, issues are project level problems and should be handled accordingly. An “issue” is defined as a current condition or situation that arises over the course of a project that may impact overarching project objectives . Issues are then assigned to particular “owners” to monitor, resolve, and follow up on. Therefore, an issue log is a chronological list of project level problems.Lessons Learned Register - A prioritized list used to record knowledge gained during a particular phase or the project as a whole. Generally, we derive the bulk of our lessons learned by uncovering the cause of variances that occur between planned and actual results. Whatever caused the difference in the outcome is the lesson learned.
- Risk Register - A prioritized list that details and documents all identified risks, risk categories, processes, and team members who “own” or are responsible for the particular risk. The risk register is used to lodge both qualitative and quantitative risk analysis results as well as planned risk responses and contingencies.
- Stakeholder Register - A prioritized list that outlines all the pertinent project stakeholders, the classification of those stakeholders (stakeholder mapping), and other relevant information about them.
These are just some examples of the different types of artifacts that can be used to help elicit requirements and help manage them over the course of the project, usually in tandem with the Requirements Traceability Matrix.
3. Ask quality questions.
Now that you have the necessary artifacts set up, what’s next? Begin interviewing stakeholders, team members, assembling focus groups, and so on to really dive deep into understanding project requirements. However, holding meetings, interviews, and focus groups will only get you so far. If you don’t ask the right questions, then you will waste your time.
Asking the right questions will not only yield quality responses from your interviewees and attendees, but it will also help to reduce the risk of bias, clarify requirements, and reduce any vagueness or fuzziness. This means really getting down to the nitty-gritty of what the project deliverables are, stakeholders’ expectations of those deliverables and how they are expected to work, or even how they will be used by end users.
Take the time to prepare for focus groups, interviews, and any pertinent discussions regarding requirements with stakeholders. List key questions to ask them. These questions could vary depending on who you are interviewing and their role. Preparation will set you up for success. Some quick recommendations: interview only up to five people at once; focus groups should be between 6 and 24 people at most at a time; and surveys and questionnaires should be used with 25 people or more at a time.
4. Determine the best project management approach.
Remember that regardless of your best efforts at preparing for stakeholder interviews and focus group sessions, asking questions, and gathering requirements, not every project will have 100% certainty. This means you might have to adjust your project management approach.
For example, agile or more iterative projects often involve unclear or unknown requirements. Project managers can get around this by building small increments and then testing and reviewing them. The project team can also develop prototypes, which allows stakeholders to review and explore the project in a shorter timeframe and at a lower cost.
How the PMP Improves Your Strategic Thinking
Gathering requirements involves understanding the big picture and diving deeper into understanding how stakeholders and end users will use a particular product or service. This involves two different ways of thinking: critical and strategic.
As leaders, many look to us to be strategic thinkers. We must focus on the big picture and how to lead and empower the team to drive successful project outcomes. And as strategic thinkers, there is always room to improve.
But how do you change the way you think? Is that even possible? The answer is YES. How? By earning your PMP (Project Management Professional) certification. Taking the PMP exam will teach you various tools, techniques, and models to implement within your team and the organization at large. It will also enable you to use strategic thinking and critical thinking to solve complex problems and plan for the future.
Where to Find PMP Certification Courses
If you have never considered taking the PMP exam, then now is your chance to improve your leadership skills, expand your general project management knowledge, and learn some new techniques and models to adopt to accelerate team and organizational success. To ensure passing the PMP exam, consider taking a PMP Exam Preparation course.
Studying for the PMP exam by taking a PMP exam prep course will not only help you to understand the key concepts, principles, and material that you will see on exam day, but you will also have an opportunity to take a cloned practice PMP exam as well as additional questions about all modalities of project management,, boosting your chances of passing the exam on the first try!
So, where do you find the best PMP exam courses that ensure success? Look no further than Project Vanguards. Project Vanguards goes above and beyond simply providing you with a PMP exam prep course. You get lifetime access to our cutting-edge learning management system and opportunities to earn free PDUs for life to maintain your newly-obtained credential and keep it in good standing over the life of your career. Vanguards will even help you write and submit your application to the PMI® (Project Management Institute) by translating your real world work experience to the language of project management, regardless of whether you’ve ever been a project manager or not. In fact, most PMP’s have and will never be project managers, so anyone can do it! What are you waiting for?
Be dangerous, and start your journey!