Enough of generalities. How do you actually, practically, go about setting up your first Kintana Demand workflow?
Let's try to automate the classic 'Bug tracking' process.
Since this is your first effort you're likely to try to do too much at once. Simultaneously trying to make sense of your bug tracking process and to learn enough about Kintana to figure out how to map your process into the tool is a sure recipe for going crazy.
The technical implementation, and the messy details of how to click though all those dialogs to set the workflow up in the tool can wait until later!
Trust me for the moment that getting the business process clearly defined, and collecting a fairly small amount of information about it is all that you need to deal with first.
Step 1 : Defining the business process
What you need to come up with is:
Let's try and define the bug handling process as practised by the Quality Assurance and Developer Teams. Sounds simple enough. After all this is well understood process. Is'nt it?
As you will soon discover, if there are ten people involved in the process, there are twenty opinions on how it actually works. Morover each person involved is likely to consider some detail to be a critical part of the process that must be implemented. If you try and cater to everyone's requirements you're likely to end up with a workflow that looks something like this:
All the extra steps centered on the development team lead are non-essential and while he may want to keep track of them the workflow shouldn't have to.
The path to the left tracks cases where the developer's implemented what the specification called for, which as frequently happens is not what was wanted (or intended). Essentially it's doing book-keeping of 'not-our-fault' cases. This may be very useful protection for the development team lead, but from an organizational perspective a bug-is-a-bug-is-a-bug and all we want to know is how many and how long bugs sit on the Team Lead's door step waiting for a resource to be available to fix them.
The path to the right tracks cases where the development team lead is bundling bugs for fixes on the next interim release, or in effect dumping it by assigning to to be fixed on the next major release. Again this is local housekeeping that would have been better handled by adding interim/major release numbers to the request.
Now I freely admit this was my first workflow. Still, this is not what you want to end up with. Let's learn from my mistakes!
To ensure that your workflow will not get infested with all the pet elaborations that the participants 'need' you must identify a manager who can call the shots on this project. If you don't do this then you'll find that every user invested in the workflow is 'management'.
After the initial all inclusive kickoff meeting, chaired by the manager,keep the initial working group small. The people you want are the ones who know the process from soup to nuts, and they're usually not the section heads. They will be your focus group for your working model, and the test group when you have your first implementation. If you explain the KISS strategy to them properly, they will become your missionaries and strongest allies in defending your workflow from over-engineering.
The key to success here is to cut out the shortest straight-line path from start to finish assuming that everything works out with no problems.
For our bug tracking workflow that means that :
This basically is it, and that's all that's important. From the time your workflow goes into production anyone can now run a report to find out what and how many bugs are just in, with the development team lead waiting for him to find a developer to work on it, being fixed, and finally being checked out by QA.
Just how elaborate your Demand workflow gets boils down to how many 'statuses' you want to keep track of for the request.
For example, consider how you want to handle these cases:
There isn't an absolute answer to these questions.
I'd argue that in the first case, if there aren't a lot of these, and resolving this is just a matter of a phone call,
then it's going to speed the process along if the QA analyst just picks up the phone, calls the bug originator,
gets the required information, annotates the request with it, and moves the request on down to the project lead.
In the second case i'd say that we do need to define a 'Not Approved' flow back, and to the Team Lead, not the Developer because the Team lead may need to deal with resource issues - that developer may now be busy on something else. Also the QA analyst does need to formally document the problem in the notes field, and maybe add references to test documentation before sending the request back to the team lead - the changes may be handled by a different developer.
Cases like this tend to be the stuff and staff of the arguments that need to get resolved before you workflow is ready to go into service and you discover how well you have actually aligned it with the business process as practised in the real world. Try to restrict the number of statuses the workflow tracks to those that get asked in the production meeting. Try to arrange for people to co-operate outside the workflow by informal communication backed up if necessary with Notes and References (to external documents). It's what they do now anyway. You're not being asked to automate the whole world, and your workflow will end up an unwieldy failure if you try to do so.
Step 2 : Defining the information to be transferred
Remember the old yellow inter-office envelope with the the ruled lines for you to fill in the addressee? You filled in a form stuffed it in the envelope, and wound that little piece of string around the button.
Kintana Demand works just the same way. You get an email that an issue's waiting for you to do something. You open the issue and fill in the information you need to add. The only difference is that the string's disappeared, and you press a button instead to send the issue on it's way.
We need to customize a request form to carry your custom bug tracking information. You can add one or more custom sections to carry the information you need. In this case one 'Bug Info' section was all that was needed. (The graphic is from an earlier version of PPM when custom information was grouped under 'Tabs' instead of 'Sections' but this makes no practical difference.)
The status tab shows the progress of the request.
It's good practice to number the (person oriented decision) workflow steps following the shortest-possible-path strategy so that the minimum path steps list first. The other steps can occur in any order.
Now you're ready to map the business process information you've captured into the tool.
Step 3 : Workflow Step definition
Formally define the step names, types (Decision, Condition, or Execution), and Parent Status.
(The Parent Status sets the Request Header Status as a Request moves into the workflow step).
Step 4 : Define Transition-Validation Mappings
Set up 'validations' (menu choice lists) to be made at each step
Each choice represents a 'transition' (workflow branch or path)
Step 5 : Define Security Groups and Workflow Step Security
Kintana Demand allows you to control who has the authority to execute a specific step in a Workflow.
When setting up Security Groups
Step 6 : Define Decision Step Notifications
Notifications may be defined for each Workflow step that will be sent out either when the step is reached, or, if the step is a decision step, when out of the outbound paths or 'Transitions' is chosen.
This allows users to be notified by email if there is an Issue pending their action,
The best way to do this is to associate a security group listing the people to be notified with either the step being reached or an outbound path. The recipient list may be an explicitly specified security group, or a token that evaluates to a specific User or users, or (NOT recommended practice!) an explicit user name.
Step 7 : Define Automatic Notifications
The first step (12) in the system is run when the bug originator submits a new bug request. It has some automated code that uses the application code to look up a list and sends an email to the QA analyst handling bugs for that application.
Note! 'ALL' should NOT be included in the application list or it will flood the inbox of the recipient!