Product Descriptions save time across the life of a project that exponentially regains the time invested in writing them. Without a Product Description what criteria are reviewers reviewing deliverables against? Peoples’ opinions? Time is wasted when people review documents against their opinion rather than a Product Description because everyone involved is reviewing against what they perceive the product should be rather than an agreed expectation. This means some people will be pulling in completely different directions. To try and get consensus through the product reviews process could take multiple reviews and weeks or months. Do you want to allow for those sort of durations in your plan?
Product Descriptions are part of the foundations of a project that allow it to run well. If asked to describe a High Level Design, or in fact any other deliverable chances are you’ll describe either the first template or the best template you’ve seen in your career. The problem for all of us is that in a world of other people's careers, different best practices and international standards another person may well describe a variable or something quite different to our view. Organisations often have established and well defined processes and templates that they will expect to use in their engagement. We cannot assume that everyone is going to agree with us or have the same view. When we have two or more organisations or people engaging it is unlikely there will be an immediate common view on how to do things. These differing views, opinions or expectations are the reason it is sensible to identify our differences up front and agree common processes, deliverables and templates. In review of a product it’s not unknown for some egotistical reviewers to say things such as the document is not fit for purpose just because it doesn’t fit their view on what the document looks like. This could be for something as simple as differing chapter titles. I’ve seen this ’not fit for purpose’ excuse used for not reviewing the document at all i.e. work avoidance. For these reasons time spent writing and signing-off Product Descriptions during ‘Initiating a Project’ stage is important and well worth the investment.
Product Descriptions are used to describe what artefacts and deliverables should look like. Product Descriptions should state whether sign-off is required or the product is just being supplied for information – we don’t want people holding the project up because they want a fortnight to review a document and give us their opinion when sign-off and acceptance of the product is not necessary. The purpose or aim of the product should be clearly stated – this will help reviewers focus their comments on matters that help the document achieve its aim. The Product Description should state who is responsible for what by including a PRACI; P=Produces, R=Reviews, A=Approves, C=Contributes, I=Informed. The products relationship to other products should be stated, which other products it gets input from and which products it gives inputs to. This gives further terms of reference for the product and keeps reviewers to the threads running through the project. The Product Description should provide a narrative description of the product including chapter and paragraph headings, descriptions of the purpose of each chapter or paragraph and the definitions of any key terms. Perhaps most importantly the Product Description should describe what the quality acceptance criteria is. By agreeing these matters up front in a Product Description clear criteria for reviews and acceptance is set. When the time comes to review the product the reviewers will be clear for what purpose and to what acceptance criteria they are reviewing the document against. Disparate or sabotaging voices can be quickly dealt with by reference to the Product Description. Product Descriptions are not optional, that are one of the key stones in the foundations of a project – they save time and relationships.
Product Descriptions are part of the foundations of a project that allow it to run well. If asked to describe a High Level Design, or in fact any other deliverable chances are you’ll describe either the first template or the best template you’ve seen in your career. The problem for all of us is that in a world of other people's careers, different best practices and international standards another person may well describe a variable or something quite different to our view. Organisations often have established and well defined processes and templates that they will expect to use in their engagement. We cannot assume that everyone is going to agree with us or have the same view. When we have two or more organisations or people engaging it is unlikely there will be an immediate common view on how to do things. These differing views, opinions or expectations are the reason it is sensible to identify our differences up front and agree common processes, deliverables and templates. In review of a product it’s not unknown for some egotistical reviewers to say things such as the document is not fit for purpose just because it doesn’t fit their view on what the document looks like. This could be for something as simple as differing chapter titles. I’ve seen this ’not fit for purpose’ excuse used for not reviewing the document at all i.e. work avoidance. For these reasons time spent writing and signing-off Product Descriptions during ‘Initiating a Project’ stage is important and well worth the investment.
Product Descriptions are used to describe what artefacts and deliverables should look like. Product Descriptions should state whether sign-off is required or the product is just being supplied for information – we don’t want people holding the project up because they want a fortnight to review a document and give us their opinion when sign-off and acceptance of the product is not necessary. The purpose or aim of the product should be clearly stated – this will help reviewers focus their comments on matters that help the document achieve its aim. The Product Description should state who is responsible for what by including a PRACI; P=Produces, R=Reviews, A=Approves, C=Contributes, I=Informed. The products relationship to other products should be stated, which other products it gets input from and which products it gives inputs to. This gives further terms of reference for the product and keeps reviewers to the threads running through the project. The Product Description should provide a narrative description of the product including chapter and paragraph headings, descriptions of the purpose of each chapter or paragraph and the definitions of any key terms. Perhaps most importantly the Product Description should describe what the quality acceptance criteria is. By agreeing these matters up front in a Product Description clear criteria for reviews and acceptance is set. When the time comes to review the product the reviewers will be clear for what purpose and to what acceptance criteria they are reviewing the document against. Disparate or sabotaging voices can be quickly dealt with by reference to the Product Description. Product Descriptions are not optional, that are one of the key stones in the foundations of a project – they save time and relationships.
RSS Feed
