I’m pleased to say that one of my recent blog articles has been published on “Techwell.com”, where I have contributed as a guest author. I’d love to hear what you think, so please take a look and add a comment on the site. A short excerpt is shown below: Excerpt: In his recent article “What…
I’m pleased to say that my most recent blog article has been published on “Bridging-the-gap.com”, where I have contributed as a guest author. I’d love to hear what you think, so please take a look and add a comment on the site. Excerpt: “I have to admit that I have a rather eclectic music…
I’m pleased to say that one of my recent blog articles has been published on “Techwell.com”, where I have contributed as a guest author. I’d love to hear what you think, so please take a look and add a comment on the site. A short excerpt is shown below. Excerpt: As an avid Skype user, I couldn’t believe…
I’m pleased to say that one of my recent blog articles has been published on “Techwell.com”, where I have contributed as a guest author. I’d love to hear what you think, so please take a look and add a comment on the site. Excerpt: “Kent McDonald recently wrote an excellent article encouraging project teams to…
Increasingly, projects teams are dispersed and may be working not only in different cities, but potentially different countries, continents and time zones. Working in a dispersed team undoubtedly creates additional challenges when facilitating requirements elicitation sessions. In fact, people may even have an initial reluctance to attend virtual meetings. These challenges certainly aren’t surmountable, and here are some concrete tips that can help:
Requirement prioritisation can be a difficult exercise. Often, stakeholders will insist that every requirement is essential and prioritising or de-scoping requirements can feel like asking colleagues to part with their most treasured and sentimental personal possessions! In this article I’m going to outline three considerations that make prioritisation significantly easier. I’m going to refer to the MoSCW prioritisation framework throughout the article.
1. Get the foundations right
When prioritisation is difficult, this suggests that there isn’t a shared understanding of the business value and the customer value that the project will deliver. This suggests that the foundations of the project are shaky—perhaps insufficient enterprise analysis took place. In these cases, it’s worth taking a step back and asking “What problem or opportunity are we trying to address here?”. If that isn’t clear, then make sure this is resolved before moving forward. Jeff Patton touches on this in his article How I Stopped Worrying and Learned to Love Prioritization and he underlines the fact that business goals must be explicitly stated.
Successful projects start with a good and clear understanding of the organisation’s goals and objectives and over time develop a clear understanding of the project’s requirements.
One significant challenge with projects can be the gap between what the stakeholders ask for, what they need, and what they can afford. There can be a further gap between what the stakeholder expects and what is actually delivered. Good quality business analysis helps to plug this gap.
Although the discipline of business analysis is young, it isn’t new. Requirements engineering is older still—yet history is still littered with examples of expensive IT project failures and projects where the users haven’t received what they expected. How can this be? And how can these types of project failure be avoided?
A key skill within business analysis is the ability to define and set goals and objectives. It might not always be referred to as “goal setting,” but every time you help the business determine the business value that would be achieved for a particular initiative, you’re really helping them to define goals and objectives. When defining acceptance criteria and non-functional requirements, you’re also setting quantifiable objectives that a solution should meet.
A common way of approaching business and project goal setting is to use the SMART technique. This technique encourages the setting of goals that are specific, measurable, achievable, realistic, and time-bounded. The SMART approach has many uses within projects and beyond. But is SMART enough?
I was recently fortunate to attend a useful and inspirational training course where I was introduced to a new technique (and acronym) for goal setting. This technique, designed for setting personal goals and objectives, is designed to be used in coaching. However, with some subtle adjustments, it works equally well in a project or business environment.
The acronym is PECSAW, which stands for:
I recently read a thought-provoking thread on the IIBA LinkedIN forum, relating how Business Analysts should state requirements. The conversation centred around one main topic: Is it advisable to define a system by stating what it shouldn’t do, or should these “negatively framed” requirements be avoided.
There’s no hard and fast answer on this, and there are certainly varying views on what constitutes a well-written requirement. However, I firmly believe that it is highly preferable to define systems in terms of what they can do (rather than what they can’t).
I’ll illustrate this with a real life—but non IT—example. I live in Portsmouth, on the south coast of the UK. Near the seafront, there’s a really steep hill. Given the number of pedestrians that are in the area, cyclists are banned from using the path downhill (as it’s likely they’d lose control and collide with an unsuspecting passer-by). A picture of the start of the hill is shown below. Trust me, it’s much steeper than it looks in the picture!
I’m pleased to say that my most recent blog article has been published on “Bridging-the-gap.com”, where I have contributed as a guest author. This article focuses on business analysis from the perspective of SMEs and stakeholders… and has caused some controversy! I’d love to hear what you think, so please take a look and add a comment…