The kernel Journals 9: Is our way of working fit-for-purpose?

The kernel Journals 9: Is our way of working fit for purpose?We have seen in the previous kernel journals that a process kernel, defined in terms of the key domain entities, or Alphas, and their value state progressions, can give us a simple, shared view of what each and every project has to achieve (which is common across all projects), that is distinct and separate from how they might go about doing it (which may vary from project to project).

If we provide projects with at least one “how” (practice guidance) for each and every “what” (alpha state progression), then no team ever has to discover or invent new ways of working. But, if we allow teams to adapt or substitute any specific piece of practice guidance with an alternative means of achieving the same end, then we can empower teams to adopt a way of working that best suites the evolving needs of their project and team circumstances.

This approach has significant benefits for process quality auditing and assessment too. In the past, quality assessors within an organization have often had an up-hill battle to determine which process a given team thinks it should be following, before they can even start to assess whether or not it is an appropriate process and finally whether or not the team is actually following it.

Being pointed to a “tailor down” process like the Rational Unified Process has never been popular with quality managers in my experience. The RUP may document everything that any project of any size might ever conceivably need to do, but everyone knows that no project ever should or could attempt to do all of it. But determining and documenting which bits of process do or don’t need to be done is challenging and onerous for projects (and therefore is either not done well or not done at all). Likewise, assessing whether the bits of process that the project team is supposedly doing, together constitute a complete and coherent process that is “necessary and sufficient” is nigh-on impossible.

A process kernel on the other hand provides a process quality assessor with a simple process-coverage checklist. We know that each and every project needs to achieve each and every alpha state progression somehow. If the project team knows how they will go about trying to achieve each and every progression, then they have a fully defined process that is both necessary and sufficient (in terms of coverage at least). A process quality assessor can therefore be presented with a project team’s defined process in the form of the standard set of alpha state progressions, with each one pointing to the practice guidance that the project team is following in order to achieve the progression.

The current state of the project is easily assessed as it is expressed in terms of the progressions that the project has made, each of which points to the evidence that shows it has been achieved, expressed in the way the practice guidance suggests it should be. The process assessor also knows which practices should be currently “in play” and guiding the planning and execution of the current project activities and tasks – these are the practices that relate to the state progressions that the team hasn’t achieved yet, but is striving to achieve next.

The kernel thus enables process quality assessors to effectively and non-invasively assess what process is theoretically being followed, whether it is fit for purpose and whether it has been and is being successfully followed.