Process Tool Selection Guidelines

Did you forget your: Username / Password ?

Microsoft

TechWell

Home

CM Journal Articles

Process Tool Selection Guidelines

Monday, 22 June 2009 14:07

This article discusses Process tools for Software Development and IT Management and the major functionalities one should look for in such tools. There are not many tools which can be categorized as pure play software development process management tools. Most of the process tools are included as part of the development and management point tools. For example, a bug tracking tool may have a process automation engine to define bug fixing processes. Similarly, a helpdesk tool may have a process to manage helpdesk.

There are a few generic process tools focused on different Development and IT processes within the same tool. These multi-application process tools which facilitate implementation of multiple processes like Requirements Management, Issues Management, Test Management and Release Management processes are becoming more and more popular. The generic process tools broadly fall in two categories - Methodology Specific and Methodology Agnostic. Methodology Specific tools are designed around a particular methodology. Their processes are implicit and embedded in the user interfaces which are specific to the methodology. There are a few commercial tools available which are specific to methodologies such as SCRUM, Agile, Phase-Gate etc. The Methodology specific process tools have an advantage of quicker and more faithful implementation of the methodology. The disadvantage of such a process tool is its limited adaptability especially when the organization wants to deviate from the strict definition of the methodology. A methodology specific process tool has little room to incorporate deviations from the methodology it originally intended to implement. Since over the long term every organization modifies its processes to reflect changes in the organization, business and technology environment, methodology specific process tools have a shorter shelf life.

On the other hand a Methodology Agnostic Process tool is more generic and as the name suggests, can implement a wide range of methodologies. Since it is not designed for any particular methodology, it may take longer time to implement a methodology unless it comes with some built-in templates. For organizations following a proprietary or a modified methodology, a Methodology Agnostic Process tool is the best option. The investment in a Methodology Agnostic Process tool goes a long way as it should be able to accommodate the changes in the business and technology scenarios in the future years.

In this article we will discuss the general features and functionalities we should look for in a generic Methodology Agnostic Process tool which can be used in a wide range of processes in both, the Software Development and IT Service Management Lifecycles.

Task based vs. State based Processes
Most of the development tools have state based process capability. A state based process allows the process to be one state alone at a given time. This is good for a simple process but difficult to implement for a complex process which requires parallel activities. On the other hand, a Task based process allows multiple parallel activities in the process in terms of multiple tasks assigned to multiple process owners each may be doing different things. Trying to implement a process with parallel activities using a state based process tool will increase the overall process cycle time since the parallel activities are to be done sequentially.

Multiple Independent Processes for each Application
For some applications, a support of multiple processes is important. For example, a Helpdesk application may have different processes for different departments. It is possible to create a single monolithic process with branches for each different departmental process. But with a tool that supports multiple independent processes for a single application, it is easier to design, develop and manage different processes in a more structured way.

Visual drag and drop process designer
Different process tools have different user interfaces to define the process. The design interfaces include graphical drag and drop interface, state tables, spreadsheet like interface and the ones with different levels of coding and scripting support. A visual drag and drop interface helps process designer to visualize the process as it is being created. It is faster and easier to create a process visually. However, it is important to choose visual interfaces that have enough flexibility to implement complex processes. A process tool with full coding support can be flexible. But implementation and maintenance takes longer and is much more effort intensive. The need of IT resources for coding for even the smallest changes makes the process maintenance overhead fairly high.

Task Assignments to multiple users/roles based on policies
One should be able to assign single activity to multiple owners in a single step. In addition, there should be ways to support queuing of tasks, load balancing, task sharing by multiple owners and independent owners of a single task among others. For example, sending a change request to a change board of 5 persons should be achieved in a single step rather than 5 different steps. A State based process cannot support any of these needs.

Conditional Branching
This is one of the most basic requirements of a Process tool but missing from many tools in the market. A conditional branching in full form allows automatic selection of the next activity based on the complex conditions defined in terms of various variables of a particular item. For example an Issue follows a particular path if it is a defect and a different path if it is an enhancement request. This routing should be automatically executed based on the field values.

Merging/Joining with quorum-based forwarding policy
Often, multiple parallel activities in a process need to be merged/ synchronized to move the process forward. A quorum based merging allows the process to move when not all but a pre-defined percentage of the previous activities are completed. For example when a Requirement is sent to a review board of 10 persons, the quorum based merging will allow the process to move forward if 80% of the review results are completed.

Process Modification without affecting running processes
In any organization processes change. There is no single ideal process which can address all needs for ever. One should be able to modify processes as the old process continues to be running for the existing items. This allows the managing of the process changes much easier and allows for a smooth new process implementation.

Restart Process at any time for multiple items
When a process is changed one may need to restart the current items running with this new process. With some advanced tools it is even possible to start at a particular step within the new process rather than at the ‘Start'. You may not want to repeat all those steps which are already done for the existing items.

Process Versioning
This is especially needed for any organization that wants to implement CMMI or similar compliance processes. Just like any change management, it is important to track the changes in the process by tracking the versions. So look for a tool which has built-in versioning for the process.

Synchronization among multiple Processes
This feature may not be necessary for a single application process tool. But for a multi-application process tool i.e. the tool which allows implementation of multiple applications like Requirements Management, Issues Management, Test Management, Release Management, the need for this feature is critical. For example, a Release Process should wait for the integration Test to start until all the Requirements and Issues included in that Release are implemented/ fixed and unit tested.

Process Activities triggering Actions in External Tools
Most organizations use various development and management tools from different vendors. Because of the lack of integration and especially for the lack of built-in process ability in most of the point tools, processes are implemented in a very few pockets of the lifecycle and processes across the lifecycle remain unattainable. A process tool that supports activities which can trigger an action in another remote tool by Web services allows the achieving of cross tool process implementation.

As you can see from this brief summary of process tool selection criteria, it is important to spend some time thinking and discussing the process needs with your vendors before making your final selection of the tool for your Life Cycle Management even though your organization currently may not be using any defined "Process". Ignoring this fact may lead to an investment in a wrong tool that may not help the organization as it grows and matures in its desire to implement a process methodology.
For any question you may email to the author Sky Basu at Skyb@kovair.com .

Sky Basu, CTO, Kovair, Inc. is the chief visionary of Kovair, leading product management, building business relationships and shaping strategic direction of the Company. In 2000 Sky co-founded Speedev which merged with Kovair in 2005. Prior to co-founding Speedev in 2000, since 1994, Sky has been co-founder and CTO at AgniRoth, and more recently, the acting CEO. He has worked extensively in the Database and Internet area, delivering mission critical applications for Fortune 500 and Govt. agencies. His innovative ideas and real-world solutions have led to several patents and awards. In 1998 a Web based distributed business critical solution created by Sky and his team received the 'Best Intranet Solution' award from Microsoft.

Sky has 23 years of experience in developing software applications, mentoring engineers and managing software companies. As a champion of Software Engineering Process for more than a decade, he has created various levels of quality and customer focused processes and automation or his own companies and his clients. His experience of distributed development process goes back to late 1980s when software development was more of a black-art than engineering.

Sky holds a Bachelors degree in Mechanical Engineering from the premier Indian Institute of Technology and a Masters in Computer Science from Indian Statistical Institute. You may reach Sky at Skyb@kovair.com .

Set as favorite

Bookmark

Email this

Trackback(0)

TrackBack URI for this entry