forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ruedi Anneler - A-R-T GmbH, Switzerland" <...@a-r-t.ch>
Subject Re: Project Deliverables List ?
Date Tue, 11 Jun 2002 09:02:13 GMT
Steven Noels wrote:

>First lesson: don't do HTML mail on mailing lists ;-)
>
o.k. thanx.

>
><ruedi>
>A graphical representation of the system showing its major components
>(inputs, main function, outputs) and their collaboration could be of
>value for newbie navigation. Are you interested in getting a draft to
>show what I mean and documenting my understanding so far?
></ruedi>
>
>Yes, please! Seriously! We all like pictures!
>
I draw such stuff with Visio 2000, and can export it in different 
formats. Which format suits best your needs? gif, jpeg, vsd ?
Can I put the drawing in the mailing list? How (is an attachment o.k.)?
For your feedback: I suggest to draw the changes you like by hand in the 
graphics I'll send you, and then fax it to me for rework.
My fax number is 0041 32 353 11 44. Is this procedure o.k. for you? Do 
you see/prefer something else?

>
><ruedi>
>Do you think it's useless to know at least the names, the purpose and
>the attributes of the project work products?
></ruedi>
>
>No. But we don't have a full vision on the deliverables (or 'project
>work products' as you seem to call them). And perhaps we will never
>have. The next thing you'll be asking is a resource/task list ;-)
>
No. For sure not.
I rode from Canada to Mexico with a mountainbike (in case of interest 
you can find the story in www.tuttobene.ch). We have been a group of 12 
people. 11 of them reached the Mexican Border. There are at least 11 
very different ways to ride from Rooseville, MT, to Antelope Wells, NM. 
The agreed by all target location Antelope Wells was of main importance 
to all of us, not the individual behaviour of any of us on the way to 
get there :-) .

The next thing I will probably ask for is a common denominator of term 
definitions for better human communication and proper understanding.
This is normally an external one (e.g. Webster's) for most terms, and a 
small own for terms defined especially  within and for a certain project 
or area of interest (e.g. business terms for a certain business area).
Having such an animal helps to reduce confusion, and to create better 
understandable documents. This will help some of us as english is not 
our mother tongue.
To give an example:
A project is a set of activities or a method devised for making or doing 
something, and achieving an end. It (usually/hopefully) has a limited 
duration and a defined scope.
A project work product is the output of a project activity. Its use can 
be project internal only or project external (within / outside the scope 
of the project).
The lifetime of a project internal work product (this is NOT a 
deliverable of the project) ends with the project.
A deliverable is a project work product that is delivered by the project 
contributors to people outside of the project for further use. Its 
lifetime spans the lifetime of the project (sometimes/hopefully).

You told me that there's nothing like e.g. a project management in OSS.
Could you please define for me what a project documentation is / consist 
of ?
I assume that the websites you will create will contain knowledge of any 
kind that is needed by project contributors and project result 
consumers. If this is the case, your websites will contain a system 
documentation covering the three main categories technology, processes 
and (few?) organisation. The main question by creating and maintaining 
such a documentation are the users needs. This addresses the different 
views onto the system these people can have, leading to the navigation 
(static / personalized on a certain level till a very high degree) your 
website will offer to them. People using a system on the hunt for 
information to a certain subject enter the website from different point 
of views, depending on their actual knowledge, activities, problems and 
need - this might be e.g. an organizational point of view, a technical 
one or a process oriented one. Static navigation always fails to fulfill 
these needs in a fast and efficient way - I have practical experience 
with this (our single information source website offered 8 different 
navigation patterns - aka views - for eight different user groups 
working with the same system). A lot of these people were on the lookout 
for the ninth view. The same is true for static documents containing all 
three categories and their context too in one information item. My 
vision is a single sourced information model cosnsisting of single 
information items describing real objects and their relationships with a 
high degree of granularity. The web site navigation and the web pages 
content is bulit dynamically according to the cureent needs of a single 
user. Such an information model supports all kind of navigation (and any 
combination of them): alphabet (sequence), time (sequence), category 
(class), hierarchy, contextual network.
I suggest to have a closer look on things like WebML, RDF and topic maps.

The attached drawing probably supports a common understanding. This 
simple model helped me to save lots of time in many engagements. It 
tells anybody in the project where we are today and where we want to go 
the next day. It shows wheter theexpected result/benefit can be reached 
or not, and it supports the decision wheter it's worth to jump onto the 
bandwagon or not. Few effort, big benefit.
It shows a high level view of any kind of cooperative work. To start an 
engagement I ask the "consumer" of my project work what he likes to HAVE 
at the end of the project, and try to fill (in this sequence) "Future" 
(might be visionary and not very "sharp", it is developed further during 
the project's lifetime according to knowledge gained), and "Now". It's 
useful to describe the parts givens, expectations, problems, work 
products and benefit and their attributes in terms allowing to see 
wheter one has it or not.
The things of importance for "Now" are defined by "Future". Its not a 
formal list, its only a collection of things I know (and allows to check 
that we understand each other and are talking about the same things).
A comparison of "Future" and "Now" tells me wheter the required result 
is reasonable and can be reached or not.
"Work" can, but mustn't be documented (all of us are smart enough to 
find a way to get from Now to Future, huh?).
The two main parts Now, and Future are not static, they change (can be 
sharpened) during the lifetime of the project.

One last word to this: I'm aware of the fact that most people like to 
talk about what they want to do (wasted a lot of time in such meetings). 
Few like to define what they want to have. If anybody has a good 
explanation for this, I'm really interested in it ;-) .
My interpretation of this is that people like to be involved, but 
dislike to be committed. My understanding of these two terms can be 
explained with the "beacon and eggs" breakfast. By preparing it, the 
chicken is involved, but the pig is commited :-D .
 

>
>Being a fledgling project, I consider Forrest being reasonable
>documented already - we could perhaps do with an update of the todo list
>and some new people contributing to the project however ;-)
>
><ruedi>
>I'm learning about the way the community works. I'll come back with some
>feedback.
></ruedi>
>
>Again, please do so - you're absolutely welcome. Within my perception of
>the world, I think we are a small but friendly community.
>
><ruedi>
>And I'm interested to learn about OpenSource development anyway.
></ruedi>
>
>I like the fact you consider OSS being something which should be
>'learned'. It's just so true: there are many more small
>incompatibilities between closed and open source development than one
>would think off at first sight.
>
></Steven>
>
Start of ado:
I've worked for more than 30 years for IBM (operator, customer 
relationships, application analyst, programmer, systems programmer, IT 
architect, method deployer for project management, application and 
infrastructure design and realization, and have worked in the areas 
infrastructure, IT and business processes, organisation development, 
application development for severel very different industries).
End of ado.
What I've learned is that the things I already know are the only things 
I can't learn ;-) . Second lesson is that I know a bit less every day of 
my life.
I assume that some values of importance for the OSS community differ 
from the values of the "commercial IT world". I assume that some are the 
same, e.g. disliking to waste time by answering questions nobody has 
asked :-D . 



Mime
View raw message