Why is Business Analysis and Systems Engineering Important?

From the start every business needs either a Business Analyst or Systems Engineer. One of the main reasons for this is that we ensure that there is a comprehensible translation between the needs of management and the needs of the various departments of the business. This is true regardless of the size of the enterprise. Without some normalization of vocabulary, communications of the needs and requirements will be spotty at best. Over the remained of this article, I will attempt to present some examples of this in order to illustrate the point.First we will look at Sven, who has developed a new game called Blastoid. Blastoid, when it originally launched was a PC game which would allow the user to send rockets and people to asteroids and mine them for metals and other resources. When Sven released it he used the popular github to publish it and the game was fairly simple, however the game was an instant hit and had over a million downloads in short order. Due to this success Sven decided to form a company and actually market upgrades and other DLC to users. As the game matured, the company grew and Sven had to bring in managers, marketing, developers, administrators and everything else that goes with a having a successful software company.

Now it when Blastoid had fully matured, it became obvious that they would need to issue a new game as the followup. So the management team got together and began to brainstorm about what the followup would look and feel like. Out of these brainstorming sessions came a set of things that they wanted to have in the new game, things like Reality Based Physics, Virtual Reality, Online Co-operative play, an entire economics system modeled on real world economies, etc. Once the brainstorming sessions concluded, the management felt that they had the bones of a very cool game and turned over the resulting sheet of desires to the developers so that they could create it. They also needed it in six months.

As time went on, though the developers worked as best as they could, the new game fell further and further behind the determined schedule, excitement from the players of Blastoid began to loose interest in the follow-on. Forums which had been created for the game began to quiet when details about what the follow-on would be were released, the level of fan disappointment was very high. What was being produced was not anything like what they thought they would be getting. Eventually, no enthusiasm within the user community and the cost of the new game growing to more than the company could support and Sven was forced to close his business.

As is evident from this scenario without proper management of project scope and expectations the end of any enterprise can come swiftly. Most businesses are not of a size that they can absorb a failure such as experienced by Sven and his company. This is where a Business Analyst can provide the communication translations between management and the other stakeholders of any project.

Lets backup to where Sven and the company management are planning the follow-on game for Blastiod. They have their brainstorming sessions but before the end they bring in a Business Analyst. As they assemble their lists of things that they want to see in the game, the Business Analyst begins to break these items down into their respective parts. These parts are things that can actually be built, one piece at a time. The parts, requirements for what the project needs, are listed and relationships between them are build. The budget is discussed with leadership and a schedule is developed. As a part of this process, the other stakeholders are consulted and after some negotiation it is determined which requirements are must haves and which are nice to have or will have to wait for a future update. Finally, a release is planned, based on feed back from a larger group of stakeholders.

Throughout the process the communication is facilitated and overseen by the Business Analyst. By ensuring that each department or stakeholder is spoken to in terminology which they understand, it prevents over promising. This way the schedule is kept and the project is completed on time. Having the requirements adequately defined, it will also prevent scope creep (the addition of items that seem like a good thing but will not fit into the release schedule from being added).

By managing each piece within its own scope within the schedule, the follow-on game is released on time and budget making it every bit a successful as the original Blastiod. Developers are happy to know exactly what they are to build, administrators are happy that they know exactly how much they will have to manage, marketers are happy to have a product which will be delivered on schedule and most importantly the customer have something to be excited about.