Two elections that few expected and a majority didn’t want- the information perspective.

Two groups of people mastered the truth about data, its interpretation and it’s presentation and two groups didn’t. The former of course are Republicans in US and Brexit’s in UK.

The theories are not new, nor are they difficult to understand but executing on them might only seem an option to somebody with no other options (Trump, Farage). Most people would never dream of applying for a multi-million pound loan and filling the entire application with fiction. It’ not because they believe it couldn’t be done, we’ve all seen it done, but because they were not brought up like that. They still believe they have other options and they won’t make that move to the dark side.  People who did it and often did it successfully were generally people who had no other option and didn’t see the downside. In banking there have always been checks and balances, but in media there has always been a weakness and right now there is a total void where the media used to sit. Enter two people who had no right to talk to us and simply couldn’t win. Donald Trump and Nigel Farage and look what happened.

Why did they win?

Nobody buys newspapers much less reads them any more and old fashioned journalists have hanged themselves by their braces long ago. There’s no revenue stream any more to sustain them, for what little use they might have been once and now we have instead, social media, polls (much the same thing) and personal content filters all very much for sale to the highest bidder and very controllable.

As IT professionals, we have always had to operate in a tricky area between less than perfect hard data collected from disparate systems or countries and the jazzy punchy little reports and dashboards that our paymasters dine on to excess.
Let’s be realistic, hard data is of little use to anyone, it’s only when the great unappreciated droves have cleaned it , sense checked it and translated it to comparable terms and then turned it into consumable visual bites that decision makers can grab it and do something useful with it, like selling a lie often as not.
When I see an email proposing a radical new strategy on the grounds of the figures in my reports I can sometimes pull somebody aside and caution them on the potential for error in the data or point to a conflicting KPI and suggest further checks. This type of scenario is part and parcel of business life in the world of IT.

Lets’ now take  a look at the world of rigged polls, injected social media, wholesale unapologetic lying and presentation that appeals to the baser emotions of fear and mob action.

  1. Destabilise the enemy by kidding them that they are doing better than they really are and encourage them to focus their attempts in the wrong places. Easy and very effective.
    I’m not sure that Farage had the budget or reach for this one, but it was certainly a central part of the Trump strategy and clearly explains why the bookies did so well. Read about Colonol John Boyd’s OODA loop to learn the basis for this strategy. Ask any social media consultant how to do it.
  2. Fill the media with mountains of lies about the enemy, begin by raking up a few real stories to set the scene, wait a few days for people to stop questioning that and then pile it on thick.
    For some good examples of this in action check out Niemanlab.org
    In the UK voters were incensed about legislation preventing the sale of bent bananas, (it never happened)
    They were told it would mean hundreds of millions per week spent on the health service, all immediately denied after election day. The list goes on and on.
    Why is it easy to find and cultivate these knuckleheads? Because Facebook, snapchat and others have detailed profiles of their entire lives and everything they discuss, read, think, say do, even the therapists they visit. Finding a numpty on Facebook and sending him to kill the president should be a doddle ( I didn’t give you the idea by the way)
  3. At the last minute create a powerful picture to capture the emotions of the more  ignorant layers of the electorate and plant a semi-subliminal message that appeals to the baser emotions i.e. massage the “lizard brain”.
    Nigel Farage’s posters were so blatantly aimed to incite civil unrest that there were well supported calls for him to be charged with this offence. On the day after the election, people of foreign birth were accosted on the streets around Britain and told to “go home”.
    In Florida, Trump’s “swing state”, Trump supports were seen on election night chanting “Lock her up”. The Canadian embassy crashed under the load of applications to immigrate and the flood of Mexicans going home in disgust continues.

In both cases, before the vote had been fully counted, the claims were being refuted and the lies were being reneged on.   No “Lock her up”, but tributes to her commitment. No “Go home”, or even close the borders in UK.  How far the reversals and denials will go on both fronts is yet an unknown, but nothing would surprise me mainly because the stretch room is usually very small once they find themselves in the reality of office.

So what is the lesson?

  1. Don’t rely on traditional media to be guardians of truth, what’s left of these are either state owned or in the pockets of the multinationals that own the politicians.
  2. Do I need to say it? Don’t expect politicians to tell the truth and don’t assume they have the same values or standards you do.
  3. Opposition parties ( that means both sides) have to guarantee the truth by monitoring and refuting media and actively and aggressively bringing liars to justice before and after the event. We all want the truth to be spoken, especially on important subjects and that is one of the things we will all agree to pay for and support politicians to achieve for us, so join the winning side for once and promote truth and honesty in media by attacking lies and dishonesty and supporting those who stand for truth and honesty.
  4. For god’s sake, or whatever you believe in don’t believe everything you read in social media, especially if it’s controversial and even more-so if it agrees with your predispositions.
  5. Make sure you defeat the personal filters to get alternative views of the world, use proxies or VPNs to hide your location and see a different view of the same thing. Ask a teenager if you don’t know how.
  6. Take responsibility for your own mind and for your decisions and actions.
  7. Don’t stay silent and let the liars prevail, it’s now a community affair, so speak out and have an impact on the balance of opinion. This way we can all help to keep society safe

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Requirements engineering strategy can make or break your project .

Part one – What would you like sir
Part two – Requirements,tests, training, help files
Part three – Why no project exists in isolation-what should be done
Part four – Business rules, Process rules, Process, Data, different viewpoints
Part five – Testing requirements is not optional
Part six  -Requirements strategy can make or break your project

If you’ve been reading my blogs on the subject of requirements, you will no doubt appreciate the level of importance I place on getting requirements right and then testing them before committing yourself to a contract or a technical specification.
Just in case you are thinking that this is in some way anti agile, then nothing could be further from the truth. Please read my blog on agile requirements engineering for a discussion on this topic.

Let’s take this opportunity to recap on why we do requirements. The simple fact is that once a development team start work on creating a technical specification, the till begins to ring up with costs and every time you make a change after this point more costs are added. The closer you are to rollout when you make the change, the greater the extra cost will be and that time phased increase is exponential, therefore the first purpose of requirements engineering is to contain costs and eliminate or reduce slippages.

The second purpose is to make sure that the end product delivers value by meeting the needs of the business precisely in order to meet or exceed the benefits targets set in the business case.

Getting requirements right therefore, is absolutely critical if you are to contain costs and deliver value

Developing a requirements engineering strategy

Each organisation and each project are different and requires a tailor made strategy for getting the requirements right by recognising, exploiting and working with the capabilities of the organisation.

To do this successfully, you will need a few things:

  1. A detailed analysis of the stakeholders involved in the as-is process in order to make interviewing efficient and thorough.
  2. A strong feel for the past experiences of the organisation in terms of successes or failures with software projects in terms of meeting business need and staying within budget and time constraints. This along with some tactful exploration of causes will give a strong steer about the current capabilities of the organisation to engage with a formal requirements process and to take seriously concepts like change control.
  3. A feel for the organisations ability to take on and successfully adapt change will help you decide whether and how far you might decide to upgrade their skills and attitudes to requirement engineering
  4. A good indicative plan that indicates the products to be created, their acceptance criteria, time scales for delivery and the amount of effort that will be needed from stakeholders.
  5. The understanding, agreement and total buy-in of key stakeholders to the proposed approach with full support in terms of making people and facilities available for the process

 

Stakeholder analysis for requirement engineering

Step one

Using RACI to identify stakeholders for the Requirements function.

In my blogs on business case techniques and models I discussed the importance involving the right stakeholders to gain buy-in and get a real picture of what success will look like.
In order to design the system, you will need a different type of stakeholder list, one that describes roles, responsibilities skills and communication. This list will give a clear view of where the knowledge skills and the responsibilities lie within the organisation and therefore point you at the right people to describe requirements and take responsibility for their quality. My favourite tool for achieving this is a well known HR instrument known as the RACI chart. Responsibilities Accountabilities, Consults, Informs and it provides a two dimensional view of a team that helps you quickly analyse the team for adequate skills, supervision, communication and quality control. It can be adjusted in form or emphasis to suit your precise needs, but the fundamental principal serves well in any circumstance straight out of the box.
Here’s an example;

RAACI example

The table above lists nominal roles across the top and Activities down the left, each cell is then marked with one or more of RACI to show who has what role in that activity.
The example is for a software development team, but if you were building a hospital it would list things like planner, builder, architect and activities like approve plans, complete design, etc.

A software project for a builders might involve, Construction director, surveyor, cost controller, quality controller etc and Liaise with clients, agree costs, sign off completion, etc.
Apart from being a huge benefit in helping to highlight the important stakeholders for your requirements process, the RACI chart also provides a quick but effective sanity check to make sure that your team is adequate and that there no duplications, conflicts or gaps.

Horizontal analysis of each task will quickly tell you whether there are sufficient doers and accountability exists and is in the right place.
Vertical analysis of roles will quickly highlight overworked, underworked, misplaced authority or responsibility and lack of or too much consultation and information.
Too much consultation stifles decision making and too little leads to dangerous decisions. Corporate culture can lead to busy bodies who don’t always follow through, or teflon in-trays. All of these issues need to be understood and ideally addressed ahead of system design, because the system will only perform as well as the people who use it.

Once you have created this chart, the next thing is to create a list of names with contact information to place in each of the role areas. If the project is large and/or complex, there may be more than one name in each box and there may be further sifting to do in order to resolve any doubts.
Don’t be surprised to find skeletons in the cupboard and lack of agreement over who does what. If you uncover these issues, now is the time to discuss them at a high level and attempt to get them resolved ahead of requirement gathering.

Step Two
The second step is identify the Actors, the people and systems that carry out tasks as part of this process and the sources of all the skills, knowledge and decisions required to complete the process successfully. This will generally begin with the R people in your RACI chart and will usually expand to people who do the work with or for the R person. E.G. the R may be in your chart as the Technical architects for design, but on investigation, you may find a DBA, a SysAdmin and many others who play key roles and these people also need to be interviewed.
The actual actors may be more usefully broken down to specific skill sets or disciplines as opposed to specific roles. E.G you may have Document writer, Interviewer, modeller all of which are actors within the BA function. This approach gives a slightly more abstract approach that lends itself to reorganising roles for efficiencies, or to adapt to a new system.Never be tempted to accept the assurance that a supervisor can tell you the whole story and you don’t need to talk to her/his charges. If anything this should be seen with an element of suspicion and tactful verification is a good idea.

To better understand and communicate how the various roles influence the outcome of a process, it is sometimes useful to create a fishbone chart adapted slightly for the purpose. Here is how i like to create it:

Stakeholder fishbone chart

The fishbone can be made as complex as you need it to be in order to show all the influences on your new project. The thing that becomes apparent very quickly is that whether they are aware of it or not, most of your stakeholders rely on others for skills, support, knowhow, data, administration and other inputs that can potentially prevent the processes progressing and hence you need to know about it and to resolve, or risk manage it.
Your fishbone chart will immediately tell you who to talk to and by way of a bonus, it will very quickly highlight the areas of influence, both positive and negative when it comes to rolling out.

Organisational culture and requirements process maturity.

Once your target interviewees are lined up, your next step is to hold a number of short interviews and/or an interactive workshop to discuss past projects, how they went and how the organisation reacted at the time and now. Asking them what they felt went well and what went wrong will go a long way towards gauging what will go down well, or will meet with resistance in terms of methodology.
The aim is not to deliver the perfect project, by your standards, but to deliver the best you can within the capabilities and expectation of the clients.

The last critical aspect of this phase is to get a good feel for their favoured mode of communication within this area. Do they have requirements documentation that they worked with in the past? Are they comfortable working with it? Does technical documentation create silos that exclude valuable stakeholders to the benefit of technical people .

This aspect is vital, because the quality of decisions they make and their perception of you as a trusted adviser will be directly proportionate to your skill in communicating the concepts clearly to them. Not only that, but your ability to get their attention at all let alone hold it long enough to achieve a useful level of consultation will depend on not confusing or alienating them with technical or complex instruments of communication or use of unfamiliar jargon.

A clearly communicated strategy and indicative plan

Once you have gathered your information it is time to make some preliminary decisions about how to take it forward. How to collect information, how to verify your information and how to communicate back to stakeholders ahead of defining the requirements.

Identifying these tasks, the stakeholder and support staff needed and the order and dependencies of the work, it is time to add this to a simple Gantt chart that defines high level activities, high level milestones and products to be delivered.

Understanding, agreement and total buy-in.

If you have done your homework and worked in a consultative manner you will be very confident before presenting the plan, that it will be understood and supported and will be accepted by your stakeholders.
You should present:

  1. An introductory explanation of the approach with reasoning
  2. A list of products you propose to produce backed by a simple concise explanation of how and why and samples.
  3. A Gantt describing the timeframes and milestones.
  4. A simple, high level risk assessment
  5. An indication of the time commitments required of key stakeholders.

At the end of this you should answer questions and ask for their full support backed by a sign-off of the plan.

Ed Taaffe is a senior Consultant in Business Improvement through technology and Hi-tech Product management.

Reblog this post [with Zemanta]

Two important rules of the learning organisation that you won’t study in an MBA yet they are ignored at great cost.

The learning cycles described by    Sekar Sethuraman CISSP,CISA,CISM,CGEIT,CIA,PMP is in my view an excellent starting point that would most likely be a significant achievement to formalise and encode into almost any organisation.

My personal experiences apart from academic interest are around :

  1. What we often call “lessons learned” i.e. the constant adjustment to circumstances and to the perceived results of our previous actions.
  2. The impact of swarm intelligence on our ability to learn and teach.

Lessons learned, maybe we should not be doing it at all?

In the area of Project Management, few organisations do anything at all about “Lessons learned”  though virtually all would express a regret about this. In truth , doing nothing formally is not doing nothing after all and hence informal learning continues. Is that better, or worse? Well it’s not a clear-cut answer.

In the past year I returned for a period to the area of managing risk in an uncertain and volatile environment with vague rules and little explicit information.  A classic example of this environment is day trading , or any kind of investment banking activity, bookmaking, military activity, espionage, football  and a long list of less glamorous situations.  Football is too tricky for this discussion  because  there is almost no conscious decision making involved.
The reason I choose to discuss these more obviously volatile environments is because they are more like real life only sped up enough to trigger human emotions and  for people to  learn from trends  and responses  that otherwise  might remain hidden. i.e. because you see the results of your actions soon enough to make an association you have a chance to reflect on the actions and the outcomes that in normal, snail’s pace life , would remain hidden from most people .negative false

Actions and results are two key elements of all learning. John  Boyds OODA loop is a wonderful example of this.  What Boyd recognised is the need for “ Sense making” and this is the key, because learning without doing this effectively is to learn things that are patently wrong. The equivalent Is to put arsenic in your coffee cup.
In a fast moving environment we see every day people who pushed  a button a and felt a shock up their leg. Like the pigeon learning to select the right beans, he stops pushing the button, because he assumes a relationship between the two. How quickly he makes this assumption and how rapidly he reacts is directly related to his self confidence and very quickly you can see the cookie crumble to a pile of dust.  Burned out traders are almost as common as arrogant and broke ex-traders.
The answer lies in the ability to ignore what you hoped or expected to see, question what you do see and only act on proven information while filing the rest away for another day. The ability to do this is much scarcer than you might think.

Lessons learned can be formally handled in a project management environment and these lessons ingrained in culture at which point the will become pervasive until they need to be superseded.

That leads us neatly to the other area:

Swarm Intelligence or Hive Mind has most of us  firmly in her grasp.

Swarm Intelligence , or Hive Mind as I prefer, or in simpler terms culture is a far more pervasive and more potentially damaging force than most observers realise , in particular when it comes to learning.  Ask Paddy Power Bookmaers.- Paddy Power Left ‘Red Faced’ After Early Payout on Greek Vote. They trusted the wisdom of crowds and learned an expensive lesson.

Surowiecki had a bestseller and started a wave of books that appeared to discover something new in old wisdom , only to be widely discredited later.

According to Jesse St Charles of University of Tennessee at Chattanoogai, there are specific rules that define a swarm or flock:
1. The rule of separation. Think of a flock of birds flying in close formation but never  make contact physically. There is an unwritten rule that keeps them a certain distance apart and that rule alone defines where they go. Watch the starlings over Rome about this time of year.

  1. Cohesion. The birds all use the same patterns of flight and movement and even squeak and defecate in unison.
  2. Alignment. They gauge their direction by where everyone is going and align themselves
    4. Type recognition. A flock of starlings will never allow a crow to join, nor will he try

Once these rules are in place, the bird has waived all control over his own brain and simply follows the pack.  In all group based creatures this can be seen and it mostly likely stems for the safety of being in a group and ideally close to the centre.

Parallel this to the Stanford Prison experiment when a group of well bred and highly intelligent students form the top 5% or so of Americans were given roles and group structure in two opposing groups; Prisoners and warders and left to enact this for the benefit of a study.  If you don’t know what happened, I urge you o read this: https://en.wikipedia.org/wiki/Stanford_prison_experiment.

I am not commenting about the scourge of starlings in European cities, or the capabilities of the human given the right opportunity, I am simply pointing out that once an individual has identified his or herself as belonging to a particular group a large part o his/her brain is surrendered to the perceived group intelligence and the power of the written or unwritten rules of that group prevent learning anything that is contradicts the group in any small way

Conclusion:

If you are engaged in deepening the learning of your organisation, or team bear in mind two extra rules:

  1. Unless you adjust the culture of your hive so that learning and changing is a source of social acceptance and security, all you efforts will come to nothing.
  2. Sense making, for adults in a business means something different than in teaching and learning. People’s emotions play a huge role in how they perceive the effects of their actions, what they learn from what they see and even what they see. If you want to create a learning organisation, you must teach and assist people to collect and observe the results of their actions in an objective way, make and execute good decisions at the right time and police their emotions against rash reactions, or unearned self-doubt.

 

Perhaps the short description of all this is leadership, the thing mankind craves for more than anything

 

The health warning attached to agile is nothing more, it’s not a reason to ignore agile thinking as a powerful tool.

As a manager who entered software engineering as the agile movement was gathering pace and returned to management in the systems world, I find it amusing when other disciplines jump on the bandwagon as it were. I also find it encouraging, but I would have serious concern if it were my business and here is why:

  1. Agile is not what journalists say it is

In much the same way that we probably misinterpret and ingratiate many movements,  Agile is credited with a lot of stuff that was never  though t of,  never intended and for the most part never happens.
A bunch of software engineers (several in several places) to decide how they could “take back control” of the software process in business.  They knew the power thy held in their hands, but could see more and more of it ebbing into middle and senior management determined to make them “blue collar”.  At the same time service businesses like IBM and Microsoft were looking for ways to reduce the paperwork and improve communication in the software transaction. The two things were married and produced a clever, but unruly child that requires careful monitoring and constant praise.  Agile was never a strategy, but a bun fight and it is far from over.

2.Fiiddling with KPIs is not changing anything.
 In my early days as a marketer I was taught that if you are not meeting KPIs, it is easier to fiddle with the KPI than change your behaviour. This is a fairly universal principal of business and nowhere is it more fitting that the world of software.” I want it and I want it now, but I am not sure what it is and couldn’t communicate it to you even if I did . In any case, what if it doesn’t work?”  I’ll claim you didn’t deliver and /or you didn’t do it right. That is the scenario driving software engineers to do away with specifications and contracts and make the product owner responsible. Unfortunately, what they didn’t spot until too late was that in doing this, they sold their souls and became blue collar again, but that’s another story.  Now they estimate in Tee-shirt-sizes and look upwards and to the left as they declare how many tee shirts they completed this month. If they don’t like the design they simply say it can’t be done or will cost too much. That is roughly where the tyre meets the road toady

3. A racehorse designed by a vet and an art student will make a very ugly camel at best

I was a product Manager for a few years, it is a natural progression for a marketer cum software engineer and I know some of the best around the globe. Some are redundant and others struggling. Why? Who needs professional when you have the seat of your pants? I am not suggesting that Agile teams with a nominated Product Owner can’t or don’t produce good stuff, simply that; successful products need a market sized opportunity, or it matters not how good they are, products need to meet an unmet need and to do it so that they are a more attractive proposition that their competitors and so forth.
What I am getting at is this; iPhones are successful because they were driven forward by a brilliant visionary who had the courage to show us what we are missing and make us love iPhones. Bill Gates did this for the PC. In an agile world neither of these products would have happened.
The iPhone would have been an ugly mishmash of half-finished features rushed out to an imaginary deadline and reflecting the current tastes of the Lead developer and the Product Owner, usually in that order.  I suspect the PC would have been a typewriter with a glass screen and a coffee holder.

  1. Lying in the water and thrashing your arms about is not swimming.
    Anybody who seriously wants to make a change for the better needs to start not with the technology, but with goals, develop strategies and work their way down to the details of how.  If that happens to be agile, wonderful, there is then a powerful chance that you will make it work.
  2. Beware the evangelists, many are trainee terrorists

Understanding the shortfalls of anything is the first sign of expertise and even love. Don’t fall for the preachers they have alternative motives. Somethings and some teams lend themselves well to agile, but not everything and worst of all, when a good agile team has been doing the same thing for a year or so, they are no longer agile, they are simply where they were before with slightly different rules and rituals.

  1. Agile is a state of mind not a book or a methodology and must be championed and driven form the top down by people who know what they are doing and why they are doing it.

Systems thinking, monkey-business and multi-headed monsters

Today I had an interesting conversation on linkedin  about SystemsThinking. We all agreed that trying to convert a group of people into something they are not is an uphill struggle and it is far better to identify what they are good at and make maximum use of this. It reminded me acutely of a blog I wrote back  in 2011 when I was steeped in business change issues and I used the example of the five monkeys parable to demonstrate the challenges of bringing about cultural change.

Culture is a peculiar thing and it is sometimes extraordinary just how long monkeys can continue to misbehave before decent people eventually intervene.  Even the smartest and the strongest sometimes doubt themselves just enough to hope someone else moves first. Hitler was a case in point, there was only a very small hard core who supported him because they were growing very rich as a result of it, yet he wielded phenomenal power over a large portion of the globe for a long time before  eventually they all turned on him.
Another aspect of systems thinking that we all agree on is simply this: For all their flaws: systems; like countries; faiths; organisations and the like survive because sooner, or later they do what it takes to survive.
The monkeys eventually go away and slow as it can sometimes appear,  the system  rights itself because it must in order to survive. Should we give it a push? of course we should, but discretion and intelligence are key, when the balance is tipped, or a few bananas distributed  many of the monkeys turn back into humans. In the software world we rarely try to rebuild from the ground up, instead we tackle the big wins and keep on plugging on.
A few months ago I wrote a series entitled Lernaean Hydra, your time is up. This blog discusses a large change programme that was so poorly put together it reminded me of the multi-headed mythical beast who grew replacement heads each time one was cut off. To read more about the mathematical solution check this math challenge from Leicester University.
The ultimate fate of non-systems thinking is, it would seem, to find that your every effort creates at least twice as many problems, while trying to change all at once is, we agreed, futile.  Perhaps the commercial solution to the five monkeys problem was after all, to open a zoo.

My favourite solution to the monkey problem is to introduce a tough monkey and when he eats the banana in spite of them,  reward not just him but all the others. Keep doing this and in a short time the monkeys will protect any of their pals who approaches the banana in the centre. If you want some hints about broken programmes read Lernaean Hydra, your time is up.

The hydra problem is more one of getting to the root before taking action, the monkey problem is about trusting the human will to survive and prosper and introducing reward and support n the right places .
Fear is  natural. It drove some of the greatest achievers including heavyweight boxers. Fear of failure cripples people. Fear of change is probably the most irrational of all and ultra destructive. Fear of extinction eventually works when nothing else has.

The DNA of CHAOS. Why software projects, peace negotiations and football games all come up short on occasion and the true value proposition of agile

Why Business analysts, Product Owners, negotiators, political reformers, scientists and many others are doomed to repeat the same mistakes until they drown in in their failures.

  1. Most people in a work situation, and indeed in most situations, live in a consciousness that is deliberately falsified to reflect (a) what they believe is expected of them by peers, and (b) what the asker of a given question wants to hear. This is a conditioned response and nobody’s fault.  Terms like “Group Think” attempt to explain it, but none really explain the phenomenon well and the long version is just beyond our scope in this piece. Market researchers are trained to try and avoid it, Politicians and advertisers learn to harness it. If you have the role of finding out what  a business wants to do so you can get the software designed to support, it, you will be faced with the same  aggravated problem. Asking and listening simply won’t get the job done.
  2. For reasons I don’t claim to understand fully, most people have a favourite solution in their minds for most problems they are aware of. Expensive  housing – they may say; “Stop immigrants coming in”.  The call centres is too expensive and eating our profits- they may say; “ Close the call centre and let them use Twitter”. Always there is an obvious political, or financial gain for the responder from this solution. If it is a senior executive, or politician, there will be cleverly argued points and tables of figures that make her pet solution look like a no-brainer.
  3. Michael D Cohen  coined the phrase “Garbage Can Theory” to describe this phenomenon which permeates politics, business, the playground and just about every area of human life crippling every endeavour to improve our lot century after century. If you are trying to get your proposal through programme and investment boards, or trying to agree a solution closer the coal-face you will drown unless you understand this phenomenon and take steps to work with it.
  4. Many researchers and writers have agreed strongly that the human brain makes virtually all decisions in a matter of time between milliseconds and 1 to 3 seconds, but then spend enormous amounts of time and effort researching in order to prove their decision was correct. Most people are entirely unaware that they do so.  This of course is not news to Scientific researchers who often publish the theory before beginning on the research.  In the academic world where we have to start somewhere this can be a useful approach. Product managers and entrepreneurs also start with the theory and are difficult to budge even when wrong, yet these leaders are necessary to get something started at all.
  5. People are conditioned to follow a strong leader and will convince themselves of their support for any theory put forward by this leader. This is largely an extension of  point one, but worth being aware of all the same when venturing into any group to arrive at a shared view.

These Five forces combined thwart just about every effort to form a good business strategy with technology in mind, agree a solution and still be in agreement when the solution is completed to specification even a few months later, let alone after a year or more. Waterfall and other methods of managing the software delivery process all rely on a simplistic view that if you gather enough requirements from users and stakeholders, you can then haggle over priority and build the killer solution to solve everyone’s problems. In reality, there is rarely any agreement, there is even less concern over business outcomes and near- total focus on the many garbage can solutions. Nothing this project could deliver is ever likely to meet the satisfaction of more than a small proportion of stakeholders, the others are always going to be loud in their dissatisfaction and only by sheer luck is their ever going to be serious business benefit.  This project, however well the techies perform will be added to the list of “failures” and the cause will be placed at the CIO’s door. Failure to focus on goals Developers and technical architects are driven by developing exciting new toys. That is their package in the garbage can. Techies ultimately want and are entitled to, clear definitions of what they must build.  They then build and test precisely what you asked for and give it to you working  very well. Few people would try to argue with that, let alone succeed.  The problem is that what you asked for does not always address the problem you needed solved and in fairness the developer or indeed the CIO is not to blame. There is one technique that all accomplished negotiators agree on whether brokering peace in a war zone or negotiating a business contract. YOU MUST KEEP THEM FOCUSED ON GOALS NOT SOLUTIONS! If you don’t, the garbage can will take over.
One cause  of the problem is not using the effective solutions we already have,
The need to focus on goals rather than solutions is not  new to the software industry by the way.  MSP, Prince2 and TOGAF are frameworks I am personally very familiar with, all of which, when used correctly, focus on outcomes required, the solutions that will best deliver those outcomes and the details of each solution, in that order. BABOK and the ISEB framework for business analysis also follow these same principals and are very clear about it. The problem is that few people make any attempt to use their training effectively, the training is rushed and focused only on answering multiple choice questions to gain a certificate and of course the majority of people involved in the business have no training at all. This same scenario, by the way, applies equally to Scrum. Scrum solves some of the problem Scrum attempts to alleviate the problem in a different way and with a similar level of success. Scrum is invented and owned by the technical community as a direct response to these issues plus the difficulty of communicating the complexity of technology with business people. The Scrum team wants only to be given an unambiguous requirement so they can do what they studied for, build great software. They place the onus on the business to appoint, or work with a Product Owner who will be seconded to their team and take all responsibility for the definition of the Product/System.   Communication issues are solved by very short Sprints of just two weeks typically and using prototypes and working software to describe things to the product owner in place of documents. Initially this arrangement solves the problems for the Scrum team, there is no ambiguity about what they must build, they do as much work as the Product Owner wants and stop when he is satisfied. There is no room for dissatisfaction with the IT team. Likewise for the Product Owner, if he is unsure, he can build something , test it on real world scenarios and then make adjustments until it delivers the right outcomes or scrap it altogether.
Inspect and adapt solves problems with lack of knowledge, but also masks others Scrum tries to tackle the strategic questions by replacing strategic decisions and documents with Inspect and adapt. For online products and for certain internal systems, this works extremely well because you can build the minimum, get it working and in use, learn from success or failure and add a little more, remove some, or start again. The risks are lower, failures are smaller and less expensive and the problems with groupthink, daydreaming and garbage cans are alleviated by an early sobering splash of cold reality that comes with release of a Minimal Viable Product. What is often wrong with this approach and fatally dangerous, is the lack of a strategic layer to the thinking process. Inspect and adapt is a close cousin of the OODA loop as defined by Colonel John Boyd. The principal is very simple that in a dynamic environment, he who has the most clear view of the situation always wins given a reasonable ability to make decisions.  Pilots flying inferior jets were seen to consistently win dogfights  because they had a better view from the cockpit and could make better decisions faster.  Developing OODA  (Observe, Orientate, Decide, Act ) and teaching it to pilots made significant improvements over giving them a detailed instruction, or a faster Jet because as the military have always recognised, in the field, the operative has superior knowledge in the heat of battle and must have the right level of autonomy and confidence to decide and act. No military  has ever cut loose a person, or team, or unmanned drone to inspect and adapt and just stay out there. There has to be a clear goal, a Definition of Done, Principals that guide it in the field and a strategy for completing the mission. Then Inspect and Adapt comes into play and in the same way that the human brain itself learns,  the actions  in the field can feed all the way back to sometimes cause a change in strategy or even a revision in Principals, but  actors in the field DO NOT  GO AWOL. Principals and strategy come first and Inspect and Adapt is a response to exceptions , it is not the  plan.

The real reason why Agile/Scrum is winning friends in the world of software and gaining attention beyond these confines

I say Agile/Scrum because when most people speak of agile they are really referring  to Scrum. However Scrum has encompassed much from other Agile implementations and definitely does not hold the sole franchise on Agile methods. The first problem Scrum had to address was the great chasm between Business leaders and Technology leaders.  Various versions of the same solution see the business seconding someone to the Scrum team, or colocation of business and technical people working on the same project. This is a perennial problem sometimes referred to as silos and secondment or colocation of cross discipline teams is a useful technique that helps, but doesn’t alone solve the problems. In the case of Scrum it forces the business into making decisions for better or for worse and living or dying by them. That helps techies to get on with building stuff, but it doesn’t, of itself, help the business much with getting the strategy right. I.E they produce more stuff, but don’t necessarily solve more problems. The next problem Scrum had to address is helping the business in dealing with the unknown. The speed of change is much greater in the past few decades driven by the fast pace of disruptive technology. Organisations are faced with problems they can’t analyse easily and therefore can’t solve. They also find that when they know the problem, they don’t have an obvious solution. This is the situation Scrum was designed for in its entirety. A Scrum team can make a best guess and very quickly get a potential solution in front of customers, Inspect and Adapt and return quickly with an improved effort until the right solution is reached by trial and error and then it can be built upon until it reaches its optimum scale. The biggest problem addressed by Scrum and that one that is causing all the excitement is the almost  total  lack of leadership throughout modern businesses (the past 10 years). Few would lament the passing of the great Command and Control organisations, but with them went whatever semblance of leadership we had in organisations. In the Flat organisation leadership in name is often cited, but leadership in deed is sometimes frowned upon or even punished. In the 80s and 90s business leaders bullishly wrote books about leadership and motivation. These were charismatic people with an instinct for what made others tick.   Kenneth Blanchard, Peter  Drucker, Stephen R Covey and their like gave us the ideas and the passion to change things and build things. We somehow lost this passion and insight in the transition.  Scrum is a beacon in the dark, because it values people and their interactions over trails of evidence. It values achievement over promises and it values self-improvement  and job satisfaction. Here and there Scrum teams are springing up that capture attention by their high productivity and ingenuity and win the envy of their colleagues for their enthusiasm and Joie de vivre.  People who see a good Scrum team in action want to be part of it or learn how to make that happen in their business.  That is the real reason why the buzz of excitement continues and why Scrum experts are being invited into other areas of business.

How to implement Scrum while keeping your sanity and your Job

Cost overruns, missed schedules and quality issues. These were the reasons cited for the development of Scrum.
Management also wants to harvest the business value expected from new software sooner, while using fewer resources

Breaking a traditional process up into small increments solves all of these problems. MSFis a wonderful example of this apart from the fewer resources bit, that is a myth. MSF encourages the business to develop a long term vision for the solution, but then it is broken into a series of small deliverables that build up in timeboxes to a full solution, or stop when time or budget run out.

The benefits are significant because; a. A proper Enterprise Architecture, style and vision is agreed first. That means that we don’t start off with one approach then half way through have to scrap it all and start again in order to scale. B. It means that at the end of the first timebox there is something of business value to show to the customer.

MSF differs from scrum however, in that it still depends on some basic documentation and designs and formal testing in a way that is familiar to most software engineers. MSF also lends itself well to procuring systems which I can’t honestly say about Scrum.

The downside is that MSF does not greatly improve communication other than the fact that it keeps the timeboxes short and encourages a collaborative agile team of peers, but the documentation still poses a threat to communication.

Scrum is a very different kettle of fish.
Scrum is designed to address a number of other problems:

  1. The Product Owner is a response to the lack of communication in traditional projects caused by remote stakeholders and by the sheer challenge of communicating a business idea from an executive to a programmer or architect accurately. Putting the business person in the role of Product Owner broke through this barrier.
  2. Demotivated and remote “techies” interested only in playing with gadgets is also a perception that still exists and it is countered by empowering them, making them into generalists and putting them in daily communication with their customer in the business.
  3. Fear of not knowing what “they are doing in there” is still an irrational fear that plagues the relationship between technology and the business. Delivering demonstrable pieces of functionality at regular intervals lets the business see proof that they are working and usually sends them off to sleep within a few months.

Aspects of Scrum that pose serious threats to success of a project

  1. Scrum was designed for writing code for fairly small projects. It was never designed to be used for many of the other unbelievable uses it is put to. The reason for some of these ridiculous applications of Scrum may be that Project management skills have been deprecated in favour of” the new thing”. The chances are they were not great to begin with and hence the adaption of Scrum
  2. Scrum is NOT Project Management, it’s designed by software engineers for software development. In small projects, the Product Owner could carry in his head all the stuff normally entrusted to a project and the scrum master can run the development, but this does not translate to bigger projects.
  3. Scope creep. Yes, we thought we had beat this one but in fact the reality is often that Scrum introduces a crippling level of scope creep. Three reasons mainly are to blame:
    1. No formal change control, nobody to say ” you are kidding?” so everything goes on the backlog
    2. No formal end date, so as long as it is all cosy, the business customer will keep on going, why should he stop?
    3. Bugs and millions more of them. Scrum teams don’t do formal testing and if you ever developed software you know what this means . Scrum teams also decide which bugs to fix and which to ignore. Naturally this becomes a tool when meeting the end of sprint deadline, it may be that the system works, but only just. That is acceptable by the way.
  4. A Scrum of Scrums is like replacing a big house with a tower block. It isn’t smaller or more manageable, it’s a mess. We spent the last twenty years turning old fashioned command and control organisations into flat collaborative ones. Now the scalable Scrum has built them back up again with a cell of cells like a medieval army. I’m not saying its impossible, just that it needs improvement and it’s not always worth the effort.
  5. Estimating is very difficult and Sprints are far worse at predicting their time and scope than traditional projects ever were. Costs are sometimes spiralling rather than falling, they just are not visibly so.
  6. Frequently the techies dominate the Product owner to get their own way and the collaboration is little more than a nice theory, the difference is he won’t tell anyone.
  7. Scrum was designed to be done by very experienced engineers all of whom were trained in Scrum. In reality few team members are even certified and the engineering skills are generally not good enough for a self-contained empowered team
  8. If any of the team members leave it can have a serious effect on the outcome.
  9. Scrumbut is a major problem. It refers to the practice of leaving out key parts of the process because you don’t like them, or whatever excuse. The problem is that velocity charts, retrospect and all the other rituals are there for a very good reason and when left out you end up with a traditional bunch of techies running amok with no controls, planning, or performance improvement strategy.
  10. The hatred of documents and authority figures really hurts when it comes to architecture.
    The team gradually becomes braver and makes more unqualified assumptions about the underlying infrastructure they are building on until eventually disaster happens and when it does there is no documentation, the designer has left and there is chaos.

 

So what should do you need to do if you are considering a Scrum implementation in your organisation?

  1. Begin by spending as much time as necessary to be very clear about what problem you hope to resolve with Scrum, or what benefit you want to reap.
    Don’t implement Scrum to deliver major projects, it was never designed for this. If you want to add some of the elements of incremental delivery etc, go ahead and introduce them to your traditional approach, or explore another method such as MSF.
  2. Define your criteria for deciding whether a project should be approached in a traditional way or via Scrum. Get advice if needed and especially in the first year, be very careful to tackle only projects that lend themselves to Scrum. As a guideline I would say:
    1. They should have a small element of invisible work, i.e. if there’s two months work to implement stuff you can’t demonstrate, don’t tackle this one with Scrum at least not till you are very experienced.
    2. The solution must be something that lends itself to incremental delivery and can be meaningfully demonstrated.
    3. The whole team including Product Owner can be located in the same building and I would try to get the Product Owner relocated to sit with the team.
  3. Define a clear framework for Enterprise Architecture and let the Scrum team clearly understand what they can touch and what they can not and don’t budge on change control mechanisms when it comes to mission critical systems and those that impact them.
    In TOGAF terms a good approach might be to say that only the Organisation specific technology can be touched and within that I might label parts of it uniquely for agile access.
  4. Don’t start with a team who have let you down at traditional approaches and read an ebook on Scrum. Send them away for a few days to be trained and hire an experienced person to coach the team through at least their first project.
  5. Put in place a QA process to monitor Scrum and their performance. Make sure that all the rituals are being done and in a meaningful way. Make sure the velocity is being monitored, monitor the accuracy of estimations, watch out for debt in the bugs department.
  6. Most of all, when you have a good plan in place and you are satisfied that you have the answers to hand, present your plan to your colleagues in the business in the context of how it will be impacting them, how they will benefit and how they will be expected to change the way they engage. Make necessary changes and then plan for the launch.
  7. This is really important. Take a cold look at your existing project management processes and ask yourself what is it that made you so keen to try an alternative approach. If some of these issues are not going to be solved by Scrum and I predict that will be the case, then set about resolving them in another way.
  8. Make sure you have a clear interface defined for how Scrum teams will interact with traditional projects and Programmes when asked to do so. There must be no them and us, but on the contrary, the two disciplines must support each other. You will need your programme and project management capabilities for many things and it will be beneficial to be able to interface a Scrum project with part of a project or a programme without ruffling feathers. This will also save you from the ignominy of trying to deliver huge projects via Scrum

 

TOGAF – well I finally did it ( here’s the summary)

TOGAF
I couldn’t find a readable short summary anywhere so I decided to bear the pain, skim read the dull text and write a summary for any unfortunate person trying to get a quick overview of a new framework in an industry he/she already knows well.
My conclusion after a few hours of wading through the treacle is that it is well put together, if horrendously poor in it’s presentation.
A slight contradiction is that parts are already a bit outdated in that it pays too much attention to things like portability in a world where interoperability is the buzz word and the “cloud” and “tower of babel” are the modern metaphors, nevertheless any slight shortcomings can easily be overcome by intelligent people using it.
A sharp warning though is that; even more so than the ubiquitous Prince2 for project management, TOGAF won’t make an architect of you, you have to bring all the skills to the table and then it helps you get things in the right order, but even that is up for interpretation, so you really must know your stuff and have integrity
It is not therefore a reliable hiring tool in it’s own right and I see it as definitely a team game.
TOGAF calls itself a Framework, but the main body of it is ADM which is in fact a process for doing architecture.
It follows the usual pattern of breaking up enterprise architecture into four logical steps (steps because it is a process)
The technical architecture uses a method closely allied to the idea of inheritance in OOD whereby the patterns and principals are inherited from more generic ones and you then build something more specialised on top of all that.
E.G.
Organisation specific ( This is the innovative bit)
Industry specific ( This is common to all organisations in a specific industry and saves a lot of time)
Common Architecture ( This varies little from one organisation to another therefore requires a little more effort than foundation, but saves much effort)
Foundation architecture ( This doesn’t vary much from one organisation to another therefore requires little, or no effort)
They call this idea the “Enterprise continuum”
Questionable ideas
Things I would question:
1.The Foundation architecture specifies knowledge bases that you need to develop such as a set of standards and a Technical reference Model. This part is potentially futile in that:
a.constant change often makes last years standards out of date, but nobody ever updates these things
b.notwithstanding the previous comment, experience suggests that few people ever refer to them even in some big name software houses.
2.Developing business processes and storing them away gets mixed reactions.
a.Many processes are defined by and governed by the existing productivity systems and in any case may even have no scope for change, so what will you gain from low level process views?
b.The speed of change is such that keeping recorded process up to date will be more of a chore than a benefit in many businesses.
c.If you can set this at a high enough level such as business goals and strategy it is very useful, but then the benefit depends on the audience who will access it, or ignore it. The jury is out.
d.The right place in my view for business process analysis is Opportunities and solutions phase and the key to this is JIT (as per the Agile principal) if you want relevance and accuracy. In my opinion,  nobody in their right mind would invest a large sum on a solution based on old archived process diagrams at least not any experienced business analyst.
e.Finally new systems generally herald a new process, or new approach to the goal and therefore brand new processes. As-Is modelling is only an exercise to extract the business rules in order to build a better process against them, otherwise, who needs a history level in a manic business world?
3.I don’t see a Zachman like illustration that lets a business stakeholder engage with it on a business level without struggling with the gibberish. If I am right about this, then it could be a downfall, because it will end up just a techie thing behind the doors of IT and the business stakeholders look skywards at the mention of it. This is very common and would negate most of the effort.
You only have to attempt to get some sense out of the Open Group website to see what I mean. If reluctantly, at least I was able to suffer it and get a glimpse of the big picture, I can’t see anybody form a business background touching it with a bargepole. I think the implementation needs to be aware of this and cover up for the shortfalls.
4.It’s a techie invention and although pretty good once you uncover it, it was “not invented here”.
5.The Migration Planning function is a potential route to serious friction. Modern business won’t stand for an IT function that wants to “wag the dog”. When they want it in three months because it is important, no amount of processes will stop them and I have seen many big rows break out over this. I recently saw a head of projects and a director resign within two weeks of each other over rows based on this function.
ADM
The process looks something like this:
The colour coding is a suggested classification based on my interpretation and my own experiences, but I fully expect to be contradicted as I did spend a only a few hours on this and concluded the following:
Pale Blue box – CTO/CIO/Technical architect and/or Enterprise architect.  Plenty of sign-off seems to be the order of the day.
Black box Technical architect’s role but very much in collaboration with the IT function, who will have to implement it and keep it running. Often the ITIL process sits between the black boxes and the rest of the process.
Red box  – Business focused business analyst and I would say a lot of verification needed to make sure the techies don’t build a toy when nobody is looking.
Green box  – Data analyst and systems analyst
Purple box –  Business analyst role working with the business to identify opportunities, develop business cases and priorities shortlists
Blue box –Test, or QA manager and UAT signed off by  Business Analyst and UX manager.
As a rough guide the phases look something like this:
Framework and principals
1.define the scope of the project,
2.adapt the ADM process to your situation
3.identify constraints, document the business requirements, and
4.establish high-level definitions for both the baseline (starting) architecture and target (desired) architecture.
Business architecture
1.business modelling,
2.highly detailed business analysis, and
3.technical-requirements documentation.
Information systems architecture
1.develop baseline data-architecture description
2.review and validate principles, reference models, viewpoints, and tools
3.create architecture models, including logical data models, data-management process models, and relationship models that map business functions to CRUD (Create, Read, Update, Delete) data operations
4.select data-architecture building blocks
5.conduct formal checkpoint reviews of the architecture model and building blocks with stakeholders
6.review qualitative criteria (for example, performance, reliability, security, integrity)
7.complete data architecture
8.conduct checkpoint/impact analysis
9.perform gap analysis
Technical architecture
The infrastructure necessary to support the proposed new architecture.
Opportunities and solutions
Evaluates the various potential solutions and prioritise the ones that deliver most.
This is about business cases and stage gates and good financial analysis, but it is also about good business instinct and gut feel and requires business people to make the decisions in possession of the best possible information.
Migration planning
This is mostly programme management in that it involves acting on the outputs of the previous step to plan the flow of project through system taking into account opportunity and dependencies.
Implementation governance
This is most closely aligned to QA functions in project and programme management
It sets the acceptance criteria
Architectural change management
This is about updating the change management documents with details of new additions. For me, this is better handled by ITIL and as a PM this normally means an agreed handover to IT as part of the implementation and rollout plans.
Once in place
After the first implementation, I interpret it that the business will engage with the Opportunities and Solution function which triggers a quick iteration of the previous steps of ADM to make any required adjustments and the new solution progresses through the remaining stages.

TOGAF

I couldn’t find a readable short summary anywhere so I decided to bear the pain, skim read it and write a summary for any unfortunate person trying to get a quick overview.

My conclusion after a few hours of wading through the treacle is that it is well put together, if horrendously poor in it’s presentation.

A slight contradiction is that parts are already a bit outdated in that it pays too much attention to things like portability in a world where interoperability is the buzz word and the “cloud” is the modern metaphor, nevertheless any slight shortcomings can easily be overcome by intelligent people using it.

A sharp warning though is that; even more so than the ubiquitous Prince2 for project management, TOGAF won’t make an architect of you, you have to bring all the skills to the table and then it helps you get things in the right order, but even that is up for interpretation, so you really must know your stuff and have integrity. It is not therefore a reliable hiring tool in it’s own right.

TOGAF calls itself a Framework, but the main body of it is ADM which is in fact a process for doing architecture.

It follows the usual pattern of breaking up enterprise architecture into four logical steps (steps because it is a process)

The technical architecture uses a method closely allied to the idea of inheritance in OOD whereby the patterns and principals are inherited from more generic ones and you then build something more specialised on top of all that.

E.G.

Organisation specific ( This is the innovative bit)

Industry specific ( This is common to all organisations in a specific industry and saves a lot of time)

Common Architecture ( This varies little from one organisation to another therefore requires a little more effort than foundation, but saves much effort)

Foundation architecture ( This doesn’t vary much from one organisation to another therefore requires little, or no effort)

They call this idea the “Enterprise continuum

Questionable ideas

Things I would question:

1.The Foundation architecture specifies knowledge bases that you need to develop such as a set of standards and a Technical reference Model. This part is potentially futile in that:

a.constant change often makes last years standards out of date, but nobody ever updates these things

b.notwithstanding the previous comment, experience suggests that few people ever refer to them even in some big name software houses, so only do it if you can enforce it.

2.Developing business processes and storing them away gets mixed reactions, I suspect that this should be built up over time as and when you have occasion to look at particular areas of process.

3.I don’t see a Zachman like illustration that lets a business stakeholder engage with it on a business level without struggling with the gibberish. If I am right about this, then it could be a downfall, because it will end up just a “techie” thing behind the doors of IT and the business stakeholders look skywards at the mention of it. This is very common and would negate most of the effort.

You only have to attempt to get some sense out of the Open Group website to see what I mean. If reluctantly, at least I was able to suffer it and get a glimpse of the big picture, I can’t see anybody from a business background touching it with a bargepole. I think the implementation needs to be aware of this and cover up for the shortfalls.

4.It’s a techie invention and although pretty good once you uncover it, it was “not invented here”.

5.The Migration Planning function is a potential route to serious friction. Modern business won’t stand for an IT function that wants to “wag the dog”. When they want it in three months because it is important, no amount of processes will stop them and I have seen many big rows break out over this.

ADM

The process looks something like this:

ADM process
ADM process

The colour coding is a suggested classification based on my interpretation and my own experiences, but I fully expect to be contradicted as I did spend a only a few hours on this and concluded the following:

Pale Blue box – CTO/CIO/Technical architect and/or Enterprise architect.  Plenty of sign-off seems to be the order of the day.

Black box Technical architect’s role but very much in collaboration with the IT function, who will have to implement it and keep it running. Often the ITIL process sits between the black boxes and the rest of the process.

Red box – Business focused business analyst and I would say a lot of verification needed to make sure the techies don’t build a toy when nobody is looking.

Green box – Data analyst and systems analyst

Purple box –  Business analyst role working with the business to identify opportunities, develop business cases and priorities shortlists

Blue box –Test, or QA manager and UAT signed off by  Business Analyst and UX manager.

As a rough guide the phases look something like this:

Framework and principals

1.define the scope of the project,

2.adapt the ADM process to your situation

3.identify constraints, document the business requirements, and

4.establish high-level definitions for both the baseline (starting) architecture and target (desired) architecture.

Business architecture

1.business modelling,

2.highly detailed business analysis, and

3.technical-requirements documentation.

Information systems architecture

1.develop baseline data-architecture description

2.review and validate principles, reference models, viewpoints, and tools

3.create architecture models, including logical data models, data-management process models, and relationship models that map business functions to CRUD (Create, Read, Update, Delete) data operations

4.select data-architecture building blocks

5.conduct formal checkpoint reviews of the architecture model and building blocks with stakeholders

6.review qualitative criteria (for example, performance, reliability, security, integrity)

7.complete data architecture

8.conduct checkpoint/impact analysis

9.perform gap analysis

Technical architecture

The infrastructure necessary to support the proposed new architecture.

Opportunities and solutions

Evaluates the various potential solutions and prioritise the ones that deliver most.

This is about business cases and stage gates and good financial analysis, but it is also about good business instinct and gut feel and requires business people to make the decisions in possession of the best possible information.

Migration planning

This is mostly programme management in that it involves acting on the outputs of the previous step to plan the flow of project through system taking into account opportunity and dependencies.

Implementation governance

This is most closely aligned to QA functions in project and programme management

It sets the acceptance criteria

Architectural change management

This is about updating the change management documents with details of new additions. For me, this is better handled by ITIL and as a PM this normally means an agreed handover to IT as part of the implementation and rollout plans.

Once in place

After the first implementation, I interpret it that the business will engage with the Opportunities and Solution function which triggers a quick iteration of the previous steps of ADM to make any required adjustments and the new solution progresses through the remaining stages.

I remember having very similar thoughts about Pricne 2 when I first tackled it, so I wont be put off.

Perhaps I am one of the stronger proponents of Enterprise Architecture as a means to avoiding meltdown, avoiding waste and keeping the IT funciton focused on value added activities. For this reason I have decided to suffer the pain and see this through.
Maybe I will then get the courage to write a consumable version of this to win back the many talendted and desperately needed people who surely must have been alienated form the profession by the manner in which this is presented.

 

Good management strategy and practice supported by intelligent modern systems

Let’s begin with the strategy and management practices before we start talking about systems.

In the last instalment, we talked about schizophrenic businesses. Businesses with confused outlooks, confused processes and naturally enough, confused systems, confused workforce, resigned customers, despairing shareholders.

The five cardinal sins that create schizophrenic organisations:

  1. You have a business made up of a number of recent acquisitions and you were always too busy to complete the business change aspects, so now you have one logo and 17 brains, in other words semi-organised anarchy.   This is painful and confusing for everyone and often a difficult environment to work in if you need to deliver things to a quality standard and meet targets. This can’t be fixed with technology alone, in fact often the technology is the one thing that got fixed, at least sufficiently to manage the finances.
  2. You bought the best systems straight off the Gartner list and now there is only one way to run the business; the Oracle, Salesforce, SAP, Microsoft way. Tough! It has it’s advantages, but the price is a very high one and the road out of this is expensive, but achievable by the very bravest and most resilient and worth the money.
  3. Your CIO needs to be the first with every new fad. He gives powerful presentations and gets his own way, then yet another expensive toy sits on the racks generating heat and costs. This is a very common situation and seems to have become worse right through the recession when one might have expected common sense to prevail. Fixing this needs engagement and dogged adherence to the principal of “so what?”
  4. You have had six years of cost cutting to keep the earnings figures appearing to rise. Every trick that could seep past auditors has been exasperated and now you have only the skeleton and one ear of the monster still switched on while the magic machine generates one more great interim report. This beast could be in trouble and making the changes you need will demand capital and commitment
  5. You follow the right methods with systems, but you have a confused collection of people in incoherent departments with conflicting goals and your entire business is a collection of silos that resembles an over busy cluster chart.  This is even harder to put right because unlike 1, it is culture rather than circumstance and technology can’t fix this alone.

Who are we listening to? The staff? The shareholder? Customer? Society? Anyone?

I take a simplistic view of business. In my view it serves three groups of people in society and though this it justifies it’s existence. When it ceases to serve any one of these groups it is on the slippery slope.

1. It returns income to investors in some form. These investors are often the very same people that pop up in other stakeholder groups such as customers and employees except these stakeholders are typically saving for their retirement and relying on the business to keep their nest egg safe. The business has a legal and moral duty to these stakeholders.

2. Employees make lifelong commitments to businesses and rely for their income, security and even their physical and mental well-being on the environment where they work, the remuneration they receive and the opportunities and stimulation it provides. In fact when you take away the employees there is no business left but a piece of paper. Again there are substantial legal commitments here as well as moral duties.

3. In a free market, the customer is the only reason the business is able to exist. If it fails to satisfy the customer, she will walk and the business will close down with loss of capital and jobs for the other stakeholders. When customers stop buying whole economies close down This is why the customer is number one. In theory at least.

4. The business can not ignore its duty to society. The peaceful stable environment, the transport infrastructure and the healthy educated workforce all are provided by the host society and must be paid for. Business exists for society and not the other way around, though most no longer are anchored in any specific  nation let alone society.
In practice today, the most powerful stakeholder in the business is senior management in whatever form. Modern market driven business cycles give little time to deliver and rarely allow for forward thinking. Horizons can be very short term and stakeholders can be forced into poor decisions to satisfy very short term demands.
Next in the order of power is the investor. The investor will take her capital elsewhere unless she receives a dividend or perceives a promise of capital appreciation  through whatever means.
Typical financial tricks to keep her happy include: misreporting earnings, misappropriating funds, cutting costs though reducing service to the customer, inflation . . .
Most capital is managed by institutions and they have short term very selfish goals that don’t often reflect the actual investor they represent.

Right at the bottom of the power list comes the customer. This is not the forum for a discussion on modern free markets and the growth of the big brand, but we all buy the same stuff from the same, or similar companies and we all know that you can go through hell to cancel your broadband, mobile, gas, current account etc only to be faced with an almost identical, if not worse service when the new one finally kicks in and the price, if significantly better won’t be better for long. The majority of non cyclical sectors are tied up in oligarchy (at best) and the opportunities for start-ups continue to decline as more of the local high street or Mall is gobbled up by multinationals the ancestral home of Lernaean Hydra.

The typical budget each of these suppliers have set aside for convincing us  that they love us even more than the opposition do and will be our best friend forever, is in most cases many, many times greater than the cost of booting out all the misconceived cost cutting measures and just giving us a great service.

Worst of all, most of the service calls are a result of; bad product, bad documentation, bad service, mis-selling, or untrained, demotivated, underpaid staff and there is a  much more effective solution if anyone was interested.
Does my broadband provider really think I want to get up in the morning and spend a few hours on the phone to their staff? Of course I don’t, I just want a service that does what it promised and to be charged as per the agreement for it. Apart from emergencies I don’t want to hear from them.

Don’t get me wrong, I have seen empirical studies proving via brain scans that consumers received substantially more pleasure from Coke when they knew the brand and consumed it from familiar branding despite the fact that preferred Pepsi when it was presented in incognito taste tests. Yes branding, when done well, not just creates illusions, but it creates real value. I do however refuse to believe that even if the monster had only one head and a very pretty one at that, I could ever be brought to feel pleasure at switching on my lights because the electricity was supplied by Gobblydegook PLC, or look forward to the next blackout so I could call them.
Dig out that business case for your “close the call centre project” and verify it a little. Now ask yourself how much you really saved net. Then ask yourself how much you will have to spend to replace the customers who left in exasperation and to counteract the low murmur of dissent on Facebook and Twitter.

Now collate a years worth of marketing communication for about a dozen customers who represent customers at different points in the customer journey (you do have one?), e.g. new customer, changing product, etc etc. Tally up the total cost of this including all the calls handled as a result and minus any new business generated from this activity and this will give you an indicator to use in your revised business case. Prepare for a shock.

Put yourself in the shoes of this customer and ask yourself; what did all this noise actually say to that customer about our business? Are you seeing 19 headed monsters again?

I have been though this exercise a few times and I could write about this all day, but you have to do it yourself to learn anything and you have to be interested enough to want to know, or this whole discussion is of no value to you. When you finally get to the point where you are ready to understand where these problems are coming from, there are tools you can use that throw light on this in remarkable ways and I will be introducing them in a later instalment.

Finally do remember, there is a time for taking the investor and the employee into account, after all, there is no point in serving a customer well if it is not profitable, and the days are gone when we are justified in enslaving people to expand the family pile, but when you are thinking customer, keep the others at bay and just focus on customer experience. Don’t have the guy who wants some branding experience on his CV decide what the customer would like to experience any more than you’d let the customer decide what final dividend to pay.

Tune in to the next instalment to see a very neat way of getting a 360 degree birds eye view of the relationship with your customer and 20:20 vision of how to bridge that gap.

Lernaean Hydra, your time is up.

Give big data the heave-ho for now and get a birds-eye view of your business without a single nosql database. 

The agile organisation – a risky proposition

When somebody tells you that they want their organisation to be agile, what do you read from that? I’ll bet you feel a bit sheepish because you feel that yours is not, but it should be. I suspect that you remember this becoming a fashionable goal and thinking you would find out at some point what it all means.

If you answered yes, then you just joined a huge club closely affiliated to the new man”, “cosmopolitan woman” and all the others.

Maybe you have already announced to your boss that you are “going agile” and you still haven’t quite got round to working out what precisely it is, but you instinctively know that it is right for you. This is also a very large club growing daily. You won’t be lonely in there either.

The most likely thing is that you came across it via a systems project and all the new converts raved about their new found, almost religious belief in this cure-for-all-corporate-ills. You loved the stories about no decisions, no commitment, no planning, and no documents. ”This is damned interesting, I want to hear more”, you said

What did Bill Gates mean and what did it mean to Microsoft to be agile. Well Bill made the mother of all misjudgements when he said that the internet was of no interest to Microsoft and dismissed its potential. Within one and a half years, Microsoft had changed its mind, won the browser war with Netscape and delivered ASP, the first and still dominant commercial application server for the internet. That was agile, but it had not a thing to do with stand up meetings around whiteboards and walls covered in scribbles.

Horses for courses

Adapting a largely web development methodology and attempting to use it as a corporate philosophy is bonkers. Anybody who tells you otherwise is out of her tree and I’m not given to sweeping statements, so I’ll need to back that up with some arguments, here goes:

  1. Large organisations need process, it is their blood supply

Have you ever experienced an agile development team in the software world? The entire fabric of specialisation, process, controls and method are abandoned completely. Everyone claims to be multi-skilled, they are a team of peers, and they operate outside of the business rules and the corporate structures.
They romanticise it as though they were a hit squad, “licensed to kill”.

All this was put in place for a reason. A highly skilled multi-talented team empowered to JFDI is a great solution to political stalemate and analysis paralysis in specific situations, but would we want the CIA or Mi6 running the country?

Even in a highly mature market, our only corporate goal is to maintain our competitive position or improve it and in many cases this is driven by economies of scale and brand strength. This is why we have oligopoly and cartels everywhere manipulating key domestic markets such as supermarkets, fuel, banking, etc. A typical sluggish, but safe operation is exactly right for the job, low risk, stable and relatively low cost. It can function with the average half to three quarter wit at the wheel and needs no dynamism. It’s all about horses for courses. You can’t take away their crutches and expect them to perform. History shows that it fails miserably.

2. The vital relationship between good strategy, intelligent planning and sane execution. Anybody who has working experience of trading the stock market knows the persona of the Bull and Bear. These fabled characters are, of course, not different individuals, but different phases in each trader’s performance. Adrenaline, or cortisol take over quickly when the action begins and knee jerk reactions produce cowardly hibernating bears, or arrogant testosterone fuelled bulls

I witnessed this just recently when my irrational fear of snakes was suddenly reawakened by almost stepping on one and watching him thankfully slither away. I was physically unable to walk any further and had to resist the urge to run back to the safety of the car. It took a few days before I could walk in the woods again without watching every blade of grass.
I went to Vegas once and discovered that one friend had a deeply rooted gambling issue such that he could only see the chance of winning the next hand and had no inclination of the odds. The higher the likely return the more attracted he was, never weighing it against the likelihood of winning. Both of these situations are unnatural and unrealistic reactions to risk and opportunity and both are potentially destructive.
Let neither fear, nor greed be your master
Human reaction to risk and opportunity both tend to bring out the very ugliest sides of human nature, greed and fear. Neither of these emotions is rational and neither can be trusted for any length of time. They stem from another era when we needed to run very fast into a cave without asking questions, or gorge ourselves before we were driven away from the feast by a more aggressive animal.

It is because of these irrational behaviours that every aspect of business behaviour must be driven by a well formed strategy that includes:

  • A well understood risk attitude
  • A carefully devised approach to managing day to say risk that keeps the bear and bull within us well out of the picture and supports rational management behaviour.
    A risk strategy is not a simple thing to plan out. The fact of the matter is that the more attractive the reward is, the higher the risk will generally be. You have to make your choices


Some examples from the finance and gambling industries
E.G. A bank with its risks spread over the right industries and economies can expect that when one is doing poorly another is doing well and thus balance risk.A bookie can balance his books by taking a precise level of exposure on every horse in a race so that regardless of the outcome he wins a little over the day’s activity. Taking a big picture viewpoint as above, and developing from this a strategy that can be applied at a more granular level allows me to look at the snake philosophically and continue my journey, it allows my gambling friend to view his account on a quarterly basis and aim for a profit without making rash decisions on the spot. It doesn’t stop me from pausing till the snake has disappeared, or taking simple precautions in future.

  • A banker without a strategy would panic when three customers in a row defaulted on their payments. A bookmaker would run for the car park when two favourites in a row won forcing him to pay out. Only reliable insight, a solid strategy and a sound plan allows ordinary individuals to successfully run apparently high risk industries.
    Knee jerk “agile” management is the stuff of the hard luck stories.

3. Responsibility to our shareholders demands responsible decisions, audit trails and experiential learning.
Never before have we been so aware of the responsibility to our way of life that is borne by officers of private businesses everywhere. Every quoted company is taking the savings of pensioners and promising to give them a return annually so they can finish their lives in dignity. Every business has a responsibility to employees and investors of all sorts whose lives depend o their performance. Our world is continually burdened with more audit requirements as more frauds are discovered. We need robust and recorded decision making and we need accountability.
Informal decisions around the water cooler open the door wide for the irresponsible amongst us. I’m not espousing process laden organisations with forms to fill in for everything, but if you leave the cookie jar without a lid, you just know what is going to happen

4. The team is everything
Teams are made of people, not numbers, roles or little boxes connected by lines.
People must have their needs met if they are to perform and if individuals don’t perform the team fails. The things that motivate people to perform are all based around security. Maslov’s hierarchy of needs and later Herzberg’s hygienes and motivators all demonstrate that people need to know where they stand in their group and that their standing must fit their contribution. An agile team in the software world can, if correctly balanced to begin with perform very well, but usually it is utterly dominated by one person and becomes a benign dictatorship. Any attempt to get things right first time are usually dropped in favour of constant revision mode and quickly they realise that constant activity disguises the lack of any meaningful outputs.
The peak of the productivity curve is reached very quickly and after that it is all down hill.
In a non software world, there is little difference other than the fact that sometimes the potential downside can be catastrophic and constant revision is usually less of an option. Single agile teams tackling key business change issues can, if correctly and responsibly set up and under constant enlightened management, both during the forming, norming . . phase and into maturity, produce exceptional results for exceptional managers, but as a broad approach and using a large team of teams, the roll call of spectacular failures speak for themselves.

5. The map is not the territory
Most management philosophies are corrupted shamelessly and misused without any insight into what makes them work. Agile works, but only in it’s own unique environment and only when the core competencies exist and the critical factors have all been properly taken care of.
The risk is seeing only the landmarks, e.g. that you see agile as: describing things in user stories, or having stand up meetings, or small empowered teams, or Just In Time decisions making, or incremental delivery of product. You can adapt any of these that catch your eye and maybe they well deliver what you expect, but that won’t make it agile.
See beyond the ceremony, stare straight through the dogma, but when the time is right, do it right and the rewards can be very encouraging, but don’t close your eyes and try to drive by the SatNav.