Friday, April 24, 2015

Key Man Theory, heard of it?

Sometime in the past decades I read about a management idea called the "Key Man Theory". Of course, I can't recall where and when, but it stuck in my brain ever since. In essence, it states that if the success of your business operation or project is heavily dependent on one person, with unique knowledge or skills, you have a huge risk to mitigate. In less sensitive times someone might ask "what happens to us if Dick (or Jane) walk out of the office and get hit by a bus? are we screwed?". The nicer way of saying it now is "what happens if Dick/Jane win the lottery?". Either way, the risk is the same; things could go bad quickly.

This in the same idea as the financial product called key person insurance, but that may not be what you want to fall back on. It is good to avoid poverty if your business fails, but what if you love your business and want to actually save it? In this case the mitigation techniques are to reduce your dependence on the key man (OK, person) by looking to hire similar people, or start some knowledge transfer from Dick and Jane to other people in the organization. Dick/Jane may not be thrilled with this --- being the key person certainly gives leverage when asking for more money or other things --- but you have to do something about this situation; being empathetic and supportive of the key person will help. In the end, when they do leave/retire, they will have felt valued and may have enjoyed passing on their knowledge to the younger folk..

 So, I was drafting some thoughts on another post to come, which refers to the theory.  I thought I would make use of web searches to find some source info or references to use and, to my surprise, my searches found nothing... nada.  So question for everyone: do you remember 'Key Man Theory'? And if so, do you know what happened to it?

Sunday, April 19, 2015

What to do when you see bad methods...

... and can't convince people of it.

I have had this experience a few times, and I have thought long and hard about writing about it.I still don't want to get into details, the old "if you can't say something good..." situation. But the possibility of it happening starts with joining a project already underway and the methods have already been chosen. When I first see something troublesome, I might nicely say something like "this is a bit different, how did come to be used?" The worst answer is "that's how we have always done it", and I really have to shut my mouth before reflexively responding "and how's that been working for ya?" ala Dr Phil.

I won't jump ship because of this (new ships not always passing by), so I make the effort. The real problem comes when you see that using the bad method(s) will make you produce bad or late deliverables. The worst response in this case is "Work harder, Work overtime, etc" because that is what always has happened, so it is seen as the norm for doing projects. Even if what you do eventually produce results in buggy systems and missing functionality, so that the change log balloons, that is also seen as the norm.

My personal problem is that I know it does not have to be this way, so it is tough to continue working to the 'norm'. If you are lucky, some project goes so awry enough that 'lessons learned' are considered; that's when you might have chance to suggest improvements.If not, I start considering my options for moving to a (hopefully) better situation. This could be within the organization if it is big enough, but leaving the org might be what is needed in order to join a better environment.

Anyone want to offer their similar experiences as comments?

Thursday, March 26, 2015

Almost a year...

Almost a year since I posted, my my. Things have changed recently, in a way worth blogging about, so stay tuned...

Thursday, April 10, 2014

Disciplined Agile Manifesto? Good but not what is needed...

Scott Ambler has posted his/DAD's updated Agile Manifesto at

It is indeed an improvement, widening the viewpoint and scope of what is involved in delivery of solutions... and yet, it does not deal with the nature of its objective, the 'consumable solution'. At some point there will be diminishing returns on the ability to deliver the best solution. Ninety percent of the cost related to a solution is incurred after it is delivered. The ability to deal with changing requirements after delivery is more important than before delivery, and yet software is delivered that deals with the moment, and the problem is that changing it after delivery takes too much time and effort.

I have said this before, but what we need more than agile solution delivery is agile solutions; solutions that are designed to accept change without needing to make changes to the solutions themselves. Business process management, Business Rules Management, mix-and-match services. All this out there, but does not get the profile it deserves.

So who wants to help me write an Agile Solution Manifesto? "we prefer configuration over software maintenance..." No, we demand configuration over software maintenance.  Who's with me?

Friday, March 21, 2014

Man, I have been really busy for the last 12 months

Man, I have been really busy for the last 12 months... I worked my last gigs with IAG Consulting, and then went independent to contract at one of the big 5 Canadian banks. It was for 6 months, been renewed, and seems possible a few more extensions will be offered.

I do miss the variety of engagements I had at IAG Consulting over the previous 5 years, and would love to do it again sometime, but a few changes in my needs led to the more traditional contract. That said, it is a great project I am on, to completely revamp how customers are treated when they come into a branch for one product and are helped to look at other complementary products and services for a better overall support of their financial needs. It is a big project , even for this bank, with more BAs in one place and time than I have ever seen before, with the project broken into components that are all being analyzed and designed in parallel.My role is primarily coordination across the components, and as single point of contact to many other stakeholders in the bank. I have been dealing with and learning from people in legal, compliance, privacy, internal controls, anti-money laundering and more.

So that is my past year in a few sentences. I think I will be posting more often over the coming months, probably more about my favourite combination of process, data, rules, services and such.

Cheers for the moment.

Monday, April 08, 2013

Agile Organizations - Dealing with Expected Change

Agile is an attractive word. It means swiftness with discipline, with an emphasis on alertness to change in one’s external surroundings and quickly responding to change as needed.

The word I want to focus on from above is external. When the surroundings that generate change are actually controllable, then the need for agility is greatly reduced. Agility comes at a price, and maintaining agility is a waste of resources when change is controllable.

A prime example of the difference between internal (controlled) and external (un-controlled) is an operating enterprise: business company, non-profit group and the like. The interesting problem for most enterprises is how effectively they control their own operations. The boundary between internal and external can become nebulous if control is lacking in parts of an enterprise.

Control sounds like a bad word. It implies top-down definition of all aspects of enterprise operations. This can be true, but control can also include delegation of authority, with expectation of results without definition of methods used. Control is maintained, but authority is distributed. This is the sphere of business management practices, defined and changing and transforming from Henry Ford to Jack Welch. It is not easy, and many others have and will address it better than I, so I will reference them as need be.

The topic of interest here is the boundary between internal and external, controlled and uncontrolled, event and response… but not between knowable and unknowable. An enterprise needs to know what is happening around it in order to focus its operations on knowing what events are important, events that it needs to respond to. For these events, an enterprise defines processes/procedures to execute when triggered by events, to provide the desired results in response to the events; successful enterprises include those that recognize that the nature of events and corresponding processes change over time, sometimes very quickly. So, at any one point in time, an enterprise needs to be in control of its processes, but that control can’t stifle the need to change as fast as the world around it changes. Further, this rapid change needs to be accomplished without disrupting on-going operations.

What we are discussing here is Controlled Agility; the ability of an enterprise to respond swiftly to changes in its surroundings without losing its internal cohesion.

The basis for controlled agility in an enterprise includes understanding that:
  •         an enterprise runs on its processes, not its org chart
  •        processes are composed of distinct activities and decisions
  •        processes run on information, gathered and stored and used
  •       processes are guided by business rules, especially when decisions need to be made.

With this basis, an enterprise is well-positioned to be Agile without losing Control. It all comes down to understanding Change.

Change comes in many degrees of impact to an enterprise. Consider workflow, which is based on process with roles and authority levels defined. If all loan applications over $100,000- go to Fred to be underwritten, the workflow will change temporarily when Fred goes on vacation. Those loan applications have to go to someone else until Fred gets back. This kind of change can happen frequently, but more importantly, it is a kind of change the enterprise knows can happen.

Frequent known changes are the heart of controlled agility. This is the kind of change an enterprise must be able to do, without changing itself, as part of operations. It should not need a project, especially an IT project, to make the change.

Temporarily changing workflow might be considered a simple example, but it is actually an example of an overall type of change that can occur frequently, and that is business rule change. Business Rules are so embedded in how an enterprise works, it is actually a new and revealing approach to call them out separately. In a lender enterprise, it is likely a fact that “Customers may apply for Loans”, but “Customers may apply for Loans, only if they are 18 years old or older” is a Business Rule; it constrains an aspect of enterprise operations and, as said above, rules change (next year it could be 19 years). An enterprise that knows the facts and rules of their operations is well positioned to change rules as quickly as needed. However, rule changes still need to be controlled to avoid using incorrect rules to the detriment of the enterprise. Still, these changes should not require a project to change the structure of the operation and, again, not need an IT project.

A major use of rules is to support making decisions.  Loan underwriting across many financial lending/leasing enterprises is heavily rule-driven, the information about a customer and the loan product being used to decide to lend or not. These can be complex rules, or simply that the enterprise does not lend to anyone with a Credit Score below a stated value; and again, the rules will be changed over time as a lender tunes its underwriting, or is willing to take on more risk, etc..

Decisions also play a role in defining what processes/activities are used to respond to events. We all know of BPM diagrams with boxes for activities, diamonds for decision points, and arrowed lines connecting them all. A process may be composed of 20 possible activities, but less than 20 might be used in response to any one event because of decisions based on rules.

What can change for a process? The number of processes in an enterprise, once all are defined, is relatively stable over time; new processes usually mean the enterprise has expanded its products/services to areas which need their own processes. Within a process, however, the exact activities that are carried out may change, or be re-ordered, or even be retired. It is the ability to change processes as quickly as possible, again without a project, that marks an enterprise as Agile.

Changes in decisions and rules used in processes are the most frequent changes an Enterprise must do. Changes to the activities in a process change less frequently than decisions/rules, but often enough the agile enterprise needs to it as part of its operations.

Are there aspects of an enterprise that are more stable? And are types of changes to them not necessarily known or predictable? This is a loaded question, because the answer is information or specific data used by an enterprise. Once all the information needs are known for an enterprise, these are very stable over time. The need to change information needs is similar to the need to add more processes; it happens when (as above) the enterprise is expanding into new products or services different from current products/services. To be more precise, information needs may change as the enterprise expands, but they may not as well; data requirements have been shown to be the most stable aspect of an enterprise.

So we have two ends of the change pendulum: from frequent and known, to rare and unknown. As said earlier, frequent known changes are the heart of controlled agility. 

Enhanced by Zemanta

Thursday, March 14, 2013

To Agile or Not To Agile

After a long period of trying to grapple with "agile" or "not agile" etc., I finally realized something; it really depends on what you are trying to develop. My thoughts now divide software grossly between "product" and "process".

If you are developing a software product, especially to actually sell to customers, then I think product development methods are the way to go, and Agile fits this approach well. You do start with a Product Owner's vision of functionality, and user stories are a great way to express that vision as a starting point for developing a prototype or first release.

If you are dealing with a business process to automate, then a 'vision' is not appropriate; you have to document what the process is, completely and clearly. High-level process maps supported by use cases are a great approach for this. You have to  realize that there can be no arbitrary first release for a process based on a sprint or other cut-off. If you are automating a process to, say, transfer money from one bank account to another, you can't first release the "from" account piece without the "to" account piece.

So, use the appropriate technique for the software you are developing; no one technique meets all needs.

Enhanced by Zemanta

About Me

Ontario, Canada
I have been an IT Business Analyst for 25 years, so I must have learned something. Also been on a lot of projects, which I have distilled into the book "Cascade": follow the link to the right to see more.