How to Change IT Vendor: Project Transition Plan
Once you entrust your app idea to an IT vendor, you expect it to be brought to life within the estimated period of time. Moreover, it’s absolutely natural when you have
- run the project discovery phase to get a clear vision of the final product
- approached hiring app developers with full responsibility
- paid attention to the peculiarities of your software development contract
- incorporated outsource vendor management best practices.
But what if, for some reason, the project is not progressing the way it should? Go through the above-mentioned aspects, and make sure there are no gaps. For instance, having technical competence or a tech consultant on your side is a must. Miscommunication and lack of accountability are only a couple of other possible failure causes. Once you fix them, there’s a chance to get things back on track.
And what if there are no gaps on your side? Then it’s time to move on, and give your app idea a second chance. Get your project transition plan ready and change your IT vendor.
When is it time to change your IT vendor?
Custom software engineering is a complex process, that’s why its transparency and visibility, along with team’s relevant expertise are so important. Lack of any of these factors may lead to
🚩unexpected yet repetitive breaches of commitments.
In this case you can try to decrease the project budget: slower development will give you time to see what the problem is and to figure out how to deal with it.
The larger consequences may include the following issues.
🚩Unstable software releases full of bugs, when about half of the delivered functionality doesn’t work as expected. It often signals about poor software architecture, meaning that something has gone wrong from the very beginning.
🚩Incomplete deliverables, when the app features are never fully ready on time.
Make sure you are giving regular relevant feedback, and you and the team see the issues eye to eye. It's crucial that you are an active participant of the app development process and know exactly what its state of art is. It is certainly a kind of project that you can not entrust on a turnkey basis.
If, despite the attempts to improve the software delivery, the red flags remain, it’s a downright signal to consider changing your IT vendor.
How to get ready to project transition
Take your time for planning and preparation
You may think: “What?! The deadlines have already been missed. I expected an MVP two weeks ago, and it’s not even half-ready. I’m looking for this new vendor to get my solution working asap!”
The thing is, if you don’t plan every aspect of project transition in detail, getting any improvements will be a 50/50 luck. And it’s not something one can afford when significant budget, time, success of your software solution, and, most likely, business digital transformation are at stake.
Select a new software development team wisely
Obviously, there’s no point in switching the current team of developers for another one without being sure they are more competent. Check out the outsource vendor’s Clutch profile, skill set and portfolio. Pay attention to the types of projects delivered, see if any of them resemble your current software development needs. Clients’ reviews are important as well. Feel free to contact any of the company’s former clients to learn more about cooperation with this team.
You will find more details and useful tips in the article about how to select your outsource vendor.
Follow the project transition plan
There are numerous not only technical, but also organizational aspects of app development and consulting. Neglecting just one of them may cause damaging consequences to the whole solution. Following the IT project transition plan checklist will ensure you’ve got everything covered and under control.
Gain clarity with your project!
Project transition plan: key points to consider
IT projects are unique. For instance, they may vary by industry, purpose, size. Moreover, they may be at different development stages when there is a need to hand them over from one team to another.
Regardless of the above-mentioned differences, the suggested vendor transition plan template will ensure you don’t skip anything important for the future successful development of your project. So, here are the key points to consider.
- Sensitive data management
- Create a list of sensitive data. It may include security documents, authentication certificates, servers access keys, source code, keybase, including access to App Store and Google Play Market, keys to third-party services integrations, etc.
- Make sure that the tech lead and a representative from your new IT vendor have this list, and have the ownership rights and all access keys for these data.
- At the same time, make sure that those who leave the project no longer have the access to sensitive data.
- Documentation control. Perhaps except for figma, all the documents listed below are necessary to fully understand your project and successfully proceed with its development. If any of them are missing, ask your current vendor to create them. Make sure you are the owner and have access to
- QA checklists and documented test cases
- Project-related documents created by business analyst, tech lead, project manager, including the written project requirements. Make sure that you are the business logic holder
- Output code documentation and API calls, often presented using tools like Swagger
- Database diagram
- Figma
- ❗️Change the keys and remove access rights from those who no longer work on the project.
- Transition period. For an efficient and smooth project handover, arrange the transition period with your former IT vendor. It’s understandable that, in some cases, there may be a heated relationship between you two. But it’s purely for the project’s sake if a software developer previously working on your app is available for cooperation with your new software development team, let’s say, for 1-2 hours daily during 1 month. It facilitates the transfer of knowledge greatly. This way, your new IT vendor will be able to get the answers to any technical questions regarding app implementation, and come up with the necessary improvements.
Project transition checklist
Based on the key points mentioned above, here is a comprehensive step-by-step checklist to make sure you are all set for successful project transition to the new IT vendor.
- Accept the last product increment delivered by the former team.
- Collect environment variables and authentication certificates.
- Collect all the project assets like mockups, design files, and marketing materials (e.g. Adobe XD, Figma files, etc.).
- Collect project specifications, code/architecture and QA documentation, database restructure, deployment scripts and procedures.
- Collect the root credentials for all the third-party services or ensure their ownership is transferred to you successfully.
- Change passwords to all third-party services used, and delete previous vendor’s accounts.
- Transfer all the source code root ownership to you.
- Set up an encrypted environment to store new development credentials and sensitive files:
- https://aws.amazon.com/kms/
- https://www.vaultproject.io/
- https://keybase.io/
- https://bitwarden.com/pricing/business/
- Agree on a knowledge transfer period.
- Onboard a new software development team.
Apply immediate process improvements (more details are in the next paragraph), like daily meetings, scrum hygiene, strive for clarity, precision and transparency both from your and IT vendor’s sides.
How to kickstart your app development with the new IT vendor successfully: best practices
Looking back at our experience of taking over software development projects, we have spotted some common issues our clients have faced with their former IT vendors. Here’s a list of our best practices to overcome their consequences and to prevent any complications in the future.
- Access control. Securely store the credentials to all required services in one place, like an encrypted storage. You should be the owner of all corresponding accounts. Make sure the two-factor authentication (2FA) is enabled to prevent hacking attempts.
- Demo meetings. Conduct regular demo meetings and agree upon the scope of the features beforehand.
- Work planning and reporting. The team should be able to plan work instead of getting things done sporadically. Ideally, you as the Product Owner should facilitate the planning by taking into account the interest of other stakeholders. The project manager, in their turn, should compile a weekly written report with a statement of work and hours spent.
- Project management system hygiene. Enter all the work items in your project management system (e.g. at Apiko we use Jira), and review them every week to validate their status, priority, blockers, and description.
- Requirements elicitation sessions with a Business Analyst (BA) for documenting any change requests or new features. The requirements should be documented, visualized, and approved before taking them into development.
- Design workshops. All new requirements should have design references so that developers don’t need to make UX/UI decisions on their own.
- Code commit messages. When developers upload the code they’ve written into Gitlab, they should create a meaningful message instead of something like “bug fixes”. Ideally, that message should contain the ID of the related Jira issue. Here’s an example: feat(AP-1123): Enable user to go "back" to the previous page after login (#235).
- Release notes. The software engineering team should create and post a release note in a separate communication channel (e.g. in Slack) 15 minutes before the deployment or sooner. They should clearly indicate the platform type and work items (commit messages) in the release.
- Proof of concept (PoC) and minimal viable product (MVP) development. PoC development is not a mandatory stage, but it’s often required, especially during the project handover phase. It helps to validate certain approaches, making sure the project is on the right track. And if your app has not been released yet, or needs a serious makeover, start with an MVP development. The sooner you are able to get real-life feedback from app users, the more chances you have to develop a successful solution.
- App refinement. When we at Apiko take over software development projects, in a way, we have to deal with legacy application modernization. Software architecture and IT infrastructure checks together with code refactoring are a must to set a solid foundation for your project.
Final thoughts
Planning does take time...to save you way more time, effort, budget, and to reduce software development risks and overall stress by introducing order, clarity and transparency. The introduced software transition plan is easy to apply to any app development project, and the attached checklist won’t let you skip a bit.
It’s not only the project transition itself, but also the way you organize your cooperation with the software development team that are crucial for the best outcome. Implementing the described proven best practices will certainly be a good start. Feel free to reach out if you have any questions or feel like you could use a consultation for your particular case.