Blogs

I have been involved in systems development for the purpose of information management for over 35 years and one thing has remained constant – feature creep. I’m not sure when people realized it, but well before I started working they learned how project approval works:

If you ask for everything you want up front, your project will never be approved. If you add requirements during development and say “we can’t use the system without this,” you’re golden.

Feature creep blows up budgets, extends deadlines and pushes every other project further down the line. Feature creep hobbles IT by leaving them vulnerable to attack from all sides. Eventually, when the feature-creeping users have to be told “no more” they complain that IT is unresponsive to their needs. Meanwhile, the users-in-waiting are looking elsewhere for support. I’m not suggesting that most IT departments are without fault, but I’ve rarely worked on a project that didn’t miss a deadline due to features being added in during development. When I worked at Weyerhaeuser, my boss was fond of saying: “I spell deadline with a capital DEAD” as a way of discouraging feature creep. However, the uber-sophisticated systems development management process included a change-control process that allowed features to be added, deadlines to be moved and projects to remain on time and under budget.

Feature creep in SharePoint is both a huge problem and a wonderful thing. We start projects that are designed to support a specific business process. During the course of development, someone realizes that the information wrapped-up in that process is useful for other things, in support of other processes, providing greater insight into the larger picture, and we are asked to expand the scope of the project. That’s great! That means that people are beginning to understand the power of information. They’re getting the message, they’re connecting the dots, the nickel is dropping into the slot and…they are killing my budget.

What’s an IT Guy to do?

Simple, the IT guy has to be smarter. I think I just heard a collective groan from the community of my peers, but it’s true, we have to be smarter. We have to realize at the outset of a project that the results we are tasked with creating will have value elsewhere. We have to think about the ways in which the data we are collecting and storing could be related to the business processes in other departments. In addition, we have to realize how that data could be used if consumed differently. I might be working on a system to support a purely in-house operation, but I have to think about the guy on the road (to see one of our customers). What if I could give him a portion of that data on his iPad? Five years ago, if I had asked that guy if he would be interested in a view of this data, he would have said “no.” That’s because the data would have been available to him in the office, where it would be easier for him to simply ask the people who own the data. He didn’t have an iPad five years ago. His requirements are changing because they can change and I have to anticipate that change.

I have argued in the past that “just because we can do something doesn’t mean that we should do something.” That’s still true, but today it has to be coupled with “just because there’s never been a need for something, doesn’t mean there isn’t a need for it today.” If we think about the broader uses of information as we design systems, we can build better systems. Of course we will be expanding our projects up front, instead of as-we-go, but it’s usually way easier to build things in in the first place than it is to shoehorn them in later. It’s not a runaway train if we scheduled a stop beyond our first destination.