Guides & Checklists
A new IT director's first ninety days: a checklist
A checklist for a newly appointed agency IT leader covering people, systems, contracts, security, work already in flight, and setting direction.
Use this checklist if you have just been appointed to lead technology at a state or local agency, whether promoted from within or hired from outside. It covers the first three months, when you have the most latitude to ask basic questions and the least institutional memory.
Each item below is written as a statement you can mark yes, no, or not applicable, followed by what to do when the answer is no. A useful result at ninety days is not a finished transformation. It is an accurate picture of what the agency runs, who depends on it, what is already committed, and where the serious risks sit.
Start with people and expectations
- You have a written understanding of what your appointing authority expects. If you do not, ask what success would look like a year from now, write the answer down, and send it back for confirmation.
- You have met individually with everyone who reports to you. Ask what they do, what gets in the way, and what they would fix. If the team is too large to cover in ninety days, meet each supervisor and a sample of staff from every unit, and keep a list of the units you have not reached.
- You have a list of systems that only one person can administer or restore. If you do not, ask each supervisor which systems have a single qualified person, then assign a second person to document the work and shadow it.
- You have met the department heads whose work depends on your systems. If any of them has stopped bringing work to IT, ask what they bought or built instead, and add it to the inventory described below.
- You have read the labor agreements that cover your staff. They govern classification, hiring, scheduling, on-call pay, and discipline. If you have not read them, ask human resources for the current agreements and for a briefing before you propose any change to duties or structure.
Inventory systems, contracts, and spending
- You have an application inventory that names a business owner for every system. It should record hosting, data classification, integrations, and support status. If no inventory exists, build a first version from vendor payment records, network discovery, and department interviews, and correct it as you learn more.
- You know which products are past the vendor support date. If any are, treat them as items that need funding and a replacement or extension decision, not as backlog entries.
- You have one renewal calendar covering software, hardware maintenance, and connectivity contracts. Renewal dates set when a contract can be changed or renegotiated and when money has to be in a budget. If dates are held by individual departments, collect them into a calendar you maintain, and ask purchasing for the notice period on each contract.
- You know how much of your operating budget is already committed. Separate recurring maintenance, licensing, and connectivity from funds you can direct. If you cannot tell, ask finance for a full year of technology expenditures by vendor and account code and reconcile it against the renewal calendar.
- You know which systems, licenses, and positions are paid for with grant funds. Grant funded items carry procurement conditions, reporting duties, and end dates set by the award. If no one can tell you, ask the grants or finance staff for the award documents and add each end date to the renewal calendar.
- You know where technology is bought outside the IT budget. If you do not, ask finance for payments to technology vendors charged to other departments. The aim at this stage is visibility and a security review, not taking the contracts over.
Verify the security and continuity basics
- Multifactor authentication is enforced for email, remote access, and administrative accounts. If enforcement is partial or unverified, get a list of accounts without it and attach a remediation plan with dates to your assessment.
- You have watched a restore, not only read a backup report. Ask for a test restore of a system the agency cannot operate without, and be present for it. If no one can produce a successful restore, schedule one and set dates for documented tests of the remaining critical systems.
- Your incident response plan names roles, says who declares an incident, and has a contact list you have checked. It should also say who notifies leadership, counsel, insurers, and any outside parties the agency is required to notify. If the plan is missing or lists people who have left, correct the contact list first, then schedule a tabletop exercise.
- You know which legal and contractual requirements apply to the agency's data. Criminal justice information, health information, federal tax information, payment card data, and student records each carry their own rules, some statutory and some contractual. If no one can tell you which apply, ask each department what data it handles and confirm the answer with counsel.
- You know whether retention settings on the tools staff actually use match the approved records retention schedule. Email, chat, text messages, and collaboration platforms can hold public records. If the settings do not match the schedule, or no one can produce the schedule, involve the records officer and counsel before changing any setting, because a change can destroy records the agency is required to keep.
Take stock of the work already in flight
- You have a list of active projects showing the business sponsor, status, amount spent, and amount still committed. If a project has no sponsor outside IT, record that as a finding and ask who will speak for the business need.
- You know the acceptance milestones and the payment schedule on each major implementation. If payments are ahead of accepted functionality, review the contract with purchasing and counsel before approving the next invoice.
- You have a recommendation for every active project: continue, change the scope, or stop. If a project is continuing because no one is willing to end it, gather the contract terms, the amount spent, and the cost to finish, and take the decision to your appointing authority.
- You have reviewed service desk volume by category and by department. Repeating ticket types usually point at a cause that can be fixed once. If the data is not being captured, set up categories now and review the results after a full reporting period.
- You know whether public-facing digital services have been assessed for accessibility. State and local government services are subject to federal disability law, and federal rules covering public entities and federally funded programs point to the Web Content Accessibility Guidelines as the measure. If no assessment exists, ask counsel which requirements and deadlines apply to your agency, then commission an assessment starting with the most used services.
Set direction before the ninety days end
- You have written a short assessment of what you found. Keep it factual, leave individual blame out of it, and give it to your own team before the governing body sees it. If you cannot support a statement with a document or a named source, take it out.
- You have a prioritized plan for the coming year with an owner and a rough cost for each item. If every item is marked a priority, rank them anyway and state which ones you are not attempting this year and why.
- There is an agreed way for departments to request technology work and see how it is ranked. If no governance group exists, or one exists but has stopped meeting, propose a charter that names the members and the chair, sets a meeting schedule, and says how requests are submitted.
- You know the budget calendar and what your next request has to contain. Submission dates and formats are set by finance and are rarely flexible. If the request is due before your assessment is finished, submit what you can support and note what may follow in a mid-year adjustment.
- You have completed one improvement that staff can see. If nothing comes to mind, ask the service desk which complaint they hear most often and fix that.
What to do with the results
Mark each item yes, no, or not applicable. Sort every no into three groups: risks that need action this quarter, items that belong in the next budget request, and matters to revisit later. Give every item in the first group a named owner and a date. Present the assessment, the plan, and the budget implications together, so the tradeoffs are visible in one place.
HQT provides technology advisory and systems engineering services, including assessments of the kind this checklist describes.
Frequently asked questions
Should a new IT director make changes during the first ninety days, or only observe?
Act right away on anything that presents an active risk, such as administrative accounts without multifactor authentication, backups that have never been restored, or an incident response contact list full of people who have left. Hold structural changes, including reorganization and vendor consolidation, until you have read the labor agreements, know what the budget already commits, and understand how the systems depend on each other. Completing one visible fix early also makes the longer work easier to explain.
What if the agency has no current documentation of its systems?
This is common, particularly after a long vacancy or a retirement. Build a first inventory from vendor payment records, network discovery, and conversations with department staff, and expect the first version to be wrong in places. Assign a named business owner to each entry and correct the inventory as you go rather than treating it as a one-time deliverable.
How should I handle a troubled project I inherited?
Establish the facts before forming a position: the contract scope, the acceptance milestones, what has been paid, and who the business sponsor is. Bring purchasing and counsel in before changing the pace of work or withholding a payment, since the contract governs what the agency can do. Present the options and their consequences to your appointing authority rather than defending or abandoning a decision you did not make.
What belongs in the ninety-day report to the appointing authority?
Keep it short and write it for a reader who is not technical. Cover what you found, the risks that need action this quarter, the priorities for the coming year, and the budget implications of each. Presenting the findings and the funding request together lets the reader see the tradeoffs in one place.
Who should sit on a technology governance group?
Include business representatives from the departments that depend most on agency systems, plus finance, and the records or legal function when retention and disclosure questions come up. The group needs a chair with the authority to decide, a published way for departments to submit requests, and a regular meeting schedule. Without those three elements it becomes a status meeting rather than a body that sets priorities.