Basic IT Project Methodology Checklist

Which methodology is best? For your project, the best methodology is the one that provides structure in a common-sense way with simple, easy-to-use tools. A methodology encompasses both the sequential steps to a project, and the documents used (tools) to manage the different events in the life of a project.

The checklist below explains the steps of a typical IT project methodology, along with a description and the tools used for each.

In each step, check out “How You Can Lose / How You Can Win” to learn how you can be drawn into the money pit, and how to dodge the pit and win instead.

▢1. Current and Future Process Definition

IN LAYMAN’S TERMS: How things work today and how you see them working after you implement the software. Do this before you commit to a system!

TOOLS USED: Process flow diagrams created in flowcharting software, PowerPoint or on flipcharts.

HOW YOU CAN LOSE / HOW TO WIN: Often this is not done in enough detail, or is not done at all. Insist that it be done with great specificity.

▢2. Business Requirements Definition

IN LAYMAN’S TERMS: Exactly what you want the software to do, in each specific business scenario. Do this before you commit to a system!

TOOLS USED: Excel document with columns for business process, functional requirement, explanation, and priority level.

HOW YOU CAN LOSE / HOW TO WIN: Often not complete, or allowed to grow as the project advances. Freeze the requirements at some point. Recognize and stop wish lists.

▢3. Gap Analysis

IN LAYMAN’S TERMS: Comparing what you want the software to do with what it can actually do, and documenting the ‘gaps.’ These include integrations to other systems. Do this before you commit to a system!

TOOLS USED: The same Excel document used for Business Requirements, with additional columns for “Fit – Yes/No,” “Resolution” and “Workaround.”

HOW YOU CAN LOSE / HOW TO WIN: Failure to fully investigate the software’s capabilities leads to overly optimistic fit evaluations. Winners do this step before they buy the software.

▢4. Gap Resolution, or “Gap Killing”

IN LAYMAN’S TERMS: Deciding what to do about every instance where the software doesn’t do what you want it to do, which means either you live with the gap, work around it somehow, or spend the money to modify the software to your exact needs. Determine the cost of modifications before you commit to a system!

TOOLS USED: This is completed in the “Resolution” and “Workaround” columns of the Gap Analysis.

HOW YOU CAN LOSE / HOW TO WIN: Balance is needed here. Modifications cost money. Question your process first. High-priority developments should be for customer and total company reasons, not convenience or ease of use.

▢5. Development or “Build”

IN LAYMAN’S TERMS: Program the changes into the software that will close the functionality gaps.

TOOLS USED: A very specific technical design document is needed here, usually Word and Excel.

HOW YOU CAN LOSE / HOW TO WIN: The usual pitfall is that this is not specific enough or that specs do not accurately reflect the business requirement. To win, limit the modifications and don’t make the software do something it was not designed for.

▢6. Configure Test Environment

IN LAYMAN’S TERMS: Put a test copy of the software, including the changes you’ve made, on a server and set it up as if you were going to use it in your business.

TOOLS USED: A simple Excel list of all the data fields required by the new system and what you will put in those fields.

HOW YOU CAN LOSE / HOW TO WIN: Can take way longer than expected, because people haven’t made decisions on what data to put in each field. Winners hammer out master data, parameters and settings during the gap analysis or earlier.

▢7. Unit Testing

IN LAYMAN’S TERMS: Mostly a test of the basic functions of the software to make sure all the setups and integrations are working.

TOOLS USED: A tracking spreadsheet.

HOW YOU CAN LOSE / HOW TO WIN: Modifications from developers that still have technical glitches. Condition developer payment on quality and timeliness of work. Insist that developers work in your time zone.

▢8. User Acceptance Testing

IN LAYMAN’S TERMS: Full testing of the software by people who will use it, performing transactions just like they would do in their everyday work.

TOOLS USED: A list in Excel of all the testing scenarios with corresponding columns for test results (pass/fail), dates, user name, transaction document number.

HOW YOU CAN LOSE / HOW TO WIN: Incomplete list of test scenarios = surprises later on that the software doesn’t do what you expect. Have a wide range of users sign off on the scenarios to be tested. Don’t forget the exceptions – deleting a sales order, incorrect master data, etc.

▢9. Training

IN LAYMAN’S TERMS: Complete hands-on training for everyone who will use the new system.

TOOLS USED: Complete standard operating procedures and step-wise instructions on all transactions, plus quick reference guides.

HOW YOU CAN LOSE / HOW TO WIN: People are casual about the training, but after Go Live need lots of support. The only truly effective training is on the job in real-world conditions. Insist that a group of users participate in the testing phase.

▢10. Go Live Prep and Business Continuity Plan (BCP)

IN LAYMAN’S TERMS: This is defined in a detailed hour-by-hour illustration of events that describe shifting the business from the old system to the new system. Includes uploading master data and all pending transactions into the new system; also includes plans to recover from failure.

TOOLS USED: A punch list in Excel of all tasks needed for go live prep, plus a depiction (PowerPoint or other) of each day or day part showing the sequence of required events.

HOW YOU CAN LOSE / HOW TO WIN: The danger here is that this work is not done with enough forethought or detail – or isn’t done at all. Business failures during Go Live add to project costs because of inadequate planning for system backups. Make sure you can still run the business even if the whole thing falls apart.

▢11. Go Live

IN LAYMAN’S TERMS: The cutover from the old system to the new system. Usually on a weekend or holiday when the business doesn’t need the system.

TOOLS USED: A record of the number of planned transactions and the number of actual successful transactions. An Excel log of issues or problems that arise with planned actions to resolve.

HOW YOU CAN LOSE / HOW TO WIN: Not enough support people in two areas: 1) system experts to help users; and 2) backup employees for those who are distracted or slowed down by learning the new system. Staff up for several weeks.