After the SRS
You've just finished a two-month, 150+ page SRS, gone through the validation process, and have sign-off from everyone. Congratulations! Time to kick back, relax, and watch the other teams build the product, right? Well, not exactly. As Product Managers, we still have a responsibility to help ensure that the product is completed correctly. In this post, I'll discuss a few roles and activities that we play after the requirements are completed. Whether you as a Product Manager play these roles or not will depend on your organization and project - however, it is important to understand that all of these roles are necessary and they need to be completed by someone, whether a Product Manager, a Project Manager, or someone else.
First and foremost - requirements change. Business priorities shift, additional information is uncovered, and interaction between design and requirements all necessitate changes to requirements. A comprehensive change control process is a must for any project. Dan recently wrote a post suggesting a change control process. Usually the Product Manager is a key player in the change control process, if not the person running the process.
Acting as an interface between the business and the development teams is another key role to play post-SRS. No matter how well written your documentation is, designers, developers, and testers will have questions. Their questions may require you to go back to the business for clarification. You will also need to review development artifacts such as design documents, prototypes, completed development, etc... Depending on how the project is structured you may need to coordinate between business stakeholders and the IT teams to facilitate review and feedback.
While the testing team has primary responsibility for verification, Product Managers play an important role as well, particularly during user acceptance testing (UAT). Typically, the business does not have all of the required skills to setup UAT, write test cases, and execute testing. Product Managers can play a very helpful role in assisting the business with their testing responsibilities (e.g. leveraging use cases to produce UAT scripts).
Product Managers should assist in the verification of training and user documentation. In fact, depending on your organization, you may be the person producing training and user documentation.
The next two roles will really depend on your organization - a lot of larger organizations have specific teams or individuals separate from Product Management who have these responsibilities. The first is rollout, and the Product Manager may be involved in helping to plan how roll-out will occur, when certain groups will get the new application, how training will fit into rollout, and other activities. The second responsibility is on-going support and maintenance, which could involve tasks like providing initial user support, training a support desk/group, and doing triage on in-coming defect reports and change requests.
Last, but not least, requirements work is a process - and with any process you should examine the process for potential improvements. After you are done with the SRS, you should take the opportunity to see what went well and what didn't. You should also take this opportunity after the project to re-examine what could be improved in the requirements process.
First and foremost - requirements change. Business priorities shift, additional information is uncovered, and interaction between design and requirements all necessitate changes to requirements. A comprehensive change control process is a must for any project. Dan recently wrote a post suggesting a change control process. Usually the Product Manager is a key player in the change control process, if not the person running the process.
Acting as an interface between the business and the development teams is another key role to play post-SRS. No matter how well written your documentation is, designers, developers, and testers will have questions. Their questions may require you to go back to the business for clarification. You will also need to review development artifacts such as design documents, prototypes, completed development, etc... Depending on how the project is structured you may need to coordinate between business stakeholders and the IT teams to facilitate review and feedback.
While the testing team has primary responsibility for verification, Product Managers play an important role as well, particularly during user acceptance testing (UAT). Typically, the business does not have all of the required skills to setup UAT, write test cases, and execute testing. Product Managers can play a very helpful role in assisting the business with their testing responsibilities (e.g. leveraging use cases to produce UAT scripts).
Product Managers should assist in the verification of training and user documentation. In fact, depending on your organization, you may be the person producing training and user documentation.
The next two roles will really depend on your organization - a lot of larger organizations have specific teams or individuals separate from Product Management who have these responsibilities. The first is rollout, and the Product Manager may be involved in helping to plan how roll-out will occur, when certain groups will get the new application, how training will fit into rollout, and other activities. The second responsibility is on-going support and maintenance, which could involve tasks like providing initial user support, training a support desk/group, and doing triage on in-coming defect reports and change requests.
Last, but not least, requirements work is a process - and with any process you should examine the process for potential improvements. After you are done with the SRS, you should take the opportunity to see what went well and what didn't. You should also take this opportunity after the project to re-examine what could be improved in the requirements process.
posted by Brad at 8/30/2007 08:19:00 AM
3 Comments:
The business priorities change, but most of the changes originate with the executive sponsor and not the business. The executive sponsor is playing politics with the requirements.
We get sucked into this because we are trying to make the requirements efficent for developers. This might have been ok when developers were expensive, but today their don't cost much particularly when you actually bother to compair true operational costs with production costs.
JAD and the notion that everyone must agree on requirements means that political warfare is the norm. This, however, is a waste of time because the real work being done at the bottom, the stuff being automated doesn't change all that fast.
Real work doesn't change, so why the heck are the requirements changing. Requirements volatility is a defect that should be rooted out by process improvements via a requirements QA function. Here I mean QA in the manufacturing industry sense, not QA as QC, as in software testing. The point to QA is to reengineer the requirements process, not fixing the defects.
If we actually engaged in QA in its manufacturing form, we would have a realistic and much improved elicitation process. Academic research on elicitation hasn't move much since the early 90's. So elicitation has not changed. It certainly hasn't responded to the economic drivers in the IT industry.
This post is being discussed on the messageboard:
http://www.seilevel.com/messageboard/showthread.php?p=3118#post3118
Great post.
Collaboration is what really makes project management successful.
I believe Requirements Gathering and Documentation are essential, but they have to be accepted as iterative processes and the combination of the right project planning and collaboration tools go along way in enabling just that.
Looking forward to many more insightful posts from you.
Post a Comment
<< Home