What Doesn't Work: 5 Steps to Requirements Document Oblivion
AIIM’s Atle Skjekkeland recently listed five steps for producing an ECM requirements document. In the interests of full disclosure – and a small bit of fun – here’s my counterpoint to his solid recommendations, as drawn from the pages of the Big Book of ECM Blunders.
1. Avoid “paralysis by analysis” and charge full-steam ahead. Don’t do so totally without a plan, but don’t wait for every “t” to be crossed and “i” to be dotted, either. Time is money, after all, so get after it as quick as you can. And besides, people will let you know if you go off course.
2. Reality-check your suspicions as to what your ECM system should do by asking a few other people what they think too. Four or five should be plenty, especially if they come from different departments – and extra especially if they’re the department managers, who can represent the views and experiences of all the people who work for them.
3. Look at the answers you get and compare them to the ideas you already had. If they’re different, that means you’ll have to design the system to do more than you first thought, and thus will have to allow some extra time to finish the job. If they’re largely the same, that means you know exactly what’s to be done and probably don’t need any more outside input.
4. Write down everything you know about what the system needs to do and which functions are most important. Since you’re driving the project, don’t worry too much about how you structure the information or even what you call things – just be sure you know what you mean, and that you look at this document every so often to be sure you’re staying on track.
5. Now that you’ve talked to everybody and documented their input, you’re ready to start building the solution. Good luck!
Good luck, indeed. A recipe for disaster if ever there was one!
1. Avoid “paralysis by analysis” and charge full-steam ahead. Don’t do so totally without a plan, but don’t wait for every “t” to be crossed and “i” to be dotted, either. Time is money, after all, so get after it as quick as you can. And besides, people will let you know if you go off course.
2. Reality-check your suspicions as to what your ECM system should do by asking a few other people what they think too. Four or five should be plenty, especially if they come from different departments – and extra especially if they’re the department managers, who can represent the views and experiences of all the people who work for them.
3. Look at the answers you get and compare them to the ideas you already had. If they’re different, that means you’ll have to design the system to do more than you first thought, and thus will have to allow some extra time to finish the job. If they’re largely the same, that means you know exactly what’s to be done and probably don’t need any more outside input.
4. Write down everything you know about what the system needs to do and which functions are most important. Since you’re driving the project, don’t worry too much about how you structure the information or even what you call things – just be sure you know what you mean, and that you look at this document every so often to be sure you’re staying on track.
5. Now that you’ve talked to everybody and documented their input, you’re ready to start building the solution. Good luck!
Good luck, indeed. A recipe for disaster if ever there was one!
Labels: ECM, requirements
posted by Steve Weissman at
4:07 PM
|
0 Comments
