Skip to main content

Tag: Software

Don’t Let Your Software Requirements Die

In the realm of software development, the clarity and accuracy of software requirements are pivotal for project success. Traditionally viewed as static documents to be archived post-project, this perspective neglects their ongoing potential. 


Living software requirements is a paradigm where these documents evolve continually with the software, serving as an enduring source of truth. This approach not only maintains relevance but also actively shapes the software’s lifecycle, promoting adaptability and precision in development processes. 

They ensure that as software grows and changes, the documentation is not left behind, thus avoiding the pitfalls of outdated or irrelevant information – because often zero documentation is worse than out of date documentation!


How requirements slowly die.

Picture this: a new software project kicks off with energy and optimism. The business analyst dives deep, engaging with stakeholders to gather an amazing set of requirements. They craft an impressive functional specification that serves as the project’s North Star, and as the project kicks off, hundreds of tasks get populated into a project management tool like Jira, mapping out the journey ahead.

The software delivery team starts strong. 


As expected, questions and clarifications emerge, evolving the requirements a little. Some tasks need tweaks; others have missing components, and there are even some sew requirements that surface. This is fine (we are agile after all!) – and these changes and additions are all added into the project management tool, as that’s now the source of truth keeping the project on track. 

As the tasks are ticked off, a sense of accomplishment fills the air. Finally, the project crosses the finish line, the board clears, and it’s a wrap. Success!

Or is it? Software, particularly the large, mission-critical kind, is never truly ‘done.’ 

The project may have ended, but the software lives on, continuous adaptation and enhancement are normal these days. But scoping new tasks becomes a little harder, as the detailed system knowledge from that original functional specification, has now changed. The source of truth is now fragmented across completed Jira tasks and buried in comment threads. 

In this scenario, the requirements didn’t just become obsolete; they died a slow death, leaving the team navigating a labyrinth of past decisions and discussions to grasp the full scope of their own software. 




How to keep my requirements alive?

Keeping software requirements alive is pivotal for the long-term health and adaptability of your system. Rather than relegating these crucial insights to a static document, consider embedding them within a collaborative platform accessible to the entire organization. This living, breathing approach ensures that requirements can evolve alongside your software, reflecting real-time changes and decisions. Here’s how you can make it happen:


1. Centralize requirements and allow collaboration: Choose a platform where stakeholders across the business can access, review, and iterate on the requirements. This system should be the go-to source for everything related to what your software does and why, and platforms such as Userdoc are specifically tailored to this task.


2. Project management integration: While the main body of requirements should live outside, ensure there’s a seamless flow of information into your project management tools like Jira. This helps in translating the high-level requirements into actionable tasks and ensures day-to-day activities align with the broader goals.


3. Continuous updates and iterations: Encourage a culture where updating the requirements is part of the process, not an afterthought. This keeps the requirements current and relevant throughout the software lifecycle.


4. Embrace AI – AI can be an amazing tool for helping determine what changes could affect other parts of your system, and understanding that when writing requirements for New Feature X, you will also need to update Existing Feature Y’s requirements.


5. Requirements versioning: Just like with code, software requirements need versions and branches. Ensure you clearly denote what features are live, what features are in development, and what features are still being scoped.


6. Living reference for all teams: From development to QA, from business analysts to project managers, ensure that everyone references and contributes to the same set of requirements. This alignment prevents information silos and fosters a unified understanding of the system.


7. Long-term business asset: Beyond project completion, maintain these requirements as a living record of what’s in place. This becomes invaluable for training, onboarding, and new developers understanding the system’s capabilities and limitations. It also ensures the source code isn’t the only source of truth for the system’s functionality.


Transforming your software requirements into living documentation is a strategic move that pays dividends throughout the lifecycle of your software. 

And the thing is, it’s not actually doing any extra work – it’s just simply unifying the place where that work is done, and fostering a culture of continuous collaboration and documentation.

Embrace the concept of living software requirements and watch your software, and team, move faster with more confidence.

Don’t Be An SDLC Extremist!

  • Do you follow process as a Fan or Fanatic?
  • Are you a Loyalist or a Zealot?
  • Are your suggestions Revolutionizing or Revolting?

In the 1980s Pepsi was tired of hearing that people prefer the taste of Coca-Cola over Pepsi. So they came up with the Pepsi Challenge. It was genius, and the results surprised more than those that were blindfolded. Characters in the ads always picked Pepsi, of course, but so did most people who tried it in real life—the sweeter taste was more appealing. So how did Coca-Cola keep their market share and brand loyalty? People continued to have positive feelings toward Cola-Cola, not because of the flavor of their soft drink or because they had a better product, but because they were loyal to the brand.

I wish there was a blind taste test for Software Development Lifecycle Methodologies, so people can see that SDLCs are not so different after all!

Diehard sports fans are the same way. When I was growing up the New Orleans Football Team was lovingly referred to as the ‘Aints’ as in “They AIN’T ever gonna make it to the Super Bowl.” So how did the Superdome get sold out Sunday after Sunday? Because Saints Fans were proud of their team whether they won or lost! No matter the projections, the odds, or the score a Saints fan would fight tooth and nail to defend their team.

I wish there was a super bowl for SDLC so we would know which SDLC has the most success.

Heaven’s Gate was an American UFO religious group from California. They believed that the earth was going to be “recycled” meaning wiped clean. They believed that the only way to survive was to leave the planet – that a spacecraft was trailing the comet Hale-Bopp. A large group of followers believed that their way onto this vessel was to leave their human bodies. Over 39 members killed themselves over a three day period, believing the whole time that they were ascending to the “Next Level.”

I am very glad that I do not yet know anyone who is willing to die for their SDLC beliefs!

Though they may not die for it, you probably know a few people who will fight for it. I know people who have argued themselves hoarse and even quit jobs because of their beliefs in a specific SDLC.

There is a psychological reason why people hold so dearly to their chosen methodology. Having a methodology in place reduces the team’s or person’s responsibility when things go wrong. When something bad happens, it is human nature to want to blame something. It is easier to be the victim of the process, than the person responsible for the failure. Identifying a breakdown in process as a source for blame provides closure for past problems, gives a sense of present control, and often eases fear of future failure.

Let’s look at it from a different angle.

  • Has any SDLC claimed that it works perfectly every time no matter what?
  • Do you think any SDLC would grow and be recognized simply by name if it was prone to continuous failure?

I am not advocating No Methodology. After all, a failure to plan is surely a plan to fail. What I am suggesting is that you think of an SDLC as a tool, there are many different kinds and it is up to you to have the right ones available and which one to use for the job at hand.

Self-Directed, Self-Organized… Really?

One of the core ideas or principles of Agile teams is this notion of a self-directed, self-managed, and self-organized team. 

In my experience, it’s one of the hardest things to get right in your coaching and team evolution efforts. 

Often I see two extremes, either:

The teams use the self-organization, self-directed mantra as a means of having no accountability. It’s essentially the “inmates running the asylum” and they can choose to do whatever they wish, whenever they wish under the banner of – “don’t bother us…we’re being Agile”.

Or the other extreme is that:

The management team says that they’re empowering their self-directed teams, but when you look at their behavior, they’re doing what they’ve always done…tell folks what to do.

People also seem to like being told what to do; being micro-managed

Self-directed teams are teams that, once given a mission or goal, are expected to sort out the challenges and deliver. 

While this is a central notion, in my experience, it’s hard to get individuals and teams to take this on. I’m not quite sure why, because it’s really such a compelling premise. That is (You) own your own destiny (Results) so figure things out.

Instead of folks embracing it, I often see them fighting it. Is it a lack of practice in decision-making? Is it a fear of accountability? Is it a fear of failure? 

I’m not quite sure, but it could be aspects of all three and much more.

It seems that many of us have become comfortable complaining about things and “pointing upward” to “them” as being the problem. Point being, many individuals have become comfortable with being told what to do. With the accountability residing with their managers and they simply are – doing as they’re told. However, if Agile is done well, then “they” becomes “us”, which can be particularly scary.

On the flip side of this, when I do see individuals and teams embrace self-direction, then it’s a “magical” thing. There is a shared accountability between the leadership team and the teams doing the work. It’s balanced and effective, with each one supporting and trusting the other. 

But this balance can often be quite difficult to achieve.

{module ad 300×100 Large mobile}

What the Scrum Guide has to say…

Next let’s review what the Scrum Guide says related to the overall Scrum Team:

The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team. The team model in Scrum is designed to optimize flexibility, creativity, and productivity. 

And then it goes on to say the following about the Development Team:

The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of “Done” product at the end of each Sprint. Only members of the Development Team create the Increment. 
Development Teams are structured and empowered by the organization to organize and manage their own work. The resulting synergy optimizes the Development Team’s overall efficiency and effectiveness. 
Development Teams have the following characteristics: 

  • They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality;
  • Development Teams are cross-functional, with all of the skills as a team necessary to create a product Increment; 
    • Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule; 
    • Scrum recognizes no sub-teams in the Development Team, regardless of particular domains 
that need to be addressed like testing or business analysis; there are no exceptions to this 
rule; and, 
    • Individual Development Team members may have specialized skills and areas of focus, but 
accountability belongs to the Development Team as a whole. 

In this case the Scrum Guide is focusing the term self-organizing towards how the team decides to attack the work they’ve been asked to perform via the backlog. Schwaber and Sutherland seem to go to great lengths to emphasize the team owning and deciding work strategy. They also emphasize a blending of roles to the point where they are near meaningless. The key points seem to be: team, teamwork, delivery of a product increment and accountability.

What Esther Derby has to say…

In 2011, Esther Derby wrote a really nice article that tried to address some misconceptions related to self-directed teams. The three misconceptions she highlighted were:

1.Self-organizing teams are completely autonomous, self-managing, and don’t need managers.

2.All you need to do to form a self-organizing team is provide a goal and apply pressure.

3.Since the team is self-organizing, they can accommodate moving people on and off the team easily.

There is an overall misconception that Esther discusses surrounding the relationship, role or ‘dance’ between the self-organizing team and the leadership structure within the organization sometimes referred to as (‘management’). 

In most cases, there isn’t a whole lot of guidance coming from the Agile community around managing/leading agile teams. And usually what does come out emphasizes the team over management. What I mean by that is that management is basically told to “leave the team alone” or “go and handle a few impediments” as their primary role.

I really like the balanced (and necessary) role that Esther describes. 

Constraints? Or do the inmates indeed run the asylum?

There seem to be two schools of thought when it comes to applying constraints to Agile teams. One is that they’re inherently bad; that they undermine the empowerment and accountability of the teams. 

I sometimes see this in coaching colleagues who use terms like:

  • Agile Purism;
  • Un-Agile, Un-Lean;
  • Arbitrary or Dogmatic;
  • Prescriptive or Prescription.

To describe anything that “forces” the team to do something against their will. Literally they want the team to be unencumbered in their journey without literally any constraints. 

Unless you’re working in your own company, or for a non-profit perhaps, I’ve never encountered a job (yes, Agile team members usually work) with a total lack of constraints. Usually there are quite a few, for example:

  • quality constraints;
  • appropriate working conditions (language, dress, hours, etc.)
  • business & financial constraints;
  • agile constraints – Definition of Done, agile approaches used, tooling, etc.
  • legal constraints.

But at the same time as we’re applying constraints, we need to be careful that they’re not too oppressive – that they leave some room for the team to make their own rules and their own decisions.

Definition of Done

I’ll use Definition of Done as an example. I believe teams need to have a deep and broad definition of done. I wrote about what that means here and here. But at the same time, I usually encourage teams to “extend” their DoD with team-based agreements and to make it “their own”. 

I encourage the same thing to happen when the team is making other operational agreements amongst themselves. 

How do we “Create” these teams?

I don’t think you do. I think the leadership team has a responsibility to create a fertile space for these sorts of teams to form, become established, and grow. 

Aspects of which include:

  1. Staffing the team with the skills required to deliver on their backlog;
  2. Trying to avoid part-time team members at all costs; if you do have some, limit them and clearly define their “capacity” within the team;
  3. If you’re doing Scrum, have a dedicated Product Owner and Scrum Master. Make sure they have the experience, time, and focus to do the job well;
  4. Respect the autonomy of the team and trust them to deliver in your stated goals and directives;
  5. And engage in all aspects of the agile ceremonies so that you leverage the transparency and real-time adjustment nature of the methods.

And the team has self-direction responsibilities as well. For example:

  1. Holding each other accountable to professional ethics and standards;
  2. Having congruent discussions in retrospectives guiding the team towards continuous improvement;
  3. Having the courage to push back as appropriate on traditional leadership that might be pushing the team too hard or in the wrong direction;
  4. Holding quality dear within the team, not only from a Definition of Done perspective, but with solid professional attitudes and practices;
  5. An overall responsibility to respectfully work together (swarming around the work) and avoiding Scrummerfall behaviors – delivering as much high-quality and high-value software as possible.

Wrapping up

I’m quite curious as to how readers might react to this article. What are your experiences in achieving self-direction in your Agile adventures? Is it easy or hard? And have you seen team resistance to the notion?

Have you discovered anything worth sharing about how to achieve this level of organizational balance? I’d be very interested in hearing about it.

And is it something, that once you’ve achieved it, it sticks? Or do you have to continuously work on your self-direction, autonomy, and self-organization?

Stay agile my friends,


A few nice references

The Silver Bullet Syndrome

Over the past several years I have heard an increasing number of complaints from a large number of Agile adherents accusing organizational management of expecting Agile to be a silver bullet (usually stated as “the next silver bullet” although I am not sure what other “silver bullet” Agile is replacing).

These accusations usually occur when there are problems with Agile or the approach does not work as advertised and organizational management pulls the plug or reverts to more traditional software development or management approaches. These complaints are not unique to the Agile community, although they do seem to be somewhat IT related in general. Hearing them got me to thinking about the whole concept of the silver bullet, the results of which follow.

We in IT are fond of condemning management of organizations for continually looking for “The Silver Bullet”. There is certainly some evidence to support IT’s contention that management expects a “magical” solution to business problems. We can cite many instances of technologies or approaches in IT that rose to preeminence and then were cast aside as not having The One Answer:  Business Process Re-engineering comes to mind as an example.

Perhaps we feel we in IT have a greater insight into how things work since Fred Brooks paper was published back in 1986  titled “No Silver Bullet – Essence and Accidents of Software Engineering.” And to a large degree, technology, headed by computer technology, has been the victim of “the next great thing” for decades. Since we in IT are the ones producing “the next great thing” perhaps, like Pogo, “we are the Silver Bullet that we complain about”. [1]

The Evolution of the Silver Bullet

For those not aware of the legend of the silver bullet, in folklore a silver bullet fired from a gun is the only way to kill a werewolf. (Note that the silver bullet was also used by the fictional Western character, The Lone Ranger, as a calling card and a symbol of law and order. We are not referring to that particular use of silver bullet in IT.) Initially, in common parlance, a “silver bullet” referred to the only successful solution to a given problem or situation (to kill a werewolf for example). It was a positive concept. I can remember management meetings in which someone would say, “well, that looks like our silver bullet to resolve the issue.” And it was.

Since Brooks’ article, “silver bullet” has become a pejorative term usually applied to management with the emphasis on the fictional aspect of the concept: there are no werewolves, and, therefore, no “magic” silver bullets to kill them. In other words, there is no single approach or technology that will solve a complicated business problem.

Deus ex Machina

Perhaps we in IT might be better served by using the term Deus ex Machina rather than silver bullet. The Deus ex Machina, Greek for “god from the machine”, was a device used by playwrights, and others, to get the hero or protagonist out of an impossible situation by means of some unexpected, and marginally believable, power or event that occurs to save the day. Usually, in Greek plays it was portrayed as some god arriving in a chariot when things were darkest for the heroes (the monster was about to devour them, or the enemy wipe them out) to set things right and to save the day.

Deus ex Machina might be a better analogy for the single magical solution that management would like to see to solve its business problem: A new product, or technology, or approach that would get them out of whatever difficulty they are in, and most likely got into by their own actions, or lack thereof.

However, Deus ex Machina is hard to say and is not quite that familiar. After all, Greek drama is not a common course for MBAs, not to mention IT curricula. So it looks like we will have to live with the term “silver bullet”.

There is a Silver Bullet

The logical binary oriented computer and IT people declaim management’s persistent belief in and search for the silver bullet. IT people, especially in software development, and more especially in the Agile approaches, state categorically that there is no silver bullet. This may be a valid, logical conclusion, at least in IT, but it flies in the face of human nature.

We might recall as children getting ourselves into an untenable situation or simply being the victim of circumstances of which we could not get out. The situation seemed hopeless, at least to us. Then our parents or teachers or some other adult produced a solution to the problem, sometimes with money, sometimes with an action they took, and sometimes with some simple adult advice and counsel. Whatever was done, a single solution evaporated the unsolvable problem. And this is the way it is supposed to be. Children trip and fall and the adult gets rid of the pain and comforts the injured so the child can get up and run again. Children try something new that does not work in the adult steps and to make it right. In other words we are used to “silver bullets” even though as we look back as adults on those events, we realize they are simply adult solutions to problems that we as children could not determine. Still, as children filled with a sense of relief that the problem is solved, we would call them “Silver Bullets” if such a phrase were in our vocabulary.

Being so used to “adult intervention” is it any wonder that we humans believe in silver bullets?

Romance and Comedy

Hollywood contributes to our continuing belief in the silver bullet. In romantic movie after comedic movie, the lead character gets something (love of their life, money, etc.), the lead character loses it, and then by some magical happenstance, the lead character gets it back (usually along with some insights) in the third act, and everyone lives happily ever after. Centuries of books, plays, operas, and nearly a century of movies (not to mention television and now Internet shows) have conditioned us to expect some kind of silver bullet to make everything right by the final credits. Regardless of how implausible, Andy Hardy puts on a show to save the orphanage. Cars line up for miles waiting to pay money to visit the Field of Dreams and save the farm from foreclosure. King Richard returns just in time to save Robin Hood from the forces of King John. The real criminal confesses to save the innocent man’s execution just before midnight. And so forth.

Our popular culture continues to reinforce the belief that somehow, someone or something will come along and save the day. More silver bullets.

The 24 Effect

In the very popular television series 24, the lead character, Jack Bauer, played by Kiefer Sutherland, had two often repeated phrases. The first, “dammit”, spawned a college drinking game. The second phrase, repeated in nearly every episode, shows how ingrained the concept of the silver bullet is in our culture. The phrase is “this is the only way”, usually stated after another character recites a laundry list of risks, such as death to Mr. Bauer.  Not only is Jack Bauer stating a single solution that will magically solve the problem (the problem of that 15-minute segment anyway) but the solution generally, in fact, works. And we believe it, or at least we suspend our disbelief.

As humans, we want to believe that there is a solution, even a “magical” solution that will get us out of our most dire situations.

This is called hope. And hope is not a bad thing.

And who knows? Maybe there are silver bullets. After all, someone has to win the lottery.

Silver Bullet Expectations

There are two primary reasons that Business Analysts have to be aware of the natural occurrence of the belief in silver bullets. We might call this the “Silver Bullet Bias.”

The first is one of expectations. This is the primary reason behind the negative connotation to the phrase “silver bullet”. If management assumes that a solution, for example an Agile approach, is a silver bullet, management will assume that the problem will be completely solved with no other action necessary.

Part of the reason for the Silver Bullet Bias is those who are proponents of the approach, the zealots or true believers.  There has been a lot of hype about Agile, for example, especially from the Agile advocates themselves. Agile, a software development philosophy or mindset, has been pushed to the corporate level far removed from the developers who signed the Agile Manifesto with promises that if the organization is Agile, great things will happen in software development and elsewhere (sales, marketing, customer service, etc.)  There is no mention of the work necessary and one of the underlying principles of Agile, which is that failure is necessary for success. Based on the concept that management is made up of human beings (although there are those in IT who doubt that concept), management will naturally jump at the possibility of a silver bullet.  We have only ourselves to blame for their expectations.

Expectations can be managed. Identifying the risks involved with the proposed solution, the shortcomings of the solution, and the aspects of the problem that may not be solved by this “silver bullet” solution will put the “silver bullet” in its proper context. Sometimes placing a potential solution in a realistic scenario including risks, impacts and limitations might force management to look for other solutions, which is never a bad thing, time permitting, and in many cases, the constraints of time tend to be artificial.

No Other Way

The second issue is more insidious. If management or anyone assumes a silver bullet approach, they will not consider any other options, and have a tendency to overlook the risks, similar to the 24 effect. If the solution is the “only way”, then there is no need to do risk analysis for the purpose of determining the alternative with the least risk, much less come up with another alternative. And this can be disastrous. 

The last thing a Business Analyst wants to hear about a failed solution is “we didn’t consider…” I’m not talking hindsight bias where the phrase is “If only we had known this would happen”.  I’m suggesting that additional information or analysis was stopped, prevented, because a silver bullet appeared and became “the only way.”  As Courtney Turk says in The Secret Diary of Ashley Juergens, or as Dr. Mouhamed Tarazi titles his book:  “There is always another way.” Or as Sherlock Holmes would say, “It’s a capital crime to theorize before you have all the evidence. It biases the judgment.”

The silver bullet is sometimes another way of jumping to solutions, or worse, ignoring or discounting any other possible solution (confirmation bias).

“No Silver Bullet” is a Silver Bullet

And, finally, the Silver Bullet Bias can be used as an excuse. It’s easy to say management is wrong because they want a silver bullet, and expect every solution to be a silver bullet and that’s why didn’t work. 

“Management expected Agile to be a silver bullet, so they pulled the plug on it when it didn’t solve all their problems.”  This is a convenient excuse, and it may hide the real reasons for the failure. Perhaps expectations were not set at the right level. Perhaps the approach was not correctly implemented. Perhaps the implementers tried to shoehorn the organization into a standard approach when customization, while more difficult, was called for. It’s easy to blame things that don’t go your way in business as a negative attitude on the part of management. The harder thing to do is to evaluate and assess and come back with a plan to do it right the next time (or at least to do it “righter”).

What can the Business Analyst do about it?

We recognize that all of us want, and to a degree believe in a silver bullet, to rescue us from whatever difficulties we are in.  While we cannot eliminate silver bullet thinking, we can address the issues of Silver Bullet Bias in business.

Considering the aspect of the “one and only” solution, the Business Analyst will offer multiple solutions to any business problem – or for that matter, any problem at all. The solutions do not have to be mutually exclusive nor realistic. In other words, one solution might be too expensive, and another realistic but improbable.  Solutions might be variations on the same theme. But they will be separately identifiable solutions to the problem.  Faced with options to solve the problem, management will likely recognize that the Silver Bullet solution is not the only way to go, and be forced into evaluating alternatives to come up with the best viable approach.

The Business Analyst can throw a little tarnish on the silver bullet showing that the solution may not provide all the answers or relief. The Business Analyst provides measurements and metrics pinpointing where the solution may fall short, and how management can determine that the solution is viable (or not). In this way, the “magic” of the silver bullet solution starts being replaced by situational reality. Management can begin to see behind the curtain.  Remember that even when the magic of the Wizard of Oz was shown to be fraud, the Wizard still satisfied everyone’s goals for going to Oz: a heart for the Tin Woodman, brain for the Scarecrow, courage for the Lion, and Kansas for Dorothy. The reality is that goals and solutions can be achieved without the silver bullet.

And, who knows, maybe the Business Analyst will show that the solution was, in fact, a silver bullet.

[1] The comic strip, “Pogo”, scripted by the late Walt Kelly (1913 – 1973) produced many quotes, among which, the most famous is “We have met the enemy, and he is us.”

6 Useful Mobile Analytics Apps to Gain Business Intelligence

The focus of the business world has shifted from personal computers to Smartphones. Most e-commerce businesses are now offering their mobile applications,

whereas some businesses are solely operating through mobile applications. With a staggering 6 billion Smartphone users anticipated in 2018, the m-commerce industry has a huge market for expansion. Analytics using mobile apps has become important in the Smartphone dominated market. Following are some smart business intelligence apps that can help in gaining deep business insights for better analytics.

1. RoamBI (Available for iOS, Android, Windows 8 Tablets & PC)

This application has any good spreadsheet analyzing capabilities. It can take data from various sources which includes SAP business objects, IBM Cognos, OBIEE, Microsoft reporting and Analysis services as well as Excel, Google Docs, Salesforce and more and present the data on iPad or iPhone. Roambi Pro is a hosted service for SMB’s and workgroups that creates a visualization from Excel, Google Spreadsheets, and Salesforce CRM. This application doesn’t have its own backend; it can only present data generated by other BI software.

2. QlikView on Mobile(Available for iOS, Android)

This is one of the most powerful tools for gaining business intelligence as it facilitates the creation and consumption of dynamic applications for analyzing information. QlikView provides fully interactive applications through HTML5. The app is available for iOS and android platform. It has an in-memory dynamic calculation engine which requires a server connection for real time analysis. It also has the ability to download and bookmark views for iOS which can be accessed in offline mode as well.

3. Renew Analytics application (Available for Android)

Renew Analytics app provided by Service Source has good data analysis capabilities. This app is very useful for recurring revenue business as it can track key performance drivers. It also provides role based access to key real time data sources. It provides a powerful dashboard for analysis of historical metrics and forecast.

Related Article: 10 Essential Apps for the Business Analyst

4. SalesClic (Available on Google Apps Marketplace)

If you want to have a better sales management through a mobile app, then SalesClic will be of great utility. It can easily integrate with Google Apps, Highrise, and Salesforce. It helps in fine tuning sales process by utilizing the historical data which are stored in Salesforce or any other database. It also helps in identifying opportunities and minimizing risk. It also helps in improving sales forecast.

5. Birst Mobile (Available for iOS, Android, Windows 8 Tablets & PC)

It is Software-as-a-service (Saas) business intelligence solution feature that includes an integrated ETL (extract, transform, load), data warehouse automation, enterprise reporting, ad hoc querying and dashboard. The app doesn’t require separate dashboards for different devices; a single iPad can be used to access all dashboards. The added advantage of using this application is that it takes leverage of iPad touch screen interface to swipe down, to scroll through rows in a table and use the two-fingers-spread to zoom in.

6. Yellow Fin(Available for iPad)

For combining multiple data sources and querying of multiple different databases to create a single report or dashboard, Yellow Fin is a handy mobile app. The advantage of using this app on mobile is that it renders a similar view as it delivers on desktop screen. The app is available in the online as well as offline mode.