This month the Atlanta SPIN (software process improvement network) hosted Kevin Shaan from Borland Software. Kevin talked about requirements development and management. Kevin spent several years as an appraiser for CMM and SEI assessments. He shared his observations about major weaknesses in the organizations that he assessed. Not surprising, poor requirements management was common. He affirmed the importance of having people (whether they are called Business Analysts or Requirements Analysts or developers) trained in requirements elicitation and analysis. He saw the requirements elicitation as a real weakness in many organizations. Problems included participation from the wrong stakeholders, lack of understanding of end users ("user constituency"), and lack of a communication plan. He recommended building the requirements elicitation and management skill set. In addition he walked through the requirements components of CMMI and explained why each is so important.
It is always good to hear more confirmation on the importance of business analysis. Kevin did a great job of explaining why each CMMI component is important and that one of the most effective ways of improving our development process is to have skilled business analysis professionals.
May 18th, 2007 at 6:09 pm
CMM guidelines and requirements management best practices establish ground for the need to have sound business process re-engineering skills.
But there is usually more to it than meets the eye.
During a handful of my BA assignments in the past, I have witnessed that even if BAs apply their analysis skills to re-design the way of doing “things” in organizations (because they have perceived inefficiencies in the status quo), they may still not be able to drive the nail into its hole. The user community typically displays resentment at learning new ways of work, let alone using new systems that inculcate revised process logic.
We need some ideas and philospohy around presenting case to these users to see rationale behind doing “things” in new way(s). Please use this forum to exchange your views on how the BAs can be torchbearers of facilitating open-mindedness for embracing change .
May 21st, 2007 at 5:14 pm
As a SME on many projects and sometimes a BA, I do understand your issue. I know that for me, I find when the BA involves me in identifying the solutions or at least asks me if I have considered doing something in a different way, I'm much more likely to embrace the change. I would feel as if I were a part of the decision versus being presented with a new system and having to change my workflow.
Recently we purchased a new software package and it addressed all of my requirements. It gave me many new features that I couldn't have imagined. While it was extremely successful, it has been difficult to change the way that work is performed to use the new system. I do feel that workflow and usability should be addressed on the front end and whenever possible involve the user in developing solutions.
Usually there is a core reason that someone resists change. It may be difficult to uncover and the SME may not even be aware of what is causing it. I encourage you to watch them work and see where they are feeling frustrated. You may be able to show them just a small adjustment that will make a huge difference.
May 24th, 2007 at 11:44 am
Thanks for your views, Lyn. I am in full consonance with your perspective around encouraging “live” participation from the SME(s). But the actual issue that I faced was a bit more evolved than what my initial note on this blog may have revealed.
Let me explain my context a bit more here. I was working for an automotive supplier to re-design the user interface of their ERP application for the Purchasing wing. The chief stakeholder in this case (as I was told) was the Purchasing Manager who had a definite idea about the way he wanted the interface to look like for the Purchasing Coordinators. He was also the “SME” on this project and I set up routine sessions with him to iteratively propose design solutions/enhancements that would spruce up the UI per his(alias his department’s )needs.
In hindsight, this is exactly where the problem cropped up. The SMEs, in real cases, should have been the Purchasing Coordinators and not the Manager. Although he was the supervisor of the team, he should not have been casted as the chief stakeholder. This boils down to one dictum - Organizations needing to implement new systems should be clear and thoughtful about the human interface(s) they need to present to outside consultants(read BAs). This would go a long way in avoiding the typical change management issues that crop up in new system implementation scenarios.