I am constantly amazed at the number of PMs -- presumably experienced -- that I speak with that don't seem to grasp the idea of "process". They all seem to know practices: Risk management, change management, chartering, earned value management, etc, etc. But, ask them about how a practice fits into a process and the veil drops.
So, back to "Process 101": Input --> practice --> initial conditions, outcome with controls, constraints, and policies as modifiers/influencers on the practice. See Six Sigma and any of a number of other doctrine -- like PDCA -- about processes and process control.
And, this matters because: Because it's about dots, connecting the dots, and having a project narrative to govern by. Narrative is what makes the connection between the business case and the project charter. There's got to be a process to get from 'dot #1' to 'dot #2'.
It's probably too much in a "101" discussion to bring in the idea of process networks with nodes, connecting links, link protocols, and work flow. But, if I ever get the "201" level, those will be ideas we'll explore.
However, even at the '101' level there should be room for a discussion of 'lean' practices -- some say lean processes -- that try to optimize the value add of the process and minimize the waste of overhead. One approach is to look at batch sizes and try to find the minimization where overhead and batch size seem to work together, and to look at parallel/serial task flow, again with the idea of value add maximization.
And, at the '201' or '301' level we might bring in the Theory of Constraints to look at how moving/redesigning a constraint can reduce the cost of the process -- by reducing the cost of process inventory at intermediate steps -- and maximize the throughput.
So, with all this stuff, perhaps I should not be amazed, but I still am.
Check out these books I've written in the library at Square Peg Consulting
