Editor's//Comment
Feature Creep, Stage Left
By David Riggs
Every now and then I get involved in community theater. Not acting, but rather in the stage band or as some unexpected, non-traditional musical addition. For instance, I played bluegrass fiddle in several productions of Woody Guthrie s American Song, electric fiddle in a rock band for Return to the Forbidden Planet, Gypsy fiddle in Othello, and, most recently, Celtic fiddle in A Midsummer Night s Dream.
My participation was the brainchild of the director, Luther Hanson, who meticulously planned and communicated how he wanted each play performed. As an outsider, it was interesting to watch the progress of each show as the acting, staging, sets, costumes, lighting, and music evolved. But in the course of rehearsals, and sometimes even during performances, I noticed a similarity between these stage productions and the development projects many of you undertake: feature creep (the act of adding bells and whistles to the detriment of the original design goals). In the stage productions it came by way of the actors adding actions, gestures, and, sometimes, even words to the original script. Indeed, sometimes a role calls for improvisation. And granted, sometimes they were clever additions. But the danger on stage is that, if you add unexpected bits, you risk disrupting your fellow actors, or you add too much time to the length of the show, or you detract from the playwright s intent. Everything on stage happens for a reason, and it must be well planned and well executed.
This same phenomenon can happen with development projects. You start with a set of requirements and before you know it, you re halfway through the project when the client or worse, your boss wants to add this cool feature or that new feature, without giving any thought to schedules, budgets, or ramifications to overall functionality. And we all know how that makes you feel. It is much easier to complete a project from start to finish than to have to make amendments, whether reasonable or not, after you ve started. You had a game plan for a reason; probably because the goals were realistic and attainable. In a worst case scenario, you could end up with a project that is overdue, over budget, and, quite possibly, dysfunctional. And we all know how that makes your boss feel.
I may be preaching to the choir, but stick to your guns stick to the script. Much like the director of a play, the project manager must methodically set parameters, guidelines, goals, and deadlines. Certainly you can be flexible, but you must be reasonable about your flexibility. Besides, you can always add features in the next rev.
Thanks for reading.
David Riggs is editor-in-chief of asp.netPRO and its companion e-newsletter, asp.netNOW. Reach him at mailto:[email protected].
