To technology or not to technology – Nik Gebhard 0

Posted on 23, February 2012

in Category practitioner experience

To technology or not to technology

Over the past few years I have come to realise that business stakeholders are growing in their understanding of technology. Does this understanding carry an advantage, a risk, or aspects of both within the project world?

In my early years as an analyst, I remember working on a particular project and jotting down business requirements that were delivered from a strategic perspective. It was blatantly clear that these requirements were carefully derived to support an organisation’s strategic mission. I discussed these with the technical stakeholder before committing to the business what could or could not be delivered.

In these discussions, I realised that many of the requirements were either a) technologically impossible within the current landscape or b) going to take much longer to complete than what the project allowed. In order to ensure that all avenues had been explored, I held workshops with the technical stakeholders to uncover alternative options or workarounds.

Challenging the challenges

My next step was to sit down with the business stakeholders and explain to them why some of the proposed requirements were not as feasible as was originally anticipated. They accepted some of the workaround suggestions, but didn’t think twice about those that would in any way compromise the ultimate, organisational strategic objective. The short of it was that I needed to sit down with the technical stakeholders again and thrash out workarounds for the ‘non-negotiable’ requirements. These would need to provide the same result – within the original timeline and budgetary constraints of course. Needless to say, long hours and vast amounts of effort ensued.

What was important here was that the business knew what they wanted and compromises to the strategic objective were not in question. Whenever requirement negotiations went on, the business stakeholders would keep that ultimate objective in mind. Everybody in the discussions knew what they wanted and more importantly, they knew why they wanted it.

We can meet objectives, or we can meet objectives

In contrast to the above and on a more recent project, I worked with a particular stakeholder who picked up information very quickly. He took the time to sit down, learn about the technologies in question and ultimately deliver better formulated requirements. I say ‘better’ in a very loose manner as these requirements were only better if seen from a specific perspective. The developers for example, enjoyed discussing requirements with the stakeholder, as they were never far reaching or difficult to understand.

What resulted was functionality that was designed around the limitations of a system, rather than requirements that were aligned to a strategic objective. The difficulty here was managing the stakeholder and asking him to take a step back and consider whether the requirements he had provided were in line with the original strategic objective of the system implementation.

If this is not managed correctly, a danger exists that a compromised system is delivered, that meets the revised business objectives, but no longer aligns to the original strategic objective of the organisation. It’s an imperative step to move out of the detail every so often and ask that all important question – Why? Why are we implementing this? Why is this project taking place? Having a business stakeholder step into the technological realm is a bit like having Darth Vader step over to the light side. You lose the story. In this case, you lose your user story.

Is the meaning of ‘requirement’ getting lost?

The role that I needed to play on this project was very different to the one I played on the project where the stakeholders took no interest in the technicalities of delivering the system. My view is that the role of the business analyst is to implement benefits driven change. To achieve this, it is necessary for the BA to understand how stakeholders approach the requirements conversation and to stand up for the benefits appropriately.

Sometimes requirements need to be challenged, even when they’re easily implemented. I understand that this approach might expose a more complex requirement, which could in turn impact delivery timelines. However, this ensures that a strategically aligned system is delivered, and not just an easily implemented system. To answer the opening question, I believe that having business stakeholders with technological knowledge holds both advantages and disadvantages. In order to make the most of it though, somebody needs to ‘keep an eye on the game’. That somebody is the analyst.

Having said this, I’m left curious to understand if this observation is unique to the projects that I have worked on, or if this is something that other analysts have also experienced? Are stakeholders becoming more technologically aware?

Do you believe that business stakeholders should focus on the business requirements and ensure that they’re delivered regardless of the technological challenges?

This article originally appeared on the Bridging the gap. Click here to view the original article.