Year: 2019

A go-to move when joining a new company or project is to ask for the template.

There’s a feeling of security in a blanket.

The intention of a template is to safely guide an individuals expertise when creating a piece of work. It’s intended to be a home for relevant content that has been driven out through the thoughtful use of appropriate business analysis techniques.

The trouble is templates aren’t always used that way. Because, templates have an unintended built-in trap.

Template-driven analysis is a rut, that:

1. Pedestals the production of documentation
2. Distracts from considering the job at at hand
3. Becomes the completion of a ‘one size fits all’ form
4. Encourages the use of content fodder
5. Builds silos across the organisation
6. Keeps the analysts roots firmly in B.A. 2.0
7. Dumbs down the value of business analysis
8. Stagnates the careers of many

Templates don’t mean to be bad. But when they’re misused, they’re horrid.

A quick scour of the web will surface many definitions of what business analysis is. All technically correct, but all quite raw (a product of the 70-year squeeze).

In this day and age, it’s time to narrate the story differently.

This is business analysis…

Business analysis is helping someone to solve their problem or seize an opportunity.

Seeking to understand the stakeholders’ perspectives, desires, and world-view.

Focusing on satisfying the need for products and services that meet people’s requirements. 

Building relationships that create meaningful change and make a positive difference.

Business analysis is a force of change. A business analyst is only effective if they create change.

Do work you’re proud of.

1951 saw the worlds first commercial business application.

J Lyons and Co. automated valuation jobs, then payroll. Then a few other companies, who didn’t have computers, wanted to borrow their machine. So J Lyons established a ‘Bureau Services’ division (which could arguably be the earliest IT consulting company).

Since then, the 3rd Industrial Revolution has been in full-flow with a very prominent theme.

The definition of standards:

• 1956 – Software Engineering
• 1957 – BCS
• 1961 – TQM
• 1963 – IEEE
• 1969 – PMI
• 1970 – Waterfall and Agile
• 1978 – JAD
• 1980 – SSADM
• 1986 – Six Sigma
• 1987 – ISO
• 1988 – Spiral Model
• 1989 – CMM
• 1991 – RAD
• 1992 – V-Model
• 1996 – Prince 2, PMBOK and Scrum
• 1997 – UML
• 1998 – RUP
• 2003 – Agile Alliance and IIBA
• 2005 – BABOK

That’s our immediate past.

The 70-year squeeze of frameworks, methods, models, approaches, processes, notations, languages, and more. Relentless standards that draw lines in the organisation, best practices which work within these boundaries, and detailed procedures to follow along.

The space for creativity has been removed and how you do what you do is shaped for you, squarely.

You’re conditioned to think inside a box.

A couple of years ago I experimented with a new personal assistant.

Amy Ingram helped me to schedule meetings. Amy learned when, where and how long I liked to meet.

But what made Amy different was that Amy is an email AI scheduling assistant.

Machine learning.

But there was also some big human learning too…

From the beginning of the relationship, I was learning how to interact with Amy to ensure understanding. Requests being asked and answered, communication sent back and forth.

Then at one point during a conversation, Amy stopped me in my tracks…

Amy said, “One way is to shoot me an email “Amy, please cancel this meeting.”

That one word in there.

“Please”.

Did I need to say ‘please’? This is an AI interaction. How had I been interacting up until this point? Had I been all ‘computer-like’ using command language such as, ‘Cancel Meeting’? Was my human behaviour (ironically) being adjusted by a machine?

Just what is the protocol for interacting with AI?

Interestingly I had been communicating politely, quite unconsciously, as the conversation with Amy unfolded naturally.

Amy has a last name, Ingram. Amy engages in conversation. Amy needs to be communicated with clearly. Amy asks clarifying questions. Amy learns. A relationship was established. I minded my Ps and Qs.

Whether as a ‘User’, a ‘Developer’ or a ‘Tester’, AI is your next stakeholder.

Soon we’ll be working together, side by side. AI will be a colleague. AI will have their own views, needs, processes, requirements and rules, etc.

This world is heading somewhere and how you work is going to change.

The T-shaped metaphor has been about for some time – being a strong person with specialist depth and generalist breadth.

People are recruited accordingly:

• A+ years of work experience in B role
• Must have C degree in D specialism
• At least E years experience in the F industry
• Experience working in a G environment
• Practical experience of working with H method

And then a subconscious bias kicks in where managers choose people like themselves. Meaning the same people are hired, again and again – gingerbread people cookie cutters.

Which often leads to a place of confirmation bias, creating a culture that reinforces the same way of doing things and affirms the same belief systems at play.

That approach worked, somewhat, during the Knowledge Age. But it’s blunt now, as this next shift – the Conceptual Age – is calling for sharp innovation.

Innovation is not down to you or me. It’s down to us. As true creativity comes from a place diversity. From having a room full of individual experiences and different ideas – a gingerbread house.

What can you do to start building a team shaped for the future?