As the Enterprise Business Architecture Practice Lead at IAG, I attended the recent Business Analyst World event this June with extreme interest. The Business Analysis industry continues to grow – with more companies hiring, and more employees getting trained and certified than ever before. However, with that is a changing and dynamic environment as BAs are barraged by new methodologies from the Agile and Lean worlds; new and more prevalent ALM and requirements authoring and management tools; role confusion with BPM, Business and Enterprise Architects; and the continued pressure from their business, project management and IT colleagues.
This theme resonated throughout the conference as the subtext of many of the talks and workshops during the week. As I sat at round tables and seminars listening to topics like the value and career path of the BA, Business Analysts were definitely vocal. I heard one participant say, “Between Management and PMs, I can’t do the job I was hired to do. Whether it’s by cutting my time short – or not getting access to the right people, I know I am not doing the job properly and it’s making me cringe handing off **** to the development team.” The frustration was clear. More than ever, they want to be value add players in the game. A game they feel is rigged against them.
Then there were the stats quoted all week long:
- 68% of projects fail due to poor requirements (from the often quoted Chaos Report)
- 45% of features put into production are unused (also from the Standish Group)
- 40-50% of budget is consumed by rework (Boehm and Basili)
- 75-85% root cause of rework is from poor requirements (from Dean Leffingwell)
Ouch. To the BA’s at the conference, this was taken as a personal attack. These stats used to be quoted to management to reinforce the importance of needing good requirements. To an audience of BA’s, this is now (quite falsely in my opinion) coming across more like a condemnation of poor work. I don’t truly believe that BA’s are perceived as the bane of every failed technology project, but it had that feeling. And what made this even stranger was the feeling that they are being locked out of Agile projects – but still being generally accountable for solutions meeting the business needs.
With 6.2 trillion dollars being spent globally on technology projects what does this mean for the Business Analyst? Given the cost of substandard requirements, which according to the BA Benchmark could be north of two trillion dollars, the business case for the Business Analyst should be obvious. To support this, the DOL and one leading staffing firm predict a shortage of BA’s in 2013 and continued shortfall in supply as technology needs ramp up into 2020.
From the seminars I attended at the Business Analyst and Project Management World conference, one concept struck a chord for me – as advice for the Business Analyst and Project Manager – and a critical factor for application development success:
Have the courage to do the right thing.
Given whatever your role and responsibility is, have the confidence to do or say what you think is right even when others disagree. Confronted with challenges and obstacles from peers and other stakeholders, stand resolute. Faced with uncertainly and confusion in your responsibilities in an Agile environment, create your value. Take responsibility. Learn and adapt. And stand by your convictions that good requirements and analysis are absolute.
Three R’s
As BAs and PMs, get the right information, the right training and right tools.
As Managers, help enable Business Analysts and PMs to do their job. Give them the right information, the right training and the right tools to do a good job.
For Business Analysts, remember these 3 R’s as your value add:
- The Right Plan: Work to a requirements management plan that defines the right approach, milestones, deliverables, tools, techniques and work plan.
- The Right methodology. Be adaptive and fit for purpose – ensuring the approach is appropriate, utilizes best practice and the principles of good requirements, analysis and architecture are maintained.
- The Right Requirements. Ensured by verification, validation, prioritization, review and traceability best practices.
And for Project Managers, the Right Stuff entails:
- Right alignment. All stakeholders agreeing on objectives, scope, requirements and solution
- Right resources. For all activities, but especially utilizing the right SMEs at the right levels that can provide expertise and decisions
- A strategy guy for the high level
- Control person for oversight
- And an execution person for process
- Right time frame. In the case of the initiation and planning phases, that there is enough time to do these critical phases just right.
Doing the right thing is hard. Doing the wrong thing is easy.
Have the courage to do the “right thing”! Positioned in the “right way” to do the “right job”!
– Judith Oja-Gillam
Thanks for the comment Howard. I read an article a little while ago called Twin Peaks. My take away from it, with respect to Agile, was with such a focus on the “short story” how will the “big picture” hang together? Dropping regular pieces of technology capability into my end to end business process will be great in the near term but will eventually create disconnects, or breaks, with a downstream or upstream business process which wasn’t considered in the context of the business analysis. Additionally Agile has high potential to impact architecturally significant decisions which reflect on the broader enterprise. I’m coming to the conclusion that Agile is great on “one of” stand alone applications with discreet start and end points. Business will be able to contain the problem when it all goes south.
I think you’re spot on with the 3 R’s Judith, and I think this is relevant regardless of scale or complexion of the initiative. This is true whether you’re working on minor enhancements through to large scale programs, just make sure to balance the risk / rewared model. As a methodologist and support role for business analysis in an organization with operations across 50 countries I see a lot what constitutes success and failure. You’ve drawn up a pretty good encapsulation of what needs to be in place to help ensure success.
On a positive Agile note, we run a variety of project management approaches in our organization, including agile. Our Agile Centre of Excellence is fully on board with the value of requirements and our business analysis framework is incorporated into their model. Agile is about trimming and paralleling competencies as much as possible to ensure quick focused delivery. Our Agile specialsts are sharp enough to recognize that requirements are the heart of every intitiave, not some fat to be trimmed.
Nice summary, Judith. The comment about BAs being locked out of agile projects really resonated. I’ve just returned from a speaking engagement at the NDC (Norway Developers Conference) in Oslo – perhaps the world’s most hard-core conference of agilists. I was a lone voice bringing the word about Business Analysis to this group; there was not a word about the function elsewhere in the conference and no awareness or appreciation of it amongst vast majority of attendees. In this new world, there will, indeed, be no place for us, unless we make our voice heard. I came away more convinced than ever, though, that the BA is needed in agile contexts, primarily because of the danger of the team being enthralled by technical wizardry and losing the business perspective.