| captureplanning.com | Learn about proposal writing and business development |
|
How to get the most out of our web site:
CapturePlanning.com is a huge resource for learning about business development and how to win proposals.
Fill in the box below so we can keep you up-to-date with the latest best practices for winning more business.
|
A new way to look at processI recently worked on a project for a company that wanted to formalize it’s product roll-out process. They were having problems with out-of-control development resulting in products that didn’t meet market needs. They sought salvation in a process that would ensure that the offering definition met the needs of the target market segment and that during development information would flow from the developers to those responsible for implement, marketing, sales, etc., at the appropriate times in order for everyone to be prepared at product launch. It seemed that a little bit of data and work flow analysis could make a tremendous improvement. Then they encountered the difference between process and reality. The process assumed starting at the beginning, so you couldn’t apply it to the current workload. And you could never define the process in enough detail to prevent it from behind botched, either by well meaning people who didn’t understand what to do or by opportunistic people looking to short-circuit as many steps as possible. As more and more effort went into defining the process, whether to include this or that, or whether to document it using these symbols or those, it became clear that process charts weren’t what they needed at all. The process called for specific deliverables containing specific information to be prepared for specific milestones. The theory is to ensure that information needed by the next step is prepared in the prior step and delivered in a specific format. But the reality is that information is developed and refined over the life of the project. You go back and add to or change things. You work with information that is incomplete but sufficient. And a lot of effort went into creating deliverables that people didn’t need (even if they did need the information contained within them, they didn't need the deliverable itself). Then their was the issue of speed, in an organization whose staffing grew by 300% in one year and was on the bleeding edge of technological change. The process environment would change between the start and end of the project. The alternative we developed was to stop looking at process and the flow of deliverables at milestones and instead look at it as a series of goals and standards to be met. Instead of requiring a market segmentation plan containing specific information in a specific format, we required that product managers show who the offering would be sold to and what the potential sales were. While it could be in any formation, this information had to meet certain standards, that could change depending on the circumstances (market size, whether the market/channels are already established, size of investment required, which business lines are involved, etc). Someone (typically a business line manager or executive) was in put in charge of deciding whether the standards had been met in order to continue. The devil is in the details, but looking at a process as a series of goals and standards instead of manufacturing steps enabled us to better adapt to the changing environment. It kept the team focused on doing what was truly needed, as opposed to what the process said they had to do (or how they could short circuit it). Managers were judging whether standards were met instead of evaluating deliverables by weight. The truth is that any process can be corrupted, and this approach is no different. But getting people thinking about what the best way is to achieve project goals and what standards should used to judge progress may be a better way of looking at how they do business for some organizations than flow charts.
Return the Favor!
Show the author of this article some love and appreciation by posting a link to it or emailing a friend and telling them about it. Thanks!
|
|
|
Copyright © 2007. Please review the Terms of Use prior to copying or distributing. |
|