Video on xProcess

There is a new training video available for xProcess developed by Dr Vic Uzumeri of Interactive Point of View. Click on the link below to try it.

xProcess Tutorial

It may take a minute because of the file size, depending on connection speed. Also as it's embedded in a PDF you need a compatible version of Adobe Acrobat. We may get a more generic and faster playing web-based version later so please let me know if you have any problems with this link.

Training graduates in Software Engineering

When gaps in the Blog occur it's a clue something rather distracting is going on! For me it was a long (10 week) assignment in North Carolina training software graduates in the induction programme of a major financial institution. Both challenging and fun, it was also an opportunity to think about the future of the industry in a challenging business environment. To me it is clear that business models are changing so rapidly - frequently totally overturning only recently established major successes - that new approaches to business and software process will sweep through many traditional firms. We taught both agile and iterative-incremental lifecycles (with more emphasis on the latter). However I expect agile to be the only option on such programmes in years to come.

Although I've had less opportunity to participate in xProcess development, we've seen healthy activity on the project over the summer and new interest from projects. For more details check out the SourceForge site here: http://sourceforge.net/projects/xprocess/.

Randomness

It seems that nearly everything that we are formally "taught" turns out to be useless. Yet a few of the so-called "useless" things we do turn out to be invaluable - incredibly useful. And without the "useless" things we do, that do indeed turn out to be useless, we would never have found those incredibly useful ones!

I was struck by Nassim Taleb's story in The Black Swan about the inventor of the laser. Far from having eyesight correction, compact disks, fibre optics, data storage or microsurgery in mind when he invented it, he was just satisfying his desire to split light beams. As Taleb observed "We build toys. Some toys change the world."

The moral of the story to me is simple: learn play! Rather than seeing education as the process of acquiring knowledge, we should see it as the first steps in learning to think. The knowledge we acquired may be dangerous, particularly as it displaces the unacquired knowledge that may turn out to be more useful in a particular real-life situation. Where it is useful it can often be acquired when needed, provided our education gave us the means to learn and to inquire.

What is an "overhead" task?

When starting to use xProcess there are a number of terms that may be unfamiliar. What for example is an "overhead" task?

In general terms an overhead task is one which does not directly result in the modification or qualification of a required project deliverable. Under this definition most management activities, meetings, planning and monitoring are overheads, while specifying, designing, coding, documenting and testing are "payload" activities.

In xProcess there are 2 ways of specifying how a task will be scheduled: date-based or effort based.

Date-based tasks are generally more applicable to overheads. They run from a date to a date (the date may be derived from other dates such as project start and end or target dates) and have a specified time (or percentage of available time) to determine the effort required per day. If there are no resources available to carry out the task the start and end date are not changed - they will just consume less time in the schedule.

Effort-based tasks are the more normal type of task in xProcess. They have a specified size and required effort (see this link for the difference between size and effort). Their start and end dates are derived from the effort required and the availability of suitable resources (people who have matching role types and skills).

You don't have to use overhead tasks in your process - for example you could include in your estimates the time that will be required for these other activities. However it is useful to get a view from the time booked to overheads of the efficiency of your process and where improvements might be made.

Nominate xProcess for the Source Forge Community Choice Awards

Source Forge today opened nominations for its Community Choice Awards. Why not nominate xProcess now in any or all of these categories:

• Best New Project
• Best Project
• Best Project for the Enterprise
• Best Tool or Utility for Developers
• Best Commercial Open Source Project
• Most Likely to Change the Way You Do Everything

Vote now - it only takes a click!

Resourcing your Scrum Project

In a previous article I explained how to set up a Scrum project in xProcess and the steps to go through to set up a Scrum project in xProcess:

1. Import the Scrum process into your data source.
2. Create a project (setting the various parameters in the New Project dialog)
3. Add project resources and give people the appropriate Scrum role (e.g. Product Owner, Scrum Master or Team Member)
4. Create the first Sprint
5. Create backlog items
6. Create a Delivery
7. Ensure Team Members update their tasks regularly.

Here I want to look in a bit more detail at adding project resources.

Clicking the Resources icon on the Project Toolbar (see image above) takes you to the resources tab for the project where you can add people to the project and also change their roles. There are 3 roles defined in the Basic Scrum process: Product Owner, Scrum Master and Team Member. Adding in people with these role types is the next step.

The tasks for Product Owner and Scrum Master are defined under "Administration and overheads" in the task hierarchy and they are date-based tasks. This means they run between specific dates (in this case the dates of the project) and are assumed to take a fixed amount or proportion of time each day. You can change these amounts by double-clicking on the task and adjusting the Required Resources. Some teams don't need to track time spent on Product Owner tasks and only wish to record work on stories and technical tasks in Sprints. If so you can can remove this task from the plan and leave the Product Owner out of the resources. It just depends what information you need, or might use later to improve your process.

Once you've defined your resources, here's what the "Available Resources" tab of the project might look like:
You can see the hours available for each person on the project and also the roles. If you need to change availability either at the company level, an individual level or for the project you can do this by opening the Availability tab of the organization or person, or by using the "Manage Project Availability for..." button on the project's "Available Resources" tab.

The Scrum configuration has one other field which uses the resource levels on the project. It's on the "Set up" tab which is found at the bottom of the project window. The field is called "Number in team member role" and it is used to size Sprints correctly when they are first created. You should enter the number of teams members (assuming they are all full time). If some are part-time, or some like the Scrum Master working on other tasks as well, remember to allow for the "Overheads level", which by default is 80%.

The next task then is to define Sprints. More later...

Using the Workflow Server

A number of people have enquired about the xProcess Workflow Server recently and whether they can download it from SourceForge and run it. Though you can download and build the source code (see instructions on the Wiki to find out how to do this - and which projects here), we’ve not included the Workflow Server in the pre-built packages for download. Instead we are supplying it as part of a support package for clients in order to ensure that we can put all the components in place for any specific implementation of workflow.

The xProcess Workflow Server runs on Tomcat and is designed to respond to events that occur within the xProcess Data Source (detected by the DataSourceMonitor) or in external systems (detected by custom Monitors). Typical uses for the Workflow Server are

• to integrate with other systems, such as bug tracking systems, that are running in your environment
• to notify users by email of changes to plans or processes
• to update external systems with changes that have occurred in xProcess.

There are some useful blog articles (referenced below) that help understand more about the Workflow Server:

• Developing your own workflow monitor
• Discussion of a typical tracking system integration
• Example State-transition-diagram (STD)

The last article in the list discusses the use of the in-built STD for definition the actions triggered by internal changes (e.g. sending notifications when the state of tasks, targets or resources change). Only this mechanism allows workflow mechanisms to be changed without writing Java code. However even this mechanism requires a significant amount of set up, for example to include email servers and to define OGNL actions, which are triggered on state changes. This is why it is best to download the source code itself if you want to really unleash the full potential of this feature of xProcess. You can build the Workflow Server directly, set up email servers and other configurations, and integrate with your own code for external system monitors.

Also included in the source code are a number of examples of workflow usage, including and integration with the “Flyspray” bug tracking system. When running, this automatically creates tasks to correspond with confirmed bugs in Flyspray, and also updates the status of the issues when the xProcess tasks are closed for example.

Open Source Announcement for OpenXprocess

This press release is hot off the press. You read it here first!

Date: 1st May, 2009
Location: SOUTHAMPTON, UK.

Ivis Technologies and xProcess Europe announced today that xProcess will now be available under an open source license, expanding its already substantial user base to a much wider community.

Also announced today was the setting up of a new company, OpenXprocess Ltd, to own, manage and support xProcess and supply training mentoring and maintenance services to users worldwide.

xProcess allows users to define project management processes (for example task patterns, artifacts, gateways and workflows) and then run live projects while monitoring targets, deliveries and process compliance. Agile methods for software development such as Scrum, FDD and variants of Unified Process are particularly well supported by the technology, which provides priority-driven ordering of activities and resource balancing. The free download of the product includes pre-configured processes for Scrum and other methods. Read more…

Scrum-xProcess: step by step

I always tell people who are starting with xProcess to try the simplest things first, and in particular to try out "Simple Process" before embarking on processes which have more complex features configured, like the Scrum and FDD processes. This is just so you get the idea of what the scheduler does, how to reprioritise tasks and the effects of adding resources, manually assigning tasks, adding constraints (dependencies) and using the gantt and burndown charts. So it's a good idea to read The Simplest Possible Way to Get a Project Plan before reading this article because that takes you very quickly through those first steps.

So I'm assuming you've had a play with those first steps of setting up a project in xProcess and now you're ready to use a more configured process, in fact to use Basic Scrum 3. (Note processes can be easily changed in xProcess so it's very possible further changes have been made to this process by the time you read this article! The principles should hold though.)

These are the steps to go through to set up a Scrum project in xProcess:

1. Import the Scrum process into your data source.
   
2. Create a project (setting the various parameters in the New Project dialog)
3. Add project resources and give people the appropriate Scrum role (e.g. Product Owner, Scrum Master or Team Member)
4. Create the first Sprint
5. Create backlog items
6. Create a Delivery
7. Ensure Team Members update their tasks regularly.

The first two steps can be done separately or together. Firstly ensure you are in the Project Manager perspective (if you see either "Project Participant" or "Process Engineer" on the toolbar, click the icon and change to "Project Manager"). Then click on the "Projects" button on the Project Toolbar (on left usually) and then select "New". This brings up the dialog shown at the top of this page. Here you can select the Basic Scrum process and import it. Then at the top of the same dialog select this process and hit next. This brings up the dialog shown here.

More to come...

Getting started with Scrum-xProcess

There are several useful articles on Scrum-xProcess in the blog and if you're starting using the process it's worth having a browse of these to guide your initial set-up.

Using the pre-defined Scrum process - this is the first of a series of articles on using Scrum-xProcess. You can follow them sequentially from this article.
Don't burn out... Burn Down! - discussion of burndown charts.
Calculating team velocity - discussion of velocity and productivity.
Rescheduling tasks to the date you want - what to do when then auto-scheduler doesn't schedule a task when you want it!

I'm going to start a new article now to take you through step by step of setting up a Scrum process. Here's the link to that one... Scrum-xProcess: step by step.

Opening the source...

The source code of xProcess is finally being released today after several months discussion and negotiation concerning the ownership and licensing terms for the code. We settled on the GNU Affero General Public License and having dotted all the i's and crossed all the t's in the legal documents, it's finally out there. Enjoy!

In search of a definition of uncertainty in three point estimates

I've written elsewhere in this blog about the value and theory of three-point estimating (3PE). See "3PE - why I use three estimates where one might do!". The main practical snag with using 3PE in an agile context is the additional overhead of thinking of 3 numbers every time you want to confirm "effort to complete" - ideally something people can quickly update even on a daily basis.

So I'm working on a mechanism which shows the level of uncertainty in an estimate to complete which takes into account the effort completed to date (T) and the three points of the estimate: best case (b), most likely (m) and worst case (w). If you're interested in the intricacies of such things, please read on!

The composite estimate (E) is the estimate is the derived "median" which is used when one number is required (as for example in the "Total" field in the screenshot above). It is derived from best case (b), most likely (m) and worst case (w) as follows based on assumptions about distribution of cases between best and worst:

E = (b + 4m + w) / 6

Various formulae are possible for our level of uncertainty or estimate risk (R). Here's a starting point expressed in terms of just b and w as follows:

R = (w - b) / (w + b - 2T) ..................................[1]

This expresses the average "error", (w-b)/2, as a proportion of the average time to complete, (w+b-2T)/2. However since it ignores the most likely estimate, it doesn't take into account that for example the worst case may be much further away from the most likely than the most likely is from the best case. An alternative formula would therefore be:

R = (w - m) / (m -T) ........................................[2]

But this formula ignores the best case completely. One could say the "error" should be defined as whichever is greater out of (w-m) or (m-b), but actually it's not this aspect that worries me practically. The worst case is always more significant from a forecasting viewpoint, and from an estimating viewpoint it is the one that can be much further in error than the best case, which can never go lower than T and in practice will always be a little bit higher than T (or you can forget about estimating and just finish it!).

So a better approach is to define the "error" in the formula for R relative to the median estimate, E, all three points are then taken into account. It's much more satisfactory.

Following this approach, here's the formula for the uncertainty in the estimates (estimate risk) that I'll be using:

R = (w - E) / (E - T) ........................................[3]

For those interested in the mechanisms within xProcess to use this formula, there'll be a discussion on that project's wiki about how users can set estimate to complete and level of uncertainty rather than worrying about 3pe every time they update time to complete.

Inaugural meeting of the Southern UK Scrum User Group

Several scrum enthusiasts in the South of England have decided that, rather than spending a few hours on the train to get to the London Scrum meeting, it would be a good idea to get together more locally to talk about Scrum. The inaugural meeting was last night at the Inn on the Furlong in Ringwood (easy reach of Southampton, Bournemouth, Winchester, Salisbury and so on). Apart from some excellent discussions about people's experiences with Scrum we were able to savour the very fine selection of real ales from the Ringwood brewery. If you're in the South of England and interested in joining us next time check out the group's forum discussions on LinkedIn here.

How to define a custom report in v3

There are 2 ways to generate a report on a project. One is to right-click on a project and select "Reports", and the other is to select from the File menu: File -> Menu -> Custom Reports and then select the type of report you want and its subject. For example using File->Export we can select a "Work Log" report for a person or a task.

What if the report we want isn't in the list? Can you write your own report template? Yes you can - that's what this article is about.

Let's say I want a report on a task in the project. I need to define an "Action" in the process I'm using, identify that action as an "Export Action" (checkbox in the Action dialog) and define the file extension for the report. Let's say in this case we want an html file. You can see in the screenshot this action being defined. Note that the "Applicable to:" field has been filled in as "Task" and also the "Expression:" field has been given the value "name". This won't be a terribly fascinating report but even so let's run it!

Use the File-> Export-> Custom Reports menu and select one of the tasks in your project as the subject of the report. Once you've supplied a filename and pressed "Finish" you should find that a browser is launched and a page generated containing the name of your task. Congratulations you've generated your first xProcess custom report!

So what about doing someting a bit more interesting. As you've probably guessed by now that will mean looking in a bit more detail at the "Expression" field. The script that goes in this field must be written in OGNL so you need to know a bit about that language - if you'd like to read the (quite small) reference manual click here - and a little bit about the xProcess Java API. (You'll also find the OGNL reference manual in the xProcess Help documentation.)

So let's try a slightly larger bit of OGNL to generate our task report. How about this:

'<h1>' + name + '</h1>' + '<br>' +
description + '<br>' +
'Start: ' + start + '<br>' +
'End: ' + end50 + '<br>' +
'Closed?: ' + closed

You could even turn this into a report on all tasks in your project. First change the "Applicable to:" field to "Project" (this will also mean you can invoke it by right-clicking on your project) and turn the above code into a subroutine that can be called for every task. Like this...

#taskReport = :[
#output = #output +
'<h1>' + name + '</h1>' + '<br>' +
description + '<br>' +
'Start: ' + start + '<br>' +
'End: ' + end50 + '<br>' +
'Closed?: ' + closed
],
#output = '',
allTasks.{#taskReport(#this)},
#output

Browse other Actions in the predefined processes to see other examples of using OGNL. Then if you make a report you think others will find useful - or if you need help with syntax or the API - post it to one of the xProcess Forums on SourceForge. See xProcessForums.

Define the process behind your projects

To get started with xProcess it's sensible to start with a pre-defined process - the Simple Process for example (see "The Simplest Possible Way to Get a Project Plan?").

However defining your own process in xProcess needn't be complicated. First thing is to switch to the Process Engineer perspective via the toolbar across the top of the screen (from the default Project Manager perspective). The explorer view in this perpective shows you the processes that have already been imported into your data source and you can create a new process simply by clicking on the process icon in the task bar on the left hand side.

Here are some of the other things you can create in a process:

• Project pattern(s)
• Task patterns
• Role Types
• Category Types
• Gateway Types
• Workflow Packages
• Artifacts and Artifact Types

Start by looking at some of the Task Patterns in pre-defined processes like Basic Scrum and Basic FDD which come included in the download. You can see the structure of the task and project patterns by using the hierarchy or process diagram. When you define a parent task in a pattern you can define what kind of child tasks can be created in the parent by right-clicking on the task and selecting New -> More Patterns... This makes it easier for Project Managers to build sets of tasks that match the process you are defining.

There are many other aspects of Process Engineering with xProcess to discover. If you are interested in taking the on-line course for the Certified xProcess Engineer qualification, contact us now through the xProcess site on SourceForge.

Theory of Constraints and Agile Project Management

Recently on the LinkedIn forum PM Toolbox, Arash Sadati asked for comments about tool support for how Goldratt's Theory of Constraints (TOC) or Critical Chain Project Management can be integrated as part of the Agile Project Management. Here are my thoughts on the subject.

One thing all agile projects share is that - because of a conscious removal of dependencies between features wherever possible - they will be resource constrained rather than critical path constrained (a generalisation but broadly valid). Methods like Scrum-XP try to avoid specific role constraints (e.g. we can't make progress because we don't have a BA or a GUI expert or a middleware expert available) by specifying only 3 role types (Product Owner, Scrum Master, Team Member). So the team as a whole must to some extent be generalists (or at least prepared to learn / fill in specific roles) to reduce the risk of role constraints. In any real application of Scrum of course such role constraints may be real and teams will have to pay attention to them. The default condition though is worth understanding because it's a means to keep the effect of role constraints to a minimum.

FDD defines many more roles and I think as a result there is a greater risk of role constraints. Availability of specific class owners for example is a typical problem which Palmer and Felsing discuss in their book on FDD. Flexibility, especially in small teams, for people to wear multiple role "hats" is crucial. The really interesting observation in comparing agile to waterfall is the requirements process where detailed specification of features is ideally "just in time". David Anderson and others point out that it is a serious waste of precious resources to allow too much work to be done on future requirements when the critical constraint is the development team.

When we were specifying the xProcess product which is designed to support any priority-driven process (any agile process in other words), we did want to be able to give visibility to problems arising from role or resource constraints. Patterns of tasks can be defined in custom processes that require specific or general roles - or even allocation to specific team members - so that forecasting can take into account not only the total development effort available, but in the cases where specialised roles are required. It can therefore show the impact of limited availability of critical roles. Custom reports can be generated to show resource utilisation, and where these show less than 100% utilisation, the situation is likely to be one where specific roles are "critical", requiring other roles to wait for them.

The Simplest Possible Way to Get a Project Plan?

I want some work done - so make a new project...

Ok. Here are the tasks that need doing (I can enter them as a comma separated list).

My task list forecasts that these tasks are never going to complete. I guess that's because I don't have anyone to work on them. So add myself as a resource to the project.

Good. They're now being scheduled but I don't think the most important things are being done first. I need to prioritise...

That's fine. They're in order and I can create a Timebox to show what will be done in the first two weeks. Let's have a look at the forecast Gantt and Burndown charts...


Seems ok but all the tasks have the default estimate of 2 days. Next job is to estimate those tasks properly. Oh and I also need to add in the other project resources, and when they're going to be available to the project. Once that's done I'll have a plan I can show my manager.

Mmmm... That didn't take too long!

FDD sub-processes in context

Like most agile processes FDD doesn't pretend to cover every aspect of the software development life-cycle. Just the essentials for establishing a common approach. In particular FDD doesn't explicitly state how and when releases of software occur during or following an FDD iteration.

Here's a diagram that attempts to put the releases in context and also shows the distinction between the first 3 sub-processes which define the project (or iteration), and the multiple instances of the 4th and 5th sub-processes which develop the project (iteration). There can be just one release at the end of an FDD iteration or (more normally?) several releases which deploy the developed software.

What's different about Folders?

When you're deciding on the structure of project patterns for a new process, often the first thing to consider is how to represent the different hierarchies of elements that make up projects.

In FDD for example there is the hierarchy of features, normally described as being Features, which are contained in Feature Sets, which are contained in Business Areas or Major Feature Sets. This logical grouping of functionality is independent of priority and time-ordering. It may well correspond to the structure of the user manual for example or the Functional Specification should such a document be required. It doesn't give us any time view. On the other hand the hierarchy from Releases -> containing Timeboxes -> containing Features is a time-based structure. Similarly the hierarchy based on the five subprocesses of FDD also will have a time correspondence: The Definition Stage -> containing FDD#1 Develop Overall Model, FDD#2 Build Feature List, and FDD#3 Plan by Feature; The Build Stage -> containing many instances (for each feature) of FDD#4 Design by Feature and FDD#5 Build by Feature; and the Release/Deployment Stage following completion of a release.

Each of these hierachies is an important view of the tasks and artifacts in the project. However when defining a process in xProcess you must decide which hierarchy will define where a task "lives". This is the parent-child hierarchy of tasks and is analogous to a directory structure which tells you where a file is located. All the other relevant hierachies can be represented with Folders which contain explicit or implicit (defined by rule) references to the tasks. This means that different features may appear in different Timeboxes and Releases, and indeed different subtasks of a feature may appear in different folders (design and build for example may appear in different timeboxes; build and certify a feature may appear in different stages). Since Folders may contain Folders in xProcess as many hierarchies can be provided as are required to understand the process, each to several containment layers if this helps understand the view.

So Folders provide an alternative hierarchy of tasks to the main parent-child structure. Their membership is defined either explicitly (because the process has put them there or the user has dragged them into the Folder) or implicitly (because the task has a matching category to the category of the Folder). In some methods it is sensible to use the parent-child hierarchy for time-based structure (Basic Scrum 3.0.1 follows this scheme for example). In others using a more static structure such as Business Areas/Feature Sets in FDD or a Work Breakdown Structure in traditional methods, gives the preferred structure for parents-children with more dynamic hierachies being represented with Folders.

Description of the xProcess product

xProcess allows projects to define their own processes... and make and monitor plans that conform to those processes.

Projects may start from predefined processes such as those for Scrum, FDD, Iconix, Unified Process or Prince 2, or define their own. Using their process definition, projects can be defined, resources added and tasks defined, estimated and prioritised. xProcess then provides forecasts for the project against which targets can be set.

Once a project is started the participants on the project can access the tasks they have been assigned and record hours worked against tasks, adjust estimates of time to complete, add artifacts (such as documents or links to managed files) and close tasks, including (if the process requires it) completing task "gateways" to show compliance with intermediate steps of the task.

Thus xProcess supports process definition (including several graphical views of the process patterns), project management (including defining and estimating tasks, forecasting, timeboxing, target definition and monitoring, gantt, pert and burndown charts) and project execution.

The main client for accessing xProcess information is an Eclipse RCP application. There is also a web server which provides browser access for project participants. The RCP client has 3 perspectives for: Process Engineers (defining processes); Project Managers (defining and monitoring projects); Participants (reviewing and recoding their work on the project).

xProcess project on Source Forge

With various announcements, activities and releases in the pipeline, you may be interested to know that there is now an xProcess projects on SourceForge. The site is http://xprocess.sourceforge.net and althought as of this moment there are no downloads available there, the forums, announcements, wikis, etc. of the project will all be moving up there soon. Why not post a message there now?!

Calling Software Development Process experts!

Did you know that from January 2009 the xProcess project is going open source?

This means that projects worldwide will be able to download and use free process definition and project management software and, if they are so inclined, configure and improve it for their own use. At the same time we are launching a new services company OpenXprocess. This company will incorporate xProcess Europe (and xProcess US), and manage the ongoing enhancement of the product, while offering services to users of xProcess such as: training in Scrum, FDD, Agile, Iconix Process, Unified Process, Prince and other configured processes of xProcess; configuration of the product to companies’ own development processes; and a support package which includes the web server for access to project data from browsers.

This is where the software process experts come in. Would you be interested in learning about xProcess and potentially offering services to configure processes or consult with clients using existing configurations? The Scrum configuration in xProcess for example provides a number of unique features which are not available in other Scrum tools (task matching, forecasting, three-point estimating, target management, multi-dimensional prioritisation) as well as familiar Scrum tools such as burndown charts (including burndown forecasts), Gantt charts (auto-generated) and backlog management. If you would like to be involved I’d very much like to hear from you.

The process configuration capabilities of xProcess, particularly now it’s an open source product, offer important innovations for the industry, and I’m particularly keen to involve experienced software consultants in this area. In the past process definitions have been of only passing interest to project managers, useful guidance but completely separate from the plans they work on day by day. xProcess changes this relationship since it is now possible to define processes that instantiate directly into project plans and aid conformance with the process (or highlight differences) as plans are implemented.

Project processes are often described with Activity diagrams or similar notations. But these are notoriously difficult to map to the actual activities of a project. With xProcess the process is described in terms of task patterns which, when instantiated within the initial project pattern, show the trackable tasks that are required to complete that part of the process. Where aspects of the process involve activities that are below the level of trackable tasks – for example a development task may involve say, coding, testing, integrating and building – these steps may also be captured in the process definition through xProcess’s Gateways, which are defined in task patterns and are completed as questions and answers on closing a trackable task. And because task patterns may themselves contain task patterns the process definition language gives as much flexibility to define optional, repeating or iterating structures as activity diagrams do, but with the important difference that they map directly into the plan structure that projects implement.

If you’ve read this far I hope that means I’ve at least aroused your curiosity to investigate further. You can download the product from www.ivis.com (soon to be www.openxprocess.com) and I very much hope you’ll do this and encourage colleagues and clients to do likewise. But you might also be interested in getting directly involved. In Q1 2009 I’ll be conducting some training workshops for potential xProcess consultants or process engineers (probably in Denver and London). Please let me know if this might be of interest. The training will last 2 days with the opportunity for a further 3 days collaborative work on a process of your choosing – this can be carried out either immediately following the training event or remotely at your convenience, with access to me via phone, skype or teleconference. Following completion of this we will offer certification as “Certified xProcess Consultant” so that you can offer services to clients directly or through OpenXprocess. OpenXprocess will only use certified personnel for training and consulting services and will support certified consultants in the field to help ensure your success.

If you know of others who may be interested in this, or companies who you feel might want to adopt xProcess, please let me know.

Wishing you all the best for 2009.

Andy Carmichael.