Guessing is not a strategy: How to build decision velocity with AI and real-time data
June 10, 2026 | Live Webinar
Situation: You Are Looking At Ways To Improve Your Core Project Processes... I would summarize the conversation by saying: 
The topic of process improvement has always been interesting to me. Short term business thinking ends up making this sort of refinement a small part of what we do, but it’s often a critical part of achieving sustainable business advantage.
I’ve spoken with Andy Carmichael of Ivis a couple of times on this topic. Their software approach is called “priority-based planning”, is very agile in nature, and involves what I would call “doing the important things as soon as you can”. Recently I asked him a few questions that I think provide some insight into how processes should be improved and which deserve a second look.
· If your projects produce multiple outputs and you can prioritize the work to produce the most valuable things first – do that.
· Some task-level activities are frequently repeated, take a hard look at improving those.
· Projects that involve professionals working together and making judgments that are inherently creating value are particularly good targets for improvement.
· The more that a process is repeated, the more value you will get from improving it.
· The same Classic ROI measures you would apply to any process or business situation would be applicable to processes improved by this approach.
· Historical data is often the best basis for making future planning decisions.
You can see this cuts out a lot of business processes (and business process automation) where the focus is on continuous activities of a clerical or mechanical nature. However it’s also clear that it includes a large amount of business activity and is not just specific to software engineering say. We have clients using or evaluating xProcess for processes in construction, training, legal processes, marketing and a number of IT processes for example.
Dave:
When you talk about priority-based planning, the focus has to be on repeatable processes in order for that refinement to pay off…
Andy:
Yes indeed. Processes need to be repeatable to be improvable. A key strategy to enable this is the recognition, modeling and execution of task patterns. A task pattern is a piece of repeatable activity within a process for a given purpose. Finding them is the first step towards priority-based planning and building a priority-driven process.
Dave:
How do you judge what types of processes lend themselves to this and how often they must be repeated to make software like xProcess worthwhile?
Andy:
It’s clearly tempting to say all processes are amenable to priority-based planning. In some senses they are, but for the moment let’s prioritize!
Our focus is:
- projects (i.e. collaborative activities with a defined start, purpose and expected duration),
- involving professional participants (i.e. people who plan their own work but must nevertheless coordinate their activities with other professionals in the team),
- where the scope, budget and schedule is not completely fixed before the project starts (i.e. where agility to follow changing business requirements is as essential as control of cost and schedule).
How often must they be repeated? We like to think we can provide value on the very first iteration. After that value increases since you have patterns defined that can be improved and experience in the team that is easier to share.
Dave:
Is there a way of projecting ROI?
Andy:
Benefit accrues from several sources in this approach.
- Improvements to process mean quality is achieved faster. This is difficult to quantify until you identify a specific better way of working and can compare. However savings and ROI from such improvements can be immense.
- Prioritizing desired deliverables means that you get some deliverables sooner that you would have, and some later. Assuming the priority order is based on some kind of business benefit per cost unit, the business benefits accrue sooner and at a higher rate than in the non-prioritized case. The ROI can be calculated where you’ve quantified such benefits, and it will be significant and higher the greater the difference between the highest benefit feature and the least.
- The effect of connecting the whole team to xProcess means that forecasting (which is done on each an every change) is based on the most up to date information, and highlights problem areas immediately they occur. This benefit could result in an infeasible project be cancelled months earlier than might have been the case (saving full project costs for these months), and equally it can highlight sources of delays or unused resources. These by and large are decision support benefits. Needless to say, making the right decision provides immediate ROI!
Dave:
How do you measure the impact of process changes and use that information to make future planning decisions?
Andy:
Persuading businesses to measure their effectiveness in this area has never been easy and it doesn’t always happen even when teams have a high degree of focus on process improvement. Having said that xProcess provides the framework for deriving such measures, both during the running projects and after the fact. In software processes measures of “size” are essential to gauge productivity and effectiveness, (for example lines of code, feature points, story points, etc.). In xProcess the units of size are configurable (the default being a “nominal size” measure which is set when creating a task) and this allows effectiveness to be compared in different cases and with different processes or different process variants. It’s a simple starting point but one which can be built on and extended as process improvement activity moves forward. The fact that all historical data is stored in xProcess in its versioned repository is important and enables data on process effectiveness to be examined at a later date.
Posted on: February 19, 2007 12:46 PM |
Permalink