Linda, I don't focus too much on the deliverable part of it, but do try to make sure that traceability exists.
1. I want to be able to validate that all my Requirements have a way to be satisfied (through an activity, task, work package etc.). For example, a functional requirement for an IT application has corresponding Development/Configuration/Testing etc. tasks associated with it. This validation helps me to ensure that all my Requirements are being addressed and there won't be gaps
2. I want to be able to validate that all my activities/tasks/work packages are originating from a Requirement. This validation helps make sure that we are not doing any work that is not required.
I simplify as: Is it necessary? and Is it sufficient?
As for tools: At the present time, I am working to implement Traceability using a tool called JIRA. I have created a hierarchy of task types to help me with this. Using JIRA helps me solve various things at one time and I feel it is much easier to manage than a spreadsheet/word document if you have requirements in the 100s Saving Changes...
Linda ZinnDirector, Enterprise Project Management Office| FlightSafety InternationalRutherford, Nj, United States
Thanks, Samuel. JIRA looks like an agile/scrum toolset for the development team. Our IT Team is currently using TFS (which is clunky and not user friendly how we have it deployed). I am hoping to find a COTS solution that focuses primarily on the requirements piece and isn't tied to a methodology like agile. We're attempting to use the RTM concept on all of projects (IT and non-IT) and I would like to create an enterprise database of requirements that can be reused.
...
1 reply by Bob Thomas
Jul 26, 2019 3:11 PM
Bob Thomas
...
Hi Linda,
One place I worked attempted to create a requirements database. We had developed a complex enterprise-wide solution for the insurance industry. There were thousands of requirements. After much effort, we learned that the database would not deliver the value to offset the maintenance cost. We discovered requirements evolved over time; they were superseded, or sunset, and technology changes impacted some. It just wasn't worth the effort to maintain the database.
The primary advantage I had with JIRA was that the Development team was using it i.e. we had already purchased it.
What I did was simply to recognize the power of the tool in simply managing work - so many tasks and issues, keeping the details straight, carrying over changes in one thing to everything else that gets impacted, etc... With categorizations, alerts, reporting etc. etc., JIRA offered so much power. So we started using it for cross-functional issue tracking replacing the hard-to-manage Excel approach.
From my experience, JIRA is not tied to a methodology... we can customize it for many things. (Understandably, there can be resistance in creating a separate structure, adding non-IT users etc., but in our case the Exec team pushed for it – since our mis-management of issues was directly causing project delays).
Our organization has also used Atlassian's Confluence as a complementary Requirements Management tool. (I don’t fully understand where Confluence ends and JIRA begins.)
Hopefully there are other ideas in this community that we can learn from. Saving Changes...
saurabh mahajanPMP, ITIL, PRINCE2| vodafonePune, Maharashtra, India
IBM rational team concert is one good tool for your purpose but licensing will be costly.
Plus my vote for JIRA as well. Saving Changes...
Seema SonkiyaHead Business Analysis Practices, PMI-PBA trainer| iZenBridge Consultancy Private LimitedJaipur, Rajasthan, India
Linda, structure and format of RTM depend on many factors like project life cycle, culture, and environment.
Saving Changes...
NAVANEETHA KRISHNAN BALRAJManager Project Management Office| Saxon InfotechNew Market, MD, United States
I'm looking for a bi-directional requirements trace-ability matrix template. Appreciate if someone can help me here! Saving Changes...
Anton OosthuizenSenior Business Analyst / Project Manager| Self EmployedPretoria, Gauteng, South Africa
Linda yes I use it all the time and the key to a good traceability matrix is that is must allow you to.... yes trace the requirement back to its origins. So the number of elements that you would maintain in your matrix will vary depending on the type of project i.e. development, software upgrade etc. I typically make sure that I know who raised the requirement, department and function. Then for each step in between, I would have the reference and the status i.e. Jira number, User story number, Test Case number and so forth. So for any requirement, I can see from the matrix exactly where it is at but more importantly, where it was. But each situation might be different since you might use different processes and tools to manage requirements. Saving Changes...
Thanks, Samuel. JIRA looks like an agile/scrum toolset for the development team. Our IT Team is currently using TFS (which is clunky and not user friendly how we have it deployed). I am hoping to find a COTS solution that focuses primarily on the requirements piece and isn't tied to a methodology like agile. We're attempting to use the RTM concept on all of projects (IT and non-IT) and I would like to create an enterprise database of requirements that can be reused.
Hi Linda,
One place I worked attempted to create a requirements database. We had developed a complex enterprise-wide solution for the insurance industry. There were thousands of requirements. After much effort, we learned that the database would not deliver the value to offset the maintenance cost. We discovered requirements evolved over time; they were superseded, or sunset, and technology changes impacted some. It just wasn't worth the effort to maintain the database. Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
It is one of the deliverable I never forget. Project Manager is not accountable for RTM. Business Analyst/BRM is accountable for RTM. Project Manager uses RTM as a tool for performing Project Scope Verification. The format for RTM must be decided aligened to the Configuration Management process. Saving Changes...
Gordon AlexanderSenior Principal - Global Programme Director| IndepndentChelmsford, Essex, United Kingdom
Hi Linda, having an RTM is a great tool for measuring the success of a projects as well as ensuring unnecessary work is not carried out. The need for an excel or a tool like Jira or Rational will be dependent on the number of requirements and type of project as per @Anton's response.
The RTM is also a good way to ensure that changes throughout the project are properly defined and tracked, build alignment through business-BA understanding-Design - Development-Testing and operational handover.
The precursor to building this is the signed off Requirements document which will have a MoSCoW rating (Must Have, Should have, Could have and Would/Wont have), based on budgets and timeframes will depend what gets through to the final approved requirements set. Changes throughout the project can be tracked back to the MoScOW analysis to ensure that the change doesn't relate to something that someone thinks is a "nice to have" rather than an agreed requirement prior to being added in.
The final part of the RTM is an RTM review at the end of the project as an part of the lessons learnt. If there are missing functionality this can be traced through the document and you can find out where something slipped through the cracks, without an RTM its based on assumptions as to who missed it.
