start me up!

Rod Bell explains systems analysis

To the best of my knowledge, systems analysis is what was practiced by Richard Riehle in Office Space.

I deal with the god damn customers so the engineers don't have to. I have people skills; I am good at dealing with people. Can't you understand that? What the hell is wrong with you people?

But we have to make sure we don't get the wrong idea about systems analysis from this movie. LOL

Enter Rod Bell, who explains the science of systems analysis in a simple (though LONG) list:

1. Analyst confers with and studies users.
2. Analyst documents current practices/procedures.
3. Users review analyst's documentation; questions/clarifications to ensure that users understand analyst's description of as-is.
4. Users ask for changes/additions/etc. as necessary to produce as-is document that they can sign off on.
5. Repeat analyst/user loop until users sign off on as-is description.
6. Analyst produces draft will-be using same documentation style as the as-is.
7. Analyst meets with IT *not* for detailed response, but for first-cut deal-killer objections on IT's part.
8. Analyst revises proposed will-be if and only if s/he cannot gain conditional ok from IT.
9. Analyst takes proposed will-be to users, with explanation that this is a "wish-list" will-be; there is no way to know if it will be technically feasible (though it appears to be) or too expensive or whatever, i.e., other stakeholders have not been consulted yet.
10. Users give analyst feed-back, loop through revisions if necessary, until a users sign off on proposed will-be.
11. Analyst modifies documentation, as necessary, to clarify for IT.
12. Analyst presents to IT, clarifies as necessary to ensure IT's understanding of will-be.
13. IT either accepts assignment or suggests/demands changes because it's too hard/expensive/time-consuming thus beyond anticipated scope.
14. If IT considers will-be is beyond anticipated scope, other stakeholders are consulted to see if scope can be expanded *or*, if it cannot, what reductions from user wish-will-be should be made?
15. May or may not be lots of negotiation/discussion here, if gap bewteen user-approved will-be and resource availability (or timetable) is too great. But here and only here is the place to get that straight, otherwise the PM or somebody gets blamed when it doesn't work out as expected.
16. Assuming no insuperable barriers, analyst does shuttle diplomacy between users and IT until a mutually signed-off will-be document exists. Note that this document may include specific screens, reports, user interfaces, etc., as deemed necessary by analyst to ensure the user will-be is fully understood by IT, and if IT wants to change those items, that's part of the negotiations prior to sign-off.
17. This document then drives the remainder of the project plan and schedule.

Labels: engineering, rhetoric

posted by Ron @ 3:10 PM