Volere and a Statement of Work

[Charlie Wilkins]

We are seeking opinion on how a Statement of Work could fit in with
our current Volere based process.

At present we prepare a Budget Estimate based on, at most, a couple of
paragraphs from the customer. This is used to give the decision makers
an early indication of the size of the project.

We then do a small amount of work to prepare an IBRD (small relative
to the size of the project)(Initial Business Requirements Document).
The guidance we give on level of detail for the IBRD is to complete
the goal, stakeholder analysis, context diagram, business events,
scope section and the requirements and constraints that will have a
material effect on the project budget.

The IBRD is used to prepare a Solution Overview and a more robust
estimate, which is then passed to the business to support their
project proposal.

Assuming permission is given to proceed, a full BRD is completed,
which is used to support the full business case.

Some of our colleagues have successfully used the Statement of Work
(SOW) as an initial project document in prior places of employment,
where the IBRD was not prepared. As a result, we are investigating
whether to implement the Statement of Work as the deliverable in our
process, replacing the current IBRD. Among other things, the SOW
contains the scope, project approach, budget estimates as well as
conditions of satisfaction for the project (see the table of contents
pasted in below for more detail).

We have two broad questions:
1. Is the Statement of Work (or similar) the standard for
organisations that use Volere?
2. How does it fit in best with Volere?

The SOW is solution-focussed. Our internal discussions have revolved
around the fact that Volere recommends that we focus on understanding
and confirming the requirements prior to considering solution. Would a
document such as the SOW fit into the Volere requirements analysis
process or do Volere and the SOW contradict each other?

Table of contents
Purpose of the Project
Background
Problem, opportunity, or directive statement
History leading to project request
Project goals and objectives
Product description
Scope
Stakeholders
Knowledge
Processes
Communications
Project Approach
Route
Deliverables
Managerial Approach
Reporting methods and frequency
Meeting schedules
Escalation
Scope Management
Constraints
Start Date
Deadlines
Budget
Technology
Ballpark Estimates
Schedule
Budget
Conditions of Satisfaction
Success criteria
Assumptions
Risks

[James Robertson]

Charlie,

we have now started a LinkedIn group that gets more activity than the Google group. Yours is an interesting post and I wonder if you would be so good as to re-post on the LinkedIn group:

http://www.linkedin.com/e/vgh/2491512/

You have to join, and if you have not already, I will approve you right away.

Best regards,

James

> --
> You received this message because you are subscribed to the Google Groups "Volere Requirements" group.
> To post to this group, send email to vol...@googlegroups.com.
> To unsubscribe from this group, send email to volere+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/volere?hl=en.
>

___________________
James Robertson
the Atlantic Systems Guild
ja...@systemsguild.net
http://www.systemsguild.com
http://www.volere.co.uk
Volere LinkedIn group: http://www.linkedin.com/e/vgh/2491512/
Twitter: VolereResources
Facebook: facebook.com/JamesStruanRobertson

Our new book: 'Adrenaline Junkies and Template Zombies' has won a Jolt Award
Amazon: http://bit.ly/TKIoR
Dorset House: http://bit.ly/teqZR

[Suzanne Robertson]

Dear Charlie,

I suggest that you also post this question on the Volere Requirements site on Linked In. http://www.linkedin.com/e/vgh/2491512/

We started the Linked In group in December as it is more accessible to more Volere Users. Already there are in excess of 250 subscribers. 

A short answer to your question is that it is important to separate requirements Content from requirements Form. The content is the requirements knowledge that you need to communicate to your stakeholders so that you can get feedback and build the solution. There is a paper on the Volere website that discusses requirements Content in the form of the Volere knowledge model. http://www.volere.co.uk/pdf%20files/requirements%20management.pdf

The knowledge model is a formal way of seeing the connections between at all the requirements knowledge that is listed in the template. Note that the knowledge model does not prescribe the order in which you discover the knowledge. 

The requirements Form is the vehicles that you use to communicate the requirements. These include things like: prescribed documents, project phases, review cycles, models, meetings, prototypes, scenarios, conversations or any other packaging of the content. The form that you use to package your requirements depends on your project sociology and the way that your organisation works. For example, if you were working in a very agile way then you might choose to keep your requirements on charts on the walls of the project office. If you are working in an industry that has a Statutory Need for requirements to be organised into particular documents then that would be your form. 

If you look on the right hand side of the Volere Knowledge model you will see that the classes of knowledge are solution oriented. Volere does not say that you must find all the requirements before you think about a solution. Instead it says that the important thing is to be able to separate the problem/work from the solution. There is nothing to stop you working on the two views in parallel providing you can keep them separate. The problems occur when people mix the problem and solution into one melange - then nobody knows that anyone is talking about.

A document, whatever it is called, is a packaging of some subset of requirements knowledge. The purpose of the document is to communicate the appropriate knowledge to a specific group of people for the purpose of: review, approval, request for tender, progress information. The problem is that many documents are either missing requirements knowledge that is necessary or include knowledge that is irrelevant for the communication.

I hope that this helps.

Regards

Suzanne

On 12 Feb 2010, at 01:15, Charlie Wilkins wrote:

--
You received this message because you are subscribed to the Google Groups "Volere Requirements" group.
To post to this group, send email to vol...@googlegroups.com.
To unsubscribe from this group, send email to volere+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/volere?hl=en.

================================================================

Suzanne Robertson      

                                  Principal 

                                  The Atlantic Systems Guild Ltd.

                                  11 St. Mary's Terrace     London

                                  W2 1SU     U.K.            

                                

                                      mail: suz...@systemsguild.net

                                      phone: +44(0)20 7262 3395

                                      http://www.systemsguild.com

                                      http://www.volere.co.uk

Video interview on Requirements  http://www.release.nl/? with Suzanne Robertson 

by Robert de Ruiter of Software Magazine in the Netherlands.

Look at our website http://www.systemsguild.com  for worldwide details of our seminar schedules

For more on Volere requirements techniques go to  http://www.volere.co.uk  

Talk to other Volere users on the Volere Linked In Group Volere Requirements

http://www.linkedin.com/e/vgh/2491512/

================================================================