Don’t Underestimate The Importance of Workflow …

One of the big reasons that, even four years after the doctor told you about the Procurement Damnation of Project Management most vendors haven’t done anything as per my post last week (read here), is that they have little or no workflow management, a capability that we told you is vital to the modern platform in our post three weeks ago where we were Digging into the S2P Tech Foundations.

Workflow is more than just a platform’s ability to guide a buyer through the application to complete a specific task, workflow is the ability of the platform to be adapted, and adapt, to the processes an organization needs to support, and the ability of the platform to support management of those processes and the projects that create them.

This is something a large majority of software application developers don’t get, and, as a result, something a large majority of applications don’t have. And it’s something that needs to be baked in at the foundations of an application, or the application will never have good workflow capability.

Why is there so little? Because classic application design philosophy, inspired by the waterfall model of software development, has been:

  • identify a problem
  • define the problem
  • translate into requirements
  • detail into functional specifications
  • build a software solution that implements the functional specifications
  • iteratively test and debug until stable enough for release

And the agile philosophy didn’t change much. The only difference is that instead of attacking the full extent of the problem and translating the full problem into requirements, you focused on a core piece of the problem, translated it into requirements, fleshed out, built, and then went back and extended the core, extracted the new requirements, fleshed those out, built new pieces and integrated into the existing solution, and so on.

No thought was given as to how to create a set of self contained units that could be strung together in a workflow to solve bigger problems, which is key to providing a platform that would allow the workflow to be extended and altered and allow the organization to change over time.

And if you’ve invested five to ten years in a platform that has been profitable, do you really want to go back to square one and build it up from foundations the proper way? Especially if you think you can still make money on what you have? Probably not.

And looking to the bigger picture, that’s the state of Procurement 2.0 and why we need new, evolutionary, platforms if we are every going to realize the extent of Procurement 3.0. But that’s another post.