In today’s uncertain economic times businesses, governments, and non-profits around the globe are trying to maximize their efforts, develop innovative opportunities, and overcome difficult challenges. During this economic slump in the US some organizations are disappearing because they cannot keep up with their competition or their business costs. Businesses are looking hard at all their organizations, their processes, their information, and their policies to examine what can be reorganized, retooled, reengineered, and streamlined. Their goals are typically to slash costs, increase productivity, and increase value in their market place. One strategic tool that is tied integrally with all business opportunities and challenges is developing new technology. Management wants it done yesterday, cheaper, faster, better. Business analysis professionals need to make intelligent decisions. In our "do it now culture," let’s not throw out what we have learned over the past 30 years about software development.
Over the years developing software has often been compared to building homes. Much of the analogy works, but building software is more dynamic than building most homes where plans remain more fixed. Builders generally do not pull out all the dry wall or redo the electrical wiring from scratch because a requirement was missed. Unless something really bad is involved, homes rarely get leveled and started over. Can we say the same about software? Unfortunately not. Many software projects get scrapped on a daily basis and started over. So much time and money out the door. Failed projects make it hard to compete, and hence the need for intelligent business analysis. This leads me to repeat a mantra of several practices that I know to be essential and independent of any industry, project, or software methodology.
- Get organized with a purpose and a plan.
- Know your business.
- Develop solutions iteratively.
- Communicate clearly and frequently with stakeholders.
- Acknowledge your lessons learned and repeat again!
More about each of these practices in the business analysis world in future blog entries.
January 22nd, 2008 at 6:52 pm
Great tips! One caveat though - consider your users as stakeholders. Don't ignore them. If I were to add anything it would be just one more point - consider business value of anything you do. Don't do it because your plan says so. If your 6 month old plan has an item to implement that doesn't provide any value today or in the future, don't do it. Rajeev
January 23rd, 2008 at 10:21 am
Rajeev,
Excellent point. Excellent business analysis professionals are always thinking about how best to spend their time. Every day we should be confirming that we are working on activities that will bring the highest value to our organizations. Doing something just because it is in a plan is not a good enough reason! Barb
January 23rd, 2008 at 12:50 pm
Rajeev, Thank you for your excellent contribution. You are so right that users are very critical stakeholders to any project.
I also love your comment about business value and that is part of what I mean by “Know your business”. We should know the business drivers and value that every project brings and how it supports the strategic goals of our organization. Business Analysts should be asking these questions. The business value of of a project should be continually evaluated throughout the life of the project. This knowledge helps business analysis professionals control scope creep that does not add value and contribute to the purpose of the project. Thanks again for your comments!
January 23rd, 2008 at 8:18 pm
I used to rely on the comparison between a BA and a construction architect. I believe that most of the way of thinking is analog. The funny thing was that my company is building a huge building and my boss was really impressed with the job done by the architect responsible. He started to tell us (the BA team) that we should learn somethings with him about how to gather requirements and finish our BRDs faster. We found the idea interesting and went researching. If there's a better way of doing it, let's find it. My boss told us that it took only one and a half month for the architect to make the whole project (and it was impressive), but we found out that what he did (and what was being called the whole project) was only design what was needed for the main structure to be assembled. Now that the structure is up he's starting to focus on the details and to listen to the stakeholders. For us, there was nothing impressive in this approach. We actually consider that he risked too much designing that big structure without going a little farther on the requirements, but that's the difference, nobody will tell him to move a huge wall, it's not a software, it's concrete, they will just adapt themselves. People are harder than softwares and softer than concrete.