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.

The post To technology or not to technology – Nik Gebhard appeared first on BSG (UK).

Implementation projects that I have been involved in, have typically deferred the engaging of business analysts until project slippage has arisen. I’m not entirely sure whether this is a scapegoat tactic or a sincere attempt at project recovery.

Either way, a challenge arises to convince business stakeholders that an analysis of the original requirements and a “system best-fit” is required. This proposal is often met with phrases like “budget spent”, “budget available” and that going back to the proverbial grindstone is too expensive and a waste of time.

Some form of requirements analysis inevitably follows. This is done to gain traction and better understand the ultimate objective and timelines.

You get what you pay for
It is at this point that a number of requirement gaps surface and the back-and-forth of change request documentation begins. Soon enough, the project team spends more time analysing and writing up change request proposals than implementing an off-the-shelf application. Along with bespoke requirements come defects and the inescapable timeline delays. Not to mention the increased vendor support and maintenance costs for bespoke code.

I find that the greatest misconception with system implementations is the forecast completion timelines. Vendors seem to be inordinately skilled at pulling the wool over business’ eyes by instilling some form of delusion that their system will be ready to suit the business need quicker and to a greater extent than any other system offered on the market. Over-promise and under-deliver is key to landing a contract. After all, it is a dog-eat-dog world.

How much money fixes a bad decision?
It is not long before conversations around technology choice become more apparent in day-to-day project conversation. A silent game of “Who is responsible?” ensues. From a reputational perspective, it could be lethal admitting that the executive team has made a poor decision and invested copious amounts of money in it. The question is though: “Is that more dangerous than continuing to throw money at it until it is no longer a bad decision?”

Personally, I’m for transparency and openness, but have now realised that this does not seem to be the favoured choice. I’ve recognised that businesses will more readily press on with extensive customisation, rather than go back to the drawing board. This approach means that change requests are raised thick and fast in return for large sums of money. Suddenly the cost-benefit evaluation that was pivotal when going through the system selection process is no longer applicable.

At what point does the reputational cost of admitting to having made a poor decision no longer outweigh the cost of customisation? Can monetary value be applied to reputation?

Should we point fingers, or should we get on with it?
I spent a little over a year on a project implementing an off-the-shelf system that was originally deemed best-fit by business stakeholders. The words “wrong choice” were blasphemy. It very quickly became apparent that customisation was the only way the business was willing to go. The instruction from the project board was to press on. Change requests were raised almost daily. Many months of missed development deadlines and revised budgets went by before the project was eventually completed.

Almost sixteen months have now passed since go-live and the executive stakeholders and decision makers are no longer in the same department.  What’s more is that the company is evaluating a new system to replace what was implemented. Something they could have been doing almost two years earlier. This is a particularly poor and costly consequence of an even poorer decision.

“Sticking to your guns” can work out
On the other hand, I have seen and been involved in a number of projects where the same “stick to our guns” attitude has been applied and organisations have shown significant growth. I have to ask myself: “Does this mean that this was a less poor choice in technology, or were other factors at play?” I do know that many of these projects also entailed extensive customisation – customisation that has since paid for itself.

Obviously the ideal scenario is for informed technology decisions to be made off the back of extensive analysis. But, what if this fundamental step has been missed? At what point do you make a call for good decision versus bad decision? At what point do you no longer insist that the price tag on reputation is higher than the cost of customisation? Is it a calculated risk or blind luck?

This article originally appeared on Bridging the Gap on 21 April 2011. Click here to view the original article.

The post Project sponsors: Saving face or saving costs? – Nik Gebhard appeared first on BSG (UK).