10 ways to fail as a Business Analyst - Lubaina Rangwala
•Download as PPTX, PDF•
1 like•345 views
This talk is about the common pitfalls of being an Analyst. From start-ups to well established organisations, this talk highlights some of the most common failures made by a Business Analyst.
Recommended
Recommended
More Related Content
Viewers also liked
Similar to 10 ways to fail as a Business Analyst - Lubaina Rangwala
Similar to 10 ways to fail as a Business Analyst - Lubaina Rangwala (20)
Recently uploaded
Recently uploaded (20)
10 ways to fail as a Business Analyst - Lubaina Rangwala
- 1. Trendz 2015 #converge #pune #thoughtworks
- 3. ABOUT ME • Worked in different kinds of places – Startup with 10 people; hopes of being acquired – Startup with 60 people; got acquired – Freelance Consultant – 1 person; gave up – ThoughtWorks! – Startup with 2000 people? • On different types of projects – The “next flash-based gamified Facebook” – A website for a company manufacturing robotic vacuum cleaners – An enterprise level software, pitched as an IoT poster- child for an Networking technology Giant
- 14. Quick Summary Fail #01 - Being a BA is all about writing stories Fail #02 - Forcing a process to work for you Fail #03 - Stories are elaborate works of art Fail #04 - Failure to see opportunities in domain trends Fail #05 - Elastic Time Fail #06 - Loyalty vs Trust Fail #07 - Sticking to Fixed releases Fail #08 - Not asking how the project will make its money Fail #09 - Lack of a Baseline scope Fail #10 - Misinterpreting Analytics
- 15. Q and A
Editor's Notes
- How I failed? By thinking that the core function of a Business Analyst is to write stories. The result - Created myopic stories that lack technical overview, and sometimes had to play new stories to add to the functionality of the earlier one. What I learnt: The goal of a BA isn’t to write a story. A story is the “output” of what a BA actually does which is (but not limited to) Stakeholder Management Requirement Gathering Facilitating Inceptions Project Architecture Non-Functional Requirements Technical Debts/ Technical Stories Quality Analysis Marketing Goals Deployment & Future Roadmap
- How I failed? The idea of a daily standup sounds appealing. It is recommended and advocated as an Agile practice. I saw it work effectively in a tightly-knit team with a single focus (with about 6-10 developers). My team had 25 devs. The result: The standup went on for 45 mins in a large team! Everyday. Standing up for 45 minutes! We started noticing symptoms when people (including me) skipped this. What I learnt: No two projects are the same. Adapt processes or practices to the project and not the other way around. Whether it is Agile or Waterfall, daily standups, Scrum meetings, Iteration duration, etc. pick something that works for your team. Feel free to tweak it. So we tweaked it – can we make it shorter? More useful? We tried splitting the team into smaller ones and have a longer standup once a week. Is it perfect? Possibly not. But it works.
- How I failed: As a Business Analyst, I am very attached to my stories One of the biggest mistakes I make is writing stories in such a way that another fellow BA would appreciate. I include ample detail, RAID analysis etc. I create my feature wall in Mingle, Rally and organise it really well. But the failure here is – I’ve never checked to see what my SME/ PO thought of the story. Did they read it? Result: They found it too complicated, too many details and a lot of jargon that didn’t help them understand. What I learnt is to keep stories simple, short and concise. A Product Owner as well as a dev should be able to read, understand and sign off on the story.
- How I failed? Imagine this. The year is 2010. An organisation, pioneering in Robotics had built a robotic vacuum cleaner. It is not the only one in the market sure, but it is one of the best. They approach you and say, we are launching in Europe and North America. We want to build a website. What is your proposal? So you give a proposal for a multi-lingual website. And win the proposal. The next proposal we give is for … wait for it… maintainance! Result: Had a huge opportunity to work on a project that was at the cusp of IoT. And all they got was a website! What I learnt? Prepare yourself to work with someone for 10 years. And then talk to them. Do your due-diligence on the customer’s domain, look at emerging trends in his business. – As a BA do research. The present opportunity is lucrative and exciting but think about the long haul. Most importantly, if the client isn’t thinking about it, he will start thinking about it.
- How I failed? As a freelance consultant, I was eager to meet clients and make money. So, at first, I didn’t charge for meetings. By not charging for my time, I gave the impression that my time (and theirs) was not valuable. The result: Long meetings that over-run their deadlines My lesson was understanding that my time means money, and also As employees we forget (because we get a salary) that we are chargeable to the client by the hour. Our time costs them money. Being on time for meetings, on time with deadlines or honoring timelines is a good practice. This way, the time spent together is productive and the customer starts to value your time as well. This also builds trust – because by not wasting time, you are looking at their best interests – i.e saving money
- How I failed? I had a dream client. He was technically savvy, knew what he wanted in life and completely respected my opinion. He came in with a brief. We felt it was a little ridiculous but kept our opinions to ourselves. Afterall, he was paying! Without challenging, questioning or understanding we went ahead with the implementation – sometimes it was easier to do then spend time fighting. Also as a start-up, money is pretty darn important. Result: As a startup, we became the vendor to supply developers when needed and didn’t get an opportunity to impact the product in any way. Because we didn’t question. What I learnt: A client-consultant relationship is more like a healthy marriage. Rather than a boss-employee or superior-inferior one. A mix of constant communication (both transactional and non) and fights. But the underlying commitment is visible to both. And building trust rather than blind loyalty.
- How I failed? At the beginning the project was under planning phase. We had ample time to set the foundation. We starting using a nominal release planning method which allowed us to have a release of 5 sprints or 10 weeks. Since this worked, we stuck to this model even after the general availability of the product. So the cycle we followed was Planning -> Development -> Deployment -> Feedback Result – A customer had to wait 10 weeks, whether they wanted a label change or whether they wanted a feature. What I learnt: - Adapt release planning based on the project lifecycle. As a BA, this is conversation that you can initiate and be part of. Have a groomed backlog. This will help in the planning overhead and rather than being a phase, it is a constant practice. The move to continuous deployment is not just an engineering decision but a business decision.
- How I failed: - We were working on a well-funded project. A large enterprise is bank-rolling an application that they intend to sell to larger organizations. They are willing to pay a lot of money to give the customers the features that they want. They have a team that is going out to sell the product. As a BA, I failed to understand how the product is being sold. Result: So how this impacted the project was that – after the first release, the client talked about introducing a feature – Licensing! This is a basic feature that most products base their architecture on! Also – the marketing team hadn’t thought about this so this would’ve been a good way to get directly involved with the customer facing team. What I learnt: By asking the question about sales, you show you care about the wellness of the customers business Its better to ask these questions in the beginning and be wrong about it, than not talk about this.
- How I failed? On a large project, there was a large program of work. During the initial discussions, we created a master story list. We didn’t put any estimations against them – they were too large and too vague. We broke them down into features and stories. We didn’t provide an estimation and a baseline scope for the stories at that point. Result: When the project was in the implementation phase, we were able to see the requirements on the features expanding. Because we hadnt stopped to define scope then or use estimations, it was difficult to manage customer expectations. We had to bear a loss and accommodate the new scope to not lose out on the whole project. What I learnt? Create and track your baseline scope. Estimate the story to give the customer an idea of what to expect – use relative sizing to help in explaining how stories have grown in size.
- How I failed? There are several tools for measuring feedback. We used Google Analytics on the website that hosted flash games and was aimed at social gaming. Based on the analytics, we saw a high bounce rate. WE concluded that we were not able to create “stickiness” and get users to return to the application. Result: Marketing spend increased and Development spend as well on focussing on elements like user profile, messages etc. to try and get a user to stay. What we missed in the analytics is that the games themselves were becoming extremely popular and people were book-marking them and landing on them directly. What I learnt - Analytics can be skewed. Spend some time or talk to an expert on interpreting analytics a more holistic way.