Soft Skills

5163 Views
3 Likes
3 Comments

Where application development is concerned, the ability to produce great code is just one small component of overall success. Just as essential is the ability for the developers to clearly grasp the business requirement – and deliver against an accurate functional specification.

Nick McKenzie, technical director at nVisionIT, notes that the process for the creation of an application is not always clearly understood. “From the business owner, to the user, to the developer, there are different perspectives and different expectations at play. As requirements pass through this chain, inconsistencies or assumptions can be introduced which can derail this process.”
 

17197 Views
2 Likes
0 Comments

No matter what requirements gathering process you subscribe to-waterfall, unified, or another approach-your discovery will be markedly easier if you can identify the right subject matter experts from the beginning. Whether they exist inside or outside your organization, people who intimately know your project's product or service, its actors, and its building tools will help you create more inclusive requirements, identify your unknowns, and grow in your own knowledge of the industry.

6325 Views
0 Likes
0 Comments

Business isn’t going to walk hand in hand with IT until we’re ready to truly partner with them. Here’s how.

I’ve had some interesting conversations about the role of business analysts and the best practices most of them use for requirements-gathering. And I’ve noticed a major contradiction between our desire to be effective partners with the business and the way we go about gathering system requirements.

The contradiction is this: current best practices lead us to gather requirements for a new system by using procedures that, right from the start, cause tension and adversarial interactions between IT and business people.

Author: Mike Hugos

10172 Views
3 Likes
0 Comments

When I’m not consulting or managing projects, some of my time is spent teaching MBA classes at Drake University.  The fact that I teach both project management AND creativity for business creates consternation among some of my friends and colleagues.  After all, can a project manager really be creative?  Aren’t those mutually exclusive skills?

My response is a great project manager also must excel at creativity to remain a viable, valuable asset in today’s marketplace.  Gone are the days of simply managing scope within a budget and schedule; project managers must be multi-faceted utility players.  Project and program managers are being expected to create solutions, to facilitate conflicts, and to motivate resources toward a goal in ways never before anticipated.

10811 Views
2 Likes
0 Comments

Good business solutions begin with good business analysis. But what's needed to excel as a business analyst and to get projects started on a good footing?

Much has been (and will continue to be) said about the set of skills that go to making a good business analyst. Forrester Research, for example, has published a spreadsheet (called the Business Analyst Assessment Workbook -- Note: subscription required) that lists more than 150 attributes of a good business analyst, grouped into categories such as Core Capabilities, Business Knowledge, Job-Specific Skills, Technical Knowledge etc. (I was particularly pleased to see this last category: It is important but not quite obvious that business analysts should also have a rudimentary general understanding of technology environments and architectures… mostly built up through seeing past analysis engagements fructify into delivered solutions).

Although the workbook is obviously intended as an assessment tool, I also found in it good for use as a training tool — for example, to bone up on technology approaches to business needs and to study sample projects, correlating the original business requirement with the type of solution delivered.

Here are 10 items from the Forrester list that I found particularly interesting and beyond the obvious (in no particular order)...

12147 Views
9 Likes
0 Comments

Here we are, the end of another year, and the question I ask always is, what have we learned?

If we are not learning something, be it from a success or a failure, or something in-between, then how can we move forward?

Information security is something that needs to continuously improve and refine itself, otherwise it will fall behind the curve of those that choose a different avenue to your beloved data store.

A tool that information security practitioners often use, especially after a security incident like a virus outbreak or full out attack, is holding a “Lessons Learned” meeting.

The core concept is to be able to take something away for the incident, no matter how big or small, so that the next encounter of a similar kind does not have the same result as the first.

19307 Views
8 Likes
1 Comments

In this article, I describe one very effective collaborative technique -- the Wall of Wonder (WoW) -- that helps software teams produce the kind of detailed, sharply defined requirements that effectively guide development. As an "emergent" deliverable, requirements evolve through exploration and examination using representative forms such as low-fidelity models and prototypes. A collaborative approach allows business and IT specialists to explore their requirements through these means, while accommodating the necessary fluidity of the requirements process.

13173 Views
3 Likes
1 Comments

A question was asked in the Modern Analyst forums. I paraphrase:

"How does a BA do their work in an Agile project? Can you give some practical examples?"

I've thought quite a bit about this topic and have experience with BAs on agile developments as a project manager and business analyst.

As a project manager I get frustrated by (but understand) the analyst’s need to move through the sensible steps of understanding the problem domain, documenting it, socialising it and then briefing the solutions team.  Many BAs struggle with breaking away from that paradigm, but to work in an agile style you have to get comfortable with the concept of 'just good enough.'

As an analyst practitioner I took it upon myself to act as a proxy for the product owner – which in a corporate environment came with the challenges of multiple stakeholders, the fact that you are not the product owner and thus don't really have the final say, and a number of other challenges that typically stump people trying to move to agile.

My circumstances were unique in some ways. I had worked in the organisation for some time and had established good relationships with all the key stakeholders. They really did trust me with their requirements because, over time, I had learnt (and shown I had earned) their business.

I also maintained high bandwidth communications with the stakeholders throughout the project and kept them informed of what was happening and how the system was shaping up in the context of their business needs. And expectations were managed.

And, lastly, at the end of the development phase of the project we kicked back into formal gated style UAT and release management.

I think the things I articulated there are useful guidelines for any BA or Project Manager on any project, but these dimensions enabled an agile approach in a waterfall type environment. I put myself forward as the product owner and acted as a proxy for the business stakeholders.

Will it work for you?

It depends on where you are working and your relationship with your client groups. A while ago I put this question of the readers of my blog: "Can the BA act as a proxy for the client?"  I got a resounding no from people that I respect and so I'll re-state that my circumstances above are probably the exception to the rule.

What I have learnt is that the BA can be a very useful person, and even play a crucial role, on an agile project.

Before I go on to speak about that I need to qualify what an agile project is: Originally when people talked about agile software development they were talking about precisely that: software development. The project community has always had a problem separating out the project lifecycle from the software development cycle. If you don't know the difference between these two concepts you need to go find out.
Here is one explanation.

So anyway, projects run many software development activities and naturally the processes and methods bleed into one another. And agile development was soon mixed into the concept of agile projects. And that's fine, but it presents a set of challenges for organisations wanting to transition from one way of doing things to another.

Have you ever learnt to juggle? I did. Hours of practicing in front of my bed so I didn't have to bend down to pick up the balls all the time. But I practiced with three balls and if I try to juggle four or five it's just too hard. I could set aside the time and practice until I get it right, but really, I am satisfied with three. It works for me, so why sweat the effort?

Same goes for shifting project methods. Sure your project office is sick of spending months and millions of dollars on wasted projects, but the various other participants in the project aren't feeling the same pain.

And smart, talented business analysts are one of those groups that aren't feeling the pain. Really, in my experience, excellent business analysts are often enough of a catalyst to break the cycle of project failures. Good requirements management, stakeholder engagement and change management really will get you there, even in the most formal waterfall environments. So why do they have to shift their whole way of doing things? They have achieved mastery of their profession, and now you want them to throw all that away and start again?

Well, yes. An agile approach in an agile environment is so much easier for everyone on the project.

Unfortunately an agile approach in a non agile environment struggles. And that environment is basically the stakeholders, the project team and the organisation's bureaucracy. So you end up using hybrid methods like agile in the developer space but more structured at the top end of the project.

The antipathy business analysts often feel towards agile methods isn't helped by the caustic tone of the agile gurus who advocate direct interface between the customer and the development team. Several of them publicly disparage business analysts and actively promote their removal from the process.

I think the key to getting master business analysts to work on agile projects effectively is helping them find a pain point they want to address, and finding a valuable place in the project for them.

The first point probably comes with either maturity – it's not all about them – or with a series of failed projects (naturally not their fault.). The second point – the BA's role – that was your original question, and it doesn't have anything to do with choices of models.
I think the role of the BA on an agile project is two-fold. Your number one role and priority is to facilitate clear requirements. It isn't to document them and it isn't to elicit them. It's to facilitate their clear transmission to the development team.

In some cases this simply means scheduling and booking meeting rooms, while in other cases it requires the BA's professional questioning and modelling skills to draw out an idea and ensure it is elaborated sufficiently for the developers to understand the full dimensions and context of the requirement.

Developers should, ideally, be in the workshops where requirements are teased out, so documentation is a secondary aspect to this work. It is about facilitating communication.

It's also about making sure the client is fully considering other stakeholders. Enterprise scale projects often have many stakeholders, and in less mature organisations the product owner or project sponsor isn't always considering the needs of his or her peers. The BA can help with that.

So, you see my idea of the role of a BA on an agile project is quite different from the traditional and industry view of what a BA does. It becomes much more people focused and much more about understanding the drivers, values and context of the business requirements than the details of the requirements themselves.

I believe these are key success factors that all excellent BAs apply in their job no matter what the project methodology.

I hope this is useful for you. And I am glad to be corrected by people who know better:" Agile Experts, what say you?"

Author: Craig Brown

8125 Views
1 Likes
0 Comments

Not many people-including business analysts themselves-are able to agree upon a standard job description, typical skill sets, proper training methods or a well-defined career path for the business analyst position. Yet almost everyone who's ever toiled away on an 18-month software development project can agree on the importance of the business analyst role to project success.

So while everyone agrees that good business analysts are extremely valuable, and that cultivating business analyst talent is essential for effective IT operations, a new Forrester Research report says that businesses need to do more. To really take advantage of everything that business analysts have to offer, there needs to be an answer to a career conundrum that many business analysts face: What's next?

In the June 2008 report, "The Business-Oriented Business Analyst," Forrester's Andy Salunga offers several potential paths to future business leadership for business-oriented business analysts.

First it needs to be noted that Forrester categorizes business analysts (BAs) into three roles: business-oriented BAs, who focus on a particular function, such as HR, finance or supply chain; IT-oriented BAs, who report into IT; and business technology BAs, who possess a blend of broad business experience and operational know-how as well as a high degree of tech know-how. However, the analysis and discussion of business analyst career path seems just as applicable to all other BAs and those who are interested in becoming one.

Author: Thomas Wailgum , CIO

16668 Views
8 Likes
8 Comments

A lot of IT folks and or BA’s believe that if you create the requirements without the business, and then review the requirements with the business for confirmation, you can save a lot of time.

After all, creating requirements collaboratively just takes too long, and the business doesn't know what they want, anyways. In addition, we (IT or BA) know the system better than the business, so it just makes sense for us to create the requirements, and then let the business say yes or no.

Let’s see this concept in practice in the “Requirements for My New Car”: a fable.

Author: James Shoemaker

4937 Views
0 Likes
0 Comments
Key to improving presentations is to focus on where your're audience is, not where you are, or where you want them to be. To do that, you must make a connection first. It is by making this initial connection that your "believe-ability" - your "buy-in" factor - and your "connection-ability" as a speaker are first made. Author: Tim McClintock, PMP
3673 Views
0 Likes
0 Comments
"Life is a series of presentations!" I'm not the first to say that. Tony Jeary said it before I did, in his book of the same title. If life really is a series of presentations (and, as a business professional, you're going to be called on to present information) the question is, what are you presenting? What is your presentation saying? Author: ...
5746 Views
0 Likes
0 Comments
Have you found yourself wondering those exact words just moments after a conversation with a co-worker? Or have you found yourself in a heated discussion because of something you've said to your spouse or loved one? Better still, your teenager gives you the "deer caught in the headlights" look when you ask where have they been so late at night? You...
4237 Views
0 Likes
0 Comments
Any project that is cancelled, not completed, or fails to meet its objectives and has to be written off, is obviously a waste of organization resources and time. However, it is also not enough just to successfully execute a project to completion. A successful project that is not implemented or used because it doesn't meet the customer's or user's r...
6499 Views
0 Likes
0 Comments

My friends and colleagues often ask me how I am able to produce so much in so little time.  Although I am flattered by such compliments, it's really not much of a secret which I attribute to the following areas (in no particular order):...

Author: Tim Bryce

Page 8 of 9First   Previous   3  4  5  6  7  [8]  9  Next   Last   

 



 

Copyright 2006-2021 by Modern Analyst Media LLC