Six Things Your CIO Needs to Know About Requirements Maturity
http://www.iag.biz/images/6_things_your_cio_needs_to_know.pdf
This post startled me when it made me realized how complacent I've become of my skills. Having moved from giant corporate to an non-profit organization of less than 200 people, I became more and more comfortable with the slow pace, lack of any kind of evaluation on my work product. I noticed a number of problems in my company around requirements maturity:
1. People only look at pictures/mockups, and don't read any text. Therefore anything not in the picture is treated as a missing requirement.
2. Each business component, e.g. security and privacy should document highlevel system capability statements and then request for these features; not asking the business analyst to produce a list of detailed rules on application security and call that security requirements.
3. The company should invest in a requirements management tool so that different views of the requirements can be generated. This would save BAs time in extracting/producing different slices/flavors of the requirements for each stakeholder.
4. Have a formal requirement sign-off process to stop requirements change right up to release
5. Have BA own all process documents to avoid business making up their own process and call it requirements
6. BAs need transparency on decisions made and rationale.
7. The product owner should know business requirements intimately, rather than questioning BA where certain requirements came from where as the requirements came from the very same product owner.
8. Business requirements should be signed off before technical requirements can start
All these problem indicate we don't have any project management mechanism in place. This has reduced us down to less than a level 1 organization.
This post startled me when it made me realized how complacent I've become of my skills. Having moved from giant corporate to an non-profit organization of less than 200 people, I became more and more comfortable with the slow pace, lack of any kind of evaluation on my work product. I noticed a number of problems in my company around requirements maturity:
1. People only look at pictures/mockups, and don't read any text. Therefore anything not in the picture is treated as a missing requirement.
2. Each business component, e.g. security and privacy should document highlevel system capability statements and then request for these features; not asking the business analyst to produce a list of detailed rules on application security and call that security requirements.
3. The company should invest in a requirements management tool so that different views of the requirements can be generated. This would save BAs time in extracting/producing different slices/flavors of the requirements for each stakeholder.
4. Have a formal requirement sign-off process to stop requirements change right up to release
5. Have BA own all process documents to avoid business making up their own process and call it requirements
6. BAs need transparency on decisions made and rationale.
7. The product owner should know business requirements intimately, rather than questioning BA where certain requirements came from where as the requirements came from the very same product owner.
8. Business requirements should be signed off before technical requirements can start
All these problem indicate we don't have any project management mechanism in place. This has reduced us down to less than a level 1 organization.
Comments
Post a Comment