Agile Development, Behavior Modeling & Design, Business Analysis, Information Technology, Innovation, Product Development, Requirements Development, User Analysis, User Experience, User-centered Design

It is beyond doubt that the current times of digital, mobile and social age demand professionals who are versatile, agile, sociable and dynamic. Business Analysts and product specialists are no exception to this. Whether its due to the industry demands, peer pressure, market needs or pure evolutionary tactics, BAs today are far more leading-edge, competitive, assertive and visionary contributors to the products, processes and businesses, at large. From an also-ran team player role, new-age analysts have come a long way as the multi-disciplinary, multi-skilled and multi-dimensional professionals. In this post, I will touch upon the many facets of the new-age Business Analyst and how they are adapting to the continual changes happening in the spheres of business, technology, professional and personal lives.

Emergence of the new-age BA/PO

As we discussed in the previous posts, there have been several factors that led to the emergence and evolution of the Business Analyst. The BA today moved on from just a requirements owner and a document expert and is now addressing several facets around products, processes, business and technology. Their focus still remains pretty much around the problem space, compared to the facilitation role in the solution space. The analysts identify problems, dependencies, needs and opportunities. However,  products, processes and business domains. The BAs today have been involved in scoping, release management, continuous engagement with customers and users, strategising, laying out roadmap, and working with multiple teams.  In a nutshell, the Business Analyst of the modern age is much like a leader, architect, soldier, team player…all rolled into one.

NBA_Leader.Architect.Soldier.Team Player_Texavi

Leader, architect, soldier, team player & more – the new-age BA

From being an analyst, the BA needs to transform into a leader, architect, soldier, team player and perhaps many more such roles, all rolled into one. Of course, they need not be all of these roles at the same time. The analyst today has to don one, few or all of these various roles based on the context, time, stage of implementation as befits the occasion. During the initial stages, the emphasis could be on being an architect, while during the scoping it could be that of a soldier. However, throughout the project, or initiative analysts have to keep their hat of leader and team player, no matter what stage the work is in. I touch upon the four primary facets of the new-age Business Analyst in the following paragraphs.

1. Sensible leader, not just an also-ran

You can’t talk enough about the all-imperative skill and art of analysts to work with people. They must have their hands firmly on the pulse of the different categories of people. These include the various stakeholders – direct and indirectly responsible for the product and process, from senior management all the way through to people working on the factory floor. As an able leader, the analysts must not only lead the way, but also set an example by following and working along with the team members. They should  listen actively, take steps pro-actively and be able to put in their efforts with sustainable passion, drive and commitment to achieve this shared vision and common goals.

2. Architect and a builder, not just another player

New-age business analysts must be able to look beyond the near term goals and benefits. They must have a really good and long term vision to not only lead themselves but also the team members and the organisation, at large. They must think far and beyond, using their rich experience, in-depth and specialised domain expertise. The added advantage is that these help the analysts with a “peripheral vision” around the markets, business domains, products, processes and technologies.  Besides, the new-age analyst adds great value by laying a robust roadmap that is flexible, scalable, high-performing.

3. A soldier, well-equipped and prepared

Like a soldier, who is well-equipped and well-prepared to face any kind of challenges, the new-age analyst must be prepared with all the right tools, methods and a positive attitude. The very nature and aptitude of business analysts help them to stay on the top of their game, be it at home or outside their turf. Their ability to adapt easily and quickly depending on the situation helps build on to the agility of the new-age analysts.  Analysts’ skills of being sensitive, scrupulous and open-minded, help them usable insights from ideas and actionable intelligence from information. In addition to these, the BAs try to keep ahead by addressing all possible scenarios, potential challenges and constraints, internal and external dependencies and assumptions – stated and implicit.

4. Team player, not just a one-person show

Business analysts over the ages had been looked at more as specialised consultants who come in, do their work and get out. The contribution of analysts is considered from the prism of a “support” role who comes in early in the project, find problems, specify scope and requirements and exits the scenario. However, with the advent of agile practices such as Scrum, user stories, XP, BDD and TDD being put in place, organisations are increasingly looking for analysts to be well-integrated into the development teams. The analysts today are very much an integral part of the teams and by being  participative, they contribute to the collective value delivered by the team. So, new-age analysts are equally adept at being followers and team members themselves as much as they excel at leading the teams.

I hope this post helped you understand the many dimensions, skills and demands of the new-age business analyst. We will cover more specific details on the tools, and methods for the business analyst/product owner in the upcoming posts, until then, ciao!

Agile Development, Behavior Modeling & Design, Business Analysis, Information Technology, Product Development, Requirements Development, User Experience

Ever since the role of Business Analyst came into being, they have been associated with one specific area more than anything else. That is requirements and over the last four decades or so, the words analysts and analysis  have become synonymous with requirements.  In a traditional project or product development context,one of the frequently asked questions for a Business Analyst undoubtedly  is “Where are the requirements?”. However, in the recent times of agile methodologies and lean processes, like all other roles in technology and business, BAs too have had a significant makeover. In this post, I will touch upon this transition and look at the all powerful tool kit of the new age business analysts.

Texavi_NBA_Transformation

Business Analyst as the owner of requirements 

BAs traditionally had been responsible primarily for requirements in a product development or project execution scenario. Even though the role of business analyst involves right from the pre-sales stage all the way through to the project delivery, their focus area had always been scoping and requirements areas. BAs traditionally had their mainstay contribution to the product/project starting with requirements gathering, and then specifying and documenting requirements and communicating them to the stakeholders ranging from the management to the team members and from customers to the end-users.

Not just requirements in terms of the functionality, the influence and focus areas of the analyst could well be extended to some of the adjacent areas. Besides requirements, the reach of the BA would still be restricted to the peripheral aspects such as vision, scope and roadmap for the product, system, process or business in question. BAs have been made the masters and owners of requirements. This has been the case with the various roles, forms and names of the business analyst – be it a business consultant, product specialist, functional consultant or a domain expert.

Traditional meaning and scope of requirements

 So, what exactly do I mean by requirements in the traditional sense of the business analyst’s focus? Let me clarify this very important point with some examples. Requirements traditionally meant the long list of documents that ran into hundreds and thousands of pages. Some were called as Business Requirements Documents (BRD) while some others were referred to in the eighties and nineties as System Requirements Specifications (SRS) during the time of SSAD (Structured Systems Analysis and Design) times. As we moved slowly into the software analysis and development, the focus of the BAs slowly shifted into writing Functional Requirements Specification (FRS) and Software Requirements Specification (SRS) documents. You can notice that its just a change of the name, however the perspective, work and the output of the analysts still remained the same.

NBA_Texavi_Blog_31Jan2014

New age BA goes beyond documentation

In the age and times that we now live in, virtually everyone and everything  is going digital, mobile, agile and social. Like all other professions and roles which have undergone a huge shift, BAs too have had a significant change, after a really long time. The actual transformation in the role, responsibilities and contribution of the analysts came with the introduction of agile development methodologies like SCRUM, BDD (Behaviour Driven Development) and User Stories.  As we started implementing more and more agile and lean methodologies in the businesses, products and projects, the role of the business analysts has a far reaching impact on how the end products or processes shape up.

Texavi on the NBA requirements and communication

Today’s analysts need to move beyond the realms of requirements area and become more versatile and tech-savvy. All the way from interactions with key stakeholders through to the time the product or process has been delivered, the new age BA has to actually work with the team members. Analysts have to actively engage with various people involved in the project, product, process or business context and work alongside them analyse, design, develop, deliver and continually enhance the solution. This means that the analysts have to now create various artefacts such as the product backlog, user stories, wireframes, domain models, solutions models, prototypes and test cases, to name a few. I will discuss the details  of how the new age business analyst creates and works with these more effectively, in a separate post.

Hope you found the post useful – like always, please feel free to drop in with your valuable feedback. Until next post, ciao!

 

 

Agile Development, Business Analysis, Information Technology, Product Development, Social business, User Experience

In an age of rapid changes in the business, technology and lifestyles, organisations and individuals alike have to be adaptive. Business Analysts are not an exception to this much alike the other professionals. What does it take to be a modern day business analyst. Is it just the logical thinking, sound communication skills, good domain knowledge? Yes, these are all necessary but not sufficient. The modern day business analysts have to be agile, suave and tech savvy. They need to be adaptive and quick to embrace change, not just to survive but to succeed. In this post, we will look at what it takes to be a successful business analyst in this new-age of digital, mobile, agile and social times.

Transformation of business analysis in the new-age

Business analysis today is less of writing requirements in long documents and more of working with the design and development team. Its about owning the product roadmap, business strategy and/or the organisational processes. Gone are the days of writing up functional specifications documents running into hundreds and thousands of pages, spending months and years. Its the time for them to be agile and lean, and move on from being traditional verbose document writers. So business analysts today have to write user stories, create wireframes and mockups, model problems and solutions, validate and test the functionality.  They must be open to change and pro-actively understand the impact of changes on business, technology, products and people.

NBA_platform_Definition_Framework

Business analysis is changing and how

From a traditional perspective,  BAs needed to be good with communication skills. They were positioned as domain experts and to some extent looked up as product specialists. Some analysts have been positioned as specialists in business process management. However, in the last few years, business analysts have moved on from mere requirements owners to product/process owners. With the extensive use of agile practices, business analysts too emerged as the change management experts. In this digital, mobile, agile and social age, the focus of business analyst has shifted to user stories, customers and users engagement, stakeholder management, modeling domain, problems and solutions. In short, the modern day business analyst is versatile, cross-disciplined, tech-savvy, agile  and a team-working professional.

NBA_platform_BusinessAnalysis_New_Age

The new-age Business Analyst’s toolset

I give below a diagrammatic representation of the toolset for the modern day business analysts. This provides a snapshot of the fundamental set of skills and knowledge that power the BAs today.

NBA_BA_Skills-and-knowledge_Toolset

Alongside the mainstream skills, the business analyst needs to be a master of communication and leadership skills. From interacting with the key stakeholders, engaging with customers and users, and working alongside the team members, business analysts must have excellent “people skills”.  Also, technology has been playing a key role in the design, development and delivery of products and services today. So, needless to say that the business analysts today have to be aware of the technologies, platforms and the application of these technologies to business context. I don’t however see that the business analysts have to be experts in technology but then they must be able to use technical applications, tools and methods to understand problems and help create solutions. Also, the new-age BAs have to be creative and be equally good with the right brain as much as they are comfortable with the data and analytics.

Hope you find this post useful – as always, please feel free to get back with your review comments and helpful feedback. On behalf of Team Texavi, I wish you and your loved ones a very Happy New Year, 2014! May your personal and professional lives be filled with joy, prosperity and success! Until next post, ciao!

         

 

 

Agile Development, Business Analysis, Information Technology, Innovation, Product Development, Requirements Development, User Experience, User Stories

Often times this thought come across to me as to what makes people choose their professions. Is it their interest, aptitude, passion or simply demand in the market? I think its not just one of these but a combination of all of these that make up the professionals that we are all today. From a doctor to an engineer, from an entrepreneur to a scientist, everyone has a choice to make and that pretty much defines how they get set into what they do as their career. Looking closely at an analyst or rather more appropriately a Business Analyst, its amply clear that the role does have specific requirements, demands and expectations. Not everyone would like to be a Business Analyst and not everyone would be a good Business Analyst. So, what is it that makes one a suitable New-Age Business Analyst? In this post, let us look at some of the key factors, skills and attitudes that are the qualities of the New-Age Business Analyst.

Business Analysis is an art and a science

Yes, its indeed the most under-stated fact that business analysis is both an art as well as science. One needs to have the flair for analysis, reasoning, communication, identifying problems and facilitating in creation of solutions. A good business analyst is passionate, enthusiastic and a continuous learner. On the other hand, there is also no denying the fact that to be a a better business analyst, you need to learn the right tools and techniques to hone your analysis skills. From the SWOT technique to various notations such as BPMN ( Business Process Modeling Notation) and UML ( Unified Modeling Language) almost everything can be learnt and mastered as a discipline on a scientific basis. I will touch upon the nuances of these tools, techniques and methods in the future posts.

The various avatars of a Business Analyst

First off, let us understand and define the various names, forms of a business analyst. From a business consultant to a product specialist and various other roles, business analysts have been known by different names. I have come across some roles such as Domain Expert and Functional Consultant too. You might notice that the Business Analyst as we know cut across different industries and verticals. This ranges from Banking, Manufacturing, Information Technology, to name a few. I give below a diagram which shows the numerous avatars of the Business Analyst. Though this is not comprehensive, it pretty well presents a picture to drive home the point that the Business Analyst comes in various packages – shapes, sizes, colours, names and forms. However, you will notice that the core work remains the same, which is what we will refer in the later sections of this post.

Identity of a BA

 

Focus Areas of a New-Age Business Analyst

The main areas that a new-age business analyst focuses on are Business, Product, People and Communication. Unlike the popular perception, it is not technology, nor projects that would interest a business analyst. As the name suggests Business is the paramount factor for a BA and up next is the product focus and product thinking. No business analysis is complete if it does not touch upon the people aspect. From customers, users and team members to stakeholders and management, business analyst has to cater to the various ‘people’ involved. And if you ask me to name that one thing that separates the New-Age Business Analysts from all other analysts, it is communication. I created the image below to represent the focus areas and priorities of the new-age business analyst.

Focus areas

You can notice that the following are the priorities for the new-age BA:

  • What and Why, over How
  • Problems over Solutions
  • Product over Project
  • Facilitation over Implementation

Hope this post helped you in understanding the basic skillsets of the new-age BA. We will discuss more on this in the upcoming posts on New-Age Business Analyst. Until next time, Ciao!

Agile Development, Business Analysis, Information Technology, Requirements Development, User Analysis, User Experience

People all over the world celebrated the onset of new year 2011 with fun, aspirations and resolutions. This cheer and  high-spirited enthusiasm continued well into the first week of the new year.  However for some people, the early days of the new year proved not all that fun. They got up later than usual, reported late, missed their appointments and meetings. You might want to blame all this mayhem caused due to the hangover and the high-spirited celebrations :). Well, that was not the true reason. The real culprit was the mobile phone they were using. Yes, it was Apple iPhone4 that these people have been using that created the problem.  The Alarm app of the iPhone4 failed and did not set off (or is it ‘set on’ ? ) the alarm.

Small problem, big pain

You might say that this is just one small problem for a few users which happened, one day. After all alarm is just one small app in iPhone and it did not work on one day and so, its really not a big deal. I agree, but then think about the consequences of this small bug and the inconvenience it caused to the users. Even a small defect in the product could become pricking one to users. I remember my good-old Hero Honda CBZ,  first version which I bought in 2001. It was a brilliant motor bike with a fantastic performance and great looks. I was really happy with it except one small itchy glitch. Look at the images below and you can guess what the problem with this motor bike could be.

Its not all about look and feel

Yes, you got it right. The problem was with the placement of  kick-rod and footrest in this model of CBZ. Footrest was placed right below and would stop the kick rod from going down. Since there was no electronic auto-ignition, starting the motor cycle requires three steps…

  1. Take the footrest up, so that it doesn’t come in the way of kick-rod
  2. Kick the rod down so that mo-bike gets started
  3. Immediately get the footrest down, for applying breaks

Phew…so much pain just to start a mo-bike. Just imagine your plight when in the midst of heavy traffic on a busy road, the CBZ stops and you need to start it in a split-second, else you might incur the wrath of a 100 horns blazing all at once. The curses and prayers of many a user like me, would have reached the people who matter at the motor cycle company. In the newer version of the CBZ, Hero Honda introduced is an electronic-ignition. So, the moral of the story is ‘all looks and no work makes your product a flop and users irate’.

Go beyond the briefing, but first get the basics right

The above problems have nothing to do with lack of user experience, or delight factors. They refer to the breakdown of a simple and basic functionality of the product. Nowadays in a bid to get quicker and closer to customers, product companies have been getting on to the bandwagon of offering delight to their users. They have been treading past the drawn lines, going beyond the briefing. I fully support their intent and actions and also believe in the end results of their efforts, which is better products and happy users. However, this is not completely hunky dory and in a few cases, companies do not realize that they are committing some basic errors. To attract their users, the product companies are forgetting that their products must first work well and satisfy the immediate needs of their users.  There is an imminent need to realize that ignoring this might lead to frustrated users who will shun using their products and services.

It does not really matter if your product offers great bells andwhistles, while at the same time it cannot provide the core  functions. Often, in the name of user experience, product owners do tend to overly focus on the presentation losing sight of the other important factors such as functionality, navigation and interaction. As Steve Jobs rightly puts it, “Design is not what it looks like and feels like, Design is how it works”. A case in point is the call dropping functionality of iPhone4. Not too long back, you might recollect the problems reported with the dropping of calls in iPhone4. This issue was more noticed when users holding their iPhone in left hand at a particular angle.  Apple accepted the that there was indeed a defect with the phone’s antenna placement and offered a bumper cover free to the users.


In case you are wondering why I am riling Apple only all along, well it is not alone in getting the bad campaign.  Hotmail recently joined the shame game when most of its users, one fine morning, found their mail boxes empty, all of a sudden. Some other users found a few mails missing. A few others were annoyed to note that some emails were lost. I guess you would agree that the basic purpose of an email product is to receive and send mails. If this very primary functionality is not in place, don’t you think it raises alarm with the users? Of course, not only do they stop using the  product, but they spread the bad word pretty quick. So, address the  important things first in your products, services or processes…functionality, those that matter the most to your users and you too.

Form follows Function

There has  been an eternal debate in the design circles about the seemingly conflicting approaches of ‘Function follows form‘ and ‘form follows function‘.  My ‘Business Systems Analyst’ background gets the better of me and I support the latter option, i.e., ‘Form follows function’ theory. Of course, I don’t apply this to all and sundry. Leave alone some specific products like art works, paintings, craft and decorative items etc.,  which definitely have a dire need to look prettier first, as that is their core objective. However, for the rest of the other products which we use in our everyday life and work, functionality should be the first goal followed by the looks. Often times, the way a product has been designed, especially the aesthetic appeal  accentuate the function and make it better.

FURPS and You

Functionality scores over pure-play user interface and mere looks. So much so that the good old model, FURPS which classifies the software quality attributes, function places Functionality on the top much before other factors. For starters, FURPS refers to Functionality, Usability, Reliability, Performance and Supportability. There had been additions to this list, what is being referred to as FURPS+.  The + or extra attributes are interface, implementation, operations, packaging, legal etc. Irrespective of whatever gets added to this list, one thing is pretty clear… that functionality always precedes everything else. So, in case you ever doubted what the Business/Systems Analyst in your team does, you have an answer now.

Focus on the WHAT

I doubt how many times you would have lifted the bonnet of your car to see what’s inside. Compare this with driving your car using the steering wheel, gears, clutch and other parts in the car nearby to  the Driver’s seat.  Not many users (barring a few, such as technicians and mechanics ) would wonder how your product is working. What matters to most of them (the normal users, barring advanced and expert users) is that the product should work and do the things it is supposed to do, in the first place. From a Software Development Life cycle (SDLC) perspective, Requirements always come first before Design and Development. Even in this age of Agile development with SCRUM, Extreme Programming and User Stories, you still need to understand the ‘WHAT is to be done’ before you proceed with ‘HOW it is to be implemented’ . First, focus in understanding WHAT is required of the stakeholders, and users from the product or application that you are developing.

Make the functionality clear

Its not only important that you focus on getting the functionality right, but more importantly you need to make it clear to the user what are the things they can do with your product.

Design and develop your products and services in a way that users should understand what they can do with the products or services.  If it is not clear to your users as to what your product offers to them they will eventually dump it. For instance, Google Wave failed big time because it was not clear to the users what they could do with it and how it would help them  any better than the existing lot of the social networking and collaborative platforms. Also, iPad had a few takers initially in the first few days, as some people had questions about what exactly it offers. They could not see the real difference between iPhone and iPad, sans the ability to call. Some even called the iPad a glorified and bigger format of iPhone.


To conclude this post, all I have to say is that, as developer of products or services,  you need to set your eyes and mind first on the functionality. If it does not work, they will not use it!

Agile Development, Business Analysis, Business Case, Information Technology, Usability Testing, User Analysis, User Experience, User Stories, User Studies, User-centered Design

Hurrah! It’s a joyous and proud occasion for all of us at the RSC and Rave. If you wonder why, well, RSC Publishing’s new content delivery platform, ‘RSC Publishing beta’ was launched today. Released as beta, which is bound to have further improvements, even as it stands today, this product is undoubtedly one of the finest platforms in the ‘STM publishing’ area. It is the culmination of various factors that resulted in the successful planning, execution, delivery of this platform. This is the combined victory for users, technology, agile methodology, collaborative team work and of course, sustained commitment and support from the RSC.

Refer http://www.rsc.org/AboutUs/News/PressReleases/2010/betaplatform.asp for more details on this.

When Taj Mahal was completed after almost a decade since the work was started, everybody who was involved in making it was excited and overjoyed to see it complete. This list included the persons who just carried bricks to the site. So also with the newly launched platform, everybody who has been part of the development project has a reason to smile today. With the beta launch, which can be equated to completing one pillar of the Taj Mahal, I think it is time for us to pause and reckon the project’s history. Being involved with the development of this platform from the beginning, I will try and give you a peep into how it all happened.

First, there was the Vision

The stakeholders at the ‘RSC Publishing’ had a dream, a shared vision of building a content platform that powers the Chemistry community with quick and easy access to the Chemistry content. Not just that, they envisaged that the platform delivers their content using superior technologies with the right user-experience. It all started with understanding their visions and expectations of the product and then we arrived at the unified product vision and roadmap.

Well begun is half done

As we discussed in the last few posts, in the software product development, if we align our processes to the users’ needs and their tasks, that product will be successful. The same happened with the RSC Publishing platform too. Right from the word go, they realised that ‘User’ is the engine that powers the rest of the product development. The team started off to gather intelligence about the users and arranged for some user studies in three different continents. Sound domain knowledge, being in the publishing industry for decades, added to the rich insights and contextual usage related data from the users. The end-result, a clear idea of what needs to go into the product and that exactly helped push the platform to the next stage.

Blueprint for the building

You cannot build a house without an architectural layout and blueprint. Similarly we cannot develop a software product without sound architecture and framework. When I say architecture, it does not mean just technical architecture. Task-flow re-engineering and information architecture also form part of laying the foundation for the product. Studying the existing systems and understanding the non-functional requirements helped build a solid technical framework, while user studies helped get closer to the conceptualisation of the structure of the user interface. Both these formed the foundation on which the entire application was built in the later stages.

Mantra behind the yantra

Can anything great be ever achieved without Technology? Definitely not, in this era of computers, and mobile phones. If Computer is the ‘yantra’ or machine, software is the ‘tantra ‘ that runs it. Here too, the right selection and implementation of technologies played a great role in ‘building’ the product from scratch. Because this platform is a content delivery product, RSC team selected a contemporary technology such as XML to help manage the complexity, volume and structure of content. Also, the selection of the content server technology played a critical role in storing the content effectively and delivering it faster. Also on the front end, superior technologies backed by integrated teams helped in shaping up a nice-looking and simple interface to the platform.

Go back to the user

It was good to have a clear understanding of the user needs and designing the product based on that knowledge. However, we cannot accomplish true user-centred design and development unless we close the loop by getting the product evaluated by users. It was again with the help of the key product owner and marketing team, we could arrange a few user tests and feedback sessions. These helped a great deal in correcting some issues which were not noticed till then.

Two teams – one goal

Hillary and Tensing could not have scaled Mount Everest individually. It is only by coming together and working together that they could achieve the feat. I think the Agile methodology’s paired programming concept would have been applied by them. In the case of the platform development too, collaborative team work has been the mantra for success. With dedicated and smart members working on both sides, RSC and Rave continued to leverage the  benefits of agile development methodologies. Continual interactions, empathy and collaborative working had proved to be the key turning points in this project.

There is only one way

And that is the way forward. With feet firmly on the ground, we are now poised to surge ahead with focus, renewed energy and the continued support from stakeholders and users. Now that the platform is in front of the users, we expect lot of feedback, comments and suggestions to come from the user community. The potential next steps are -addition of new functionality, changes to the existing features, usage of advanced technologies and fine tuning the overall application architecture for better serving the users. This would help us continue our march towards making the product better, quicker, simpler and a joy for the users and also for us, to be associated with the platform.

Here is the final score card, at the end of the play:

Users – 10 points, Technology – 10 points, Business – 10 points, Team work- 10 points! (On a scale of 0 to 10) victory to one and all. The game did not end here and now. It just began.