It your responsibility to make sure that you understand what the impact of GDPR are going to be for the data that you work with. There is no doubt that this is going to shake things up in the data protection world for both organisations and individuals. We will publish another blog that will tell you what steps as a business analyst you need to make sure that you and your organisation do not breach GDPR regulations.

Success and failure are difficult to define and measure since they may mean different things to different people. An assumption that success can be quantified seldom holds true in the face of an ever-changing yardstick used to measure success. What might be considered to be a successful attribute today can be rendered unsuccessful under the influence of dynamic and multi-dimensional constraints.  A project is primarily implemented to target a predefined outcome, and it is imperative to measure the output in order to determine the benefit derived through the project. However, benefits realized do not necessarily add up to success. Project ‘success’ is different than ‘benefits realization’.

“Well it just so happens that I have a question about tools.”

"What tools do you suggest a business analyst use in pursuit of his or her vocation? What tools can be used as best practices for business analysts?”

How do you become a business analyst and where do you begin?  So you want to cross over to the land of analysis? A land of ‘schizophrenic’ people who need to possess multiple skills and make meaning out of ambiguity. You'll need to break down complex problems into bite-size chunks that can be easily understood. You'll also need to manage different stakeholders and break down knowledge barriers formed by these stakeholders. (Most having been in their organisations for decades) Finally, you'll need to develop a thick skin to stand in the firing line.

 

One of the key aspects to be considered before implementation of Agile methodologies is the degree of agility suitable for the organization. Due consideration should be given to the ‘current state’ before we create a proposal for the ‘future state’ of agility desired. Neglecting this aspect may invalidate the very purpose behind the endeavor.  Degree of agility refers to the relative ability of an organization to adapt to the lightweight methodologies in conjunction with an assessment of current state process maturity.

A long, long time ago in a land far, far away…. a project delivery team was busily spending their days delivering projects. They were tasked with delivering change projects and often these included software delivery. This team consisted of people with a variety of skillsets, personalities and experiences. Some of them were project managers, some were analysis and some were developers. Others were software testers and others were business experts and non-project people.

Since 2009 we have enjoyed reflecting on what’s happened the previous year on projects and making predictions for the upcoming year. Here are some of the recent trends we have discussed: agile successes and challenges, recognize the importance of roles that help maximize value, Scaling Agile, Certification trends in business analysis, etc...

Here are the seven industry trends that we have chosen for 2018.

During a recent presentation to business analysts, I used one of my consulting projects as an example of how to apply an analysis technique we were discussing. A member of the audience asked, “What made this company hire you as a BA consultant to tackle this project, when they already have so many in-house product managers and business analysts on their teams?”

In his classic book Flawless Consulting, Peter Block described three types of roles that consultants might take on: expert, pair-of-hands, and collaborator. Each of these represents a different kind of interaction when working with clients and a different source of satisfaction for the consultant. Business analysts can engage with clients in the same three modes. This article describes some of my experiences with these three modes of consulting engagements.

Intelligent Business Requirements are business needs and objectives that were designed to add business value and promote scalability and innovation.

‘Project success’ is the attainment of predefined criteria that emerge from attainment of user requirements. User requirements, in turn, are defined by an evaluation of the business and functional requirements. Thus requirements pave the path that leads to project success.

Given the speed of change, it is really tricky to predict what trends will grow in popularity or relevance. I am sure whatever emerges will seem obvious in hindsight, even if it would have been difficult to foresee. Yet, I have always thought that making predictions has a useful place in that it creates a conversation and it creates debates. So, what follows is designed to provoke discussion, and is intended to represent ‘potential trends to watch’.

Are we really trying to promote teamwork or is this nothing more than the latest corporate fad that is being implemented more for public relations than anything else? Let's hope for the former and not the latter. Teamwork is a powerful concept, particularly when there is anything of substance to be done.

Agile adoption is not ‘a walk in the park’! Agile is a framework of lightweight methodologies aimed at fostering flexibility and evolved as a proactive means to challenge the conventional mode of software development (SDM). The Agile methodology relies upon an iterative and incremental process to accomplish the project objective. Agile is a sharp contrast to the traditional sequential developmental methodology that lacks the ability to adapt to challenges through the lifecycle of projects.

As, more and more companies start to embrace cloud technology, it is vital that business analysts are able to identify the cloud service that is required to meet business requirements. As business analysts, we are often criticized for not getting involved in the technical side of things. However, it can be difficult to make decisions on technical side of things, if you don’t understand the language that is used in this space.

I don’t know how many articles I’ve read where the author states requirements should be “what” the user/client needs, not “how” to deliver the solution. They say “A requirement should never specify aspects of physical design, implementation decisions or system architecture”... In my humble opinion, every requirement, even the business level needs, goals and objectives, are just the start of a long march to a solution.