Posts Tagged ‘documentation’

How, Who and When Document

Posted in 03 - Product Development, Book Review, Design, Development, Methodology on September 20th, 2009 by Paul McArdle1 Comment

This commentary was initially included in a lengthy book review post about the book “Tale of Two Systems”.  Given I will be referring to these two documents on an ongoing basis, I have shifted the commentary to this separate page.

In the book, the 2nd key document is called the “Statement of Work” (SOW).

This, along with the “Concept Document” are the two key documents referenced in the book.   I agree there should only be two!

According to the book (p8) this “laid out the ‘how’, ‘who’ and ‘when’”.

The author notes that this was developed concurrently with the iterative development of the Concept (i.e. “What and Why) Document.

In my view, it is important that this was a separate document, as these types of details (whilst needed up-front) should not pad out a business case.

As a business owner, what I need is to know that the SOW exists and to have trust in the people who have developed the SOW – I do not necessarily need to read the details.

For our company, moving forward, we’ll place particular emphasis on conversations, and documentation, that answer together the:

HOW, WHO and WHEN

What and Why Document

Posted in Book Review, Methodology, Requirements Gathering on September 20th, 2009 by Paul McArdle1 Comment

This commentary was initially included in a lengthy book review post about the book “Tale of Two Systems”.  Given I will be referring to these two documents on an ongoing basis, I have shifted the commentary to this separate page.

In the Tale of Two Systems, this is called “The Concept Document”.

This, along with the “Statement of Work” are the two key documents referenced in the book.   This model of only two key documents is certainly something worthwhile for us to follow…

Personally speaking (and knowing how language is loaded with semantics) I would prefer we even use the name “What and Why Document” to describe this one.

Paraphrasing the book, this is essentially the marketing document (i.e. the business case to which internal and external partners sign up).  It contains such things as:
1)  Financial projections
2)  Who we think the users are
3)  Their value proposition
4)  How much we think they will be willing to pay
5)  How much we think it will cost us to develop
6)  The risks and threats we see.

In other words:

WHAT and WHY

Why do we document?

Posted in CEO's Philosophy, Company Roles on September 19th, 2009 by Paul McArdle5 Comments

This post was originally written to be part of a (lengthy) Book Review:  The Tale of Two Systems (an overview of Lean & Agile software development).

However, I thought I would need to refer to this numerous times in future, so have placed it on our blog as a separate post…

read more »