It should be a new story, and maybe more than one. The companies that I can see are the following:
* Construction companies * Installing companies * IT development projects Basicly all companies that creates something using projects as a way of working (establishing an organisation, has its own budget and has a start-date and an end-date). Companies that are using projects for the way of working multiple projects to make deliveries. The major challenge is to keep track of materials used to make deliveries. Should the project make or should it buy (I tested the BOM-simulator, and that could be used for that decision). If it decides to by it will use an order. If it decides to create, it will use tasks and man-hours. All of these companies has something in common: There will be something delivered to a customer, and there needs to be deliver documents to go along with it. Therefore there is a need of a list of deliveries as well as tasks. Torstein -----Opprinnelig melding----- Fra: David E Jones [mailto:d...@me.com] Sendt: 23. juni 2009 00:01 Til: dev@ofbiz.apache.org Emne: Re: SV: ASF Board Report for 2009-06 This looks like a good start Torstein. How do you see this fitting in with the stories that are currently in the UBPL (ie: http://docs.ofbiz.org/display/OFBREQDES/Universal+Business+Process+Library+I ndex)? -David On Jun 22, 2009, at 1:23 AM, Torstein Hegbom wrote: > Please find the user story below: > ------------------------- > 1.1 A delivery project > A delivery project will deliver some functionality, where the > functionality > is based upon a requirement from a business organisation. The > functionality > is some text that describes an organisation, some processes and some > business rules. > > The delivery can be a physical piece, a building or it can be an IT > system. > All of these has in common that there is a need for a project > organisation > to deliver. The project will have a planned start-date and a planned > end-date. The project will have an project organisation and a project > manager. > > The most important role of the project manager is to manage the > changes > impacted on the project organization. This can be changes external > to the > project, changes in the project staffing or changes in what and when > to > deliver. If the project manager fails to manage these details, the > project > will fail. However having a good steering group and a good change > management, the project manager has good prospects to succeed. > 1.2 Two different preconditions > Below there is mentioned two different cases where a project can be > initiated. > 1.2.1 A new delivery for a new customer > If there is not an established customer, there may be a RFQ (request > for > information), and there may be a bid-process. In any case the result > will be > an agreement for a delivery, with delivery-terms. The agreement will > outline > a delivery date and the functional requirements. > 1.2.2 A new delivery for an existing customer > If there is an established customer, there may be cases where the line > organisation finds the delivery too big (too many man-hours) that > cannot be > done in an ordinary maintenance delivery-release, and decides to > establish a > new project. > 1.3 Change orders > All changes related in dates or functionality will be handled by the > project > manager (and the change manager), by change-orders. The change > orders can be > written by the customer or the supplier, using a computer or a hand > held > device. > > These change orders are analysed and estimated by the project > organisation. > The analysis will describe the impact on the delivery date and the > added > cost for the customer. The change board will finally sign the change > order, > and it will added to the agreement. > 1.4 Project model > All organizations should have a project model, which is used for all > delivery projects. This will make the steering group committee have an > easier job of understanding the status of the project. The project > model > will describe the phases and the decision points in the project. The > project > model can vary from company to company. One project model can be a > delivery > project that has four phases: > . Analysis phase > . Delivery phase > . Verification phase > . Deployment and handover phase > > Note that the project can be split into smaller projects, but all > subprojects will have all phases, independent upon the method used for > implementing the requirements. > 1.4.1 Decision point > Within each phase there will be milestones. Each of the milestones > has a > delivery that can be celebrated by a cake. If the achievement is not > applicable for a cake, it is not a milestone. Connected to a > milestone there > can be a decision-point. A decision that cannot be made before the > milestone > has been passed. The decision point is related to the project and the > information to the decision is quantifiable, and could relate to > cost and/or > resources. Milestones can have dependencies and can be used as an > outline > plan before adding the tasks. > > The decision points are numbered DP1, DP2, etc, and the decision > will be > documented, so that the next project will learn from this project. > 1.5 Analysis phase > The main goal of the analysis phase is to detail requirements and > details > the plan. The result should be a functional description giving > details into > the specifications, what and how to deliver and the dates of the plan. > > The following documents should be produced from the analysis phase: > . Functional specifications describing what will be delivered, > connected to the requirement in the agreement > . For each functional specification there will be written acceptance > criterions > . The plan will be detailed > . A Bill of Materials (BOM). A document that describes what pieces and > documents that will be delivered internally and externally to aid > the final > delivery (including verification and training). > 1.6 Delivery phase > The delivery project will be to produce the results described during > the > analysis phase, and to merge in the changes that are arriving from the > change-management. > 1.7 Verification phase > During the verification phase the customer/klient will verify each > piece > that has been delivered from the delivery phase. Normally there will > be an > internal verification before the customer/klient verification is > started. > > The number of changes during this phase is more than in any other > phase, > since everybody now can understand how the end-result will work in > practice. > The change-board will be an aid to keep the process moving and > decide if a > given change will be delivered in the project or the first change- > delivery > after the project. > 1.8 Deployment and handover phase > During deployment there may be a migration process from the old to > the new. > Typically the migration is a sub-project. > > After the deployment has been done there will be a handover phase > where the > project is scaling down after each piece has been handed over and the > training has been finalized. > > When all handover has been done there is a final acceptance, the > agreement > has been fulfilled and there may be written an agreement for > maintenance. > --------------------- > > -----Opprinnelig melding----- > Fra: Torstein Hegbom [mailto:torst...@itpolaris.no] > Sendt: 19. juni 2009 12:29 > Til: dev@ofbiz.apache.org; 'Jacques Le Roux' > Emne: SV: ASF Board Report for 2009-06 > > I don't have access to the space. :-( > > Torstein > > -----Opprinnelig melding----- > Fra: Jacques Le Roux [mailto:jacques.le.r...@les7arts.com] > Sendt: 19. juni 2009 10:44 > Til: dev@ofbiz.apache.org > Emne: Re: ASF Board Report for 2009-06 > > I think you could create a story there > http://docs.ofbiz.org/pages/listpages-dirview.action?key=OFBREQDES > But I'm not sure if you have access to this space. Then adding a > comment at > the right place would be taken into account > > Thanks > > Jacques > > From: "Torstein Hegbom" <torst...@itpolaris.no> >> I have been testing the project manager module, and maybe there >> should be a >> connection to content-management, or something else. Before a project > starts >> there is a set of requirements and suggestions. >> >> A sub-project has a start and an end, where purpose is to make some >> deliveries. The deliveries are described in the requirements. These >> requirements are an attachment to an agreement with the klient. >> >> When a project has been decided the requirements are frozen, and a >> Bill Of >> Material can be created for a sub-projet. The Bill Of Materials will >> describe what the sub-project will deliver, and the tasks in the >> project-plan describes how, who and when to deliver each item in >> the Bill > Of >> Materials. >> >> Torstein >> >> -----Opprinnelig melding----- >> Fra: Jacques Le Roux [mailto:jacques.le.r...@les7arts.com] >> Sendt: 17. juni 2009 02:00 >> Til: dev@ofbiz.apache.org >> Emne: Re: ASF Board Report for 2009-06 >> >> I think it's a bit harder for the wiki part (we hage a project >> manager but >> no wiki), thus need for requirements collection and >> design thereafter >> Anyway, David already sent his links... >> >> Jacques >> >> From: "Ean Schuessler" <e...@brainfood.com> >>> I think the most reasonable first step would be for us to build >>> importers that mirror the state of JIRA into OFBiz project >>> management. >>> All user accounts should be modeled as Party with the proper >>> corresponding roles. Once we see that we can get to a parallel >>> level of >>> functionality we could then transition OFBiz development onto our >>> own >>> infrastructure. Achieving this result should speak more firmly >>> about our >>> intent than any spoken claim and will convince other Apache projects >>> that we have the capability to execute on the plan. >>> >>> Hans Bakker wrote: >>>> In general these subjects were handled by Tim, perhaps better he >>>> reacts >>>> on that? >>>> >>>> i was referring to the last report about Infrastructure, >>>> shouldn't we >>>> mention that we are now using contegix resources and are waiting >>>> for the >>>> infrateam to respond? >>>> >>>> Then there was also a request to use ofbiz for the apache >>>> administration/content management, shouldn't we say we are ready >>>> for >>>> that and are interested to make ofbiz suitable for that? >>>> >>> >>> >> >> >
