Things that could kill your outsourced IT Project
— Written by
If you are a customer to a consulting company, you need to let go of these practices to make sure that you get the best product out.
Things have changed already in the industry. People are well aware of the rapid release cycles, technological changes and the way agile development is happening these days. And these changes are good, since you get to see things very clearly in real-life without having to plan months before you execute them.
Scoping is the most important thing that dominates the entire lifecycle of a consulting engagement. Having a rigid scope might put the entire project under huge risk. Let’s be honest, nobody knows anything solidly when they start out to work on an idea from scratch. And even if they have a solid idea and workflow structured, it is going to go down for four iterations as the product is being built.
A scope is just a prediction about what could go into the product to set it’s milestones. Being flexible with the scope (either scaling the scope down or increasing it) will go a long way when it comes to building a product that will work with your users. Once your product hits a critical mass, your users will be the one setting the scope for your product and not you necessarily.
Micromanagement is demotivating, frustrating and not good for anyone who is being micromanaged. Empowering people is super crucial for any manager or a leader. Micromanaging Project Managers think that they have hit the result, but all that they are left with, is a bunch of frustrated team members looking to take a bit of you when they get a chance.
Meetings are important. And I’m not talking about the closed room meetings alone. I’m talking about the small meetings that you might have with your consulting company through different means. It is very important to record everything that you communicate with your counterpart. This prevents all the miscommunication that could arise down the line.
We’ve seen people maintain numerous documentation for one single product, and a reference document to know which document to refer to when in need. This is bad. The last thing you would want to spend time on is to maintain multiple documents, instead of focusing on what really matters for the end-user.
Maintaining one single document for one product is the best way to go about it. That will be a transparent reference point for the entire team and will also have everyone aligned to one single north star.
This is literally the mammoth task of everything leading to deadline slippage. Over planning and overly thinking about risk management causes delay in delivery. And involving the development team in planning meetings is literally a crime.
Planning in small increments or from one milestone to the other is very efficient. This allows everyone to focus in small iterations and learn from its complexities rather than to aim for the big one and learn one big expensive lesson.
These are the learnings from some of the experiences we’ve had working with customers across the world. We believe this will help you or your counterpart work better together. And hey, talk to us if you need to build something great.
Up nextI was bored and I made a bot