The problem with BA Tools Part 1

The failure of MS Word as a BA tool

As BAs, one of our primary goals is to improve the productivity and effectiveness of the businesses we work in, yet many of us are using tools that are detrimental to our productivity and restrict our ability for effective information management, communication and stakeholder engagement.  This exacerbates communication problems and introduces significant risks into project delivery that contributes to the dire IT software project failure rates.
Typically we spend too much time on administration, rather than doing analysis.

Tool adoption and usage

While other similar professional roles such as Project Managers, Software Developers and Testers have benefited from the development of well designed, process defining and tailored software tools, Business Analysts have not, although this is now starting to change for the better.  So despite their critical shortcomings and our dissatisfaction, approximately 70% of the estimated 1 million+ BAs globally use MS Word and Excel for capturing, managing and communicating requirements.
BA practices have evolved using Word templates and even the most comprehensive and most recognised methodologies such as the Volere Knowledge Model is predominantly enabled using Word.  In our recent survey, 86% of respondents said they were using Word templates for requirements capture, management and communication in their BA practice and this included large multi-national public, private and government organisations.

The failure of MS Word as a BA tool

While MS Word is incredibly easy and intuitive to use, it is a poor tool choice for gathering and communicating requirements.  When requirements are captured in MS Word they are inherently tied to the presentation of the information, which makes any sort of information analysis, sharing, linking, relating, reusing, and filtering extremely difficult.  It is possible, but takes unnecessary time and often results in more serious versioning and duplication problems.
MS Word does not support real-time collaboration or concurrent users which means reviews and approvals are undertaken in silos using large unwieldy documents, most of which contain content and requirements that are not even relevant to the reviewer.  A large proportion of time is wasted collating feedback, facilitating meetings, resolving conflicts in order to obtain collective agreement.  I am under no illusion that this process is required, but there is unnecessary waste in this process for the BA, project team and business stakeholders.
The concept of traceability, versioning, and change history / management are foreign to MS Word, so this has to be managed manually, often in a separate spreadsheet or tool.  Managing this in one or two documents for a small number of requirements is sometimes manageable, but far from ideal.  As requirements are decomposed, further layers of requirements are discovered and are captured and communicated in an ever growing number of documents, such as Tender / Procurement (RFP/RFP) documents, solutions / technical design, Release Documents, Change Requests and the list goes on.  It can very quickly get out of hand and become completely unmanageable.

The impact of poor requirements practices

You may have seen some industry figures and statistics around the impact of poor requirements, for example:

  • Computing Technology Industry Association (CompTIA) believe that poor communication is the reason most IT projects fail.
  • Software Engineering Institute believes that requirements are primary reason for project failure.
  • EBG Consulting found that 50% of defects originate from requirements and design.
  • The IDC Group research found that 70% of project failures can be attributed to poor requirements.
  • IAG concluded poor business requirement capability undermines organisational competitiveness and organisations with poor business requirement capability:

pay a 60% time and cost premium
have 3 times as many project failures as successes
expend twice as much time, budget to achieve half the result

Poor requirements management in practice – case study

This example is based on true events.
Company A was looking for a new software system to manage a core aspect of their business.  They formed a project team and prepared a requirements / tender document in MS Word.  Approximately 300 high-level business requirements were identified.
Vendor X, Y and Z tendered for the job, each providing associated responses and their solution requirements and statements.  Dependencies between the solution requirements and the original business requirements in the tender document were in some cases maintained manually in a spreadsheet by the vendors.
Vendor X was selected as the vendor and the proposed solution requirements formed the basis of the contract between the two parties.  Soon after, the high-level and detailed analysis phases started and with this came the development of the high and detailed design documents and requirements.  Again these were all created in MS Word.  The number of requirements soon reached into the thousands.

It became increasingly difficult for the project team and the vendor to provide assurance that the business requirements would be delivered to expectation and that key requirements had not been overlooked.  The lack of control, visibility, and traceability of business requirements was soon highlighted as a significant risk to the project and that at best it would cost tens if not hundreds of thousands of dollars.
Frustrations between the Business, Project Team and Vendor soon mounted, as it was externally difficult and time consuming to:

  • track the relationships and dependencies between the business requirements, proposed solution, contract requirements and systems requirements,
  • track the relationships between business requirements and design documents, and
  • assess the impact of change requests and validate whether they were in fact valid change requests.

Significantly more effort and cost was required to maintain a level of requirements communication and management that was necessary to deliver a successful outcome.  Even with this increased effort requirements were missed, change requests were duplicated and contract negotiations were required to rectify the problems.  The project was challenged.

Good business requirements are the key to project success.  What makes good requirements?

“Clear business requirements are achieved only by getting the right content in a consistent format, using a clear process.  Defining accurate requirements, interdependencies, unambiguous goals, and documenting information required to support the process.“
Keith Ellis – IAG.

This statement is generally understood but is extremely difficult to achieve, given the lack of tools specifically designed for the role and tasks for the BA.  The decision of tools to enable effective requirements capture management and communication is the double edged sword.  Using Word has some obvious pitfalls but the alternatives are not without theirs.
Your feedback?
I am interested to hear your thoughts and experiences around using BA tools and MS Word.

In Part 2, I will talk about the problems with existing tools and how, as a practicing BA, I’ve collaborated with the BA Community to solve this problem.


This article was written by Jody Bullen who I met online a few months ago. Initially, I was concerned he would only be interested in pitching me his new tool. However, his background as a BA and passion for helping BA’s won me around. His believes in actively engaging with the community on a one to one basis. I’m happy to give him an opportunity to share his knowledge and experience.

Please be kind enough to give him some feedback

More on Jody below…

Jody is a highly experienced and award winning business analyst who understands how to deliver business value through technology.   In 2009 Jody was awarded New Zealand Business Analyst of the Year, by Computerworld magazine.  Jody is passionate about business analysis and has presented many times in New Zealand and internationally.

He has extensive experience in researching and defining end-user requirements, business process analysis, automation and reengineering, creating business cases and developing requirement documents and functional specifications.

He has worked in, coordinated and lead business and technical teams in all phases of the Software Development Lifecycle across various industry sectors.

Jody is now the CEO and founder of Yonix.   A company committed to making the job of the business analyst easier, through software designed specifically for the role and tasks.

About Alex Papworth

Leave A Comment...