echo
Echo summarizes responses made to various postings to groups and forums.
Is your PM smarter than a fifth grader?
"PMI conducted research and found that PMPs are no more successful at managing projects than non-PMPs [where approximately 50% of projects did not meet the success criteria] .... You can teach the basics of organizing projects to 9-year-old children ... Is there a need for the specialization of project manager?"
In my experience, truly successful projects are a result of effective business analysis, project management, and quality assurance, in equal measure. (And, of course, platinum-grade engineers are a definite plus!)
If a BA crafts a solution that helps an organization achieve its goals and objects, a PM can then balance scope, time, and budget, to implement the deliverables, and QA can determine whether processes and products conform to the stated requirements and standards.
Personally, I think it's helpful that each specialty offers broadly-based certifications that focus on exposing the applicant to the most common practices. Best practices are often contextual, and a "best practices" certification would be even more controversial than those we already have.
You must be "this tall" to analyze ...
Someone recently asked me "Who would want to be a 50 year old BA?".
According to the Institute's 2010 salary survey, the median age for a BA is 40-49 years old, with an average age of 43 in the US, and have 9 years experience in the role. Most BAs ave 6+ years of development experience before becoming a BA. It's not an entry-level position.
Our local meetings in Rochester NY bear out the survey. I'm 52, and, usually, I'm not the oldest guy in the room. :)
Ready, Set, BA!
"What do you do first when someone in your company wants something to be done in Salesforce ..."
One definition of business analysis is to identify changes an organization must undertake to accomplish its goals or objectives. (Which can include no change at all.) In order to identify change, I like to establish a solid baseline.
I usually start by describing any existing process with a set of formal use cases, sometimes accompanied with a flowchart. Then, I copy those assets, and start a second set that describe the amended business process.
For use cases, my goto reference is Writing Effective Use Cases by Cockburn
For solution crafting, extracting nouns and verbs is a classic object orientated technique, where nouns are objects and verbs are methods.
Has any one applied some other classic techniques, like UML workflows, to Salesforce projects?
BA by the numbers ...
"What do you say are the three most useful requirements attributes, and why?"
I like to capture the "Current Capabilities" and the "Desired Capabilities". Many times in discussions of what people want, we skip over what they already have. Sometimes a small tweak to an existing process can be enough to avoid a shiny new boondongle. It also helps to compare how the new system is different than the old system.
Is it Agile or is it Improv?
How would you respond if challenged that "Agile is just making it up as you go along"?
In practice, most teams have their own spin on things. I don't know if anyone has actually defined what "waterfall" means. I do know several people have defined in great detail how to run an Agile project.
Books
I'm also careful to refer to "truly Agile" projects, since its true that there are people who use it as a codeword for no methodology. But, in practice, waterfall is often just a codeword for "writing a lot of documents before coding anything", along with a homebrew methodology that varies greatly from shop to shop.