1

Are BRD and FRD documents required for non-systems/non-IT projects? We are involved in services migration project moving managed website hosting services from a fully-managed external vendor to in-house so we can manage these ourselves. Because this is a transition project which does not require the development or building of any IT systems or infrastructure (we already have the servers to support the website), it can be compared to a construction or engineering project where BRD and FRD documents don’t usually exist.

Usually, the requirements are based on Business Objectives and then functional and non-functional requirements are based on requirements. If this is a transition project which is moving a service from Provider A (external) to Provider B (in-house), is a BRD really required?

The primary business objective is to transition the managed services externally to in-house. If we look at the actual tasks and the work pieces involved in the project to successfully achieve the business objective, a few of these at a very high-level include:

  • Documentation: Identifying and transferring support documentation.
  • HR: Employing new staff or employing existing vendor staff to manage the hosting serviced internally.
  • Processes: Obtaining from the vendor and introducing new processes to provide the same managed service.

The primary constraints, or non-functional requirements if this were a systems/IT project, would be:

  • No loss in service delivery during transition.
  • Adhering to company processes and SLAs.

Are BRD and FRD documents required, or would a series of plans (implementation plan, transition plan, continuity plan, SLA, etc.) be sufficient?

Update: thank you so much for the replies and comments so far. I am calling for more viewpoints and comments that can contribute, as such projects are not uncommon but there is scarce information online to refer to.

Improve this question

3 Answers 3

Reset to default
1

The point of these documents is not to meet a process requirement (although you may be required to do them by your process) - it's to clarify what needs to be done and get everyone on the same page.

The documents you mentioned in the conclusion of your question (implementation plan, transition plan, continuity plan, SLA, etc.) are useful, but the documents that allow you to declare "done" are your requirements documents. I would encourage you to do them, whether or not your stakeholders insist.

Improve this answer
2
  • Thanks Scott. If we go with a BRD, can you give some examples of what actual business requirements, functional requirements and non-functional requirements would/could be? Out of this project we expect to develop and/or acquire hundreds of documents on how to provide the same web hosting service. Would we have hundreds of business requirements to address each document?
    – Bec
    Apr 8, 2012 at 8:46
  • For example, if the business objective is to transition managed website hosting services externally to in-house and in order to do this successfully we must not have any downtime or affect business operations, in which documents would we place the work of: • identifying and transferring support documentation • employing new staff or employing existing vendor staff to manage the hosting serviced internally • obtaining from the vendor and introducing new processes to provide the same managed service, etc.
    – Bec
    Apr 8, 2012 at 8:46
0

I suggest that without some form of requirements document, you don't have a clear statement of expectations, so it makes a great deal of sense to develop even a high level document that says what you will do within this project, and define some criteria by which the project will be measured - conditions of satisfaction, if you like. On the type of project that you describe, you will have expectations about performance, cost, reliability, and functionality. Even stating explicitly that the performance, cost and reliability will be the same or better than the current outsourced service, and that the functionality will be identical, is a good start. Otherwise, you may find that your technical teams start making changes within the scope of the project, just because they can, and because there is nothing to tell them not to do so. (And if the business does want to allow changes, you can use a change control process to manage this.)

Basically, you need some structure to define what is in and what is out of the project, and then you either work within that, or modify it consciously and deliberately. Either way, you have a starting point from which you can keep the project focused on delivering the business value that is anticipated.

Improve this answer
5
  • Thanks Iain. I am still unclear on which specific direction to take. There is a defined Project Scope defining what is In and Out of scope, and tasks and activities are defined in the WBS based on the Scope. If we create a BRD it will contain a few requirements which are listed above. Is there any way we can include all of the documents we need to create as business requirements? If we need to create a continuity plan, multiple SLAs, operating procedures, etc, to support the in house website hosting, how could these be turned into functional requirements used to verify the requirements?
    – Bec
    Apr 8, 2012 at 10:31
  • Bec, the Project Scope document may be sufficient, as long as you have addressed the risk that your view of the deliverables and the business view of the deliverables are in line. Consider starting with the risk, then work backwards until you are sure that everyone is on the same page in terms of understanding, then stop. Don't do more than you have to. Also, don't get hung up on document names: it's the content and value of the documents that count, not what you call them. If your Scope document meets the requirements, then don't go producing something else that you don't really need!
    – Iain9688
    Apr 8, 2012 at 13:46
  • Thanks Iain. Where would we specify the actual hundreds of individual documents to be delivered such as: support documentation, SLAs, etc? These support the transition itself so that we can manage it in-house. The difficulty will be to communicate with stakeholders and the PM that we only have a Scope Document and no actual requirements? The expectation is to somehow create hundreds of "deliverables" from all of these documents so that each can be verified to ensure the transition is successful and nothing has been overlooked or missed. The project is critical in nature.
    – Bec
    Apr 8, 2012 at 21:40
  • There is no right or wrong answer to where you define the individual documents - but a Business Requirement Document may be the right place. My hesitation is that you may end up producing dozens or hundreds of documents that add no value to the organisation, but if you define them all up front and deliver against that list, you could be delivering stuff that is never read and ends up gathering dust. Let me just ask a question - and I don't need an answer: Does the documentation define success, or does a reliable, secure, robust, working system define success? Only you can answer that!
    – Iain9688
    Apr 8, 2012 at 23:43
  • Thanks Iain and some good food for thought. Although deliverables may be at a higher-level, supporting documentation and other resources are there to support and ensure the service is reliable, secure, robust and working. It is a positive if these documents are rarely retrieved and used.
    – Bec
    Apr 9, 2012 at 12:17
0

I think that every project/feature/task, no matter how small they are, should be planned for.

What if one of the sites that you are about to migrate relies on a third party which you are not aware of? If you have your requirements in a document, you can circulate it to relevant people and get their approval (sign-off). This will not only cover your back, but it might also give you a better understanding of a problem.

How do you know when the project is complete if you haven't said anywhere what counts for "complete"?

Documents that you have mentioned is what I would refer to as analysis document. Analysis document should provide enough information to somebody new to pick-up the task in the event that you decide to leave company. If it's a few page document, then I'd simply call it an analysis document. If it was a forty page document, then I would consider breaking it down into smaller documents.

Improve this answer
1
  • Thanks CodeWorks and your feedback us a good view on the problem. It looks like a combination of analysis documents, business requirements and a few other things will be the way to go.
    – Bec
    Apr 11, 2012 at 13:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.