Archive for July 2009
The Significance of Time, Budget and Scope in Product Development
July 15, 2009 | 
Author 
Recognition of time, budget and scope as the three variables in product development is of paramount importance. At the outset, it is essential to have two of the variables fixed, otherwise we will never get the product out. Whenever someone says, they can launch a product on time, on budget, and on scope, take it with a bucketful of salt. It almost never happens and when it does, quality often suffers.
Ideally, which are the two variables that one should keep fixed? If you’re a product company, it necessarily has to be time and budget, for one should never throw more time or money at a problem. Additionally, during your product engineering phase itself, your product marketing would have gone to the market in promoting it and it doesn’t make sense to miss the timelines.
Posted in Outsourced Product Development, Product Development, Product Engineering | 
Tags: 3RD PARTY ENGINEERING, DEVELOPMENT MANAGEMENT, FIXED COST, FIXED TIMELINES, OUTSOURCED PRODUCT DEVELOPMENT, PRODUCT DEVELOPMENT, PRODUCT DEVELOPMENT VARIABLES, PRODUCT ENGINEERING, PRODUCT MANAGEMENT, PRODUCT MARKETING, PRODUCT SCOPE, SCOPE MANAGEMENT, SOFTWARE PRODUCT DEVELOPMENT, WORKING PRODUCT | 
Comments Closed
Prototype Before You Build
Prototyping is one of the most important activities of requirements analysis. Typically when people think of requirements gathering, they think about writing a document. Although writing a formal document is necessary, it is not sufficient to provide non-technical users a good understanding of the product that is being built.
For most web applications, a simple prototype can be easily created using plain old HTML. This will provide the customer with an understanding of the user interface of the application and the workflow of the system. Misunderstandings can be quickly corrected thus putting the requirements on a firmer footing.
Prototypes are usually meant to be thrown away. This means that you don’t have to spend too much time worrying about the source code of the prototype. The visuals and the workflow are what is important. Getting a prototype up sooner saves time in the requirements analysis process and serves as a good foundation for the rest of the project.