Requirements Management for Projects

[JennaHe]

Hello - does anyone work with a requirements management tool (like iRise, or something similar), and if so, how do you integrate or also use Workfront without dupilcating effort? On the flip side, has anyone found a creative way to do requirements management directly within Workfront? Thanks!

[GregBe1]

We used to use iRise, but we didn't use it extensively for requirements documentation. For our projects, under "Documentation" we'll create a folder called "Requirements", and basically ours are Word docs that we'll save there. We could also put the iDoc there. If the requirements change (and a new version of the Word doc is created), we'd upload a new version of the same doc to Workfront.

[RobertGo]

In our non-Agile world... We are trying to get our PMs to name their deliverables as tasks , under which they build the WBS for each deliverable - normal PM activity. Then, they would record requirements for each deliverable as issues on each deliverable task - "abnormal" PM activity. That "engineering" takes advantage of a Workfront constraint: Workfront prevents completing deliverable tasks until all the issues on a task are "Resolved", that is, in this case, until the requirements have been tested to the client's satisfaction. Adding other types of issues on deliverable tasks are good way to manage requested and approved changes to deliverables, and to manage deliverable defects, as well. To make the use of issues on tasks work this way, you will want to define issue Topics in the project Queue Setup. Topics let you create issue types, e.g., "Requirements", "Change Requests", "Defects", etc. so you can segment them in filters, views, groupings, and reports/dashboards. However, adoption of this approach has been very slow. Folks remain attached to their office documents in which they keep track of and report on deliverables and requirements. We are working on better task and issue reporting to improve adoption.

[BethMa1]

That's an interesting idea, Robert! So it's only the PM who creates the issues for your team? In many cases we PMs wouldn't know the details (ie, dimensions, word counts, etc.) but rather the project team members would be aware of these. Unfortunately they might forget to double-check what they deliver against their own specs - so I wonder if one possibility could be for the project team members to make these issues on their own as a sort of checklist to remind themselves. Beth Massura Assistant Director of Operations, Marketing The University of Chicago Booth School of Business 5807 South Woodlawn Avenue Chicago, Illinois 60637 Phone: 773.702.7598

[RobertGo]

Anyone with appropriate permissions to the project is free to add Issues. It's up to the PM to triage and manage them. As for deliverable-type tasks, that's the job of whoever creates/manages the WBS, usually the PM. For requirement-type issues, the PM would want to keep an especially watchful eye on additions and changes to those. If we can get our task/issue coding and reporting right, we would like to use Workfront tasks and issues as our "statement of work." I am not "far down the street" from you it seems. I am with Presence Health, and visit their offices in Elk Grove, Bolingbrook and Des Plaines, among other Chicagland locations.

[Former Community Member]

Hey there! Interesting concept. I love the thought of having the requirements broken down by deliverable. I've thought about it myself. However, we have a really hard time getting our users to close out their individual tasks. Who in your model is responsible for closing each requirement/issue? What is your average number of deliverables and related requirements (if there is such thing) per project? Are your PMs working on one project at a time or multiple?

[EricLu2]

Hi: Primary responsibility for keeping task information (percent complete, commit date) accurate is with the Primary person assigned to a task. We show them how to do a project status update and adjust the percent complete when they complete their timesheet. Secondary responsibility is on the PM to update tasks as a result of verbal updates given in meetings or hallway-drive-bys. Unfortunately, more updates are made using the latter process than the former. I can’t speak to the average number of requirements - I’d be guessing, plus I know the larger projects have hundreds and the smaller projects have tens. An average doesn’t really mean much here. We use Excel to document the requirements and trace them up and down the SDLC. Our PMs definitely work multiple projects. We try to keep it below five if possible. We also provide project administration support to help the PM, to ease the administrations burden. Well, that means the PA does most of the interaction with WorkFront, the PM interacts with people. Hope this helps! Eric