All images © 2008-2019 Cyril Souchon (All rights reserved) unless expressly noted otherwise

Tuesday, December 20, 2011

Four Principles for Understanding and Improving Systems



Edwards Deming is well known for his 14 Quality principles.

What is less well known are the four basic principles of Systemic Improvement that he identified and which underpin all his work. He called these his System of Profound Knowledge.

We could do well to revisit them whenever we~
  • Look to introduce new tools and processes
  • Do Requirements gathering and Functional design
  • Solution architect
  • Build Project plans and Programme manage.
In this article, lets unpack the principles and at the same time (for illustrative purposes) frame them in the context of Function Point Counting:
  1. We must have a deep appreciation of our systems and processes.

    DEEP Appreciation!?
    What's that?
    Why Deep? And what's that mean ~  "Appreciate"??

    Well, it’s certainly more than a process flow diagram, or a set of documentation, I assure you!

    • Its an understanding of the process from the point of view of its strengths and weaknesses, its bottlenecks etc;
    • Its knowing more than the Main process: it's knowing its tributaries and Streams, and why they exist, and how they came about;
    • Its knowing the expedient things that happen off the record, and why these have never been formally incorporated;
    • Its knowing the shortcuts that people take, and why; and
    • Its knowing where the controls sit, and how they protect/limit/constrain the process

    How else do we take advantage of the good things, buttress weaknesses, and find points where improvement is necessary or possible? All the roles, values, responsibilities of the process need to be thoroughly understood in this fashion, and the impact of changes to the process understood/predicted in the same way.
  2. Introducing FP counts must follow this principle: ie know exactly where an FPC is applied, what Gap it is filling, what it replaces or supplements, when it is pertinent, how this feeds back into the wider project, what the window of its value is, exactly: and how that is applied in the project and without. This does not require an expensive analysis with lots of consultants: just knowledgeable people who work within the system capable of collaborating and motivating back to Management.

  3. Simply put: if you cannot measure, you cannot improve.

    This feeds directly back into the first principle, because the importance of measurements is knowing what to measure, when, why, to what level of granularity (because measurements abstract as they accumulate), for how long the measurements remain appropriate, and the time-window within which it is most important to act.

    It is impossible to set these things without that deep appreciation that he spoke to. As a corollary, if you do not have mechanisms to measure and improve, then improvement tools are a drain on the organisation. Function Points are layered measurements, by which I mean they can act at several levels.

    • The first of these is their obvious role as an estimating tool for sizing projects, and as an assist/traffic light in committing to work.
    • A second is across the project, to see how the delta between what was understood/designed early and what was delivered later conforms to a norm.
    • Both of these are project focused.

    • They can also be used to normalize other metrics, as a way to make apples and pears comparable: particularly iro scale. You can do this by referencing other metrics to the FPC baseline. Getting this right is not trivial.

    All this goes to usage: how do we intend to use the FPCs now, at what point do they reach the point where we are confident that the counts are consistent; at what point we become confident that their ability to provide accurate estimates occur; and at what point they shift from measures within a project, to measures that contribute to continuous improvement: the point where Deming’s second principle is met.

  4. The underpinning theory of knowledge must be well understood [from a training point of view and from a Knowledge base point of view]

    • Training because we must know who to train and what to train them with, the depth of their existing skills which make it possible to absorb the content, when and how often to train, what the context of the knowledge must be for its users, this most importantly, because we must at any time be able to justify its value in driving the organizational framework.
    • We also need this Theory of knowledge to guard against using tools/measures/processes/whatever inappropriately. Somewhere, someone in the organisation must be able to think things through and watch the process unfold: this is the point at which the first 2 principles converge because raw data becomes organisational Knowledge - ip.

    From an FPC viewpoint, what's needed is an owner who is process oriented, Business driven, and Technically adept. And who is not fooled by Statistics and statistical mumbo-jumbo.

  5. You must understand the psychology of the workplace because everything is done through people, and (crudely put) without the goodwill of your workers up and down the chain: find something else to do.

    In the context of FPCs,
    • The counters must understand and buy into the counts they are doing, and must feel that what they are doing is valuable. This protects the integrity of the counts.
    • We must remember that they are not (yet) recipients of the value of their work. This only happens when time has passed. It is easy for them to become disheartened and (more serious) disinterested.
    • A QA process is needed to maintain the standard of the counts, this builds Business confidence in their efficacy.
    • There must be consequence management for those who do not apply themselves, meaning that there is also a KPA implication.
    • The users of the outputs must understand both the value in their existing projects, and the long term value (lessons learned).
    • And most crucially, Business (in particular) and IT must be confident that the tool acts as the intended bridge between estimation and reality.
Especially for corporates - tier 1 companies, and the majority of tier 2 companies – they must be clear on their goals (in itself not an easy thing!), and act on them confidently and with insight.

In tier 3 companies (and to a lesser extent, tier 2) this can often be done without a great deal of formality: a POC can be rapidly deployed and the intent made understood. Value can be extracted through the direct oversight of Line Management.

In tier 1 companies this is commonly not the case. They can prove it locally, but to roll out widely (and quickly) demands hard work and attention to detail, more than many have been able to apply until now, for reasons such as short-termism and cost containment.

Last Word

Stepping away from FPC's and back to the original argument. Deming's 4 principles apply to every endeavour, but they are especially pertinent for Project Managers and Business Analysts, for whom context and understanding is everything.

So the Lesson is, surround yourself with line-of-business people who have that deep appreciation of the nature of their business and then tease out from them the implications of the other three principles.

Buzzword corner

  • FPC - Function Point Count
  • ip - intellectual property - what you know about the Business, what makes it different and gives it it's edge, what you don't want to give away, and what you want everyone inside to use to make the difference
  • POC - Proof of Concept
  • Tier 1 multi-national
  • Tier 2 Regional (national, or in the case of the US, State-wide)
  • Tier 3 Local

Further Reading


Image (c) Author

No comments: