Monday, 15 September 2014 00:00

Business Analyst: The Strategic Implications

Written by

The new role of the BA is far more strategic in both the organizational sense as well as at the project level. In fact, I would go as far as to say that the BA, when appropriately leveraged, represents a liaison between business, project and customer teams. This shift in responsibilities identifies two areas that need to be addressed by any organization seeking to expand this role:

  • The organizational structure must support the actions of a “strategic” BA position.
  • The BA candidate must have wide skill sets, encompassing many generalmanagement competencies.

As organizations shift to become “projectized,” the roles and responsibilities that have supported projects within a traditional matrix structure must shift as well. Over the years we have seen organizations struggle with the following challenges related to shifts in both structure and culture:

  • Broken or disjointed cross-functional communication channels.
  • Uncertainty around roles and responsibilities within the project structure and beyond.
  • Quality concerns at the point of project delivery.
  • Skewed scope statements and thus implementation plans due to early stage breakdown.
  • Overall loss of productivity on project teams due to lack of continuity and methods
Monday, 15 September 2014 00:00

Why Your Idea is Probably Bad, and That’s OK

Written by

I’ve noticed that people often become very attached to their ideas, and don’t like having any flaws pointed out, or even questioned. That’s ok when it’s your own personal interest, but it’s a big problem when you’re part of a team working on a large and expensive project with a lot at stake. A key part of being a good Business Analyst is developing the habit of questioning everything so that you can sort the good from the bad.


In the interest of full disclosure, I’ll admit that before I started working as a consultant in IT I studied physics to a pretty advanced level. When you study one of the fundamental sciences you find that it’s really, really hard. And because it’s so hard, you learn to get used to being wrong most of the time, and not to become too attached to your ideas or be too fearful of criticism. You also learn how to go about testing ideas, and develop a healthy scepticism of silver bullets.

The reasons your idea is probably bad

The number one reason why your idea is probably bad is that there are simply many more ways to be wrong than right. In the space of all possible ideas the chances of hitting on a good one are improbably small. Of course you can have good ideas, but it’s likely that you’ll have many bad ideas before you hit on a good one.

Monday, 15 September 2014 00:00

5 Lessons from Working with Agile and Waterfall Teams

Written by

Over the course of my career, I have always been intrigued by leaders who promote a specific methodology or tool or process as THE RIGHT WAY to deliver solutions. They dispense mandates and proclamations to promote their all-or-nothing, purist approach to methodology. Typically it is because it worked in the past for them, and once it fails to deliver results onto a new one.

I’ve seen so many CEOs, CIOs, CoE leaders, and technology directors come and go with their unique methodologies and approaches. Do you know what doesn’t change?—the way BAs do work to be successful; The BA mindset, the key tasks and core set of techniques, remain constant.

We may need to use a new tool, try a new technique, a different template or learn a new set of acronyms, but the mindset, tasks, toolbox still work regardless of methodology.

Success and failure do not discriminate by methodology either. I’ve worked with teams that consider themselves Waterfall, Agile, hybrid or generic. I’ve seen huge success and mind-numbing struggle in all types.

I find myself in the midst of the following questions and thoughts often: Does methodology really matter? Does the BA role change based on the project approach? Are Agile and Waterfall really opposites? Can we apply Agile principles to traditional environments? Is innovation really dependent on a particular methodology? How can we boost collaboration regardless of methodology?