How to Start Projects with IT Vendors. Part 2: Analysis

27.11.2017
7 min.
title

Me and my colleagues from Itransition have prepared a series of blog posts about what happens at first stages of any IT project and how to behave if you are a client. These tips are great for working with any IT vendor:

  1. Pre-sale;
  2. Analysis;
  3. Start of the project;

At the last stage, you and the vendor outlined a general roadmap of what to do. During the current stage it is necessary to figure out the details: what exactly you want done, who will do it and how. Let’s say that you need transportation. At the pre-sale stage you and the vendor decide what it will be: a bus, a train or a plane. At the analysis phase you will discuss how many seats the cabin will have and what color its body will be, what properties the engine will have and where you will order the necessary parts from. You will also choose fuel and schedule the date of the first trip.

To describe the entire system and name the exact cost of development it usually takes from two weeks to two months. In the end, you will have a complete specification, technical solution and detailed plan to start the project with this or any other vendor. You pay for this phase, but its results are your property.

Here’s what to do to ensure you are not pouring money down the drain.

Define areas where you can save money

Let's say that after the presale stage, the vendor will say: “This will cost you three to five buckets of money.” In my experience, customers are more often inclined to see the final cost to be closer to three buckets, rather than to five. And I fully support this position: the less money you need to release a product, the more likely it is to see the light of day and make our world a little better. But outlining the areas where you can save should always be done keeping in mind your business goals.

The same features can be implemented in different ways. For example, customer registration can be done by email or by an SMS confirmation. A good vendor knows how to realize both, but the cost will be different. If the registration method is not a critical factor in your case, opt for the email option or even use an out-of-the-box module — it's cheaper. The SMS registration option will cost you more, so state it explicitly during the analysis phase and include it in the plan.

Just like at the presale stage, first of all you should align your features with your business goals — maybe you don’t need registration at all. The analysis phase is the time when you and the vendor decide what aspects you cannot save on.

Don’t overspend on aspects that don’t affect your business goals

Choose an engagement model

Depending on how you allocate the budget and what system requirements you have, there may be two directions project management can take.

If the budget offers some leeway, business requirements will change and there is no final vision of the system yet, then it’s better to do the whole project in short sprints. The duration of a sprint is chosen in a way so you can finish a particular part of the system on time. Then you proceed to the next part and finish it again in one sprint. In fact, with such project organization you will have one general analysis phase at the very beginning of the project and a bunch of mini ones during the course of the project – before each sprint.

Let's return to our transportation analogy. Imagine that at the general analysis phase you decide that it will be an airplane, but with beds instead of seats. If the idea with beds suddenly turns out to be bad, and it's better to go for the chairs instead, with the concession that they are wider, then you will realize it problem-free together with the vendor when it comes to the sprint with the chairs.

Changing requirements to fit business needs on the fly is pretty impressive, but budget management in such conditions is very difficult. Most likely, with all these alterations, you won’t even notice the budget ballooning 10 or even 30%. For such conditions, the Time & Materials engagement model will work best – you will pay only as much as you really need.

If you need to know the exact cost and a list of what you get for this money, you will have to create detailed documentation for every small tweak to the system. Before the start of the project the business analyst, technical specialist and project manager will grill you for business requirements (what to do) and propose solutions (how to do it).

That’s the situation where you know exactly what kind of aircraft you want, right up to the color of the seat upholstery. The vendor will thoroughly interrogate you on every detail of the plane and make sure that you really need a plane, not a train. Then you will have to choose a particular engine, fuselage, anchorage, number of portholes, etc., making decisions on every little aspect that gives you exactly the end result you have envisioned.

As a result, you will have a complete system specification, a technical solution and a project plan. Now the vendor knows how this will be implemented, has a rough design idea, understands how integration with other systems will work and will be able to name the exact cost of the project. Armed with this information, you can go ahead and negotiate with investors or finalize the budget and say: "Guys, I need $131,638 and this money will be spent on this and that, the projected result is such and such." This engagement model is called fixed price – the cost of the project will not change, but it will be difficult to alter project aspects on the go without changing the budget.

T&M is for experiments, fixed price is for planning

Think about what else you might need

Sometimes a plan and an evaluation are not enough. Some clients need to see how the system will look; others want to check the validity of the idea. Everyone has different requests, and a good vendor will do everything at the analysis phase to make sure you are not wasting money. Here is what we most often do for clients at this phase, in addition to the analysis itself.

A dynamic prototype

This is a rough sketch of how the system will look. The analyst will draw several screens and create transitions between them – you can click through those and estimate how user-friendly they are. But these are only mockups – no dynamic prototype solves any practical problems. It is usually needed to show 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, but you can click the tabs. Try it for yourself at our demo host.

Dynamic prototype of a BI system
Data and design might still change, but the work logic will remain

Design

At times during the analysis phase, the client needs the final design of the entire system. This is particularly useful on mobile development projects, where the look greatly affects the cost. It is much easier to evaluate the entire project when the design is finalized.

And here is the design that we did at the analysis phase. You can’t click here, but still at the phase of analysis it is clear what the system will look like: we were able to accurately plan the workload of layout designers, and the client did the same for content managers. Look at the screens below, as an example:

Mobile design example: appointment scheduler
Mobile design example: chat

Functional prototype

This is a simplified version of the system. Instead of static pictures you have a working system with all the basic functions. Such a prototype is needed when no one can guarantee that the system is operational taking into account the current level of technology. In this way you check your idea before investing hundreds of thousands of dollars into it.

A client came to us with a request to automate passport checks: you take a picture of a passport page on your smartphone, and the system recognizes it and fills the necessary fields itself. Since this has never been realized before, we assumed we’d quickly run into issues. We created a technical prototype, and as expected, the system worked poorly due to technological limitations. The laminated pages gave a flashback, the fields were not recognized well, the clerks had to struggle. As a result, the client decided not to develop the project further.

Prototypes and design are done simultaneously with analysis – while the manager is discussing the project plan with you, the designer is sketching out the screens of the system based on the information you gave the analyst. So if you need a prototype or something else, then just tell the vendor about it. However, to make it work, you also have to do your homework.

Ask the vendor for all artifacts you need at the project start

Allocate time

At the analysis phase, you will have to answer a lot of questions about your business and internal systems. It’s hard to say exactly how much time it will take – it all depends on project size and how unclear the requirements are. Allocate roughly one to two man-hours a day to do your part of the deal.

This time will go to finding answers to the business analyst’s questions, making decisions and corresponding with key team members. Usually, we have lengthy discussions with the client at the beginning of the day, and then think it all over: the client is looking for answers to our questions, and we come up with ways to implement the client's requirements. The next day, the cycle is repeated: we offer solutions and ask questions, and the client either answers them or redirects us to a person who has the answers.

To make this process painless, schedule a time in your own calendar and the calendars of the responsible parties from your team. To make decisions at this phase, you will need the following people, at the very least:

  • Product Owner — a person who knows why this project is important for business, how everything should work, and who can choose an option that’s most suitable for business from a pool of proposed variants.
  • Technical specialist — a person who will tell us how your internal systems work and answer all our technical questions.

An even more effective way to do this is to for the analyst and technical specialist to sit down in the same room with all the responsible parties from your side: in a week or two of intense discussions all the key issues will be solved on the spot. All the vendor needs to do is prepare documents and ask clarifying questions. In this way you don’t waste time on correspondence and get distracted by other tasks. If you can afford this, it's the best option.

Minimal plan: one-two hours a day on a project

What’s next

If you have time left, show the results of the analysis phase to another vendor – in case you have missed something or your initial vendor took a wrong turn somewhere. If there is no time, you can start the project right away. Learn how to do it well in our next article.

Tags: