The IT Project Success Playbook: IT project management services for Twin Cities companies

Why IT projects fail in the middle, not at the end

A 140 person distributor in the north metro approved a Microsoft 365 migration project in January. By April it was "mostly done." By September it had a weekly status meeting, a budget line and no momentum, and the engineer who owned it was back on the help desk queue full time. Nobody cancelled it. Nobody finished it either. That is how most technology projects fail at companies with 25 to 500 employees across Minneapolis and St. Paul: not with a crash, but with a slow fade into phase two.

The research is unusually consistent on this. The Project Management Institute's Pulse of the Profession 2020 found 11.4% of project investment is wasted through poor project performance. The 2018 edition found 52% of projects experience scope creep, up from 43% five years earlier. McKinsey and the University of Oxford studied large IT projects and found an average budget overrun of 45%, delivering 56% less value than planned. Oxford researchers Flyvbjerg and Budzier, writing in Harvard Business Review, found one in six IT projects becomes a "black swan" with a 200% cost overrun.

Here is the encouraging part. Almost none of those failures were caused by technology that did not work. They were caused by nobody owning the decision, the scope growing, a dependency surprising everyone in week six, a team that had a day job, or three vendors each assuming another one was handling it. Every one of those has a fix, and most of the fixes are decisions rather than purchases. Professional services from Solution Builders in Bloomington are built around those fixes, and this article walks through them the way we do with clients.

The five stalls and the early warning for each

A stalled project still has a budget, a team and a weekly status meeting. What it no longer has is momentum. Each of the five patterns below shows up early, usually between weeks four and eight, and each has a specific owner who can fix it.

1. Unclear ownershipThree people can say no and nobody can say yes. Decisions wait for a meeting, the meeting waits for a calendar, and the schedule quietly absorbs the delay.
2. Scope creepEvery "while we are in there" adds a week. Without written change control, the project you approved and the project being built drift a little further apart every sprint.
3. Dependency surprisesThe new system needs a firewall rule, a license true up, a data cleanup or a vendor API nobody checked. Each one surfaces exactly when it blocks the critical path.
4. Part time project teamsYour best engineer owns the project and the help desk queue. The queue always wins, because the queue is loud and the project is patient.
5. Vendor handoffsThe software vendor, the carrier and your IT partner each deliver their piece. The gaps between the pieces belong to nobody, right up until go live weekend.

Every stall announces itself. The announcements just do not look like problems yet.

One question predicts the outcome before kickoff: who can say yes to a scope change, and who hears first when a dependency slips? If those are two different people, or two different meetings, you have found the first stall before it happens. There can only be one accountable person per decision. Two is zero.

How to scope so there are no surprises

Surprises are not random. They are assumptions nobody wrote down. Most scopes are feature lists copied from a vendor proposal. A useful scope is three lists: what the project will deliver, what has to be true for that to happen, and what is still unknown, with a name and a date next to it. PMI found 37% of executives name unclear objectives as the top cause of project failure, which is another way of saying the first list was never written in business language.

1. Discovery, days one to fiveWalk the environment, interview the people who do the work, and inventory every system the project touches. Count users, licenses, integrations and the data that has to move.
2. Requirements, in business languageWrite what the business must be able to do, not which product does it. "Payroll closes by noon on Friday" beats "migrate the payroll server" every time.
3. The assumptions logEvery "we think" goes on a list with an owner and a date to confirm it. Unconfirmed assumptions are where the surprises live, so confirm the scary ones first.
4. Change control, agreed before kickoffDecide how a change is requested, priced and approved before anyone needs one. One form, one approver, one answer within 48 hours.

Here is an assumptions log one week into a network refresh project at an 85 workstation manufacturer with a plant in Greater Minnesota and a sales office in the metro.

Three of five confirmed in week one, and the circuit assumption was wrong. On a feature list that discovery happens on cutover weekend when the file sync crawls. On an assumptions log it happens on a Tuesday, when a circuit upgrade is a purchase order instead of a crisis. The project plan tells you what should happen. The assumptions log tells you where it will not. Review it weekly.

Small scopes land, grand ones drift

The strongest predictor of success is size. The Standish Group's CHAOS Report found 61% of small projects deliver on time, on budget and with a satisfactory result, against 6% of the largest. That is a tenfold difference, and it is the reason a Microsoft 365 migration project should be three phases of a quarter each rather than one eighteen month epic.

• Ninety days or less from kickoff to a result people can use. If it is longer, split it.
• One owner who can approve scope, spend and schedule changes without convening a committee.
• One measurable outcome, written down before kickoff, so "done" is not a matter of opinion.

Then send every change through the same door at the same price. Nobody creeps scope on purpose. It happens because saying yes is free in the moment and expensive in month four. The change request fits on one page: what changes, in business terms; why now, which separates must have from nice to have; the cost and schedule impact, priced by the delivery team and never guessed by the requester; what gets dropped, because scope is a budget; and who approved it, the single named sponsor. Requested at hour zero, priced by hour four, decided by hour 24, scheduled by hour 48. The baseline moves once, not forever.

In house vs on demand expertise: the real math

Every project needs people who have done this exact thing before. The question is whether you grow them, borrow them or hire them. The internal option looks free because nobody writes a check. It is not. Count the hours, the help desk coverage you lose, the learning curve on a product your team will touch once, and the delay. Then compare it with someone who has done it fifty times.

The figures are illustrative, from Solution Builders project reviews of a typical 85 user infrastructure project. Your numbers will differ. The pattern will not. The expensive line item is not the salary. It is the 26 weeks the business waits for the result.

On demand expertise is not outsourcing your team. Write knowledge transfer into the scope: as built documentation before the final invoice, a recorded walkthrough of every admin task, credentials in your vault from day one, two weeks of shadowing and a runbook for the three most likely failures. That is how an 85 user manufacturer finished a full transformation in 90 days, eliminated 100+ hours of monthly downtime and cut tickets 60%, with its own IT lead still in charge. The same bench runs cloud migration projects and the ongoing version of the arrangement, Co-Managed IT, for internal teams across the Twin Cities.

The go live checklist: 24 items, or move the date

Go live is where a project meets the people it was for. A clean one feels boring: the system works on Monday, the help desk is quiet and the project team goes home on time. Boring is the product of a checklist that starts fourteen days before cutover, not the Friday before. The ITIC 2024 Hourly Cost of Downtime Survey found more than 90% of midsize and large enterprises put an hour of downtime above $300,000, which is why the last two weeks are for freezing, rehearsing and deciding rather than building.

Two weeks out

• Acceptance criteria signed by the sponsor, in numbers: "every user sends and receives on the new platform by 8 a.m. Monday," not "email works."
• Scope frozen. Anything new goes to phase two, in writing, with a smile.
• Every open assumption confirmed or escalated. The log should be empty or red.
• Rollback plan written, with a trigger in numbers, a decision owner reachable all weekend and a time limit.
• Communications drafted: the announcement, the day of instructions and the "we rolled back" note.

One week out

• Full dry run of the cutover runbook, timed, with every step logged. Rollback rehearsed once, end to end.
• Pilot group of five to ten real users on the new system for three working days.
• Backups of every affected system verified by an actual restore, not a green checkmark.
• Go or no go meeting on the calendar, with the checklist as the only agenda item.

Cutover and hypercare

• Runbook open: one person reads steps aloud, one does them, one logs the times. Point of no return announced out loud.
• Smoke test by five real users before the all clear. Old system left running, read only, until hypercare ends.
• Two weeks of hypercare: project engineers on point with a 30 minute response target, a daily 15 minute standup with the sponsor, acceptance criteria measured on days three, seven and fourteen.
• As built documentation and the runbook delivered, then a formal handover and a one page lessons learned.

IT project management services in the Twin Cities: what to do next

Three moves for the project on your desk right now, and none of them require a purchase.

1. Name the AFor scope, budget, cutover date and acceptance, write one name next to each. If any line has two names or none, that is where the project will stall.
2. Start the assumptions logSpend 30 minutes with the team listing every "we think" in the plan. Give each one an owner and a date. Confirm the three scariest this week.
3. Get an outside readA Project Scoping Session with Solution Builders is a free 30 minute conversation. Bring the project, leave with a clearer scope and the first three assumptions to confirm, whether or not you ever work with us.

A project with no single owner is not late yet. It is just early in the process of becoming late.Solution Builders Professional Services

Solution Builders has delivered technology projects for Minnesota businesses from Bloomington since 1995. Professional Services is the I in our RISE framework, Integrated: 50+ engineers, senior project leads, fixed scopes, a rehearsed cutover and two weeks of hypercare, with a 98% client satisfaction score measured on every ticket. If the project on your desk is a move to the cloud, the Smart Cloud Migration Playbook covers the specifics.