In several issues we encountered an ambiguous usage of project management terminology within the Storm module. For example, a "Storm Ticket" has several categories, including "Task". Also there is a own content type for tasks (Storm Task), but it should be either a ticket or a task, not an ambiguous mixture of both. Also, a Storm Ticket can be assigned the category "Task", but it can't be resolved with a Storm Task.

To resolve issues like this, I'm suggesting to develop documentation for the terminology used in Storm, especially definitions what the different content types are, how they relate to each other, and what they are supposed to be used for. This might help to clean up terminological confusion like in this issue #1178720: Allow to resolve Storm tickets with a Storm task.

Comments

asb’s picture

For starters: Wikipedia definitions.

Project, http://en.wikipedia.org/wiki/Project

In project management a project consists of a temporary endeavor undertaken to create a unique product, service or result. Another definition is a management environment that is created for the purpose of delivering one or more business products according to a specified business case.

Or, more general, from Oxford English Dictionary:

A project in business and science is a collaborative enterprise, frequently involving research or design, that is carefully planned to achieve a particular aim.

The key elements from those definitions are: "temporary endeavor" - "collaborative" - "carefully planned" - wants to "achieve a particular aim" (= product, service or result).

Task (project management), http://en.wikipedia.org/wiki/Task_(project_management)

In project management a task is an activity that needs to be accomplished within a defined period of time. An assignment is a task under the responsibility of an assignee which should have a start and end date defined. One or more assignments on a task puts the task under execution. Completion of all assignments on a specific task should claim the task as completed. Tasks can be linked together to create dependencies.

The key elements from those definition are: "activity" - "defined period of time" - can have "assignments" and "dependencies".

In Storm's terminology, an "assignment" probably matches more or less a "Storm Ticket" (at this point, Storm seems to move away from project management and switch to Bugtracking terminology).

Ticket (in an Issue tracking system), http://en.wikipedia.org/wiki/Issue_tracking_system

A ticket is an element contained within an issue tracking system which contains information about support interventions made by technical support staff or third parties on behalf of an end-user who has reported an incident that is preventing them from working with their computer as they would expect to be able to. Tickets are commonly created in a help desk or call center environment. Typically the ticket will have a unique reference number, also known as a case, issue or call log number which is used to allow the user or support staff to quickly locate, add to or communicate the status of the user's issue or request.

This terminology is interesting since it matches the usage in Storm (tickets are created not by the end user, but "in a help desk or call center environment"). However, we'd still have no way for users to report an incident within Storm.

In this definition the connection between "Issue" or "Case" and "Ticket" isn't clear to me. Wikipedia continues:

Issue (in an Issue tracking system), http://en.wikipedia.org/wiki/Issue_tracking_system

Issues can have several aspects to them. Each issue in the system may have an urgency value assigned to it, based on the overall importance of that issue. Critical issues are the most severe that should be resolved in the most expedient way possible, taking precedence over all other issues. Low or zero urgency issues are minor, and should be resolved as time permits. Other details of issues include the customer experiencing the issue (whether external or internal), date of submission, detailed descriptions of the problem being experienced, attempted solutions or work-arounds, and other relevant information. [...] each issue maintains a history of each change.

So there seems to be a difference between an "Issue" or a "Case" and a Ticket". If we actually had a way for users to post Issues in Storm, we'd get a Issue tracking system ;)

juliangb’s picture

I'm not convinced that there is a major difference between a ticket and an issue - and hence don't see the need to have issues as well. Some systems will use issues, some tickets.

On the definitions of task and ticket, IMO the Storm types seem to match fairly well.

How can we progress this to a solution?

asb’s picture

Probably there is no quick solution. Maybe we should wait for comments of other users.

If we say (Storm) Ticket := Issue, we run into this again:

Issue management, http://en.wikipedia.org/wiki/Issue_management:

In Project Management, the purpose of Issue Management is to ensure that any concerns recognized during a project are addressed in a timely manner and do not go unresolved until they become major problems.

That's the definition I'm familiar with, and this leads us again to the dead end since there is no way to address Storm Tickets since they're the end point of the content type hierarchy. Thusly, we'd need to say: (Storm) Task := Issue.

Process Flow in the Issues Management Process from Source: http://www.pmhut.com/issues-management-process:

  1. Document the Potential Project Issue: "The most common source of these issues is from the Status Reports of Project Team members. When an issue is recognized, the Project Manager should document a general description of the issue, the potential impact of the issues and any suggested resolution for the issue." In Storm and if Storm Ticket <> Issue, someone files a task (which is actually an issue);
  2. Assign Ownership of the Issue; in Storm, someone assigns the Task to a Storm Person or a Storm Team;
  3. Document Resolution: "When the issue is resolved, a description of the resolution and date of closure should be documented."; in Storm, the asignee files a Storm Ticket.

A typical issue workflow in product or software development, according to http://en.wikipedia.org/wiki/Issue_management:

  [issue submitted] -> [open] -> [in evaluation] -> [in work] -> [in test] -> [closed]

Where the [in test] and [in work] phases often loop, and none of this would imho work in Storm, unless all phases occur on the same Storm Task node (which would mean to lose the phases' history, and it wouldn't allow for proper loops). Indeed this is complicated :-(

juliangb’s picture

Version: 6.x-1.x-dev » 6.x-2.x-dev
Status: Active » Closed (won't fix)

I'm not convinced that we need to define Tasks / Tickets more specifically.

Please reopen if there is specific action we can take to help.

kaizerking’s picture

Hi juliangb,asb
For your benefit of understanding The a project will be as follows
1. Project is a structural plan frame to execute a work/job
2. Job is broken in to chunks/pieces of work We call WBS element(Work break down Structure) according the requirement/feasibility. granularity/accountability.Some call this as Task some as WBS Element in MS Projects it is called "Task"
3.Each WBS element may have or may not have Activities i.e the actual execution such as digging a trench where the value addition happens to the work, The WBS element may/can have one more WBS element in parallel or Hierarchical tree structure the levels can be un limted.
4.These Activities may or may not be linked/related to each other
5. An activity will have a start time and Finish time
6. When a relation exists between the activities then we define relations as SF or SS or FS or FF
Start to Finish ,Start-to Start, Finish to Start, Finish to Finish
7 if there is time gap between two activities then we call the deference as "Float"
8.The activities as a group is called Activity Net work or simply "network"
9.Where there is not enough float and deadlines or very strict and narrow the work path of activities is called Critical path.
10 A Project Typically have stages
a) Plan -> Schedule->release->Execute->Report(confirm the work done in quantities) ->Close
All the stages can revert to previous stage if wished how ever all the changes have to be logged to record to report and see the variations in plan change to attribute the changes in result. This is normally viewed in graphs, bar charts, pie charts S curve apart from normal tabulated sheets etc..
11.Every time you plan or change plan you need to extrapolate ->schedule or re-schedule
12. Scheduling means declaring the start date and end date and the flow of activity network.
13.Planning is done for various resource This is known as Multi Resource Planning (MRP)
1.Cost planning (plan the costs estimates for various WBS Tasks or Acivities)
2.Financial planing(Budgeting)
3.Material Planning (included in cost Planning)
4.Work Force Planning
14.Same way Scheduling is also done for Multiple Resources it is called Multi Resource Scheduling
it determines what is required, where is required when is required .How much is required is the "plan"
It may be a good idea to call the task as WBS task to make it is easy for all

Now coming to the point of Issue:
A issue is the mother of task , it is only a point of concern or a requirement raised by the client or team member, which will be converted in to a task or Activity and a resource allocated (plan) give time lines and Schedule,the resource will execute/solve the problem and report(confirm it is done and enter the times) Sometimes there is a client acceptance for the work and then the times will be approved -Close
hope that clarifies.

Just yesterday only i happen to stumble on this STORM while i was searching for Project management module.downloaded the D7 version, read the document provided in the documents, it seems the document is for D6 needs work for D7.
I did not get how it works can some one put the steps please