As a Product Manager, once Bick was asked to look into why a new point-of-sale software was behind schedule. He requested the business requirements and was given the document. It was written by a member of the technology department. No one on the business side had taken time to document the requirements for this new software. So that software development (programming) was being subjected to the impact of a lack of ownership by the business.
Think of it like building the house. There is a specific order in which things need to be done. And there is a point where some changes cannot be easily incorporated into the effort. A decision is made: the customer wants a ranch with three bedrooms. Blueprints are drawn up and the effort begins. Land is purchased and a foundation is laid. Pipes are put in. Rough framing begins. At this point the client says "wait, I need a four bedroom ranch". But the foundation accommodates three bedrooms. Do you redo the foundation? Do you reallocate square footage in the rooms of the original blueprint? Do you just redeploy the living room and change the blueprint to add a closet? There are no easy answers to this dilemma. And so the conflict between the contractor and the customer begins.
In today's technology-based world, business associates need to be able to clearly articulate the business requirements for either a new system or any business update to an existing system. Developing quality business requirements is a skill that can be learned, and once learned, can be refined. And there is a process that needs to be adhered to when developing business requirements. That process includes a step Bick calls "validation".
Do you validate your requirements before development (programming) begins? Are there frequent arguments between the business community and the technology community over what the technology community is delivering or the time frames within which it is delivering? Then your organization may be less effective at bringing technology to bear on opportunities or issues. If you are not sure about requirements effectiveness, if you want to further inspect your organization's ability to author quality business requirements, or if you want to improve your organization's ability to author effective business requirements, visit the contact page and reach out to us.
Think of it like building the house. There is a specific order in which things need to be done. And there is a point where some changes cannot be easily incorporated into the effort. A decision is made: the customer wants a ranch with three bedrooms. Blueprints are drawn up and the effort begins. Land is purchased and a foundation is laid. Pipes are put in. Rough framing begins. At this point the client says "wait, I need a four bedroom ranch". But the foundation accommodates three bedrooms. Do you redo the foundation? Do you reallocate square footage in the rooms of the original blueprint? Do you just redeploy the living room and change the blueprint to add a closet? There are no easy answers to this dilemma. And so the conflict between the contractor and the customer begins.
In today's technology-based world, business associates need to be able to clearly articulate the business requirements for either a new system or any business update to an existing system. Developing quality business requirements is a skill that can be learned, and once learned, can be refined. And there is a process that needs to be adhered to when developing business requirements. That process includes a step Bick calls "validation".
Do you validate your requirements before development (programming) begins? Are there frequent arguments between the business community and the technology community over what the technology community is delivering or the time frames within which it is delivering? Then your organization may be less effective at bringing technology to bear on opportunities or issues. If you are not sure about requirements effectiveness, if you want to further inspect your organization's ability to author quality business requirements, or if you want to improve your organization's ability to author effective business requirements, visit the contact page and reach out to us.