What’s blindingly obvious from one perspective might not be intuitive or “obvious” at all from others.
My employer, Jabian Consulting, produces a semi-annual publication of our consultants’ latest thinking on today’s most important business and technology issues. The Spring, 2014 issue just came out today, and it’s really good (and I’d say that even if I didn’t work there!)! You […]
It’s not because they don’t want you to know, it’s because they do things automatically and don’t even think to tell you about it.
Occasionally, an analyst will encounter a stakeholder who wants to prescribe the detailed solution on day one. What then? Here are a couple techniques that have served me well over the years.
If we can learn those basic, timeless principles that make any project successful, we’ll be able to identify them and adapt more easily to any environment whether waterfall, spiral, scrum, or the next big thing. One of those principles is that of enabling and empowering the cross-functional team.
It’s important that we take our own advice when it comes to our analysis efforts and keep ROI (Return on Investment) at front of mind.
Agile team members must know something about teamwork and this means understanding a lot about human behavior and why people do the things they do!
This post is spurred by a few articles I’ve read recently which have only served to reinforce some similar thoughts I’ve been having for a while now on the constant, competitively toned comparisons between agile and traditional development methodologies.
As I read article after article extolling the wonders of these new methodologies against the weaknesses of the traditional methods, I begin to wonder if the emphasis isn’t too much on agile methodologies over agile principles.
“You don’t get paid for the hour. You get paid for the value you bring to the hour.” – Jim Rohn
Mark Twain once said, “I can live for two months on a good compliment,” and I think many of us would agree with him. The “business” of delivering business solutions can be a stressful and, at times, seemingly thankless one. […]
Just a brief quote and a comment this evening to capture a thought that crossed my mind while contemplating the main differentiators between the great analyst and the good.
A candidate’s resume may be held to many of the standards used to evaluate a project deliverable.
Many BAs I coach make the mistake of mixing software capabilities with business rules, employee procedures, and operational guidelines when documenting requirements for an information system or software application.
John Maynard Keynes, the acclaimed economist, once stated, “It is better to be roughly right than precisely wrong.” This holds true for business analysis and solution requirements.
Think of requirements as inventory or as component materials in a storage bin with a shelf life and a carrying cost. Inventory isn’t free. You have to pay someone to produce (model and document) requirements. You need a supply of good, current (fresh) requirements to produce a quality product.
There is no perfect, fits-all template or set of documents which will be effective across all companies or even for all of a given company’s projects. The business analyst should work with internal and external stakeholders to determine which communicative tools will best serve for each project effort and model requirements accordingly.