Now we don’t have to battle fierce monsters or have big sword fights with enemies in our projects (well not the ones I work on), but we may still face battles of a different kind. Like understanding what the users really want, their expectations, and what can reasonably be delivered within the project’s constraints. Budget and timeframe are obvious ones, but companies often have policies and standards that can create substantial constraints. We also need to know what the current IT capabilities are, and it is critical to understand what integration is required with other systems (some of these can be real monsters; now where did I put my sword?).
A movie it tells us a story. It all starts with a script and is developed into a storyboard which blends words and pictures into scenes. The scenes must work together and flow. Much like the way we model business flow, take our requirements and write Use Cases for how a particular aspect of the system will be used, giving it context.
So how do we make sure our requirements tell a complete story - and the right story, one our users will get excited about? And users do get excited about what the requirements will deliver. We need a business analyst that can act as a director and bring all the ideas, needs and requirements together, prioritise them and, in conjunction with an architect, identify where they all fit together with existing systems and business processes.
It is important for the business analyst to find the best way to communicate and deliver his or her interpretation and analysis of the requirements to the business and all stakeholders. Like the movies we must know our audience and present the information in a way that is right for them. Requirements must also be analysed then reviewed with key business representatives and other stakeholders, from all groups involved (including IT), to ensure understanding and acceptance. We must also accept that we don’t always get it right first time and be prepared to re-work the requirements, format, models, or presentation to gain that acceptance and, in some cases, signoff.
A balance must be found between the business needs and expectations and what is practical to deliver. Plus the solution proposed must suit the purpose. There is no point having a mighty sword if you can’t lift it, just like there is no point having really sophisticated security that lets no one in.
We see from the “making of” section on DVDs, that making an animated movie is a complex process taking many years. They have a team comprising many different groups of people working together in collaboration, and using iterative processes like storyboards and other design prototypes. Obviously a movie is very visual, but it too has integration issues like bringing music and spoken dialogue together with the computer generated images.
In the end all the animation and dialogue must be complete and it must all work together with the music. If something is missing, or poorly done, the film will not deliver the excitement and fun the children (and adults) expect. Using a collaborative approach with constant reviews and good communication, and iterative builds with constant review and testing can be applied successfully to most software projects. As with our projects we must make sure the requirements are well defined and understood, that developers create new or changed applications that look and function well, and are integrated correctly with other systems and all aspects of the agreed business, legal, security, quality of service and architectural requirements have been delivered and work well together. As business analysts we need to see beyond the requirements to the final solution.
Like the line in a recent movie I saw, we must “keep moving forward” and continue to develop our skills and techniques to understand our audience better, and ensure better requirement delivery in software.
After all a requirement is only as good as the delivered functionality that results from it. That’s how to become a BA hero.
Ross Wilson is a Senior Consultant with Equinox Limited in Auckland, New Zealand, specialising in requirements management. He has been working in IT for 23 years and has a wealth of varied project experience in a number of different industries. For the last 14 years, he has focused on business analysis, project management, and team leadership. Ross can be contacted at email@example.com