Paul’s Patented Process Design Principles (PPPDP) - for software

I want to define a software process - I am very keen to solve world’s problems and make money out of it if possible – so here are Paul’s Patented Process Design Principles (PPPDP) for Paul’s Amazing Process (PAP).

First: I’ll make sure my process has enough roles to map all the existing ones. This way the resistance to change will be minimal once the people realize there will be no change!

Second: I’ll carefully check all the buzzwords in the industry so my process will include for sure references to Design Thinking, DevOps, Lean, Agile, Kanban, Reinertsen, Sange and some more – if three gurus in the industry wrote about it I’m putting it in because it must be important – after all adding stuff is FREEE!!!!

Third: Since my process now contains pretty much everything (yes you haters, also a kitchen sink) it’ll be easy to say that “you’re doing it wrong” to any fortunate soul who might try adopting it.

Fourth: I’ll also make sure that the bubble named “customer” is displayed in the middle of my process diagram in bold so that everybody and their dog will understand how important the customer is in my process.

Fifth: promise 20 to 50% improvement in pretty much every dimension and use testimonies like “by using PAP, Van Gogh managed to create five times more paintings than Paul Signac and my three years old daughter beats them both”. Preferably in industries where productivity measurement is hard or impossible!

Sixth: create a certification program; since the process is very prescriptive it’ll also require a lot of training to get it right. I’ll also promise that upon trainer breathing the same air with participants for 2-3 days the trainees will become PAP Leaders. I'll also claim that the training changes mentalities.

Seventh: goto First; /*I didn't intended this step but then I read that iterative processes are all rage today so stay posted for version 5.0 of my process with bigger bubbles and more buzzwords! */