Strictly speaking, the Project Manager role is largely that of a coordinator and facilitator. The PM brings together different people with various areas of expertise and orchestrates how they will work together (what they will do, how long it will take them to do it, what other pieces of work they depend upon, who depends on their work, etc.). PMs are never expected to be able to have perfect knowledge of everything done in the project. PMs should understand what each team member is producing (their "deliverables").
I majored in MIS but I don't consider myself technical. However, most of my projects have had some IT implications. In fact, most of my projects have involved implementing systems into a business.
I don't necessarily know all the technical details of HOW technology deliverables are developed; I just know THAT they need to be developed. Here's how I would go about dealing with that...
1. Ensure you know what needs to be produced by IT (do research and ASK the IT folks).
2. Talk to the person responsible for producing each IT deliverable. Have them describe (generally) the work that needs to be done. You don't have to understand all the details but you DO need to understand why it matters to your project.
3. Based on your discussion, identify a few "milestones" to indicate progress and put those on your project plan.
4. As the project progresses, talk to those responsible for the IT deliverables and ask them the same questions you would ask anyone else producing deliverables for your project (Progress? Issues? Potential issues?)
After you get a couple of these IT projects under your belt, you'll see that the same general types of IT deliverables and tasks are done for most projects. Here is a brief checklist of IT items for a project:
SOFTWARE - For new software that doesn't exist, gather Business Requirements, produce Technical Design Specifications, have someone program the software, ensure the software works from a technical and business perspective (Unit Test, Systems Integration Test (SIT), User Acceptance Test (UAT) are common forms of testing). Software also needs to be configured (e.g., loading branch codes for a bank). System users need to be trained (which requires needs analysis, design, develop and deliver training using training materials). (I'm basing my idea of software development on the Software Development Life Cycle (SDLC) phases.)
INTERFACES - Interfaces are the sending or receiving of data from other systems (inside or outside the company). These programs will also go through SDLC.
DATA - If your project involves getting rid of an old system and going to a new system, you will probably have to convert the data from the old system (source data) to the new system (target data). This will involve something called Data Mapping and another round of its own SDLC to build the programs that will convert the data from one system to the other (called "Extract Transform Load (ETL)" programs).
TECHNICAL ENVIRONMENT(S) - The software will need to exist in a network environment. Businesses have what they call a "Production Environment" where they do business. Since Production is what really matters, you don't want to do any training or testing in Production. Rather, it may be a good idea to have another dedicated technical environment specifically for Testing (the Test Environment) and/or Training (the Training Environment). The technical environment that the programmers use is typically called the "Development Environment" (or DEV). When the software goes from Version 1.0 to Version 2.0 (for example), that software needs to be "migrated" from one environment to the other. For example, the programmers work on Version 2.0 in DEV. When they're finished and it's ready to be tested, someone "migrates" the Version 2.0 code to the Test Environment. After it's thoroughly tested, it's migrated to Production (or maybe to an intermediary "Staging" environment). Again, you don't need to know HOW they do this; you just need to know THAT they're doing this.
SYSTEM ADMINISTRATION - After the system is installed, someone (or several people) need to be responsible for the "care and feeding" of the system (e.g., technical jobs that need to be scheduled and run; User IDs set up for new hires, etc.). The Information Technology Infrastructure Library (ITIL) is a great set of IT processes to use as a checklist.
HARDWARE - Your project may involve upgrading all or part of a user's hardware.
Take the job as a PM and read up on the basics of IT, the SDLC (and other development methodologies), ITIL, etc. No one will expect you to be an IT genius as a PM. Just learn all the different aspects of IT and you'll be fine.
Good luck!