Suppose you join a small nonprofit organization with one office.  As the new IT person, you decide to build a software application to help the office to work more efficiently.  Everyone is anxious to see your results, so you push through the requirements gathering stage and come up with a reasonably good solution.  Your colleagues are pleased.  Management praises your work and all is well.

A short time later, your organization decides to open a second office, which has a different business focus than the first location.  But they ask if you can adapt your application for their needs, saying that they would like to go live in a month.  You try to get specific details about what they would like to see in the new system, but everyone is frantically busy and you end up having to make certain assumptions to revise the application for their needs.  But you push forward, and somehow are able to finish by the deadline.  Again, everyone is pleased.  Management again applauds your efforts.

Before you can savor your latest success, the first office asks if you can add some reports to the application which they hadn’t included in the original specifications.  (You had asked about reports, but were told that they would deal with that later.)  When reviewing their request, you realize that much of this information isn’t collected by the application, so you have to go back and revise some screens before creating the new reports.  And because of the tight deadline, you don’t have time to develop a front end interface to run the reports, but you say that’s OK because as the IT person, you can run them when requested.

You roll out the new reports and application changes, but then realize that your edits have broken something that is used by the first office.  So you need to go back and tweak the code a bit more and do more testing so that the application will work properly for both locations.  Due to some personnel changes at both locations, you also realize that you need to schedule user training.  And when they ask for user documentation, you realize that this was not done due to the rush to get things finished.

Eventually, your nonprofit keeps growing, and so does the use of your application was you originally designed for one office.  You keep making modifications, but these changes end up making the code increasingly complex.  (When you hire a new programmer to help you, it takes him months to figure out how everything works.)

Now your small application is in use by over 10 offices, all which use it a bit differently.  You’re now getting many requests for user support, and your tech support team can’t always help because they don’t fully understand how the application works.  When you speak to users from some of the earliest opened offices, you find out that many have established parallel systems in Excel and Access to handle situations that your software can’t accommodate.  Apparently, the business needs of your offices have changed so much that your application will need to be redesigned.

Finally you decide to have a meeting where you invite representatives from all of your offices to discuss what to do next.  Everyone says that their needs are unique and that they should receive special priority.  Many staff seem happy to continue using their personal spreadsheets and databases since it allows them to more easily manipulate and report on their data.  But your research department, which is trying to prepare organization wide reports to show the effectiveness of your work, is increasingly frustrated, saying that the data that they pull from your application is no longer accurate.

What to do next?  My recommendations:

1. Evaluate hosted solutions.  Unless your business need is very unusual, there’s probably something else out there that will meet at least 75% of your needs.
2. Look for the commonality between your offices’ work.  Even if you do end up having to build something yourself, there’s probably much functionality that will work for all.
3. Decide up front what reports will be needed, and in what format.  Give users the ability to manage their own data, otherwise they’ll again be tempted to enter data again in a parallel system.
4. Find out how other nonprofits of your type are handling similar requirements.  You may be able to learn from others’ experiences.
5. Sometimes you will need to say no when you don’t have the time to do the job right, or if you’re not getting the cooperation from stakeholders in defining requirements.  Better to be unpopular in the short run than to be blamed later for a system which doesn’t work as expected.
6. Use agile project management techniques to focus on short term deliverables.  This will allow you to more effectively respond to changing organization needs
7. Provide ongoing training for both new and experienced staff members.  Most systems aren’t easy enough for people to easily ‘figure out’ how they work
8. Get top management support, especially when you have to remind colleagues that not every request for program customizations can be handled.