As I finish preparations to begin a new project, I have spent some time discussing several methods of documenting requirements. More specifically in a requirements collection phase, at what point and with what audience do we put pen to paper with the deliverable being a requirements document.
The discussions in which I have been engaged in the last week have defined four basic scenarios that can occur, each with their own advantages and disadvantages and degrees of passion about the method.
Conduct all meetings first and document later
In this method, the project team conducts the days or week worth of meetings, meeting minutes are kept and published. After all meetings are conducted, a subset of the team begins the writing. The writing is typically accomplished by a business analyst but any team member(s) can also accomplish.
The advantages of this method are: 1) decreased time defining requirements so less business user time, 2) complete focus on requirements without need to discuss verbiage, 3) during writing, rest of team can accomplish other startup tasks.
The disadvantages are: 1) longer approval cycle as requirements wording is left to the end, 2) results of discussions may be lost. This is a greater risk the longer the requirements meetings occur, 3) writers must spend time initially preparing and then reviewing meeting minutes to write final document. Initial sets of meeting minutes are non-value add as they are duplicative to the final requirements document.
Conduct meetings and document weekly
In this method, the meetings are conducted for a number of days during week which is typically either 3 or 4 days. The remaining 1 to 2 days are used to document the results of the week. A subset of the team is typically used for the actual document preparation and is well suited for a business analyst. Typically, the emerging document is reviewed weekly and prior to beginning the new week of material.
The advantages of this method are: 1) all parties can focus on requirements definition without overhead of documentation, 2) writers have dedicated time to document at the end of each week, 3) less delay between definition and documentation so time lapse issues are less
The disadvantages are: 1) some time lapse issues and verbiage issues remain, 2) time to define requirements is extended as time is spent dedicated to documentation, 3) time lapse issues created additional uncertainty on the approval cycle length and thus the associated schedule risks, 4) end user subgroups may be required to attend sessions split across disjointed weeks.
Conduct meetings and document daily
With this method, the writers keep up with the daily definition of requirements and document said requirements during the evening hours. This enables up to a 5 day workweek to document which may be useful when limited time is available either all together or with a particular end user group. A business analyst remains well suited to the writing tasks but technicians with good functional skills can also accomplish easily. Typically, the prior day's language is reviewed prior to beginning the day with new material.
The advantages are: 1) lag time between definition and language agreement is substantially smaller eliminating the loss of agreement over the lag time, 2) the team is better able to monitor progress as the definition and language are agreed upon in a more incremental fashion, 3) individual subgroups of users are needed for a confined time as they are not required to come back at a later time to reach agreement on language.
The disadvantages are: 1) writers are required to put in additional hours at night and will loose effectiveness due to fatigue, 2) the days can be disjointed as language is reviewed at the beginning of each day causing greater stress on the end users, 3) the time lag of even a day can result in loss of agreement on the material from the previous day.
Conduct meeting and build document in real time
The advantages of this method are: 1) progress is incremental and easily tracked against the available schedule, 2) once all material is covered, the document is ready for signature and all parties have agreed on the language, 3) no time lag is created between requirement identification and documentation, 4) each end user subgroup is needed for only a single period of time vice coming back for a document review.
The disadvantages are: 1) writers have great pressure of them to either type in real time while interpreting the requirement or creating a diagram in real time, 2) end user may feel additional pressure since requirements are documented in real time vice having some number of days to review after documentation is complete.
In summary, I prefer the build as you go method as it provides a better gauge of progress, keeps all project team members focused on the goal of completing the deliverable, and typically has a smaller approval tail then the other methods. The key assumption here is that parties are held accountable to the verbiage written as they go along and wholesale revisions are not made at the end. This risk is further mitigated by publishing the draft on a daily basis.
Comments