One more feature please ...

How can you get discipline to not have feature creep? How can you decide when it is appropriate to change your plans to accommodate a request? What can you do if your business depends on accommodating feature requests?

In many ways this goes back to the discussion about how important predictability is to your company. As I have said before, I believe it is paramount. It is how your sales folks know what they can sell and how customers can know what to expect and depend on it. Predictability as a priority allows your employees to stay focused and feel accomplished.

Unfortunately, we know the technology world changes quickly. Here are some basics you must do to even have a discussion about change later:

• Have an approved budget
• Have an approved roadmap
• Have a release definition and approval process

Once you have these things, then you can put in an exception or variation process. Without them, your developers and company will experience unpredictability and chaos.

You should develop an exception process that looks at the following:

• The business case for doing the feature
• The development cost for doing a feature
• The other things doing this feature will affect like schedule or resources or customer expectation
• Executive signoff

The major thing is to make a premeditated decision. There are almost always tradeoffs and your company needs good information in order to make those tradeoffs. Good executives will help make sure the right decision is made and minimize the number of exceptions they will entertain.

If you find that you are experiencing a lot of feature requests because of customer requirements or industry requirements, then you may have to firewall resources to handle them. Think top-down. How much of your development resource do you want to dedicate to handling these kind of requests? Allocate them and use managerial courage to not allocate anyone else. If you always dip into all of our resources, you will never accomplish the less tactical and more strategic goals. Get agreement from the stake holders like sales or professional services on the allocation. If this still does not meet the needs of the business, you may have to rethink your business model.

Change is good. Constant change is not.

More later ...

What can you do about over-commitment?

I just heard a fellow on NPR talk about his book called Results : Keep What's Good, Fix What's Wrong, and Unlock Great Performance. His name was Bruce Pasternick. Someone called in and asked him about the increased workload in the corporate world today. He pointed out that employees have been taking issue with this forever.

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 ...