Andy JordanPresident| Roffensian Consulting S.A.Cherry Grove, AB, Canada
What does everyone think that the most common problems with requirements are? I frequently see stakeholders who don't understand the importance of accurate and complete requirements, and sometimes project teams who aren't very good at helping them to understand that importance, but what else do people see? Saving Changes...
Sort By:
Michael WoodProject Manager / Business Analyst / Business Process Improvement Guru| Independent ContractorGig Harbor, Wa, United States
For me, three of the most common mistakes are as follows:
- Failure to trace requirements (or groups of requirements) back to the organizations objectives as part of the business case in order to VET their value and necessity.
- Failure to perform high-level mappings to the data model early on in the discovery process.
- Failure to estimate each requirement through each stage of the development life cycle. Saving Changes...
Elizabeth HarrinDirector| RebelsGuideToPM.comLondon, England, United Kingdom
I would say making assumptions that aren't documented, leading to misunderstandings and errors in the build later. Saving Changes...
Abdulilah AngaaCrowne Plaza Project Manager (Riyadh)| RIDCORiyadh, Saudi Arabia
Stakeholders Requirements Balancing if you do not do that you are going to face a lot of conflicts.
Final user requirements if not considered your project is worthless. Saving Changes...
Matt LightResearch Vice President| Gartner Inc.Stamford, Ct, United States
Over-reliance on text-based requirements. Thorough illustrations (models and diagrams, interface mock-ups, even cartoons) help overcome poorly written requirements and low reader comprehension. Saving Changes...
Markus KopkoAI Enabler for Project & Program Mgmt | Founder PMotion.ai / The PM
AI Coach| PMotion.aiHamburg, Hamburg, Germany
just brainstorming; no particular order; not exhaustive:
-Reviewing Requirements without sufficient Collaboration
-Assuming Use Cases are allways sufficient
-Documenting Constraints as Requirements
-Inadequate or Non-existent Requirements Tracing
-Inadequate Tool Support
-ambiguous requirements
-(not all) stakeholders are sufficiently involved in the requirements process
-No adequate managements of the requirements after the initiation stage
-Not differentiating between capabilities, rules, project tasks, and design
-Allocating requirements too early to the applications they will be implemented in
-Losing Sight of the Original Vision
- Not analysinf and understanding the Business Process before defining (SW) Requirements
-just starting off without sufficient documentation and not Preparing a Requirement Management Plan first
... Saving Changes...
Juan Escobar LopezSenior Project Professional| ENELBogota, Cundinamarca, Colombia
Another some ideas are:
1- Failure to define Scope; sometimes the stakeholders aren´t clear with the scope.
2- Some managers aren´t capable to management the projects, it cost hours and hours of hard word, lost of time, lost of resources and so on.
Saving Changes...
arlene trimbleAssistant IT Director| Local GovernmentAlamo, Ca, United States
1. Failure to identify the appropriate project stakeholders who would provide the business need.
2. Failure to elicit from the business owner or stakeholders the requirements.
3. Failure to verify/validated with the business owner or stakeholders the gathered/written requirements.
4. Gathering requirements too early and by development time, requirements are dated already.
Saving Changes...
Cheryl LeeBusiness Analysis and Project Management Consultant and Instructor| Knowledge AdaptersThornhill, Ontario, Canada
Failure to plan out the business analysis activities prior to getting started. We are always flying by the seat of our pants throughout the analysis phase of the project which gives the perception that requirements management and business analysis is very hap hazard. While I understand that sometimes you don't know what you don't know, failing to map out your activities usually means missing stakeholder groups, not allocating enough time to create supplementary requirements documentation like models, not seeing dependencies between tasks usually leading to re-work...and the list goes on.
Fail to plan, plan to fail! Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
The common mistake is do not understand what a requirement is, which are the main division (product requirements and project requirements), and who is responsible to get them taking into account each division. With the new practice standard for business analysis the PMI has made a great work to explicit clarify the importance to take into account two separate roles (while the PMI is working on that from years ago). What is key is to understand that we ever get needs/wants/desires/wishes from stakeholders that we need (the business analyst) to transform into requirements (in fact, well formed requirements, as IEEE Std 1233). Saving Changes...
