Were Business Analysts responsible for all that project chaos?
According to the tables at the top of the early Standish Chaos Report into why projects fail are the quality of business requirements followed by the lack of involvement or engagement of users.
This reading was often used to extrapolate project failure largely to the BA, with user engagement being cited as the Business Analysts responsibility. On the flip side, I cannot recall BA's receiving significant attribution for project success when they succeed having quality requirements and strong user relationships. So who was making the call that requirements inadequacies ruined the project or is it just a case of who is being asked to explain why and what interests they have in who they blame?
Reading just a little further down this same report, managers with projects failing all around them do not mention requirements at all. They see a broader malaise that results in it being nearly impossible for the BA to be successful which is attributes of management including; poor attitudes to change; incompetence; a lack of vision and management level politics. So should the BA be held accountable for not creating a silk purse from a sow's ear?
The introduction of business analysis certification (such as CBAP) is a great way to increase predictable outcomes and metrics for the quality of business analysis. The information and structure around business analysis provided by BABOK has led to an in improvement in the technical application of techniques applied by BA's, but what impact if any has this had on project outcomes? Apparently very little.
The "Chaos Manifesto 2013: Think Big, Act Small" focuses on smaller projects and highlights the steadily upward trend in project success from 2004 to 2012. The report highlights the improved success rates achieved by smaller projects over their larger cousins, illustrating the wisdom of the adage "how do you eat an elephant?" to which "one bite at a time" is hard to argue with. The only potential downside to running a number of smaller projects instead of one larger one, is the potential for additional administrative overhead when doing multiple initiation and project close phases, though a flexible and rational PMO and/or business stakeholders can easily prevent documentation overkill.
Similarly, the industry recognition of project management as a specialist capability and a rise in professionals with such certifications is given some credit. The prevailing wisdom that great project managers are not born, but require broader business experience, study, and a structured approach, may also be due to changes in workforce dynamics and flatter organisation structures that require these people to be skilled and not just strong. But poor project management was not accused of being a significant contributor to project failure previously, definitely not to any comparable extent that requirements issues were, so why should the current crop of up-skilled PM's get specific credit and not CBAP enhanced BA's delivering improved requirements?
Along with better sized projects and improved PM's, iterative delivery and the complementary concept of living requirements receive attribution as if the approach, and not the role-holders responsible, can claim credit. Living requirements, be they in a product backlog or other form, require far more effort to identify, manage, prioritise and keep traceable than waterfalls 'fire and forget' ones. In other words, the person supposedly responsible for earlier requirements issues, the BA, now does a more difficult job and does it better.
This also overlooks the most significant philosophical requirements and project management failures of waterfall, and the fact that neither were problems of the analysts making. The waterfall BA was highly engaged by the PM at initiation and early execution, and generally had negligible continual engagement until testing and deployment. As a result of the project management methodology, the likelihood of needs changing was almost guaranteed on anything but the smallest low-risk projects - and this is irrespective of the quality of the initial requirements. All BA's I know preferred remaining close to the project, in constant liaison with their stakeholders, rather than re-assigned to other activities just when their hard work began to take shape. But this was not their decision to make.
Similarly, is there any wonder there would be significant problems with user engagement as the key point of contact disappeared just when the project commenced delivery. From the user engagement perspective, Business Analysts frequently invested significant emotional concern for their stakeholders, empathy being an important attribute of the successful BA, and took great pride designing the solution in detail from defining data models, processes, interface UX when that was part of their job. Note, skilled BA's performed this work quickly and efficiently, I do not believe having the co-located user design the interface with the Agile team was by default what solved problems with solutions not being fit-for-purpose, though this did have a positive effect.
Another issue beyond the BA's control was unless the PM could identify risks to the original requirements and re-engage the BA quickly, then there was every likelihood that work updating requirements would impact project time and budget. The BA, who was meant to be redundant during this time, suddenly re-appeared on the resource cost schedule. If the project then failed to meet the constraints, running over time or over cost while changes were investigated, analysed and incorporated, to what, or whom might the PM attribute failure? Poor risk management or contingency planning did not factor in the chaos report.
As with project managements PRINCE2 and PMI, the iiBA has defined processes, practices, attributes, capabilities and certification to specifically enhance the Business Analysts' professional value. Whilst there are new tools available to project teams to assist requirements management and traceability, this would be like attributing project management success to enterprise project management server applications.
It's a shame that those exponents of this crucial skilled role, previously so maligned as the likely culprit in project failure, are not also given credit in the ongoing improvement in project success. But then it always depends who you ask, history is written by the victor and not the scapegoat.
This reading was often used to extrapolate project failure largely to the BA, with user engagement being cited as the Business Analysts responsibility. On the flip side, I cannot recall BA's receiving significant attribution for project success when they succeed having quality requirements and strong user relationships. So who was making the call that requirements inadequacies ruined the project or is it just a case of who is being asked to explain why and what interests they have in who they blame?
Reading just a little further down this same report, managers with projects failing all around them do not mention requirements at all. They see a broader malaise that results in it being nearly impossible for the BA to be successful which is attributes of management including; poor attitudes to change; incompetence; a lack of vision and management level politics. So should the BA be held accountable for not creating a silk purse from a sow's ear?
The introduction of business analysis certification (such as CBAP) is a great way to increase predictable outcomes and metrics for the quality of business analysis. The information and structure around business analysis provided by BABOK has led to an in improvement in the technical application of techniques applied by BA's, but what impact if any has this had on project outcomes? Apparently very little.
The "Chaos Manifesto 2013: Think Big, Act Small" focuses on smaller projects and highlights the steadily upward trend in project success from 2004 to 2012. The report highlights the improved success rates achieved by smaller projects over their larger cousins, illustrating the wisdom of the adage "how do you eat an elephant?" to which "one bite at a time" is hard to argue with. The only potential downside to running a number of smaller projects instead of one larger one, is the potential for additional administrative overhead when doing multiple initiation and project close phases, though a flexible and rational PMO and/or business stakeholders can easily prevent documentation overkill.
Similarly, the industry recognition of project management as a specialist capability and a rise in professionals with such certifications is given some credit. The prevailing wisdom that great project managers are not born, but require broader business experience, study, and a structured approach, may also be due to changes in workforce dynamics and flatter organisation structures that require these people to be skilled and not just strong. But poor project management was not accused of being a significant contributor to project failure previously, definitely not to any comparable extent that requirements issues were, so why should the current crop of up-skilled PM's get specific credit and not CBAP enhanced BA's delivering improved requirements?
Along with better sized projects and improved PM's, iterative delivery and the complementary concept of living requirements receive attribution as if the approach, and not the role-holders responsible, can claim credit. Living requirements, be they in a product backlog or other form, require far more effort to identify, manage, prioritise and keep traceable than waterfalls 'fire and forget' ones. In other words, the person supposedly responsible for earlier requirements issues, the BA, now does a more difficult job and does it better.
This also overlooks the most significant philosophical requirements and project management failures of waterfall, and the fact that neither were problems of the analysts making. The waterfall BA was highly engaged by the PM at initiation and early execution, and generally had negligible continual engagement until testing and deployment. As a result of the project management methodology, the likelihood of needs changing was almost guaranteed on anything but the smallest low-risk projects - and this is irrespective of the quality of the initial requirements. All BA's I know preferred remaining close to the project, in constant liaison with their stakeholders, rather than re-assigned to other activities just when their hard work began to take shape. But this was not their decision to make.
Similarly, is there any wonder there would be significant problems with user engagement as the key point of contact disappeared just when the project commenced delivery. From the user engagement perspective, Business Analysts frequently invested significant emotional concern for their stakeholders, empathy being an important attribute of the successful BA, and took great pride designing the solution in detail from defining data models, processes, interface UX when that was part of their job. Note, skilled BA's performed this work quickly and efficiently, I do not believe having the co-located user design the interface with the Agile team was by default what solved problems with solutions not being fit-for-purpose, though this did have a positive effect.
Another issue beyond the BA's control was unless the PM could identify risks to the original requirements and re-engage the BA quickly, then there was every likelihood that work updating requirements would impact project time and budget. The BA, who was meant to be redundant during this time, suddenly re-appeared on the resource cost schedule. If the project then failed to meet the constraints, running over time or over cost while changes were investigated, analysed and incorporated, to what, or whom might the PM attribute failure? Poor risk management or contingency planning did not factor in the chaos report.
As with project managements PRINCE2 and PMI, the iiBA has defined processes, practices, attributes, capabilities and certification to specifically enhance the Business Analysts' professional value. Whilst there are new tools available to project teams to assist requirements management and traceability, this would be like attributing project management success to enterprise project management server applications.
It's a shame that those exponents of this crucial skilled role, previously so maligned as the likely culprit in project failure, are not also given credit in the ongoing improvement in project success. But then it always depends who you ask, history is written by the victor and not the scapegoat.
