And other questions you always ask when starting a project
Last time we answered some questions we frequently get prior to starting a project (you can read it here). This time we will talk about the issues that bother you when the project actually starts. We talked with one of our Project Managers, and thanks to her experience, we gathered the list of seven things clients often want to know, are unsure of or get mistaken.
Without any further ado, let’s begin!
1. Can we combine the work of two teams?
There are situations when clients have, for example, their own backend team, but need an agency to develop the frontend part of the project. Quite often they wonder if it is even possible to combine their work — and whether it will be an effective cooperation.
We are here to explain: of course, we can — whether there will be two separate teams or more, everything boils down to clear agreements at the beginning and willingness on both sides to cooperate with each other. Of course, it’s much easier when both teams work in the same methodology — and that leads us to another issue…
2. Can we combine the work of two teams with different methodologies (Agile and Waterfall)
Sometimes our clients work in different methodology than we do. We work in Agile, and to be more specific — Scrum. It happens that the other team we work with on a particular project work accordingly to Waterfall methodology. We talked about both methodologies in the previous part of the article, but basically Waterfall means working in a chronological order: first the concept, then design, development and testing, while Agile follows an incremental approach.
What happens then? Well, we have to make an effort to create a hybrid of both. It’s relatively easy when it’s only a communication hybrid, like leading the project in Scrum but creating the project plan in Waterfall. A more difficult situation occurs when we have to combine two separate tech teams, one accustomed to typically corporate processes at client’s, and Scrum-befriended developers in our office. Nevertheless, once again — clear agreements and willingness to cooperate always save the day. We are able to make things work as long as both sides are compatible and affirmative.
3. Is Time & Material a way to go?
Lots of our clients have this misconception in mind that Time & Material is an unpredictable monster that will suddenly swallow all their budget. It’s most definitely not.
T&M is a financial summary method where customers are charged for the exact amount of hours spent on a specific project and the costs of used materials. It has a lot of advantages, most significant of them being its flexibility, so important in Agile methodology. It is really great for long-term projects with dynamic requirements and when the scope of the project is not fully known from the very beginning.
Having a fixed price model is actually quite risky, especially when the scope of the project occurs to be not specified enough. Why change requests happen? Because very often in the process of estimating, the scope is not detailed enough or client is unsure about many issues. In the process, it happens quite often that either something turns out to be impossible to be done, or client changes his mind or would like to add a new functionality. Such changes are treated as a change requests (CR), and it means expanding the scope of work, which results in costs increasing. In pretty much every fixed price project, change requests happen on a daily basis and in the end it becomes clear, that the scope and budget have changed significantly. Nevertheless, clients still prefer to have their budget rigidly specified from the start.
Is there an actual reason to be afraid of T&M? First of all, it isn’t true that in T&M you have no estimation. There is one, but it is much rougher. You can, for example, determine your maximum budget.
Secondly, you agree on the hourly rate before the project even begins. When you work in Agile, you are a part of the team and therefore you are present at every sprint planning (every week, every month, as you will). Every task is estimated separately, which means that you can clearly see the price of every sprint — and even invoice every one of them.
In practice, you have a lot of control over financial issues in T&M. We give our clients access to JIRA, a tool we use to manage projects and track errors, in order to be fully transparent. Thanks to that, you can clearly see, in every single moment, how many hours every person involved has already worked, and how many hours you have “left to spend”. That gives you a great sense of control over the money flow. If you see that your budget is about to end, you can decide whether you stop the project, make it simpler or maybe look for funding.
The more unconventional, personalized things you are doing, the more use you find in T&M. Once again, you are the part of the team now — we have a common goal.
4. Why do we suggest another technology?
Sometimes things change. The project that was meant to be simple succeeded so rapidly that now you want to expand it and create something bigger out of it. You want some new features and functionalities — but the technology in which the app was created is simply not enough. It can not support your needs anymore and that is the harsh truth.
In this case, we may suggest you to rewrite the whole application in another technology. It is not an easy decision, so we will consider it carefully. We will talk about advantages and disadvantages of such decision, about features we can move to the new version of the app, define what will change, what we will be able to add, how it will convert into money, and so on. If we are developing a project from scratch, we always advise you to settle on a technology that will assure you with great scalability, instead of a temporary solution that only ends up being a fancy facade. Unless you want something very cheap very fast — but then we make sure you are aware of the consequences.
Another case is when customers want to expand and build the same app in another technology — they have Android and want iOS as well, or the other way around. It’s not just an “update” or “additional feature” then, but a whole new project, developed in another technology, by another team, and with corresponding costs involved. It’s important to keep that in mind.
5. Why do applications need to be maintained?
We talked about it in one of our previous articles — maintaining is caring. It’s important to understand that the process of maintenance isn’t about sitting and watching the grass grow. It is the continuous control, checking, trying, changing, receiving feedback and reacting to it.
One of the aspects which cannot be stressed enough is the initial testing. Clients do not always realise how essential is their feedback in the first weeks. Before the product is officially launched, the client is obliged to test it, report every encountered problem and inform about any observation or opinion he/she has.
Of course, the agency has a whole team responsible for QA and testing — an extremely important but time-consuming and sometimes really frustrating process of finding any errors in the product. Later on, the client also tests the app on testing servers in order to see if everything meets the expectations. Our process of QA is inscribed into the standard of our services. That’s just the way we create software — solid QA is an obligatory part of it.
However, there is a difference between testing environment and real world. You can’t predict everything, especially when it comes to Android — there are simply too many devices with it and too many versions of its operating system. That’s why initial testing, that comes right after, is so crucial. Nothing will go to the final production and distribution without the client’s official approval. Of course, the agency is responsible for fixing any bugs that are found during the established maintenance phase, but many of them can simply be avoided thanks to aforementioned solid initial manual testing.
