[thor] Proposed Thor changes

[Carlos Pedrinaci]

Given that definition of what an Objective is I think that we could see
a Project (from the Plan point of view) as:

* Project-Plan:
---------------
A Project-Plan is composed of (0..*) Project-Plans (of its Sub-Projects
if any) and (1..*)Objectives.
There may exist the typical relations between them (End-End, Start-End,
etc..).
Every Project-Plan has a set of costs estimations and may have some
"known costs".
These are all derived from the Project-Plans and Objectives that compose
the current Project-Plan.
 

* Objective:
------------
An Objective is composed of (0..*)Objectives and (1..*)Tasks (Nag Tasks)
It has also these pieces of information:
>   * Description of problem
>   * Description of solution
>   * Estimated number of hours to implement.
>   * Test script (human-readable instructions on how to prove that the
>     modification was made and works)
>   * Estimated number of quality assurance hours.
>   * Required resources (conference rooms, projectors, particular
>     employee (Joe Fabetes), or a class of employee (Web Designer) etc.)
>   * The objective's history (using Horde_History::)
>   * Business case information about the objective (estimated ROI, net
>     present value, how the return is generated e.g. labor savings or
>     revenue increase or increased accuracy, etc.)
>   * The objective's state (e.g. "initial", "agreed", "completed",
>     "in progress", "cancelled")
>   * Required expenses (e.g. hardware purchases).
>   * Dependencies (on other objectives). 

See that I clearly make the difference between a Project and a
Project-Plan as I also want Thor to serve as a Project Repository a la
SourceForge.

I'm not sure about whether the fields you want to add to the Project
should be part of the Project itself or part of the Project-Plan. I tend
to see them more as part of the Project-Plan mainly because that
information strongly depends on the company. We should allow some sort
of customization for that... but this doesn't seem obvious to achieve.


Carlos.


On Sat, 2004-02-28 at 19:27, Jason M. Felice wrote:
> This is an excerpt from our internal "software roadmap".  These are the
> additions we'd like to make to Thor, plus Thor-related additions we'd
> like to make to other applications.
> 
> We envision using Thor to track all the stages of a project, including
> the preliminary proposal, the specification-writing and research phases,
> tracking approval status working on the project, quality assurance,
> delivery and signoff, follow up and analysis, and then (hopefully) back
> to preliminary proposal.
> 
> * Add the concept of "Objectives"
>   
>   An objective is a unit of work.  It is one concrete, measurable
>   action, for example "add an invoice entry screen."  It contains many
>   pieces of information:
> 
>   * Description of problem
>   * Description of solution
>   * Estimated number of hours to implement.
>   * Test script (human-readable instructions on how to prove that the
>     modification was made and works)
>   * Estimated number of quality assurance hours.
>   * Required resources (conference rooms, projectors, particular
>     employee (Joe Fabetes), or a class of employee (Web Designer) etc.)
>   * The objective's history (using Horde_History::)
>   * Business case information about the objective (estimated ROI, net
>     present value, how the return is generated e.g. labor savings or
>     revenue increase or increased accuracy, etc.)
>   * The objective's state (e.g. "initial", "agreed", "completed",
>     "in progress", "cancelled")
>   * Required expenses (e.g. hardware purchases).
>   * Dependencies (on other objectives).
> 
>   Refining objectives in our organization is an interative process which
>   happens outside of a proposal (sometimes before a proposal is
>   written).  We want to have our consultants refine objectives even if
>   there is no immediate plan to implement them.  Maybe six months or a
>   year later we can review unproposed objectives and go back to the
>   client.
> 
> * Add fields from our proposal template.
> 
>   I'd like to add fields from our proposals to Thor projects:
> 
>   * Project overview
>   * Project assumptions
>   * Project deliverables
>   * Project milestones
>   * Executive summary
>   * Project approach
>   * Check off legal boilerplate which applies.
>   * Project scope (what we are and aren't quoting).
>   * Organizations affected, project organization (sponsor, executive
>     sponsor, maybe an org chart).  We actually don't use this much,
>     though we should.
>   * Estimated cost for different types of labor.
>   * Name and title of person signing to approve project.
> 
> * Add PDF-print capability.
> 
>   We'd like the ability to provide a template for the proposal (probably
>   a .xsl stylesheet) and have Thor create a PDF.  It would also be nice
>   if we could have it directly email or fax proposals.  Nah, not worth
>   it :)
> 
> * Add payment schedule ability.
> 
>   Add information about payment on the proposal.  Are we billing hourly,
>   and for what sort of labor are we billing hourly?  Is it fixed bid?
>   What's the down payment and how much is paid per milestone and on
>   delivery?  What are the invoice terms for milestone-type payments?
> 
>   Is there a recurring service payment (for hosting or retainer)?  What
>   interval and how much and until when?
> 
>   This information will allow us to project our cashflow to some degree.
>   Also, billing will eventually be done completely out of Horde and I'd
>   like completed milestones to be automatically billed with the next
>   billing cycle.
> 
> That's it for Thor, but there is also:
> 
> * Add the ability to bill time to a project (or objective?) in Hermes.
> 
>   So we can track actual vs. estimate.  Also so we can bill with correct
>   rates per project automagically.
> 
> * Export Thor workflow hooks when we get workflow stuff implemented.
> 
>   So we can make Thor tasks (refining and sending proposal, reviewing
>   requirements, QA testing, post-mortem or follow up, etc.) part of the
>   organization's workflow.  Also, each project has a sort of
>   sub-workflow with dependent tasks assigned to different users.  This
>   seems like an interesting interrelation, but it's something I'd like
>   to put forth.
> 
> 
> There is no set timeline for these additions.  We've estimated the
> amount of time and/or money each would save and/or make us, and we'll do
> whichever is most valuable at the moment--probably not for a few months,
> anyway.
> 
> FYI, all of these points would be "objectives" in our system, had we the
> system now.  Except of course that if we had the system, we wouldn't be
> doing any of these because they'd already be done.
> 
> -- 
>  Jason M. Felice
>  Cronosys, LLC <http://www.cronosys.com/>
>  216.221.4600 x302