One of the biggest problems of modern software development is making technical specifications fit business expectations. This is a crucial task if it is necessary to implement the concepts, processes, and applications in the practical dimension effectively, despite the results have to be virtual, being software, or physically tangible, being hardware.
Business people have business goals & KPIs
Developers have technical specifications and frameworks
How does one help them meet?
We have to deal with the range of limitations such as laws of physics, boundaries in upscaling computational capacity, or technical unavailability to rewrite the applications on the go, and until we succeed to learn how to cross such restrictions, we will always deal with slight hitches in the process of software production. However, steering these limitations along with the deployment of down-to-earth business requirements as a guiding landmark is an efficient instrument to reach pay dirt.
If you know a thing or two about software project management or you have ever been engaged in the process of software production, you might be already aware of the challenges arising in front of a development team, project managers, and, indeed, – customers.
The main problem is that the idea, delivered by the client, which reflects his vision of the future product, maybe significantly transformed throughout the development process and, finally, the result may surprise the customer being completely different from what he expects to get. Besides, what is more important, the understanding of the concept, provided by the client at the first set-out, doesn’t necessarily mean it is the same as what the client means.
The oddity of such situations is demonstrated in the cartoon pictures showing how the everyday software production project looks like. In a nutshell, let’s say, the vendor understands that the customer orders a regular wooden bench for his garden, and this is where the initial concept starts being ruined:
- A project leader, tending to simplifications, understands that the client wants to get a single wooden chair instead of the bench.
- In turn, the engineer designs it more as a teeter-totter.
- The software developer creates a bench, but you can’t sit on its as it is sloping.
- At the same time, a sales executive describes it as an extremely soft lounge chair.
- Talking about the documentation of the project, we see the garden, but there is no bench at all. Regarding the helpdesk, we see the garden, and we see only a few planks. But finally, you figure out that the client didn’t mean a wooden bench – he wanted a hammock! It’s no go!
QUESTION NO. 1 TO BE CHECKED: WHETHER IT IS PRACTICAL AND FUNCTIONAL
First of all, it is necessary to determine each business need in writing and become convinced that everybody who participates in the round table discussion is capable of answering the question, whether this goal is reasonably practical. In some cases, the designated persons want to get a massive metal bench standing on the porcelain legs, or a lounge chair to be used outdoors in rainy autumn, or even a hammock that has to be installed without a single tree in the garden, and such discrepancies in the decision-making process make it clear that the team has to reassess the purposes of the task in order to define the feasibility of the project. Indeed, you can’t change the laws of physics or avoid atmospheric events. Thus, you have to analyze the unreal conditions that can’t be fulfilled and choose the most realistic scenario.
In the world of software development, the unrealistic condition may be related to the limits of computational capacity or storage volume. For example, you are launching a startup specialized in video processing as its main field of activity. Therefore, if your application has to be able to compress and store an enormous number of video files, the individual size of each of them is also too large, and this task has to be performed in the split second, it is practically impossible to do and the project can be considered to be not feasible, at least on the present stage of digital technology progress.
Another question that has to be taken into consideration is whether the application is functional. In order to evaluate the operational capacity of the product, you have to convert the list of business requirements into a range of functional opportunities. Indeed, this is not the whole story since even a perfectly completed list of functional requirements can have the opposite side – by elaborating every single functional option of the future solution you take a serious risk to distance yourself from the primary concept of the product, delivered in the customer’s request. Your operational model of the product can be incredibly productive, but it may a far cry from what your client expects to get.
Speaking about the garden bench, you can design it to be made of solid cast iron, so the wind or heavy rain won’t ruin it. Moreover, you can even integrate some sort of automatic mechanism in order to adjust the height of the bench according to the height of the person who will sit on it. You can even tack some wheels on the legs of the bench in order to make it transportable. However, after all these modifications you may leave out of account a few things having nothing in common with practicality but without which the customer can’t imagine his future bench – the material of the bench must have the romantic wooden smell and natural grain.
UNSCRAMBLE AND MAP UP THE PLAN
Compartmentalize the business requirements into a feasible plan that can be implemented by the software developers. Certainly, the process of drafting a plan will be different depending on the characteristics of the product and technologies deployed, however, the basic principle to be used in this case is pretty common – divide the business needs into separate blocks and elements, then elaborate the timetable of production of every single component and designate the personnel to execute the structured amounts of work.
The best thing is to start by solving the essential issues. If your bench has to be steady, you have to figure ours on what surface it is going to stand – concrete, asphalt, soil, or grass. Probably, it is necessary to design and develop some additional facilities, like a platform made of stone, where the bench will be placed. Or you can use the existing surface, for example, compacted soil area.
Moreover, the customer may want the bench to be fixed or to be removable. Lots of questions may arise when thinking about the functionalities and characteristics of the future product. It is recommended to deploy the concept of the Minimum Viable Product and to provide it to the client before the actual works start. After you get a response from the client, you are ready for full-scale software production.
On the other hand, if you pay lots of attention to the compartmentalizing of the business requirements, Waterfall can be your pick. However, you have to be prepared to receive a huge amount of communication and graphics when solving the task delivered by the client.
Now you are almost there. Draft a plan of the activities to be performed, including the exact timetable showing the duration of each work. At this stage, assure yourself that existing limitations such as productivity of the system or storage volume have been taken into consideration and the functionality of your product is secured even under the specified conditions.
For instance, make sure that your bench won’t be doing when it heavily rains for three months per year. Besides, it is worthwhile to keep in mind that there are other factors that may influence the feasibility of the project: for example, sudden changes in the structure of the development team are likely to lead to modification of the project performance plan, which, in turn, may require slight changing the design of the product as well.
Roasting snow in a furnace by matching the business requirements, technical specifications, and functional capabilities is a hard challenge but managing the issues of practicality and functionality allows making the first step. Obtaining a sufficient understanding of the business request, compartmentalizing the request into the administrable elements, and drawing the plan of works is a key to successfully aligning the customer’s needs and computational capacities.