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).

No question, no gain

From the onset it’s evident that the project is about replacing the CDS with the QLT. Before long a seemingly uninterested attendee enters the room. It’s Gary from RGM. You remember that RGM is the department that is strongly opposing the project. It’s ok though, because if the system can adapt to the existing LGM and then bypass whatever it is that’s stopping it in GDR, the benefits will greatly outweigh the resistance put up by RGM. Obviously it’s all down to the timing though, because project Wolf is underway and creates a major dependency for this project. The session draws to a close. You look around the room and the stakeholders seem satisfied. It looks like they got exactly what they wanted from the session.

You look down at your notepad and there are a bunch of acronyms, question marks and additional names that were picked up in conversation. Right, it’s up to you. Go forth and do the analysis and deliver something awesome by Friday. Thanks.

This is unfortunately, a position that many analysts find themselves in too often. I know this, because I have had this conversation many times before.

Question all, assume nothing

Let’s replay this scenario. The conversation kicks off and acronym one rears its ugly head. You interrupt the conversation and sheepishly question: “CDS?”  You receive the anticipated ‘idiot’ glare from across the room, followed by: “Yes, Customer Data System. You know, where we keep the customer data stuff…” That’ll teach you to ask stupid questions.

After the fall, you get up, brush yourself off, and brave the next question. “What type of customer data?” “Well, it stores names, addresses, telephone numbers…” There’s a brief hesitation – “And relationship information” shouts a voice from across the room. “Does it?” questions the original attacker. “Of course it does; that’s where we get all the information we provide Marketing.”

Hmm… the attacker needed help this time round. Perhaps they don’t know everything. “What type of relationship information?” you ask. The original attacker cautiously answers, “We store information related to the type of products customers are interested in, so that Marketing can target them specifically.” You quickly fire in the next question, “Is that information collated into specific groups, or is it a free text field?”  There’s a moment of silence. You look around the room in anticipation for an answer. Nothing.

Questions can be more powerful than statements

The question is parked and the conversation swiftly picks up again. Acronym number two comes up and you ascertain that QLT stands for ‘Quick Leasing Tool’. It’s the name of the project after all. The meeting room door opens and a seemingly uninterested attendee sneaks in. There’s a pause and the facilitator points out that this is Gary from RGM. Notice how easily the next acronym snuck in there? You guessed the second one and it’s time to confirm this one. “RGM… Marketing? “Yes, Retail Group Marketing” Gary confirms.

Excellent, we’re making progress. You remember that he’s from the department that is strongly opposing the project. “Can Gary answer the question we parked earlier?” you ask. Gary wraps his mind around the question and immediately expresses his frustration. “It’s a free text field. It’s amazing how many ways there are of writing the same thing!” “How do you target specific customer groups from this information?” you ask. Gary shows more frustration as he passionately explains how a single employee spends their time sifting through the information to identify potential target groups. This is why the communications to customers are always late.

“Why don’t we collate this information into specific groups asks the facilitator?”  Excellent, they’ve asked the question that you couldn’t, because you don’t want to make promises on functionality this early on. Gary explains that this wasn’t thought about when the system was originally designed in 1992. “You mean we can change the way this is captured in the future?” he asks. Gary’s interest in the project has suddenly increased – and so has your value add. “Yes” answers the facilitator. “It’s why we’re implementing this project, to improve the quality of data we get from the system.” Have we just changed Gary’s position from ‘strongly opposed’ to ‘mild interest’?

Stupid questions are only as stupid as the assumptions that support them

So what does this story demonstrate? Part of an analyst’s job is to bring previous project experience and innovative thinking to the table. By asking the ‘stupid’ questions, they break down assumptions and demonstrate to stakeholders why obvious questions aren’t as instinctive as they seem at face value. Stupid questions are only as stupid as the assumptions that support them.

As an analyst you need to challenge what you hear. You need to seek clarity when you’re unsure and most importantly – never assume. Never ever assume. You’d be surprised how often I have asked a question, only to hear someone say, “Thank goodness someone else doesn’t know,” or “I was about to ask the same thing.”  If you don’t know something, it’s quite likely that someone else around the table doesn’t either. And if you are the only one that’s learning from the question, then at the very least you’ll be able to follow the rest of the conversation.

Never be afraid to question, never be afraid to challenge assumptions and never be afraid to analyse. Ultimately, the analyst needs to understand – that’s why they’re there. The only stupid question left to ask is… Why aren’t you doing this already?

What ‘stupid’ questions do you wish you had asked on your last project? Share your experiences below in the comments.

This article originally appeared on Bridging the Gap on 3 November 2011. Click here to view the original article.

The post The stupid analyst – Nik Gebhard appeared first on BSG (UK).

Innovation requires support

In response to my last post, “The best methodology is freedom“, I have had a number of questions around how a culture of freedom and innovation can be established. There is little merit in compiling a rulebook for promoting such behaviour. I don’t want to get into the dos and don’ts for embedding it. That would be counter-productive. I’d be advocating freedom and innovation and then prescribing a one best way to achieve it.

I believe that a guideline for creating a culture of creativity and innovation is less important than the outcome. What’s important is how an analyst is supported in being innovative. In this way, a unique structure can be tailored to underpin a culture of innovation, rather than having the structure dictated.

An environment that lends itself to innovation is one where analysts not only feel comfortable putting forward creative suggestions, but are encouraged to do so. New ideas should never be frowned upon or laughed at; no matter how trivial or how extreme. In fact, they should be celebrated and rewarded.

It is also important that analysts receive appropriate feedback from colleagues. If an idea is not going to fly the analyst needs to understand why. Our organisation has recently introduced ‘innovation boards’ where new ideas can be noted and become visible to all. This opens the door for questions and feedback from colleagues.

The natural tension between prescription and innovation

My previous post talked about methodology and freedom and how innovation is key to an analyst’s job. I strongly believe that fewer constraints bring greater innovation. This may seem obvious, but how often is it considered when guidelines are being compiled? Do the guidelines at your workplace offer leeway? If my project’s office wasn’t flexible in its project governance, there would be no room for innovation. If it were mandatory to complete documents x, y and z for each project and the sections within these documents were inflexible, not only would I struggle to keep the content relevant, but there’d also be no encouragement to innovate.

I’m not advocating lawlessness, but I am saying that too much structure has the ability to cripple innovation. There is a happy medium where structure and innovation can live together peacefully – even support each other. I believe that a good, flexible structure helps guide the direction of innovative thinking. If I know that risk mitigation method A, which forms part of the project structure, has proven to reduce the likelihood of project failure, I may want to consider incorporating this, or a similar, method into my thinking.

With great innovation comes risk

Our company has recently agreed to trial an ‘incubator’ approach. This is an idea (I believe first introduced by Atlassian), where an analyst, or a group of analysts, set aside time to come up with innovative concepts. These ideas don’t necessarily need to relate to analysis, but could be geared towards improving the work environment or simplifying existing processes.

An incubator idea is proposed to management who approve the concept. At this point extensive detail is not required. The analyst takes this concept away and spends time working out the detail. Ultimately, the proposal is presented back to colleagues at a team meeting for peer review. If the findings show that the idea will add value, it is implemented. Our company understands that while this approach can bring great innovation, it also bears an element of risk. Not all concepts will provide a benefit, costing the company valuable analyst time.

If you want innovation, you need to accept that it goes hand in hand with a level of risk. To an extent, this risk can be reduced by allowing senior analysts to cast their eyes over the innovative ideas. Due to past learnings, senior analysts may be in a better position to spot potential risks by applying some ‘seen before‘ logic. I accept that this is not a fool proof technique. In fact, it has a potential to damage the process, but it does provide a simple gateway for eliminating ideas where likely failure is obvious from the onset.

Another method is to ensure that analysts are not afraid to verbalise their thinking to as many people as possible. Sharing ideas with numerous people before committing to a design can reduce the risk of investing copious amounts of time in an idea that is likely to fail. The more people that challenge a solution, the more robust it is likely to become. Peer-reviews, wireframes, user group testing or process walkthroughs are some suggestions as to how these ideas might be presented to potential audiences.

The best approach to innovation is an innovative one

Creating a culture of innovation is an innovation in itself. We’ve worked hard recently to improve our ability to innovate within my organisation – incubators, innovation boards and the like are relatively new and we’re beginning to reap the rewards. I am given the time, space and support to drive innovation at my workplace.

Are you?

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

The post Fostering a culture of innovation – Nik Gebhard appeared first on BSG (UK).

Business is changing. So is business analysis.

Almost every article surrounding business today makes mention of the changing business world. Specific emphasis is placed on the doom that organisations face if they don’t adapt with the changing times. Cue the enormous gulp of fear. Given that a large focus of business analysis is on… wait for it… – business -, it seems only logical that the business analysis role needs to follow suit in the game of change. Tactics that have worked previously won’t necessarily work today.

It’s all good and well to highlight the pros and cons of various methodologies and then make an informed decision as to which is the best. The question is though – is there a best one? I’m not convinced that any methodology can be prescribed to squeeze the greatest result out of a project. In fact, I believe that, in hindsight, there will always be a better methodology. I use the term ‘methodology’ loosely, because I think that while methodologies provide a good set of guidelines, they shouldn’t be followed to the nth degree. I think most people agree on this point.

I can almost hear someone shouting: “Methodologies are project and scenario dependent. You must decide which one is best suited for your need.” I agree. To an extent. Off the back of every project comes a set of ‘lessons learned’. We live, we learn, we adapt. Concurrently, the business world is changing. This means we’re chasing a moving target. Perhaps the discussion we should be having is not around agile methodology, but rather about the need for agility in methodologies. Picking bits of a methodology that worked 5 years ago, is not necessarily going to work today.

It is up to business analysts to be innovative. Or is it?

Innovation and the ability to adapt are two key skills required by business analysis today. Bear in mind that adapting to an environment is the 101 of building initial rapport. Adaptation brings us closer to stakeholders. Getting closer to stakeholders means improved trust relationships. This, in turn, assists with requirements gathering and enriches teamwork. If your stakeholders suit up daily, so should you. If your stakeholders believe that neckties are simply neck warmers, so should you. Try it. It’s a simple first step to curing the ‘us and them’ syndrome.

So are analysts alone responsible for nurturing an environment that is conducive to innovation and creativeness? The short answer is: “Not entirely.” A certain level of interest is required before an individual will ooze innovation. You may argue that, in order to be an analyst, surely one would need to be interested in business analysis. Yes. No. Maybe.

Let me use an example of something that motivates me. Problem solving. I’m very interested in the topic. This may be because it is something I’m given complete autonomy over in my day-to-day job. I’m empowered to solve problems. How I do it, is up to me. I also have the necessary support structures in place to help me along the way. This motivates me to find innovative approaches to problem solving. I then have the opportunity to share my findings with colleagues.

A friend of mine lies on the opposite end of the autonomy scale. He has got an amazing eye for detail and loves solving problems. Never will you hear anyone talk so passionately about container shipping and specialist logistics. Of late he’s been extremely lacklustre about work. This is to the extent that he questions whether he’s made the correct career choice. It is disappointing to hear this because I know and understand his skill. I see it in action when he’s not at his job. So what has driven him to this mindset? His working environment. He’s not empowered to make decisions and innovate. He’s given a set of guidelines to follow. Creativity is tantamount to sin.

If you want a new methodology, liberate, don’t dictate.

Freedom to explore and innovate is essential. There have been endless discussions around reinventing methodologies. Good analysts are able to adapt to scenarios and apply themselves. It’s no good spurring an analyst on to innovate and then enforcing a strict methodology to which they must adhere. That’s counter-intuitive. Guidance and direction is always welcome. However, getting a really good result means that trust needs to be placed in an analyst to go against the grain and step outside of their comfort zone. This is an on-going game; not a one-off.

I have not yet applied a best ‘methodology’ to any of my projects. I don’t think I ever will. There will always be room for improvement. What I do know, is that I have the ability and freedom to adapt prescribed methodologies and come up with innovative, tailor-made ways to run projects that are sure to give them an edge over standard methodologies. I then have the ability to share what has worked and what has not.

Do you?

This article originally appeared on Bridging the Gap on 16 June 2011. Click here to view the original article.

The post The best methodology is freedom – Nik Gebhard appeared first on BSG (UK).

I wouldn’t expect much “umming and ahhing” if I alleged that there was considerable value to be gained in building strong relationships with stakeholders. It seems almost logical that building robust connections brings with it not only commercial benefit, but also project benefit. It instills a sense of teamwork as opposed to the typical “us and them” scenario. Strengthening relationships inadvertently means building an understanding of a person’s background.

Some facets of a person’s background can be researched, interpreted and assumed. I’m not attempting to create a foundation for über-prejudice, but it’s fair to say that when working with team members from other countries, a simple Google search or picking up a decent guidebook / travel book affords you valuable pointers on general customs and beliefs of a population. I appreciate that some of these facts may not apply, and that members working in a particular country are not necessarily originally from that country. However, having this information at hand does not hurt.

Researched characteristics can equip you for better planning

With the rise of global organisations, it is becoming more and more common to be part of a cross-border, and specifically cross-timezone, team. To give one example of cultural difference, I worked with a team where members from one country believed that working long hours in order to get the job done made you a better employee. Members from another country argued that having a good work-life balance enhanced productivity and reduced long-term fatigue.

In my experience, this often becomes a point of contention when things don’t go according to plan. This isn’t a debate about which is correct or more effective, but rather a discussion around understanding, appreciating and embracing cultural differences and using this to the advantage of project planning. Having an understanding of these working habits early on, means that better resource allocation can take place. Tasks assigned to employees who work a stringent 7 hour day may take longer than tasks assigned to employees working an 8 hour day.

Some characteristics – similar to the example on cultural difference above – can be researched. I recently read a guidebook on the United Arab Emirates (UAE) and was intrigued to learn that this type of information was readily available. I believe that, as far as possible, such characteristics should be taken into account during project planning. How and to what extent they are taken into account is up to the planner.

Going beyond skin-deep takes time, but enables you to fully leverage team member skills

Building rapport with stakeholders is about occasionally flaring from regular project tête-à-tête to associated personal experiences and stories. This opens the door for understanding similarities or dissimilarities between ourselves and others. It gives us an opportunity to learn about those attributes which cannot be researched, such as previous experiences, personal skillsets or even individual strengths and weaknesses.

I have been privileged to work with teams that have not only been culturally diverse, but also experientially diverse. An individual’s experience is clearly something that cannot be researched, but can be learned through the building of a strong relationship.

The benefit of having greater insight into an individual’s experience or skills is that these factors can be considered during project planning. Knowing that an individual is familiar with a specific aspect of a project means that their experience and skill can be leveraged. This does not only allow for better resource allocation, but also means that the individual can be consulted to provide recommendations on timeline estimations.

Something to consider here is the time ‘cost’ of getting to know an individual, versus the benefit of improved project planning.

Characteristics of newly promoted leaders may require additional schedule buffers

On one project, during a scoping and planning session, I was informed who my stakeholders were and covered the pertinent bases around level of seniority and experience. Regrettably, something that wasn’t as widely covered was the duration that some of them had spent in their current roles as leaders. While I realise there are numerous other areas that may be explored, this is a particular one that struck me.

It quickly became apparent that some of the members had recently been promoted to their current positions and had no previous leadership experience. This meant that behavioural attributes, such as slow rate of decision making, inability to delegate and difficulty in managing underperforming employees came to the fore. While this is not an exhaustive list, these characteristics noticeably impacted our project delivery timeline.

Identifying that stakeholders are new to a leadership role means that ‘typical’ characteristics of newly promoted leaders can be taken into account during project planning. Obviously an understanding of what these characteristics are needs to be obtained first.

Relationship building informs planning, but how much is enough?

It seems somewhat intuitive to perform a certain level of research on stakeholders or team members prior to project engagement. My experience has shown me that doing more homework on stakeholders can help with timeline estimations. In addition, there is considerable value to be gained in building relationships with stakeholders to understand their backgrounds and skill sets.

There are some questions though:

• To what extent can this research be performed?
• How much time do we realistically have to get to know stakeholders before the business demands estimated project timelines?
• Do you believe there is a link between getting to know stakeholders and project planning?

This article originally appeared on Bridging the Gap on 23 May 2011. Click here to view the original article.

The post The link between stakeholder relationships and project planning – Nik Gebhard appeared first on BSG (UK).