Axosoft wants to hear from you about how you use OnTime!  Please read below! 

I wrote a blog entry just now and pointed over to this thread...here is the blog post:

---

 "Your Company's Process in OnTime"

The one thing I do here at Axosoft more than anything else are presentations of the OnTime software to customers.  This may include pre-sales demos or post-sales trainings.  During all the time I spend with customers, the most recurring set of questions I get asked about are how OnTime can manage the process of a company.  Questions in this area are usually similar to the following:

-How does OnTime manage reporting the same defect from multiple customers?
-When a user opens a feature, I want the user to select what kind of feature it is and then be shown certain fields on the screen based on the type of feature...can OnTime do this?
-I want to get e-mails when a task reaches certain workflow stages.
-What are the best ways to go about building multiple workflows?

In my last blog, several people communicated that an understanding of "good process" in OnTime is something that customers want to hear more about.  One suggestions was to create "templates" of different kinds of processes that new users or potential users could examine toi see exactly how OnTime can handle certain process situations.  The easiest way in my mind to build such a set of templates are to start with the user community...and so I have an assignment for anyone who would like to take a few minutes out of your day to help me.  

I am going to create a thread in the new "Project Management Forums" under "General Discussions" titled "Your Company's Process And OnTime".  What I need from anyone who is using OnTime is to write up a post about how your company users OnTime:

What types of Objects are you using?  How are objects moving around in your database?  What kinds of things are users doing to enforce your process?  How have you bulit Security Roles around your process?  How have your build your Workflow(s)?  What types of Notifications are being used?  

The more information we get in this thread, the better I can track and build a series of templates for new and existing customers to explore different ways to use OnTime.

Thanks in advance for your input!

---

So what we're looking for is input from YOU!  How are you using OnTime?

---

Michael Robinson
Axosoft Training Specialist

Click here to learn about Axosoft University!

Here's a copy of the latest entry from my blog...it's a good example of a way that OnTime can be used:

 

---

 

In my last blog, I discussed that there are lots of ways to use OnTime and that new users sometimes feel overwhelmed with the amount of freedom that they have while implementing the system.  So I asked people to write about the different ways they use OnTime in our new "General Discussions" forum.  The best way to get people started is to write up how I am using OnTime to track my day-to-day activities at Axosoft.

As a member of the User Education team, I spend much of my day giving demos and training sessions to our customers.  One of my early tasks at Axosoft was to set up a system for coordinating training and demo sessions in an organized manner.  What better way to do this than with OnTime? :-)

First, I needed to figure out what objects to track.  I originally needed to track three kinds of objects:

• Small Business Demos
• These are given once a week to a group of users
• PRO Demos
• These are scheduled individually with the individual customer
• Trainings
• These are individual training classes scheduled with the individual customer
• Axosoft University Classes
• The Axosoft University classes were added more recently and track our weekly scheduled classes
  

To set this up, I chose "features" as my type of object and created four directories underneath a parent directory called "Professional Services".

 

 I then began adding items underneath these directories.  Highlighted below are a series of "Pro Demo" items that I have given.  Each line entry represents a different demo that I have given to a client:

 

Next step is creating the field templates for these entries...what information do our trainers and salespeople need to access about demos and trainings?  These are things like:

• When is the presentation scheduled?
• Who is supposed to show up?
• What things am I supposed to be covering and are there any special circumstances? 

After the demo/training:

• How did it go? 
  
• Are there any action items I need to perform after the event?
• Is there any pertinent information that our salespeople need to know about after this event?

To properly capture and display this information I designed a series of field templates.  For demos, I designed three templates:

 

These represent the three views that a user will get about the item.  Different Workflow states will drive when these field templates are used to display the demo item.  Here is an example of how a demo looks as it moves through our process:

On this first screen, the salesperson enters the information about the demo itself.  Here information is passed to the presenter about what the demo should cover or any other important information.  Once the salesperson writes up the demo request, it is then sent over to the trainers:

 

You'll notice that the screen gets much larger here--this is because the presented who performs the demo/training needs to record a number of additional pieces of information.  To use these field templates, I designed  a few different OnTime Workflows to incorporate our different object types.  Here is the one we use for demos:

There are four main states that a demo can be in.  Workflows allow us to quickly search for items based on state and the state can also control how the item looks.    Here is a different example that we use for our Training Workflow:

The steps for a training object are different...trainings sometimes require some additional followup action from a salesperson or tech support representative.  Additionally,  the "Training in Limbo" state designates if a customer has paid for a training over multiple sessions, but only attended one session and wants to save their other session for another time later.  I hope this is a good example of how the trainers at Axosoft use OnTime to schedule our demos and trainings.  Development and Marketing have completely different ways that it is used--this is just a solid example of our process. 

 
So what processes are other people using to manage their flow of data?  How are you running things with OnTime?

---

Michael Robinson
Axosoft Training Specialist

Click here to learn about Axosoft University!

Hi Michael,

Great post!  Okay, I'll do my best, but unfortunately I can't use illustrations like you did since I don't want to exhibit any proprietary info... I'd mock something up, but I don't want to.

Objects:

The only objects we use are Defects. Currently we don't make use of the Incidents or Tasks. We don't use the Features tab either, since there is currently no consolidated Defects/Features tab, making it difficult to see who's doing what at a glance. So policy dictates that users pretend that that Features doesn't exist for now. :-)

Projects:

Our projects are set up so that the top level of the heirarchy mirrors our CVS (source control) module names. The second level mirrors the names of the .sln("solution") files available within those modules, and the 3rd level mirrors the sub-projects within each solution.

We have also set up special customer project names, with the convention "Customer - [Customer name]" under the name of the solution which they are licensing. They are given access to this branch from the Customer Portal, and it allows us to finely tune what defect items can be accessed by this customer.

Customer Portal:

Testing/evaluation/setup of this feature is still in progress, so it is not yet in use.

Policy:

To establish policy, I made a little video using Camtasia Studio 4 (which I believe is the app AxoSoft uses for thier tutorials). I don't like "Lunch-and-Learn"'s, and neither do our users. Unfortunately, nor do they like watching 13-minute videos! So in order to get them to watch, I had to tell them all that I "trash-talk them" throughout the video. That seemed to do the trick! :-)

We set up our workflow step field templates to be as intuitive as possible to users so that very little policy needed to be established in order for them to use it correctly. We were also very loose with workflow, since our company has a very long-standing tradition of not bottlenecking the development team with too much process (see Workflow section below). However, we did establish the following 3 policies:

1. After a user has completed their action item for a defect, the user *must* select the next appropriate workflow step from the list. This selection must be made *before* any other fields are filled in. This is because the edit fields are dynamically configured and default to values relevent to a selected step; so selecting a new workflow step *after* filling in fields may render the newly entered data irrelevant.

2. If a defect being added was originally reported by a customer, the customer/contact's name must be selected from the "Customer who reported this defect:" field in the Customer Portal tab. This will allow us to sort, group, and filter based on customer and contact names.

3. Stick to the Defects tab for now. Especially don't use Features.

Security Roles:

Currently we have only 4 security roles; Administrator, Developer, Tester, and Project Manager. The Project Manager has most privileges enabled except for Features and Incidents (the latter of which does not even appear as a tab in our GUI thanks to the Setup Wizard configuration). Testers and Developers generally do not have access to any of the management-type features, and cannot assign tasks, etc. Testers cannot view work logs, since it is none of their darned business! :-)

Aside from Admin, no users have access to the Edit Defect feature. This is because I wanted to force all users to edit within the workflow.

Workflow:

Workflow is set up in a very non-restrive non-linear manner such that most users can select most workflow steps from most workflow steps (with a few exceptions which I will explain below). Our company is a small one, without enough employees to fill every single role. Therefore there will often be cases where a user fulfills the duties of a developer, AND a manager, AND a tester on a particular defect. So for example, a developer might find a bug in their own code, assign it to themselves, fix the bug, verify the fix themselves, then mark it closed and check it into source control. While that is not the most ideal scenario, we allow it to be used in extreme cases with the caveat that the privilege can be revoked if not used sparingly.

All of the workflow steps are set up with Force Edit checkbox selected on the Item Edit Template tab, so that the user is prompted for the relevant fields for the workflow step they just selected. This takes the guess-work out of which fields need to filled in and when, and by whom.

Also, all of our workflow field templates are modified copies of the workflow template that preceeded it. This means that each subsequently selected step retains all of the visible fields and required fields of the preceeding step (with a few exceptions). Doing this makes it so that if a user skips a bunch of steps in the workflow, no fields are missed; the user is still prompted for all the fields that were required many steps back, and cannot use workflow step skipping as a "loophole" to avoid entering data.

The workflow steps drive certain fields; for instance, the Status field is automatically changed every time a new workflow step is selected. Also, the Assigned To field is automatically changed to the relevant user whenever possible. When a step is selected where one of these fields needs to be changed by a user (rather than being defaulted to a value), the field is changed to Blank, and I make sure to flag this field as Required in the template so that the user cannot close and save without filling it in.

We currently only use one workflow, and it is applied to All Projects. The "Enforce workflow step selection for items" checkbox is selected, and new items are placed into "Bug FOUND=>Needs verification". Moved items are also placed into that step, although we would very much like to see an option that allows moved items to be placed into the step that is currently selected for that item. (Are you listening feature request guys? :-) )

The workflow steps are given names that reflect the action item that was just performed, as well as the required action item. For example..

"Bug fix ATTEMPTED=>Needs verification"

...denotes the action that was just performed (fix attempted), and the action that needs to be performed next (needs verification). Each step has its own template, but for the sake of brevity I won't include the details of each one... sufficed to say they contain Required and Visible fields relevant to that step. We have the following workflow steps, listed in order of selection:

Bug Found=>Needs verification

Step Actions: Date Found is changed to [CURRENT DATE], Status is changed to "Open-Awaiting Verification" (the status field is driven by the workflow step selection), Assigned To is changed to me (the main tester).

Allowed Next Steps: "Bug clarification ATTEMPTED=Needs verification" and "Bug fix attempt FAIDED=>Needs re-visiting" and "Bug RE-OPENED=>Needs re-visiting" cannot be selected by any users, from this step. "Bug Fix IN PROGRESS" and "Bug fix ATTEMPTED=>Needs verification" cannot be selected by the Tester role from this step (it wouldn't make much sense for a tester to be able to select either one of these, so this is done to eleminate confusion)

Bug verification FAILED=>Needs clarification

Step Actions: Status is changed to "Open-Awaiting Clarification", Assigned To is changed to [REQUESTED/REPORTED BY].

Allowed Next Steps: Same as above, only "Bug FOUND=>Needs verification" is also un-selectable from this step.

Bug clarification ATTEMPTED=>Needs Verification

Step Actions: Status is changed to "Open-Awaiting Varification", Assigned To is changed to me (the main tester)

Allowed Next Steps: Same as above

Bug VERIFIED=>Needs to be assigned to Dev.

Step Actions: Status is changed to "Open-Awaiting Assignment", Assigned to is changed to the name of the project manager. Priority is set to Required for this step.

Allowed Next Steps: Same as above, only "Bug verification FAILED=Needs clarification" and "Bug clarification ATTEMPTED=>Needs verification" are also un-selectable.

Bug ASSIGNED=>Needs to be fixed

Step Actions: Priority is changed to [Blank] (it is also set as Required in the field template... this is done so that the project manager is forced to fill this field in. If I didn't blank it out, the PM would not be promted (forced) to change it, and could just as well save & close without changing this field.), Status is changed to "Open-Assigned".

Allowed Next Steps: Same as above, only "Bug VERIFIED=>Needs to be assigned" is also un-selectable

Bug fix IN PROGRESS

Step Actions: Status is changed to "Open-Fix In Progress"

Allowed Next Steps: Same as above, only "Bug fix ATTEMPTED=>Needs verification" is also un-selectable

Bug fix ATTEMPTED=>Needs verification

Step Actions: Status is changed to "Open-Awaiting Fix Verification", Assigned To is set to [Blank] (and is also set as Required in the template for this step), Actual Duration is set to [Blank] (and is also set to Required in the template for this step). A custom field called "Fix attempted by:" is required for this step, so that the "Assigned To" field can be free to assign the task of verifying the fix.

Allowed Next Steps: Same as above, only "Bug fix IN PROGRESS" is also un-selectable

Bug fix attempt FAILED=>Needs re-visiting

Step Actions: Status is changed to "Open-Re-Assigned", Assigned To is set to [Blank] (and is also set as Required in the template for this step)

Allowed Next Steps: Same as above, only "Bug fix IN PROGRESS" IS selectable.

Bug FIXED=>Needs to be checked in

Step Actions: Status is changed to "Open-Awaiting Check-in", Assigned To is changed to [Blank] (and set as Required in the template for this step). The Fixed By field is set to Required in the template, and the user is required to copy the custom field "Fix attempted by" to it.

Allowed Next Steps: Only "Bug fix attempt FAILED=>Needs re-visiting" and "Bug Closed" are selectable from this step

Bug CLOSED

Step Actions: Priority is changed to [Blank] (and is no longer Required), Status is changed to [Blank] (and is set as Required and Editable in the template for this step -- this is so that the user can select between various "Closed" options, like "Closed-Not a bug" or "Closed-Fixed", etc.), Assigned To is changed to [Blank].

Allowed Next Steps: Only "Bug RE-OPENED=Needs re-visiting" is selectable from this step.

Bug RE-OPENED=>Needs re-visiting

Step Actions: Status is changed to "Open-Assigned"

Allowed Next Steps: Same settings as the "Bug ASSIGNED=>Needs to be fixed" step

Notifications and Alerts:

I've set up Workflow Step Notifications to be sent to [REQUESTED/REPORTED BY], and either [ASSIGNED TO] or [LAST UPDATED BY] (depending on the step selected), and our project manager. I've also set up Global Notifications to go to [REQUESTED/REPORTED BY], [ASSIGNED TO], and [LAST UPDATED BY] whenever a defect is changed.

I've set up an Alert to monitor whether users are actually advancing the workflow step. This Alert is sent to me whenever a user has modified fields for a bug without changing the workflow step. This was originally sent out to [LAST UPDATED BY] with the email header "Defect Id 50 raised Alert :Workflow Step Wasn't Advanced! (Just a reminder in case you meant to but forgot :-) )", but users found it annoying since there were often cases where it was necessary to update fields without advancing the workflow step. I was nearly lynched. So now it only goes to me.

I would love to create an Alert that's a "timed reminder" so that users in the Assigned To field will receive an alert [every x [amount of time]] while [condition a] is not met. Currently this functionality is unavailable.

Public Filters:

I've got "All My Defects", "All My Open Defects", and "All Open Defects". I haven't come accross any need for others, although if there were an ability to create one called "All Open Defects as of [a dynamic or static time/date, e.g. Last Week, or March 31 2007]", I might do that. Currently this functionality is unavailable.

That's all I can think of for now.

Just a quick note that you can create filters based on dynamic date ranges.

---

Hamid Shojaee
Read the Ship Software OnTime Blog
Axosoft, LLC

Thank you for your very detailed response!  It's always so interesting to hear how other companies are using OnTime!  Here are a couple things I found interesting about your process:

•  "The only objects we use are Defects."
• I've heard from a handful of different companies before who only use one tab because they want all their data in one tab
• "...all of our workflow field templates are modified copies of the workflow template that preceeded it."
• This is smart...you have a good grasp of how Workflow and Field Templates work together.
• "I would love to create an Alert that's a "timed reminder..."
• Well depending on exactly what you are trying to do, this is possible.  Creating an alert using a filter allows you to check for a state, much like what you are describing.  For instance, I could make a filter with the parameters: "Last Modified Date older than one day" AND "Workflow Step = Some Step" AND "Some Variable = Some Value".  Then I could create an alert tied to this filter that will send an email to [ASSIGNED USER] if the filter's conditions are met and the system will check this alert every X amount of time.
• "although if there were an ability to create one (filter) called "All Open Defects as of [a dynamic or static time/date, e.g. Last Week, or March 31 2007]", I might do that"
• The date parameters that we have available for filters are very close to what you are describing...much like my example above.  You could create a filter like this:  "Status = Open" AND "Date Fixed = 'Last Week'"
  

And again, thank you for your valuable input! 

---

Michael Robinson
Axosoft Training Specialist

Click here to learn about Axosoft University!

That's a good point about timed filters.  I'll give that a try!

OnTime 2007 never ceases to amaze me; every time I need to do something specific, if I look hard enough the solution is almost always there!  Sometimes that solution is in the form of a workaround, but it's rare to encounter one that's not an acceptable workaround.

Regarding the workflow templates, I learned that trick through much deliberation and discussion with other forum users.  It seems as though that's the only way to keep users from using workflow step advancement to bypass having to fill in required fields.  It's actually a pretty esoteric subject; I doubt if anybody casually browsing this forum would understand that concept, without having gone through the pain of trying to figure out how to make OnTime dummy-proof.

Another similar thing I experienced was, how do I get my users to actually advance the workflow step?  OnTime does not really have a built-in feature that reminds them to advance the workflow step.  The solution lies in Alerts; theoretically, if I set up an alert with "Generate alert when [Workflow Step] doesn't change" specified on the Alerts "Add Field Change Trigger" tab, it will send out an alert email whenever a user changes a defect item without advancing the workflow step field. 

Unfortunately it wasn't that simple since the [Workflow Step] selection is not available for selection from that list!  So I had to create a custom picklist called Workflow, then populate it with all of the workflow step names, then update the actual workflow steps to automatically change this field whenever a new workflow step is selected.  So if I then specify "Generate alert when [Workflow] doesn't change", it effectively produces the same result. 

I then ran into the problem of conveying to users the purpose of the alert email, since apparently OnTime 2007 doesn't allow you to provide any customized text in the email body.  A little more searching led me to the discovery that whatever I name this Alert, will be appended to the title bar of the email!  So I named the alert ":Workflow Step Wasn't Advanced! (Just a reminder in case you meant to but forgot :-) )", and this displays the following header in the alert emails:

"Defect Id 60 raised Alert :Workflow Step Wasn't Advanced! (Just a reminder in case you meant to but forgot :-) )"

Not perfect, but it was better than nothing!  I could then set up the alert to send these emails to [LAST UPDATED BY].  Unfortunately, it turns out that there are a number of real world usage cases where a user might actually need to update fields without advancing the workflow step.  So I started getting flogged for this, and I ended up modifying the alert to only send the emails to me.  It still works out well though, because at least this way I can monitor who's using it correctly and judge on a case-by-case basis.  If I see a case where a user should have advanced the workflow but didn't, I can make them aware of it.

I would love to see more "tips and tricks" like the above-mentioned ones posted somewhere.  If you can gather up more of these and put them in a future blog, that would be awesome.

That's some really great feedback, Brian.  Thanks for taking time out to tell us about your experiences with OnTime.

>>  I would love to see more "tips and tricks" like the above-mentioned ones posted
>>  somewhere.  If you can gather up more of these and put them in a future blog,
>>  that would be awesome.

I'm shooting for doing this little by little in my blog.  I just put one up about some of the confusing aspects of Tasks. I plan to keep posting them to help out those who use OnTime.

 

---

Michael Robinson
Axosoft Training Specialist

Click here to learn about Axosoft University!

Hi Michael, I have been trying to implement a similar system to the one mentioned in your blog fo our demos and training.  The thing I can't work out is did you use custom field labels for some of the fields such as 'Date and time of event' or are these custom fields.  I can see where you can change field labels in the system options but I presume these are global and not on a per-project basis.  Am I right in assuming that the atendees and follow up actions fields are custom fields?

Yes, I used custom fields for this.  Even though the custom fields are global, they don't apply to other projects because only my project's field template is using that field.

---

Michael Robinson
Axosoft Training Specialist

Click here to learn about Axosoft University!

A small bit about our company:

We are a small company developing a web based application.  We have ~10 large customers, who are companies themselves, that use our product.  We will be using On Time to manage the requests of those 10 customers.  These customers usually have a single point of contact with us.

 

Starting with the Projects Layout:

 

We've structured our Project Layout like

All Projects

            -All Customers

                        -Cust1

                        -Cust2

                        -Cust3

                        ....

                        Internal

 

This allows us to select the All Customers project to deal with our requests on a company wide level, or we can select individual customer projects when talking with a specific client.  Each Customer will have accesses to their own project through the customer portal.  We have also setup an Internal project where our personal company items can be located and yet still grouped together with our customer requests.

 

The Available Tabs:

In our setup we have only two tabs.

 

"Defects/Features" This is the default defects tab renamed to Defects/Features.  This is where all of our client requests come into or are recorded in the system.  As we term it, this is the ocean of stuff our clients want us to work on. Through the customer portal a customer can add/view/edit these items, giving them the ability to manage there requests and their priorities right in our system.  No more of clients keeping their own lists, and our project managers having to translate them into our lists, its all in one list. This is a PM's playground, the general developers do not have access to make modifications here.

 

"Tasks" This is the default features tab renamed to Tasks.  There are some major reasons for not using the default tasks, most notably, security, and workflows.  Our Tasks are created and assigned to specific individuals by a Project Manager, and then those workers must work through the workflow for an item.  The reason we assign Tasks and not the Defects/Features to people is that generally a Defect/Feature is made up of multiple tasks for multiple people which would make the Defects/Features tab horribly cluttered if we tried to capture all that there. This means that if we were to look at the Tasks tab as a whole for all customers, this shows our current workload as we don't generally assign tasks to far into the future. Tasks are the meat of what developers deal with.  This is where they pull their assigned list of what they should be working on.

 

 

How it all works in a very simplified way:

 

A customer logs in to our customer Portal. Then add a new feature, for example, they would like to see a new field on a web page.

That request would be entered as an item under Cust3 project under the Defects/Features Tab. It comes in with a workflow status of Reported.

When these requests come in, the project manager(PM) for that customer would recieve an email.

 

There would be some communication between the Customer and the PM to possible clarify any details.  The PM would then set it to a work flow status of Verified.

 

At some point the company decides to pursue this defect/feature.  The PM opens up the item in On Time.  He sets the workflow to assigned, which sets the client visible status to "in progress".  Using the "add related item" feature, he adds two new Tasks.  One for the Database administrator to add the field to the database, and one for the Web Page Designer to add it to the webpage.  These related items help a PM and Developer to identify the "other half" of the request.

 

The Workers then work through a workflow for each Task.  The PM receives updates for these items, and when they are both completed the PM then can confirm the work is complete with the client and update the Defect/Feature setting the workflow to complete.  This sets the status to Closed on the customer portal.

 

 

 

We are definitely still green on using OnTime and learning as we go.  Hopefully we can get some feedback and suggestions.

mmathieson,

Thanks for your description of how your company is using OnTime!  This looks like a classic "contractor" type setup where companies are given their own physical space on the project hierarchy, thus making it easier when configuring Customer Portal.

The one point of feedback I'd like to make is about your choice to use Tasks as "Features".  You mentioned that this was done for two reasons, "for security and workflows".  As far as security is concerned, you're right--tasks do not have the same security.  Using Tasks as "Features" gives you a stronger set of security to draw from.  But as far as workflows are concerned...they are the same for Features or Tasks.  Workflow mechanics are not different between the different objects.

It sounds like you made a well thought out choice and your plan looks good.  Thanks for your input!

 

---

Michael Robinson
Axosoft Training Specialist

Click here to learn about Axosoft University!

There is a subtle difference in the configuration of workflows between Features and Tasks.  In the Features security, I can remove the ability for users to "edit" an item.  This forces those people to use the edit in workflow methods.

 This sounds like a minor thing, but it makes sure that the workflow requirements and visibility are correctly followed.  Workflows are critical to our processes.  They force people to do things correctly.  It makes my life a whole lot easier especially when trying to keep numerous employees from making accidental mistakes.

I would recommend to anyone else though that if they plan to rename features to something, don't call them tasks.  There are numerous places in the system where even if the real tasks is turned off in the system, it still shows the four options, and we currently have Defect/Feature, Tasks, Tasks, Incident.  We are going to be looking to rename the real tasks to something else to help reduce confusion.

There is a subtle difference in the configuration of workflows between Features and Tasks.  In the Features security, I can remove the ability for users to "edit" an item.

Ah, that is true.  While workflows function exactly the same between features and tasks, the way that you control access to the workflow level is different.  You are corrrect.

This sounds like a minor thing, but it makes sure that the workflow requirements and visibility are correctly followed.

No, this is not a minor thing.  I stand corrected. 

I would recommend to anyone else though that if they plan to rename features to something, don't call them tasks.

Very, very, good point.  That naming convention is very important.

---

Michael Robinson
Axosoft Training Specialist

Click here to learn about Axosoft University!

How?

Well, my last post wasn't threaded. So, here does again: How do you create filters based on dynamic time? Or do you mean you can use things like "Last Week".