Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Importance of early project requirements definition


Published on

This slideshow highlights the need to budget adequate time and resources to the requirements management process early in the project execution lifecycle and the importance of a mature requirements management process to ensure project success.

Published in: Business, Technology
  • Be the first to comment

Importance of early project requirements definition

  1. 1. • A reason why the requirements managementprocess tends to be often unstructured with arelatively shorter duration is because it isprimarily viewed as a documentation activity.• It is also seen to only have a supportive rolein the context of broader project execution.• The underlying assumption (albeit anincorrect one) is that there will be little materialimpact even if the requirements process isrushed through or that requirements can bedetailed out subsequently without any adverseimpact on the project.• This paper highlights the need to budgetadequate time and resources to therequirements management process early in theproject execution lifecycle and the importanceof a mature requirements management processto ensure project success.Introduction :
  2. 2. • The quality and capability of the requirements management process followed in anorganization can be essentially measured through the functional effectiveness of projectimplementation and whether the same was achieved within the defined budgetary andtime limits.• Studies conducted to assess the relationship between an organization’s requirementsmanagement process maturity and the success of projects indicate a strong correlation.• Moreover, there is statistical evidence of improvement in project performance metrics asan organization moved up the requirements maturity chain (IAG Consulting, 2009).• The lack of complete detailed requirements and a change management plan areconsidered to be the most common causes of project failure (Oberg, Probasco, & Ericsson,2000).Some Key Metrics :
  3. 3. Some Key Metrics :Requirements Discovery and Management Maturity of Organization.Source: Business Analysis Benchmark, 2009
  4. 4. Some Key Metrics :• The amount of time and effort an organization spends at the requirements stage variesbased on the size and complexity of the concerned project, but typically this is predicted tolie around the 10% mark.• However, this proportion tends to be on a much higher side when only projects thatachieved business expectations within the initial estimates of cost and schedule areconsidered.• A sample study in the telecommunication and banking industries indicated that mostsuccessful projects spent 28% of their resources on requirements management (Hofmann& Lehner, 2001).
  5. 5. Some Key Metrics :Requirements Effort versus Total Project Effort (Personnel Strength).Source: Hofmann & Lehner, 2001
  6. 6. Requirements Management in Product Selection Context :• An aspect especially relevant in a product selection scenario is the strong preferenceclients may have towards particular products and vendors.• The consequent impact in such a situation is that product selection dictates requirementsdefinition and refinement rather than business requirements directing product selectionand implementation.• Product biases may often be influenced by economic considerations, but it is more likelythat such not so well thought out choices may actually hurt even financially when a slightlylonger time horizon is considered.• It is true that in most instances, requirements cannot be fully defined at the beginning ofthe project and that may lead to some unwillingness to devote serious time on carefullydrafting out a comprehensive requirements document.• What is most necessary in this case is avoidance of a rigid insistence at the outset for afinal version and agreeing upon a basic criterion to move the work ahead withoutcompromising on the quality of effort spent on requirements investigation.
  7. 7. Requirements Management in Product Selection Context :• What this means is that requirements management in general and more particularly in aproduct selection context ought to be really well discussed out, and the views of allpotential parties that may be impacted by the new product have to be factored in.• It is obvious that multiple stakeholders bring the need to investigate diverse businessaspects, constraints and perspectives; so some critical pain areas need to be identified,agreed upon and prioritized for resolution.• Moving beyond the internal considerations, an external evaluation of the organization’sability is also essential and then a business case for further course of action may be builtaround the organization’s unique strengths and weaknesses.• The importance of having a comprehensive requirements package prior to productselection is covered in full detail in Maveric’s Point Of View titled “Importance ofRequirements Management in the Product Selection Process”.
  8. 8. Requirements Management in Product Selection Context :• The next step in the requirements management lifecycle is building further upon theagreed scope and needs to identify specific players who will co-ordinate on various aspects– business, technical and administrative.• The requirements gathered may have to be refined through additional questionnairesand interviews and the channels and protocol for multiple rounds of communication mustbe clear.• The point that needs to be emphasized here is every bit of energy expended at this stageis worth it because of its potential to prevent huge rework at a later point.
  9. 9. Pitfalls of Improper Requirements Management Process :• An improperly and arbitrarily conducted requirements analysis process may not onlylead to non-fulfillment of functionality due to inaccurate choices of products andimplementation mechanisms but also cause significant budget overruns.• Studies indicate that about 70% of quality related defects are introduced at therequirements and design stage but a majority are detected only at user acceptance stageleading to a sharp credibility question (Hewlett-Packard, 2008).• Such delayed realization may lead to more than 50% higher redevelopment andmaintenance costs (IAG Consulting, 2009).• It is no surprise then that organizations at a higher requirements maturity leveloutperform peers significantly on the return on assets (ROA) parameter.
  10. 10. Pitfalls of Improper Requirements Management Process :
  11. 11. The Importance of Non-Functional Requirements :• One of the key aspects of requirements definition that gets overlooked is non-functionalrequirements (also referred to as “ancillary requirements” by author Mr. MuraliChemuturi).• Key aspects include performance, scalability and reliability related requirements.• When non-functional requirements are being specified, it is important to ensure thatfuture business needs are factored in and the right stakeholders are involved in thisprocess.• While business users would be best positioned to weigh in on performance andscalability related requirements, portfolio and enterprise architects should be roped in toprovide their views on other aspects including reliability and backup related features.
  12. 12. Conclusion :• Finally, it is important to underline that a mature requirements management processand excellent requirements analysts together only can form the potent mix to lay thefoundation of successful achievement of business goals.• A deficiency in either process or people is a setback, and both these facets need thesupport of a strong intent to devote time and energy.• Requirements management is not just a static documentation exercise but anevolutionary activity that needs a committed, structured and dynamic approach.
  13. 13. Bibliography :• Hewlett-Packard. (2008). Reducing risk through requirements-driven qualitymanagement: an end-to-end approach. Hewlett-Packard Development Company, L.P.• Hofmann, H., & Lehner, F. (2001). Requirements Engineering as a Success Factor inSoftware Projects. IEEE Software.• IAG Consulting. (2009). Business Analysis Benchmark.• Oberg, R., Probasco, L., & Ericsson, M. (2000). Applying Requirements Management withUse Cases. Rational Software Corporation.