I work for a small company as a software engineer. Our company doesn't have a business analyst or a project manager. We are about to sell a custom CMS system to a very IT illiterate customer.
Who is responsible for creating the requirements specification? If it's a project manager or a business analyst, who should fill this role and how can we avoid any problems as a result?
The customer is ultimately responsible for specifying requirements. Whether your company has a business analyst or project manager is irrelevant to identifying the responsible party.
A business analyst is generally a liaison between the development team and the client, and is responsible for working with a client to elicit or refine requirements. However, the requirements themselves always originate with the client. In many cases, the business analyst is in the best position to document the requirements once they've been defined, but that is really a matter of convenience and is ancillary to the role.
Put another way, the business analyst facilitates requirements-gathering and refinement of the deliverable specifications from the client. The client remains responsible for defining their needs and expectations.
The project manager, on the other hand, has the responsibility for managing the specification artifacts (e.g. storing and disseminating the specification documents, if any), and for integrating the specifications into the project plan. As before, the client is responsible for the specifications; the project manager just facilitates the inclusion of specifications into the project management process.
Ideally I think you'd want someone who isn't a direct part of the development team to be gathering requirements. This is partly because requirements should (depending on your precise situation) go beyond the technical needs of the project to the business needs of the client - something that developers/engineers may not be best placed to advise on. I'm fairly agnostic on whether this process should be undertaken by a business analyst or project manager. I've been in situations - particularly in small organisations - where these roles overlap or are performed by the same person.
Since you have neither resource available to you I think you need to identify someone whose role - as far as possible - spans both business and technical domains. If you work in an agile environment I wonder if a scrum master or similar might be the most appropriate person. Alternatively the role could be split between someone on the technical side (e.g. you!) and someone in a sales or account management role. This would provide a range of views (with sales/accounts helping to document the 'why' and technical helping to document the 'what' and 'how') and ensure that the 'IT-illiterate' client doesn't get too lost in the details.
Customer IS responsible for requirements; however, it is the company's responsibility to organize them and translate into a technical language.
Agility of development is a must in the current subset; therefore, make sure that customer gets to see and approve every step of the development (working prototypes).
It would be much easier to answer if we knew who else is the part of the process, meaning - what positions are there in the company? A software engineer cannot be a requirements elicitor (he/she can theoretically, but it is proven to be counterproductive in most cases. One of the reasons - the tendency is to minimize the coding workload; therefore, the product and customer satisfaction suffer).
Instead, someone in the company, who is not technically illiterate, and at the same time can speak business language, should perform the duty of BA. For instance, it can be a sales person who is familiar with the production. But my advice is to contract a BA for requirements.
In the absence of a PM or a BA, the person(s) who has done functional testing on the product is a good choice for drafting the requirements specs. They can easily reverse engineer their functional test specs into requirements specs.
If this formal process ( of having documented functional specs and subsequent functional testing)is not in place, the engineers who build the product are the ones who should document requirements.
As a side note, if you are selling a product to an IT-illiterate customer, a better format for documenting requirements is a user manual or user help document that will help the user navigate the system.
Adopt agile values Everyone in the team should be responsible for bringing value for the customer and not developing non-sense. You have to speak to your customer. You have to provide working software - not future-complete, but working - as soon as possible, so you can receive feedback from the customer. You have to talk with the users of the CMS; with the people that will actually use your software. You can create mockups instead of software, to check the interactions your users expect and to show them what the software will look like.
Based on my personal experience as a project manager, it is generally the business analyst who is responsible for writing up the business requirements specifications. The project manager is responsible for ensuring that business analyst delivers the business requirements specifications on schedule, signed off by all parties and shared with software development team for analysis.
It depends on the methodology and the context. Is this an Agile/Scrum project? Is this a Waterfall project? Is this a Agilefall project?
Getting requirements right seems to a major problem for any project using any methodology. The only common thing in all of them is to provide "an result" early and get feedback. If either the requirements (and/or user story) have changed or the requirement was misunderstood then early feedback will move the requirement towards what the customer really needs solved.
So when in doubt "iterate" soon and often!
Yes, I understand that doesn't work easily or at all when there is no visible input/output on a project.
Tom
Nice question!
BRD (Business Requirement Document) and FRD (Functional Requirement Document) are the two types of documentations needed. Both BRD and FRD are carried out by a Business Analyst and not by Project Manager. I have also observed that many companies ask their Project Manager or UX Designer to carry out these responsibilities which ideally belong to Business Analyst. Business Analyst is the one who is expected to elicit and refine the business requirements by building a strong rapport with the client.
Few roles of the Business Analyst (BA):
I have seen many small companies or start-up companies asking their employees to wear as many hats as they can! But If you are not comfortable with a particular role, then you should straightaway let them know about your concern!
As a Senior Business Analyst (BA) with over two decades of experience as BA (did a little PM work, but prefer being a BA, is my passion), I can tell you that the only one responsible for gathering business requirements specifications is the BA (and that means Functional, Non-Functional, and Technical Specifications, including Use Cases, Flow Charts, etc.). The BA prepares a Business Requirement Document (BRD) and needs to be approved by the client, to ensure that all his/her needs are being met.
It is true, the requirements start with the client, as they are the ones in need of a solution to their current situation, however, the client does not speak technical and technical does not speak business, thus, the bridge is the Business Analyst. S/he has the skills needed to speak both languages, and collect all requirements, negotiate requirements, and come out with a recommended solution (or multiple solutions) from which the client will choose.
In the BRD, all information (not just requirements) must exist (Use Cases, Diagrams, specially flow charts, etc.). This is to ensure that when the solution is implemented there will be no gaps and it is the appropriate solution the client needs and to ensure that it is built with strong scalability to continue to improve it as time goes on.
In Agile, everyone is responsible for bringing value to the customer's project. However, in a more traditional sense, the Business Analyst has been more directly responsible for eliciting the requirements, translating them against suggested solutions, and working with the system architect/project manager/lead programmer. In some cases the role of the Analyst will go further in helping to create documentation, and training materials on the resources that were created as they are supposed to be the closest to the end user. If there is a specification that your team is using specifically to handle Requirements, the Business Analyst would be the closest role to this document.
A Project Manager on the other hand looks at the full picture of the project to create the necessary environment for everyone to do their job. They would be responsible for managing all documents created by the team, organizing them and agreeing on a single format, interfacing with your final customers, gaining their sign off on what can and can't be done, as well as mitigating any obstacles that might prevent tasks from being completed. In the end, they are two separate roles that will be working closely together.
The bottom line is that the Business Analyst MUST get the specs right.
In other words, he/she needs to write the specs so they do exactly what the customer wants and then...
The Customer is responsible for signing these of.
However, if the specs are vague or inaccurate, and even if they are signed off, the Customer is always right. A cliche I know but true.
As they're paying the bill, they can make mistakes but your BAs can't.
