The Internet boom and follow-on Tech bust may make you feel like the problem is worse today. Do things on Internet time with less people. The squeeze is on. Large companies play catch up and leap frog quicker with competitors. Small companies get led around by customers for new features and products. Your employees either get burnt out or ignore the pressure and work to the level that meets there abilities like water seeking it's own level.
The results are unhappy customers with missed expectations and unhappy employees with little in the way of sanity or home life. Is there a way to do it all and within budget? Is there a way to retain your humanity along the way? There are good solutions to this issue and like all good solutions everyone will have to compromise.
It is all back to basics. Here are the steps to avoid over-commitments:
- Create a budget
- Get buy-in from product management, sales and support
- Instill development hygiene
- Handle surprises and requests
As a manager, your first job with the highest priority is to get a budget in place with a proposed set of deliverables. Your team has to develop estimates. Everyone hates to develop estimates, but you cannot do planning without them. Divide the work into external work that the customer sees directly and sales cares about and internal work that has to be done to keep the infrastructure going. Prioritize the projects with product management. Make sure you account for ongoing maintenance.
Plan regular frequent, smaller releases instead of larger releases with a lot of features. Large releases are hard to integrate and requirements often change during their development which often leads to delays.
Balance internal and external work in your releases. If you do not have some balance, your company will fail. You need features to meet customer demands and be competitive. You also need the basis and infrastructure to scale and extend your product.
Once you have a budget and plan for releases, you must get buy-in. I favor actual signatures by key stakeholders on the executive staff. Nothing like a signature to make people pay attention. Both the overall plan and individual release plans need approval. Often, you will find last minute intense discussions when you hit this step.
Now you have a budget. Go to work. All of the things you learned now come into play. PRDs, design specifications, architecture, code reviews, automated testing, adequate integration cycles, design patterns, coding conventions, well-defined APIs, detailed schedules, documentation, diagnosability, etc. Pay now or pay later. You can streamline processes and procedures but skipping them will cost you more time in the end.
Finally, the hardest item. What happens when you get a critical new unplanned requirement? What happens when you find a bug in the field that requires unplanned effort from your best resources? This is where many plans fall apart. You need a mechanism to evaluate and approve any changes. You only have four areas you can adjust: resources, schedule, features, quality. If you go back to the same area each time you have a change, your company will fail.
Make sure the business case for fixing a bug or doing a new feature make sense. Make sure the change is weighed against the other work you are doing. Get creative: bring in contractors, find bridge solutions, look at third party solutions, employ swat team efforts, learn how to say no, learn how to sell what you have, etc. Don't start work on a new feature until it is clear how you can afford it.
Don't assume you can just add one more thing your development team has to do without some other change to the equation. Especially when it is the third, fourth, or fifth change! Don't get caught in just saying yes. In the end your customers will suffer will late or low quality products and therefore your company will suffer with lost reputation or sales.
Use these basic steps and you will manage your commitments.
More later ...
