When do requirements need to be completed?
From the Requirements Blog
by Mike Frenette
Effective requirements collection, management and traceability plus smart PM practices equals project success.
Recent Posts
Planning. Linking to Strategy. Delivering.
It's all about the outcomes..... NOT the outputs.
Caution: Agile Surface May be Hot
Organizational Change Management: The Most Critical Requirement of All!
Rethink Requirements: The Natural Language Processing Approach
Categories
Business Analysis,
Complexity,
Data Models,
deliverables,
done/not done,
earned value,
Leadership,
managing change,
project activities,
project success,
project tasks,
Quality,
Requirements Management,
Requirements Management,
scope,
Strategy,
strategy,
traceability,
vision,
wbs
Date
People often ponder whether requirements for an IT project should already be in place before a project begins, whether they should be detailed at the front end of a project, or whether they should be refined as the project progresses. The answer is not simple, and has a lot to do with the sort of project you are running.
We would all likely agree that no project can even be chartered without some level of requirements being in place - high level business requirements at the very least. But it is a rare project that will kick off to the resounding thump of a multi-hundred page business requirements document. Most waterfall-type projects have the creation of the BRD as an early step in the project. Most Agile projects will have high level requirements, often in the form of user stories. And then there is everything in between.
But there's the rub. What apporach and methods are being used on your project? Is it waterfall? Is it one of the Agile approaches? Can requirements change while the project is in motion? Might such changes alter the direction of the project?
I would hypothesize that requirements can and do change on any project, regardless of the project methods being used. Remember the old requiremernts freeze? "You must sign here, and we will build what you have asked for. No changes wiil be permitted from now until project end." Seems almost hilarious now, doesn't it? The only freeze that would really be in effect is the one that freezes you out of any more work with that client.
So - still we are left with question, "When do requirements need to be completed?". The question itself might be a tad banal. Before we design, before we build, before we test... requirements must be clear. Do we need a 50 pound signed off document early on? Maybe... if we are designing and building software to run a space shuttle. But do we need it if we are only configuring an ERP package? Or designing a web site? Or might we need only story elaboration a bit at a time when we have a fully engaged and knowledgeable Product Owner?
As with most questions in this field the "It depends." answer pops to mind. It depends on so many factors, including contract types, that the answer will shift like the sand dunes on the Sahara.
It's getting cold in here. Must be those frozen requirements.
Posted on: May 22, 2015 11:42 AM |
Permalink
Comments (9)
Please login or join to subscribe to this item
anil kukreti
Senior engineer | Mobiquity softech pvt ltd
Ghaziabad, Uttar Pradesh, India
"Before we design, before we build, before we test... requirements must be clear. Do we need a 50 pound signed off document early on? " .. I think because of this , PMP Exam Trainers and manuals suggest think of big projects having budget more that 10 millon USD and having a schedule frame of more than a year. Please correct me if m wrong.
Salam Kalandos
Chief, Healthcare Technology Management - Clinical Engineering | US Department of Veterans Affairs
Chandler, Az, United States
As you go deep into project execution, you might find out that changes are needed that benefit the project and /or the end product. this is both expected and healthy however, the project plan have to structured in a way to allow for those changes and still maintain control over the project (i:e avoiding never ending project).
Navdeep Joshi
Sr. Consltant - CA PPM| TBD
Bangalore, Karnataka, India
Before execution, and anything that is not finalized should be taken up via the CCB, and only once it is approved and made part of the plan should it be included... NJ
Sujith Kattathara
Founder, CEO| FreelanceTeams Private Limited
Ernakulam, Kerala, India
Mike
The question is almost philosophical .. As you said rightly, the answer is "It depends".
If the Project delivery and Customer organizations have mature adoptions of Project management methodology and Software development methodology as appropriate, then I as the PM would not be very worried. We can always apply change control as we move forward with an unfrozen set of requirements. There may be additional costs incurred in case of rework, but if the Customer is fully cognizant of this implication, then maybe the PM can proceed.
But again, if there are very tight deadlines - possibly tied to government mandates or some End user penalties, etc - then I would again be wary of projects with volatile requirements.
In this scenario, I would try to go for prioritization of requirements - The specific requirements relating to the Government mandate and/ or End user penalty to be baselined first & delivered as part of the first deployment, and the remainder to be scheduled later. (How much later - depends!)
The Project delivery methodology to be used - Waterfall or Agile - also plays a significant part.
Theoretically, on Waterfall, all Requirements MUST be frozen before one proceeds to Design & Coding. However, any experienced PM would explore the possibility of fast-tracking & crashing schedules, before going back to the Customer with a recommendation.
Again, the Customer may need to be prepared to shell out more funds than planned initially, since both fast-tracking & crashing would likely incur additional costs - Fast-tracking by potentially increasing rework, and crashing by increasing the number of resources and the corresponding training/ induction/ communication costs.
It would be critical for a well-qualified & knowledgeable Customer SME to provide clarifications to the SRS/ Design team on almost all projects - But if the Requirements are not frozen, then this expectation would become a make-or-break decision for proceeding with the project.
One final thought that comes up is: What is the driver which necessitates the project to move forward with an unfrozen set of requirements? Can we (the Project team + Customer team) devise some work-around that can be used to temporarily hold the fort while we work in parallel to baseline the requirements? Which approach (short-term workaround + baseline + project start OR start project delivery with unfrozen requirements + later rework) would result in more risk/ cost ?
Bottomline: It depends.
Bernard Gore
Portfolio, Programme & Project Professional| NZ Police
Wellington, New Zealand
There's no standard answer - some projects take previously well known requirements, some will take the vaguest ideas and develop requirements within the project, and everywhere between.
José Félix
Project Manager| SAECON Proyectos
Toluca, Mexico, Mexico
Very interesting question Mike and the answer is never simple. I work in construction for pharmaceutical and industrial projects, I am just finishing the construction of new facilities for an external customer and guess what, requirements have not completed so far.
I do not know how are IT project but I suppose is kind of similar to build a new plant, when we think everything is finished, the owner think still is possible to include something more. These are real projects... this is real life...sorry for that!.
Usually it may not be possible to freeze all the requirements at the time of initiation of the project. However, it is preferred to freeze the high level function and flows. The world is changing with a very fast speed and users are so smart and they may not agree to the requirement signed two years ago.
Marcos Silva
Program Manager / Release Train Engineer| Philips
Campinas, Sao Paulo, Brazil
Mike, my friend...
My 2 cents contribution!
"It depends" is a perfect answer... For R&D I can add some insights. I mean, two dependency dimensions. It depends on business and lifecycle stage.
Business: This is the start point for all requirements. Every single requirement must trace to few business requirements. This ones shall be very clear before project begins. The nexts steps, depends... as you mentioned before.
Lifecycle: I run Advanced Technology R&D projects. At early stages we barely know almost a single requirement, we just do ideations and PoCs. At middle we get details about what customers want and then we can write requirements as stories. At end stages, we know exactly the numbers for performance requirements and we need some "pounds of paper". (Off course this is a bit more complex)
Gopal Sahai
Corporate Trainer| Self employed
New Delhi, Delhi, India
When a requirement being elaborated progressively starts becoming 'creepy', is the real job of a BA / PM.
Agile Abuse is Scope Creep.
Please Login/Register to leave a comment.
|
I saw someone on the street eating M&M's with a spoon.
- Jerry Seinfeld
|
