Sixto Rodriguez : life, winning and what success really is.

I think by now, we all know the story of Sixto Rodriguez. A poet, a songwriter with lyrics like Dylan, haunting melodies, infectious music that digs into your soul and never leaves. Forgotten by America, loved, adored and worshipped in South Africa. Or so the Oscar winning Documentary goes.

 

I grew up straddled across the end of apartheid. Half my childhood happened before it ended, and the other half happened in a bright new Rainbow Nation struggling to find its identity without imploding on itself.

Photo of Steph with Family in South Africa in 2015 - picnic venue
My Crazy Family (missing a few peeps who couldn't make it) - this is winning in my book.

For me Rodriguez was, and always will be a superstar. I reckon I could sing the words to “I Wonder” before I could talk in full sentences. My parents loved his music, my grandparents loved his music.

 When children grow up as digital natives, they do not comprehend a world where you have to wait to phone someone for any reason whatsoever, similarly for me, it just never occurred to me that there could be a world, where “Sugarman” was not as big or as popular as any song from the Rolling Stones or Beatles.

So, finally in 2012, when I watched Searching for Sugarman from my home in Melbourne Australia, I was blown away.  I could not immediately and fully process the fact,  that the man I had thought of, and known as a mega-superstar, was completely unknown in his home country until recent years.
I was using my iPad while watching the DVD to google the director and producer of the movie, convinced that this was some elaborate hoax.
And since then, I have watched as he has finally been recognised as an artist in the USA, and across other parts of the world.
I had the opportunity to see him perform live in 2014. And I was not disappointed.
There are no pyrotechnics in his show.  He has none of the trappings of being famous normally associated with musicians his age. He is also a bit frail, and reportedly suffering from eye issues, so had to be escorted onto stage.There are no props, dancers, or any other extra bits normally associated with a live performance.
And yet - it was the best live show I have ever seen. Hands down.
Rodriguez' talent is humble, and great, all at once. He stands on stage, plays his guitar, sings his songs, and for everyone, it is enough. In fact is it more than enough, it is everything.
Rodriguez teaches us, that fame corrupts. That success is a matter of opinion. And what makes us happy, gives us meaning, and fills our souls, is what we should be doing with our days, our lives and our work.
And while it sounds like the enthused ravings of an obsessed fan, just stop and consider the brilliance, sincerity, and timelessness of his music.
He has new fans now, because the album is amazing. Not because we all feel sorry for him. Empathy alone could not translate into sold out shows across the globe. Facebook likes don't pay the bills or fill stadiums.
We will never know how badly disappointed he really was all those years ago, but all of us that have tried and failed know exactly what it is to put your life-blood into something and have it come to nothing.
We all know the heartache of making something that has every bit of our soul poured into it, and then finding out that actually no-one wants it.
So finally – what Rodriguez teaches us,  is about failure. And how it's never the end.
We learn to pivot and be happy, there is always another market, a different space, and sometimes the problem is timing.
So while many people focus the sad and "lost years" of non-fame in the USA. I prefer to ponder the joy of his later years.
No matter what your age, when you pour your soul into creating something, be it music, art, a company, or a product, there is always a small part of you that will find satisfaction in the recognition of your work.
I for one, take heart from Rodriguez, that somewhere, sometime, what I do will matter, and I will make a difference. It will come.

 

In 1971 the USA lost out on a great talent, but it’s never too late for an American Dream apparently, and so, at the “south side of 72” in 2014, Rodriguez has finally won.

My first (failed) business.

I remember very clearly the first business I ever started.

It lasted about 6 hours I think, possibly a bit shorter than that.
I couldn't have been more than 9 or 10, definitely younger than 12 because it was in our first house , the one I was born in, until we moved when I was 12 going on 13.
It was a handmade greeting card business.
Now, I'll be the first to admit that I am not particularly arty. I have lots of creative ideas, but not too skilled in the delivery department. But I knew I could make a mean greeting card, plain and simple, Some birthday messages, congratulations,  even plain cards for your own words.
So, I tinkered around the house, appropriating card stock, cutting it down to size, writing with my koki pens ( that's a texter if you're Aussie) . Drawing and even gluing pictures from magazines on the front of the cards. I even had a range of tasteful, executive postcard sized thank you notes planned for a future expansion of the business.
When I was happy that had sufficient stock, I made a sign, and stuck it on the front gate of our property facing the road.
A couple of hours later. My mother came home from work, and my sign was pulled down. The business was over before it even made its first sale, thanks to Government Interference.
I was gutted. What? My mother couldn't see the benefits of me being financially independent ? I mean seriously. Who would want to do chores for pocket money, when I could have my own business ? The earning potential far outstripped my pocket money, which was ( in my mind ) limited by my parents willingness to part with their Rands.
In hindsight, and knowing that I grew up in the middle of the demise of apartheid, my mothers actions make sense. A little girl alone at home for a couple of hours after school, it's not the place you want to be inviting strangers in.
As I have grown in my various jobs and career path, I also see very clearly that I have always had that independent, I'll do it my way attitude. Thankfully it has not been conditioned out of me along the way.
And I have learned over the years to focus on what I am good at, instead of any random idea that might work, if only I was able to deliver the product.
If I had to give my 9 year old self any advice today, I'd tell her to rope in her arty friends to make the cards, buy them wholesale ( at a fair price) and sell them into the wealthier suburbs of Johannesburg for a good markup, get a table at one of the markets.
To any parents reading this blog :  Take heed - when your child starts making up a business, be involved,  and guide them in the market forces that surround your home. And be happy, because a 9 year old entrepreneur is inevitably going to grow up to do great things in their own life, if not the world around them as well.
Most importantly let them fail, if the idea is bad, or they have gaps in their abilities. Failure is a vitally important lesson in the entrepreneurial journey, and the sooner they learn to deal with the disappointment of not having an immediate success, the more resilient and the less entitled they will be as adults.

Starting at level one, for the second time.

My iPad gave up the ghost a couple of weeks back.

Kicked the bucket.
It was an iPad 2. Many years old. It had served me well. And like most of my technology, gadgets, toys and work tools , I had maintained it and looked after it well.
But all things come to an end, and finally last Sunday, I awoke made coffee, and blam, the iPad went dead as I was checking Facebook.
So we trundled off to the Apple Store in Southland, as conveniently enough, the 9.7 inch iPad Pro has just recently been released, and this 'dying of the light' in my iPad had settled the 'should I get a new iPad now or later' debate.

Now - this story is not about the new iPad. It's not even about the relatively seamless experience of setting up the new iPad. No, this post is about the one game that I could not restore from a backup and how that experience is an allegory for shifting perspective when a disaster strikes.

Ever since I got my first iPhone, I have been playing a game called Pocket Frogs. First on the iPhone 4, then transferred over to the aforementioned late, great, iPad 2.
I am absolutely addicted to pocket frogs. But not in the daily, all day long, every chance I get kind of way. I do in fact, lose interest fairly frequently in growing, taming and breeding my frogs. My addiction is more of the 'I'll just keep you around, because I can't bear to lose you' type of way.

this is a pocket-frogs screen - it's bare because I had to start again

Pocket Frogs has survived every single app cull and device cleanup I have forced on myself. Every, Single, One. No matter where I am in the game, or how much my interest has waned at any point in time. I simply cannot delete the game from my device. 

 

Now, Pocket Frogs, is a simple game to play, and yet, at the same time it is quite detailed,  complicated, and multi faceted. Much like life, really.

 

There is only one way to 'level up', and that is by gaining experience points. You can breed frogs, sell frogs, amass money, amass awards, and gain a whole lot of bells and whistles on the side. But you cannot level up without experience points. And there are only 2 ways to get consistent experience points, breed frogs, and tame frogs.
As at the demise of my iPad last week, I was playing at level 16. That's really low considering I've been breeding and selling my little digital amphibians for almost 5 years now. I did have a lot of coin in bank. I had a lot of breeding pens ( called habitats) . I had won a fair few awards and badges.  But because I had focused on the awards and money, I had not tamed any of my frogs beyond the ones I need to breed. And I had missed out on crucial experience points and thus had not leveled up in tandem with my growing frog breeding empire.
I was thus a little stuck, because leveling up opens up new frog species, and I was working on an award which required frog species' from level 17, and 18. And I was about as close to level 17 as I am to being an astro-physicist. Yes, I was that far behind.
And while I was figuring out, how I was going to get lots of experience points really quickly, it dawned on me; that there was no quick way to get experience points. So I had to catch up the old fashioned way. By actually getting the experience points one frog at a time. Much like life, you can fast forward some of the time, and occasionally you can make quick money, but in the areas that count ; like putting in the work to get the experience, there are no shortcuts. And experience always wins.
And then my iPad 2 died.
 
Pocket Frogs has a rather complicated way of restoring game play to a new device, and unlike a lot of other games and apps, they do not have multi device support. And since I was at one point totally paranoid about people knowing what games I was playing ( it's a long story) - I had logged out of and disabled my Game Centre. Which was the only way to 'transfer' game history to a new device. 
By the time I figured out that I had done all the wrong steps on my new and old iPad, it was too late. I had lost my old game, at level 16, entirely. All the money, all the frogs, all the amassed potions and stamps and habitats filled with foliage and happy little breeding frogs.

All gone.

 

Steph looking shocked and distressed with her hadn't up to her faceIt was all of 2 seconds of distress to be honest, because in a flash, I realized what an amazing gift this was really. I had a clean slate. A fresh start, with the knowledge how the game should be played. A chance to do it all over again,with the benefit of my game play experience of the last 5 years.

Yes I had lost all my coins. Yes my awards had become meaningless because they were gone, and yet, here I was, freed from the ownership of those meaningless stars and badges in a silly game about breeding non-existent species of imaginary frogs.
 
I could have spent hours and days trying to restore my game, but to what end? I had played badly, and the things I had accumulated were meaningless within the context of my game experience. I had not done it right, it was a flawed game. So I let it go. 
 
In real life, often, it may feel like you've lost something that you worked for, when in fact, your game-play was flawed by your assumptions, from the start.  Letting it go is the best thing you can do. 
 
It may be as small as changing how your business operates in one small area. It may be as big as changing your whole career. It may be nothing more than a change in your mindset and a resolution to see each new day as a chance to do better, and be the best you possible. You may walk away from your old life and start anew in another country. Whatever it is, take the good with the bad, accept the bad, and then let it go. 
 
And that is what this post is about. The lesson in life of using your disaster to catapult you into bigger and better things the second time round. Use your experiences to do your Do-Over right.
If anyone needs me, I will be breeding and taming level one frogs the right way. (!)

Uber me baby, Uber me

Uber

Nemesis of taxi Drivers everywhere.

The Ultimate Disruptor in transport.

*except for Self driving electric vehicles of course. ;-)

We recently began using Uber in earnest. Mostly for business related trips, up to the airport, the train station or to see a client where I don't have my car for the day. For those times when it's just not useful to drive and park your car at the airport for a gajillion dollars.

I loathe taxi's. Mostly I have had some really sh^&*y experiences, here in Melbourne, in Singapore and in the good old US of A. I cannot say that I remember anything that is pleasant, even in the most uneventful of taxi rides. And it's not the drivers necessarily that are the problem (although I have met some real special ones along the way).

I hate the fact that I have to have local currency on me, just in case the taxi can't process credit cards. Or, as happened to me in Singapore, they didn't take Visa cards, and my Master Card (from South Africa) is a Debit Card, which is blocked for international use anyway ( because the Saffer Government is hell-bent on not joining the global economy, and thinks that my money is their  money... but that's another post)

Oh yes, back to my story about loathing taxi's and my Singapore experience.

In Singapore, the taxi stops, I ask them if they take credit cards, they say yes. I double check, "It's a VISA card ? "

Yes, yes says the driver impatiently. I climb in.

Upon arrival at Fuji Building, and lo and behold, the card won't process. His machine doesn't take VISA cards. And now I am stuck, because well you know, in between the international long-haul flight, landing, showering and coming down to the meeting, I haven't actually had any time to draw actual cash at an actual ATM.

*note to self - make a habit of drawing cash at the airport before exiting*

So, there I was stuck on the side of the road with an irate driver in Singapore, and rapidly approaching the point of being late for my meeting. I was saved, but again, that's a story for another post.

That has never happened to me with Uber. Never. This app payment story is priceless.I don't need cash or special open for banking cards. And the driver knows he's going to get paid, because Uber handles all of that already. No risk to me, and no risk to them.

Also - as a side benefit, I have met the most interesting people using UberX to go to and from my various networking events and meetings.

Here are some highlights ;

- The Civil Engineer  who works flexible hours for his main employer, and drives for Uber for a couple of hours in the evening.
- The Brickie who drives for UberX on rainy days and any other day when inclement weather won't allow him to ply his trade.
- The semi-retired Writer, who also has a room he rents out with AirBnB, and does 2 toastmasters meetings a week to boot. Talk about embracing the digital age!
- The IT Student,  who quite frankly drives better than any taxi driver I have come across and told me all about his plans to uplift his coountry once he goes back and starts his offshore IT development business in Pakistan. Ambitious youth, aah I remember it so fondly !

So I say, Uber me baby, Uber me.

At least until something freaky happens, and then I'm out.

Then I'll be saying : Bring on those self-driving cars.


Word of the Day : Sweat Equity

Ok, so it's 2 words.

But Words of the Day doesn't really sound as formal, educational and proper.

Sweat Equity. 

Anyone in their own business, or in a small business, partnership or otherwise will be totally familair with this concept. It generally refers to the increase in value (or equity) in your business as a direct result of the work you do in  your business.

More recently, it's become associated with employee share schemes. Where employees that contribute greatly to the value of the business become partners and shareholders as a result of their 'sweat equity', often while working for a vastly reduced salary compared to market rates.

Interestingly, there are apparently numerous ways to account for not only the increase in equity of the company , without an actual direct cash injection, but also for the quid-pro-quo associated with an employee (or the owner) doing the work.

But what I find most interesting, is discovering today, that apparently in some jusidictions a company can undertake a sweat equity issue, where the company can issue shares to employees, making them partners in the business, specifically because of their 'sweat equity' and without them having to buy the shares. And that in those jusidictions it's actually called a sweat equity issue on the formal paperwork. Who knew?  Not me.

I have learnt my new thing for today.

So there you have it.

Sweat Equity. My new favourite term.


UML2.2: Microsoft Visio's shortcomings

This is a very short entry as I am in the middle of frantically trying to finish up a first draft version of a functional spec , for various stakeholders to take a first stab at a review .

I thought I would quickly post something regarding the rather fortunate discovery that I made today with regards to a lovely person by the name of Pavel Hruby ---- his website is here.

This bastion of decency and fundamental niceness has put together stencils for what appears to be all versions of Visio, for UML2.2.

Yes that's right - all the RIGHT shapes and icons and stereotypes, in Visio.

I am beside myself with joy, as now I no longer have to sit creating 'pseudo'shapes and objects , events and classes with all the wrong base classes to get the shapes and diagrams the right way round.

The link to the stencils themselves is : http://softwarestencils.com/ and I have saved it into my links on the left.

If I believed in A higher Power ( which I don't) I would say God Bless Pavel Hruby. But I'll settle for making a donation to his cause , and spreading the word through my blog.

For once I get to do a diagram right without struggling my ass off to phenagle the shapes around the correct UML2.2 notation.


Modelling the business problem: Business Context and the argument for free diagrams

Having recently undergone a peer review, just before Christmas - this topic is sitting right at the top of my mind at the moment.

I wrote a business requirements document ( although in this particular company it's called a Customer Requirements Specification - due to the fact that the system teams can service other system teams as well as business areas.) In my opinion , the name of the document is far less important that it's contents, and I see no conceptual conflicts with referring to your client area as 'the business'. In practise , and for all intents and purposes , even if you are not directly interacting with an Operations Business Area , you are servicing your business clients, be they  another system area that requires a service from you , or a business ops area that requires new functionality or a new process.

One of the areas that I was questioned on was my choice of diagrams, and the contents thereof. I must be honest , I had an absolute ball researching the things I wasn't sure of , and making mental notes to update my definitions and internal frame of reference, but the one point I found myself sticking on was that fuzzy grey area around modelling the business context.

I ended up using "use case" notation - and I use quotation marks deliberatley as I am still not too happy with the end result which included about 3 comment boxes detailing the problems.

I found this method on another blog : The BA Times: The Business Context Model; As Good as it Gets.

It's a very useful way to describe the problem to the business , and to the architects, system team members, and while I have no real issues with the method - I am still very cautious about it's usefulness in a document where the business problem is already described in detail both in the introduction and in the tabulated list of stated needs.

In my experience, and strictly talking in terms of the business stakeholders and users that I have dealt with, they are far more comfortable with pictures that are not UML, and short bullet points to describe the needs they have.

To contrast the UML method with the diagrams that I prefer to produce for the business sign off - I have produced two diagrams , using generic terms like : The Business Problem , and Area of Interest.

This is the first one :

And this is how I would model the same problem:

The purists among you will note and probably froth at the mouth that this is not a workflow standard diagram , neither is it proper UML, or BPMN. And yes - you would be wholly correct.

My response is this  - for the purposes of getting your head around what the business problem is , and the points along the way in the high level business process that are hot spots and points of contention, this diagram is far more useful than the first one .

Note - I am not saying that the first diagram is not useful, and I am not saying that mine is better . I am saying that given the environment that I have my experience in , and the users that I have dealt with thus far , the second diagram lends itself more to being presented to the type of business users that are not interested in learning what all the funny pictures mean in BPMN, or UML. You really do need to explain less about the second diagram, and it will prompt more questions than the first.

And questions are good. If they are asking questions , it means they are thinking about how you have described their problem , and deciding if you really understand it. A 45 minute meeting going over and over how you have described their issues is infinitely better that walking into a room , having the users take one look at your use case , tell you it's fine and walk out.

There are people ( and the author of the blog I have referenced appears to be one of them ) who will claim that Use Cases are simple and easy for users understand. And they are mostly right on that point. Use Case Diagrams are a very succinct way of placing a process , or set of "uses" from the business in context.

They also however - miss out critical details about what's wrong with the current process , and what the business's stated needs and problems are. Which is why I do not like them for anything except the finest grained of system and business process definitions in a functional requirements document.

I am a stickler for doing things the right way - but I am even more of a stickler for being efficient and getting people to understand. Understanding , agreement , consensus , and coming to the same mental picture of that damn swing that we all know so well are far far more important than producing pretty little standards-compliant diagrams that no-one but you and your fellow BA council members can understand.


IT BA and BA : what's the difference ?

OK Cherubs , here's a thought. Debate rages all around about BA's and what is a BA exactly . While we have been blessed with the thorough and extensive work in the Business Analysis Body of Knowledge® (BABOK ®), and the rising star of the International Institute of Business Analysis IIBA®and its various local chapters, there is still a lot of debate around whether a  BA focussed on Business processes only – also sometimes called a Business BA ( don't you love the redundancy in that term ? A Business Business Analystwhat a mouthful!), and an IT BA need the same skills necessarily, and what those skills should be.

Chief among the sticking points is calling an IT BA by another name, such as a Systems Analyst. The BABOK®  is clear in its definitions , anyone who does anything that is remotely considered under the auspices of the work of a BA , is considered to be working in the realm of BA'dom. This includes (but is not limited to ) System Analysts and Process Analysts, as well as Project Managers.
This article however will focus on something that I find to be a very contentious issue, hotly debated amongst my previous and current colleagues. If we are going to make a distinction between a BA , and an IT BA, then which do we need on a technology project , and why should the IT BA do the business requirements at all?
I’ll start by listing what I see as the main differences between a BA and an IT BA.
In general all BA’s should be able to:
·        Analyse and document business processes.
·        Conduct Stakeholder analysis
·        Elicit, identify, analyse and decompose business problems.
·        Produce from this analysis a Business Case.
·        Refine the business problems into a set of Business Requirements
·        Propose and document a solution for the business problems which can consist of any one,  or a combination of the following within the business requirements document / specification:
o   TO-BE Business Process
o   Business context diagrams
o   Business conceptual Domain Models
·        Elicit , identify , analyse and decompose Solution Requirements.

see also Requirements Analysis  for some background and a more information

All of the above does not require the Solution to include any technological aspects.

It is when a technology solution is required that we see the rise of what is more commonly being referred to as the IT BA .
An IT BA should further be able to ( in my opinion):

o   Elicit, identify, analyse and decompose Solution Requirements that consist of

  1.      Functional Requirements
  2.      Non-Functional Requirements

The IT BA therefore, it is presumed and assumed should have some background in technologyMany graduates with IT focussed degrees , become junior developers , moving through the systems analyst role, and eventually taking on the role of IT BA. This is not always the case however, IT BA's, and BA's come from many different backgrounds.

Further to that - in my opinion, the IT BA  should also be able to hold their ground , and have substantial input into the architecture of any solutions. As the person who understands ( hopefully!) the business problems and needs more so than any other project member, they must be able to discuss and debate the merits of various approaches with the project Architect, and Developers. It does not matter how fabulous they are at documenting anything, because people are uniquely shaded by their own perspectives. An Architect will have a leaning towards their own personal preferences in technology and platforms, developers will present solutions that fit within their preferred languages, and it takes a strong person to ask the questions regarding the 'fit' of the technology design onto the solution requirements and back to business requirements. Which is in itself a constant process of re-evaluation throughout the project. Don't hesitate to ask those questions of yourself and others , even when you think you have everything nailed down.
 
There is in my view a  distinct separation of a BA role and an IT BA role , and the outputs they should produce in a project cycle. In an organisation where the roles are distinct and occupied by different people , the BA will do the analysis of the project up to the point where the business requirements are documented and signed off, and will hand over  at that point to the IT BA.
This is where, things start to go pear-shaped. And where many good people lose the plot, so to speak.
In theory - at each stage of a development cycle, the previous role player hands over perfectly executed , exquisitely documented  outputs. There is,  in an ideal world, no shades of grey, when the BA hands over the business case or business requirements to the IT BA, they are getting the best possible representation of the business needs , without exception.
The reality is however that projects start late, they are delayed and impacted  by people who are sick, people have sick children/dogs/parents/spouses. They have car accidents and flat tyres. Key stakeholders miss meetings , or are not identified. Strong willed business stakeholders hijack meetings to push their own agenda's.  Any number of things can go wrong , or be missed in the first stage of requirements elicitation. And when the project is high profile, and impacts the business deeply and badly , there is constant pressure to deliver things quickly rather than properly.
Yes - the IT BA will be given the best possible document that the BA can produce, but it will be subject to any number of negative factors. The IT BA must therefore operate under the assumption that the requirements need to be managed , and QA'd. Even updated , added to , or in some cases scrapped entirely and replaced.
This begs the question - why even bother with the split approach anyway? Surely it would be better to just have the IT BA do everything ? That way , they would be able to make sure they do the best they can do , and at the very least , even if they do a bad job documenting the business needs , they'll understand them , and be able to make a brilliant solution anyway?
I think not. I think that both the BA role and the IT BA  role should be involved in all parts of the project from the start to the end. Buddy Buddy works. And it works well when the BA's on the project collaborate effort skills and knowledge.

The roles and responsibilities stay the same , but the collaboration of the two uniquely positioned viewpoints means that the processes , the analysis , the outputs and the resulting requirements definitions are, within the constraints of the project , the best they can be.

This does not mean necessarily that there will be two people working on the project. In organisations with resource constraints, or where there is no distinction between BA's and IT BA's , there will often be only one BA assigned to a project.

It is these projects where the BA's ability to don different hats becomes critical. If this is you , you must be able to do the BA work as a BA, focus on the Business definitions , concepts , problems and terms. Talk about the solution in terms of what the business will want to achieve.  You should then effortlessly be able to step out of that role , and converse technically with the relevant development team as an IT BA regarding the mapping of those business requirements into functional requirements and solution architecture, while maintaining in the back of your mind anything that might impinge on the business needs.

Globally the role of the BA is becoming more recognised as a profession in it's own merit , and as this thinking gains ground, it becomes ever more critical that BA's step up to the challenge of delivering on that expectation. This means we all need to be able to play different roles, BA, IT BA, technical advisor, systems process analyst, process designer. User Champion.

Yes - User Champion. If that role has not been represented correctly on your project ( a senior VP Exec is NOT a user champion. ) then you need to take on that responsibility , at least to the extent of owning the Functional Requirements and relating them back to an actual business need.

Don't know what a User Champion is  ? Check out below for some interesting reading :

http://www.frontend.com/design/the-user-champion.html
http://tc.eserver.org/19312.html

A BA is not someone who takes notes and writes down what the users want. A BA questions , probes , elicits information , and gathers details. All of this for the purpose of creating a unified view of the problem , it's solution and the road map to get there. In order to accomplish this they will need to play various roles, produce several artefact's and acquire and hone many skills, all of which combine to produce a uniquely skilled individual. An individual who is capable of filling those messy inconvenient gaping holes between Project Managers , Users , Architects, Developers , Business Management, Development managers and  Executive Stakeholders.

If you're up to the challenge , it can be one of the most stimulating environments to work in. Nothing can ever be the same , and therefore everything changes , all the time.

A last word of advice : If you don't like your cheese moved, don't become a BA.

IIBA®, the IIBA® logo, BABOK®  and Business Analysis Body of Knowledge® are registered trademarks owned by International Institute of Business Analysis.