Taming the Feature Creep Wildfire Freedom from Surprises Newsletter July 2007 In This Issue News Reality of Feature Creep Taming the Wildfire Quick Links Visit Our Website Downloads IC Coaching Blog Press Releases Questions Dear Jeff,   Scope expansion, scope change, feature creep, requirements update; these all carry the same meaning - something is different today than it was yesterday and your project direction "may" now be headed down a different path. My personal favorite term for unplanned changes on a project is "feature creep" because it exemplifies the need for a continuous watch for the possible redirection. Skillfully managing a possible modification in features is the main component of a team that is considered to predictably execute on projects. This newsletter is dedicated to mitigating the impact of ever evolving requirements to your projects. Jeff Jorvig, IC Design Process Coach JCI News All of our quick start products are now available as instant downloads. Check out our product lineup here. New checklist is now available for download. Click here for details. New lower base price on our Analog Design Guide, now just $249. Take our seminar survey here and save $50 on our Analog Design Guide download. Check out the Six Simple Rules of Managing IC Design in our blog. If you visit, please do leave your comments. Need a clone of yourself? Watch for our Virtual Design Manager product offering in the coming weeks. Feature Creep is a Reality - Know it's Personality I prefer the term "feature creep" to signify the need to keep a continuous watch for possible feature changes that are constantly on the horizon of any project. Feature expansion is a normal, healthy and expected part of any project. It should not be perceived as wildfire that must be snuffed out, but more of a controlled burn that needs to be planned, guided and monitored. While appreciating the benefits of feature creep you must also be conscious of the project impact in cases where changes are not managed to the crisp degree that is crucial. Scope changes are likely to be masked from different disciplines of the product development team, depending on the source of the change. If the potential change is not properly communicated its "real" impact (cost, schedule, risk) will not be properly assessed and the team will be confused about the scope of their individual tasks. The wildfire will be set free. Beware of the "no brainer" or "it will just take me an hour" changes. These are insidious given that they appear benign hence are easily bought into by a small subset of the overall team. "Simple changes" also have a greater likelihood of being masked from the overall team. Project impact is glossed over and the change becomes a reality while having a yet unknown, although possibly significant impact to the project or another team member. No brainer changes are kindling for the feature creep wildfire. Where do changes come from? This must be understood so the lookout in the fire tower has the knowledge of where to be keeping a watch for flare ups. There are multiple sources of potential changes for any project. The most well known point of origin is from the customer. Also bear in mind that the source of change may be from design, test engineering, product engineering, marketing and even the business itself. The lookout must keep a broad watch across all of these potential sources of ignition. Taming the Feature Creep Wildfire Broad awareness of a potential change and a crisply communicated disposition of the change keep the feature creep wildfire tamed. To cultivate the proper mindset, take into account that there are rarely benign changes, only under scoped changes. Strive for thorough disclosure of impact to schedule, cost, die size and the decision to proceed or not will be properly nourished. Crisply communicate to the entire team the inclusion or rejection of a proposed change. The decision about whether to proceed with a requested change must never originate from a single point. A committee made up of broad discipline members must decide the outcome of potential changes based on the proper information being supplied to them out of the feature scoping process. The committee must take this information and consider the overall product opportunity and how this change might enhance the market appeal vs. total project impact. The final decision about a change is a process with multiple assessment points based on continually expanding information about the proposed scope modification. The feature request may bring no discernable advantage to the product or it may be one that positively sets the product apart from others and add months to the schedule. It may offer a significant cost reduction (die size, test) or greatly increase cost while brining a significantly higher ASP. The feature creep matrix is complex and requires a broad view to drive the best decision for the business, one that can only be provided via a multi-disciplined decision team. It is in designs best interest to force formality in a change process. Without a process in place, design is left defending project delays introduced by unmanaged changes. Design must pushback on any behind the scene change requests to elevate awareness and insure alignment of the change to the business strategy. Failure of design to drive feature change requests back to the business will result in uncontrolled/undocumented project slips that will be perceived as a failure in design project execution. Unmanaged feature requests will allow the wildfire to consume the projects ability to predictably execute.