The Ultimate Guide to the SDLC

The Complete and Ready-To-Adapt System Development Life Cycle

  • Home
  • SDLC Principles
  • Articles
  • Table of Contents
  • Downloads
You are here: Home / Computers and Internet / IT Governance and the SDLC – Part 2: Upfront Requirements Elicitation

IT Governance and the SDLC – Part 2: Upfront Requirements Elicitation

By Victor M Font Jr Leave a Comment

IT Governance and the SDLC – Part 2: Upfront Requirements Elicitation
Public Domain Image from Pixabay.Com
When discussing investment opportunities at governance meetings, senior managers invariably ask: “How much will the project cost us?” In the early phases of opportunity talks many IT leaders respond with the “SWAG” (Scientific Widely Aimed Guess) based on experiential supposition. Later, after governance approves a deeper investigation into the cost, IT leadership returns to governance with a slightly more predictable estimate known as a ROM or Rough Order of Magnitude, based on nothing more than executive level discussions, the research they’ve done from talking to vendors and presuming what resources will be needed. They don’t even have enough information at this point to distribute a formal Request for Information (RFI). Returning to governance, they supply a statement of work documenting what they believe is required, a Return on Investment (ROI) calculation based on the ROM, resource plan and projected schedule. If all goes well, governance is convinced of the projected derived business value and ROI and approves the project—all based on conjecture.

Nobody up to this point has gathered any of the actual requirements from the business users. The discussions thus far have all been very high level. This is highly ineffective IT Governance in action. You may also say this is IT Governance inaction. Ineffectual governance processes often lead down the path of conducting requirements elicitation and analysis early in the project life cycle but only after the project is approved and funded. This is always a bad decision and one that leads to more problems for IT leadership down the line.

When Business Analysts start the requirements elicitation process after the project approval and kick-off, it doesn’t take too long to discover the original investment estimates were way too low. Now that the true business requirements are known, the project team realizes the scope to deliver the necessary functionality to the business is much broader than they first thought. As the project proceeds several months down the road, IT leadership goes back to governance and asks for more money to complete what they started and explain why the original timeline has to be extended. Governance either reluctantly responds to the increase in funding or trashes the project altogether. Whatever the case, IT leadership loses credibility with senior management.

Do you think this scenario is farfetched? It’s not. I’ve worked in organizations that have followed this exact process and have witnessed it time and time again. Senior leadership’s loss of trust and credibility in the IT organization is always the result. It is a difficult if not nearly impossible obstacle to overcome. Trust and credibility can be regained over time, but it takes a lot more than continuing with the same processes that got you into trouble in the first place. It often requires replacing the senior IT staff and embarking upon a long journey of IT business process transformation.

The truth is that questions surrounding IT investment and prioritization cannot be fully answered until at least one practice area of the SDLC[1] is executed and at least partially concluded. That area is performing the processes and practices governing requirements elicitation and analysis. This may also be known as a feasibility study. The question that now comes into play is “How deeply must I capture the requirements at this phase?”

The answer is variable depending on the project, but as a general rule of thumb, if we apply the Pareto principle to investment value and requirements, the resulting theorem says, “80% of the business value of an investment comes from 20% of the requirements.” This tells us that we don’t have to capture all of the requirements in the initial pass. We only need to capture the major requirements in a quantity sufficient to extrapolate a fairly accurate resource allocation and cost projection. A common practice is to pad IT project cost estimates with an additional 25% contingency anyway. By executing the requirements elicitation upfront, before project approval, you’ll provide much more accurate cost estimates, lower your contingency padding and reduce the chance of project overruns.

[1]System Development Life Cycle.
<= IT Governance and the SDLC – Part 1

UltimateSDLC.com runs on the Genesis Framework

The Genesis Framework empowers you to quickly and easily build incredible websites with WordPress. Genesis provides the secure and search-engine-optimized foundation that takes WordPress to places you never thought it could go.

Check out the incredible features and the selection of designs. It's that simple—start using Genesis now!

Click here to download The Genesis Guide for Absolute Beginners (PDF - 1.4 MB)

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Buy Now, Instant Download

The Ultimate Guide to the SDLC front cover
PDF eBook

$49.99

Add to Cart

Download Free Preview

$0.00Free Download

UltimateSDLC.Com is Hosted on SiteGround

SiteGround Web Hosting

Testimonials

Thank You for Your Testimonial

“…The author has truly “hit the nail on the head.” Whether you are an academic student who is aspiring to be an IT professional one day, a trainee that has just started career, a business & quality analyst and manager that has years of IT SDLC project experience—a must read for an IT professional at all levels of IT journey.” —Sekhar Bommana PMP, ITIL, VP – … Read More

Consulting Services

I have the prescription for your IT ailments

Implementing a SDLC is not an easy task. In fact, it can take months or even years to develop the policies, processes, procedures, metrics and training to bring you the kind of results that lead to repeatable project successes, reduced rework and deliverables that meet or exceed stakeholder expectations. There are a number of factors that … Read More

Connect with the Author

  • Email
  • Facebook
  • LinkedIn
  • Pinterest
  • Twitter
  • YouTube

Copyright Notice

Copyright © 2010–2023 Victor M. Font Jr.
Unauthorized use and/or duplication of this material without express and written permission from this website’s author and/or owner is strictly prohibited. Excerpts and links may be used, provided that full and clear credit is given to Victor M. Font Jr. with appropriate and specific direction to the original content.

Recent Posts

  • Managing Scope Creep
  • Agile Manifesto
  • Adaptive Software Development
  • Incremental Commitment Model
  • Legend of the Chicken and Pig

Recent Comments

  • Gold on The Project Management Method and the SDLC
  • Phineas on Adaptive Software Development
  • Victor M Font Jr on US Vee Model
  • Jessica Tattersall on US Vee Model
  • Aditi on IT Governance and the SDLC – Part 1

Tags

Affiliates Agile Best Practice Business Analysis Checklist Commission Elicitation Good Requirements Hybrid Hyrid IT Governance Model Organizational Change Outsourcing Project Management Quality Assurance Requirements Elicitation Risk Management SDLC Thought Provoking Waterfall Waterfall Variant

Return to top of page

Copyright © 2010–2023 Victor M. Font Jr.

Privacy Policy | Terms of Service | Contact Author | Report Erratum | Sitemap