How to build an Innovation Factory

What is innovation and how do we make innovation intrinsic to an organisation?

Recently I attended Australia's most innovative company awards. The recipients were all impressive in there own right, however I came away questioning whether people understood innovation...

Firstly,  what is innovation? Sometimes confused with invention.  Invention is a type of innovation, a new product/service,  usually the result of an idea.  Innovation at a corporate level more generally however is about improvements, not necessarily something new. As a Business Analyst I practice a systematic approach to improving the current state. We elicit the problem or need, and work with subject matter experts to improve the businesses capability. Innovation is most often the result of careful analysis and a process of 'questioning assumptions'. Think there is a false impression that all innovation is born while sipping on a cafe latte.  Sure some innovation stems from ideas,  but clearly much less predictable and repeatable.

Now that we are clearer with what innovation is,  how do we make the concept part of the business? I heard someone mention the concept of an innovation factory, which got me thinking... how do we build one? If we wanted to create continuous innovation what are the critical success factors?

Well its quite simple ...lets start with a quote

"When you say “collaboration”, the average 45 year old thinks they know what you’re talking about – teams sitting down, having a nice conversation with nice objectives and a nice attitude. That’s what collaboration means to most people. But for Google and many other companies, collaboration is a profoundly new approach to orchestrating capability in order to innovative, create goods and services, and solve complex problems" 
Don Tapscott, MacroWikinomics

A profoundly new approach to orchestrating capability in order to innovative, create goods and services, and solve complex problems...BINGO

Collaboration maturity is a series of events where we learn to connect, share, solve and then once the group has achieved these levels of collaboration maturity we are able to innovate.

So how do we improve our collaboration maturity?

1. Invest in the right technology...with a Enterprise Social Platform (ESP) at the centre
2. Embed collaboration in process...meeting management, executive engagement, project delivery methodology, etc
3. Change the organisational mindset...Trust in beta, public by default, understanding networks, responsibility to share, appreciating context (over content) 

If it was that easy everyone would be doing it...Get collaborating

The truth

"Seek the company of those who search for truth. Run from those who have found it." - Vaclav Havel @mcafee

A BAs Top Three

So what three things should we be looking for in modern Business Analyst?  


Capability, Competencies and Skills are often use these terms interchangeably. What results is a messy overlap that compares apples with oranges...it just doesn't work. So I decided to provide my top three of each. Below is how I define these characteristics:

• CAPABILITY - ability to derive relevant value. Usually a combination of skills and competencies eg effective 'Business Process Management (BPM) is valuable to an organisation. Can be assessed, but difficult to train as it is a set of complex attributes.
• SKILL - activity related components that contribute to capability. eg i'm skillful at business process modelling and contributes to my capability in BPM. In isolation provides little value. Can assess and trainable.
• COMPETENCY- intrinsic ability to execute skills and derive capability. Often related to leadership, however in Business Analysis the scope is broad. eg i am an excellent listener which helps me engage stakeholders and elicit requirements. Difficult to assess, can be improved with training and experience. Not industry specific and often stronger competencies are learnt through industry diversity.

Top three capabilities...

1. Business Process Management - capture/improve/redesign, governance, strategic alignment, culture/people implications, tools
2. Requirements Management - elicit, manage, document, tools
3. Enterprise Analysis - vision/strategy, stakeholder assessment, financial analysis, business case

Top three skills....

1. Collaboration (tools and techniques)
2. Business Process Modelling
3. Writing Business Documents (as opposed to technical documents)

Top three competencies...

1. Integrity and trust (leadership)
2. Interpersonal savvy (leadership)
3. Business trends and best practice (functional)

There is a place for email

A recent blog I responded to encouraged me to explore appropriate use of email.


Email is a channel too often used inappropriately...
It is time to discuss what it should be used for, and what it should not.


What email is for:

• Personal messages - can be a good tool for clarity in one-on-one dialogue, eg after a phone call..."I'll send you an email to confirm our discussion"
• A directive - to a group of people and don't expect a response
• Specific people - when you want to limit (not control) distribution
• Notifications - consolidates updates from various platforms (C3, Facebook, Linkedin, etc)

What email is NOT for:

• Dialogue - telephone and IM are better tools for one-on-one discussion
• Discussion  - email is a channel, not for discussion. Stop the 'reply all' emails. 
• Innovation - Controlling distribution is a significant dampener to innovation.
• Everyone - a question, comment or answer will be of greater value on a platform.

Stop inappropriate use of email!

Are BAs ready for Agile?

Over the past 12 months I've been involved in some interesting discussions about BAs and Agile. What is clear is that the capabilities needed for business analysis in Agile delivery are quite different to that required for waterfall. BAs traditionally are training to define solutions and limit change. In Agile, we are looking for BAs who resist the temptation to define the solution, and accepting of change. Waterfall is about documenting with the client in mind, whilst Agile is with the developer in mind.


With this said, it is understood that the transition from waterfall to agile is a step learning curve for all concerned. What is possibly lacking in the BA space is role models and/or managerial reinforcement. Engineers are generally taking this journey as a team, but from experience... BAs tend to have a lonelier existence. Methodology that is inherently highly structured, management that are struggling with the shift in required capabilities, and engaging with businesses that just want documented requirements.

The thing is BAs should be better suited for Agile than most. They have a set of competencies that are well suited to dealing with ambiguity. Good BAs are experts at managing expectation, and this is a important for Waterfall or Agile alike.

My personal experience is with Scrum, and good evidence for effective use of BAs. In one project we used a BA to work a sprint ahead, preparing the sprint backlog for the dev team. On another (a large Defence project), after a number of setbacks the lead BA became the scrummaster and completely turned it around. It was so effective, there was consideration for this to become a norm. On my last project (before switching companies) I was the Product Owner on a BPMS implementation where business commitment was a problem. I am obviously bias but would like to think we provided an impressively innovative solution with equally impressive speed.
I found this in the definition of a PO "product owner is in many ways an empowered business analyst" (http://goo.gl/JM8xw).

I am convinced that BAs are in the box seat to play an integral role in the Agile transformation and believe we will see benefits from a greater overlap between the communities.