Emil Waszkowski
Head of Strategy
You’ve prepared a product specification, you’ve chosen a software house and signed a contract — it’s time to start the cooperation. Setting cooperative objectives, expectations and rules at the beginning of a project will ensure that the supplier’s team will essentially become a part of your organisation, which is especially important in remote cooperation.
Before we start, make sure you have chosen a proper company. If you haven’t done it yet, read our earlier entries: how to write a project brief and how to choose a software house . Exactly in this order.
Each project should be started with “having a vision of its complete version in mind”. It doesn’t mean you have to imagine every function of the product, but you should know what you want to achieve. Without setting the objectives the team won’t know what to focus on and what to head for. Let us assume that your company is a furniture manufacturer and wants to create a mobile application that employs Augmented Reality. There are several areas for which you should specify your goals:
Setting objectives in these areas will cause that every action in the project will be done with those goals in mind.
It’s important that everyone knows their role and what each team member is responsible for. Following positions should appear in every IT project:
Product Owner — the most important person in the project, responsible for the final success. PO defines the vision and business objectives of the product, as well as the requirements, prioritises the product backlog and connects all stakeholders with the development team. She/he should be involved with the project on a regular basis. Product Owner is a so-called Single Point of Contact who answers software house’s questions and makes decisions. This person's availability is crucial for the smooth project implementation.
Project Manager — a person who coordinates the work of the software house. She/he ensures good communication, proper planning, manages the backlog and monitors the progress and the budget. PM will help you transform a vision into a product, will specify what is technically possible, and what is not. They will suggest the best solutions to a given problem.
Tech Leader — is responsible for the system architecture and managing the technical team.
Setting the objectives alone is not enough if you don’t have a plan how to achieve them. Therefore you should create a roadmap with your team. In other words — a product development plan.
A roadmap should include the so-called milestones, which are the most important events that sum up reaching a given project phase. In case of IT products these usually include a prototype, MVP, and a fully featured product. It is good to specify high-level product functions at each milestone. A simplified roadmap of our application will look like that:
In big projects it is good to specify the MVP scope. Its functionalities should cover 50-60% of the final product. This is a phase when a product has basic features and you can launch it into the market.
While planning, don’t forget to define available resources and time. Ask yourself two questions — when do I want to launch a product and what is my budget? Give this information to the Project Manager and she/he will plan the development process to achieve your goals.
Communication is a very important aspect of an effective cooperation between a customer and a software development company. Learn about mutual expectations at the very beginning and set the rules e.g. plan weekly meetings where you and team members discuss progress and decide on next priorities.
To make the work more efficient use project management tools such as Jira, Trello, Redmine, Asana, etc. remember to also use a chat software (Slack, Hipchat), so the developers can discuss their doubts and share their ideas on a daily basis. Remember that chat is just an extra tool and it shouldn’t replace the ticketing system (it can distract the team when overused).
Your tool list should include:
We recommend you use Agile Methodology, especially when a project is large and not well-specified. Project implementation based on Scrum is divided into sprints. Each sprint should begin with the analysis and creating the so-called sprint backlog, which is a list of features or scenarios that need to be implemented during the sprint.
Then, the designing, programming and testing process begins. To make the work smooth, the team gets together for their daily stand-ups, short meetings arranged to inform everyone about what’s going on. If you want to, you should be allowed to take part in these meetings.
The result of two weeks of work is a new version of a tested and working product, clearly defined at the beginning of the sprint. Each iteration ends with a so-called sprint review, during which the project manager presents the effects and then you discuss them together.
Require up-to-date documentation available to all team members. It helps you avoid time-consuming, costly and unnecessary confusion. Make sure that backlog, user stories, diagrams, task boards, and processes are available for the entire team and everyone is on the same page. Documentation is the best way to record what part of the work is done and all the product specifics. Having everything written down can help you evaluate the project.
Open communication and treating the software house team like your own is one of the most important elements of a successful project. Remember that you’re all playing in one team and your joint objective is to create the best possible product, therefore be transparent: share the challenges, problems, goals and ideas. Thanks to their technical knowledge the team will give you best solutions to given problems or explain how to implement an idea. They will also tell you what can’t be done due to technical reasons and what can be done better than you thought. You should also demand transparency from the team. Project Manager, developers or testers shouldn’t make important decisions or changes without consulting them with you.
Assessment of project risks needs to be deep, detailed, realistic and should be managed. You should come up with a risk register with an action plan to moderate each significant risk. Then discuss your risk plan with team members and all the project stakeholders.
Knowing what action you will take in case of a problem is a great stress reducer for the entire team and the stakeholders. The benefits of risk management in your project are huge. You can save a lot of money if you deal with uncertain events with a proactive approach.
In the context of open communication — make the team aware that they should communicate possible problems and doubts immediately. If Project Manager sees that burning rate is not the same as expected, she/he should inform you about it immediately and propose a suitable solution.
This is how we have come to the point when we discuss the issue of controlling the most important indicators of any project — time, budget and quality. Project Manager is a person who is responsible for that. At the end of each sprint you should receive a report that will review which parts of the plan were completed, taking the above indicators into consideration. At the end of the sprint, when you receive the next version of a product, check whether all new functions are operational. After all, you don’t want to show a non-functional product to the board, the investor or potential users.
Every subsequent project is a valuable learning opportunity. Review every stage of the project and analyse its different components. Remember not to focus only on the successes — the best lessons come from failures. The lessons you learn from each project will help you minimise future failures.
Assess initial project goals in terms of value for the end-user, target time and budget, value for organisation, the project quality and team performance.
Don’t forget about gathering feedback from each team member. It helps you become a better Product Owner and leader in the future.
Have a vision which you will convey to others, be proactive and lead by example. You are a Product Owner and a person ultimately responsible for meeting targets. You are shaping a product and software house should be flexible to a feasible extent in order to be able to adapt to your needs. If, for example, you don’t like how a certain team member works, just ask if there is a way to replace them.
Listen to customers and stakeholders, but try to do as much decision making as possible. When the decision making chain in your organisation gets longer and longer, you won’t manage to deliver the product within the target time.
We’ve created over 100 digital products for clients as well as for ourselves. In some projects we played the role of a Product Owner and in other ones we provided advice to a client and monitored product development. Remember that your IT supplier should go with you through all the above points, perhaps except for the last one, although, if a software house won’t confirm to some of the other points, assertively remind them who’s in charge. If you have any questions, write to us !
I.Franke - Head of Advisory
K.Borowiec - Business Development Manager
I.Franke - Head of Advisory
J.Dogadalski - Business Development Lead
