Welcome to the second post in the series about IT consulting for IT vendors’ clients. The guides describe the ins and outs of cooperation at the very first stages, with tips on how to maximize impact, address possible pitfalls, and avoid IT outsourcing risks.
- Presales
- Business analysis
- Project start
During presales, you would have already outlined your general project roadmap with the vendor. By now, all the business goals, project scope, timeline, and budget are put together in a commercial proposal and clarified. Business analysis (BA) comes next, meaning it’s time to get down to the details of how exactly the software in question will be delivered.
Let’s illustrate this with an analogy. Let’s say you need a vehicle. At the presales stage, you and the vendor would decide the vehicle type to build: a bus, a train, or a plane. At the business analysis stage, you will be discussing the number of seats in the cabin, the color of its body, its engine properties, and spare parts suppliers. You’d also decide on the fuel and schedule the launch date.
It usually takes from two weeks to two months to describe the entire system and arrive at the final cost of the solution. At the end, you would have a complete software specification and a detailed breakdown of development and implementation. Although vendors bill for such business analysis services, the documentation you get as a result will be your intellectual property. That said, you can proceed with this particular vendor or take it to another one without being locked-in.
The following is our take on what to expect during business analysis in software development, and how to ensure you’re spending your budget wisely.
Define cost-cutting opportunities
The budget estimates frequently fall into certain price ranges. Therefore, it stands to reason that you, as a client, would try to stick to the lower side. It does make sense: the lesser the costs, the higher the probability that your product sees the light of day.
For this purpose, it’s recommended to look for any cost-cutting opportunities in the project specs. It will help to keep in mind your business goals defined during presales. This way, you’ll be able to tell must-haves from just nice-to-haves and focus on first-priority features.
Pick the right alternative
Sometimes, the same feature can be implemented in more than one way. For example, customer registration can be done through email or SMS confirmation. A good vendor would know how to implement both, yet the costs will be different. If the registration method is not a critical factor in your case, opt for the email option or even an out-of-the-box module, since it's cheaper. The vendor’s business analysts will help you look into such details, make the decision, and put it in the plan.
Tip: Don’t overspend on the features that have no direct impact on your business goals.
Choose an engagement model
IT business analysis can help you not only with the requirements specification and cost-cutting but also with choosing the appropriate engagement model on the project. Depending on how flexible your budget is and how detailed your project requirements are, there can be two options.
| Time & materials | Fixed price | |
|---|---|---|
| Budget flexibility | Extendable | Fixed |
| Client engagement needed | High | Low |
| Timeframe | Flexible | Fixed |
| Requirements | Changing | Fixed |
T&M: pay as you go
If the budget offers some leeway, business requirements are likely to change, and there is no final vision of the solution yet, it’s recommended to run the project in short sprints. In this case, each sprint will last as long as it’s needed to release a particular functional deliverable. It’s worth noting that this engagement model implies one general BA phase at the very beginning, as well as a chain of additional BA sessions before each sprint.
Such flexibility means you can change project requirements on the fly should your strategy or any arising factors demand it, and your team will be able to adjust to that. However, budget management gets complicated due to inherent unpredictability. Alterations to the software requirements can scale the budget both up and down, so going for the Time & Materials model would protect you from risks. You’ll be billed only for the hours and resources actually spent.
Fixed price: ultimate predictability
If you can’t afford to let the project take its natural course and want ultimate control, the Fixed Price model is the one to choose.
While you’ll know the exact cost and the list of what you get for this money, you will have to create detailed documentation for every small tweak to the software. And that all will have to happen before the project even starts. You won’t be alone in that, though—the vendor’s business analyst, technical specialist, and project manager will sit down with you to compile all the business requirements and propose solutions.
It’s the heart of business analysis services—to help you arrive at a clear and comprehensive picture of what you need and how to address those needs technologically. The vendor’s team will help you specify every minute detail and put it down in the documentation to ensure that you’ll get exactly what you envision.
As a result, you will get a complete system specification, a technical solution, and a project plan. These critical documents will contain all the details that the vendor needs to know to name the final price: implementation and system integration methods, design briefs, licenses to obtain, and more.
Armed with this information, you can go ahead and negotiate with investors or finalize the budget. Under this engagement model, the cost of the project will not change, but it will be difficult to alter project aspects on the go without changing the budget.
Tip: T&M is for experiments; fixed price is for thorough preliminary planning.
Visualize and test your idea
Sometimes, it’s not enough to have just a plan and estimations to kick off the project. Some clients need to see how their systems will look in reality; others want to check the validity of their ideas. Everyone has requests of different complexity, and it’s business analysts’ task to ensure each of them is feasible and won’t cause any trouble technology-wise later.
To help our clients visualize and validate their projects before they start, we at Itransition deliver a few options of tangible—and testable—prototypes.
Business analysis services and prototype design
Sometimes during the BA stage, the client needs the final design of the entire system. This is frequently the case on mobile development projects, where the look and feel greatly affects the costs involved. Since it is much easier to estimate the project with the design finalized, business analysts call on UI designers to assist.
Below is the example of the design Itransition delivered during the BA stage on one of our past projects. Although it’s not clickable, it makes it clear how the interface will look. Thanks to this effort, we could accurately plan the workload for layout designers, while the client allocated the right amount of working time to their content managers. This is what the designed screens looked like:
A dynamic prototype
This is a rough sketch of how a client’s system will look. The business analyst will draw several screens and create transitions between them—so that you can click through those and see how user-friendly they are. But these are only mockups—no dynamic prototype solves any practical problems. It is usually needed for showing to investors or the board of directors to finalize the budget.
To illustrate this, here is a dynamic prototype we have developed for one of our customers. It features standard charts, a sample picture in the header, and some random numbers.
A functional prototype
Of all three prototype options, this one is superior in possibilities. In fact, this is already a simplified version of the system. Instead of static pictures, there is a working system with all the basic functions in place. Such a prototype is required when no one can guarantee that the system would be operational, for example, when technology is still nascent, or the idea is not trivial. This way, you can check how feasible your idea is before investing hundreds of thousands of dollars into it.
A case in support
It’s probably helpful at this point to provide a business analysis project example. A client came to Itransition with a request to automate passport checks. The process would be the following:
- A user takes a picture of their passport page with a smartphone camera.
- The system recognizes it and fills the necessary fields automatically.
Since such functionality had never been realized before, the team assumed they could quickly run into issues. As a response to this challenge, the team created a technical prototype, and, as expected, the system did work poorly due to technological limitations. Laminated passport pages produced glares, fields were not recognized properly, and those in charge of checking passports had to struggle. As a result, the client decided to drop the project.
At all times, business analysis consulting services accompany prototype development and designing. While the business analyst is discussing the project plan with the client, the designer is sketching out the screens of the system based on the information received. It’s fine to give a vendor a heads up if you need a prototype, yet you would still need to have more than just a rough idea to make it work.
Tip: Ask the vendor for all the artifacts you need before the project starts.
Collaborating with business analytics vendors
At the BA stage, you will need to answer numerous questions about your business and internal systems for the vendor’s team to get the complete picture. The exact amount of time depends on how big the project is and how clear the requirements are. To be on the safe side, it’s recommended to allocate at least one or two person-hours a day on the client’s part.
This time will be spent on finding answers to the business analyst’s questions, making decisions, and communicating with the key team members. The flow of this process can be illustrated the following way:
In this two-day loop, the vendor and the client are exchanging questions and answers, going back and forth to each other to clarify how to address the project challenges best. Setting this routine of “a meeting a day” is sufficient to keep BA at a steady and productive pace.
It helps to have all the required team roles covered on the vendor’s side to assist during IT business analysis. The following ones are especially instrumental in decision making, so arranging their presence at BA meetings is highly recommended:
- Product owner—a person who knows why this project is important for business and how the software is supposed to deliver on business needs. They are also the ones to choose the solution to build among a pool of proposed variants.
- Technical specialist—a person who can guide the vendor in how the client’s internal systems work and answer all the technical questions.
It’s very effective to arrange such meetings with the business analyst and the technical specialist both in the same room with all the project stakeholders. Following this pattern, it will be possible to address any pressing challenges in just a week or two of intense discussions and avoid spending extra efforts on ping-pong communication.
Tip: Allocate at least two hours a day on collaborating with the BA team.
Business analysis consulting services are done. What’s next?
Once the requirements specification is approved, prototypes are validated, and collaboration details are settled, it’s time to move on and actually launch the project.
By now, you as a client would have completed all the required preparatory steps to equip you with a clear and thorough vision of the software you’re looking for. Yet, there is still much work to be done in terms of getting to know your team and infusing them with the collaborative spirit. Find tips on how to do that successfully in our last post in this series.
