Skip to content
Home » The Raw Truth: Software Projects from Start to Finish

The Raw Truth: Software Projects from Start to Finish

I love software projects.

For all the focus on the technology, a lot of the job ends up being about people and expectations.

And while every project is different, after you’ve done enough of them you start to see the same phases coming around again. Maybe not exactly the same, but close enough.

1. The ‘Prequel’ Phase

Long before a project formally reaches you, people will have been talking about it. Maybe there was a meeting. Maybe it was just a few conversations.

If you can get involved early, great. You’ll pick up some useful context.

But the bigger thing to be aware of is this: by the time the project formally reaches you, someone senior may already think the clock started weeks ago.

That’s caught me out before. You think you’re at the start. They think you’re already a few weeks in.

And the next time they ask about it, they’re probably not looking for an update on how you’re getting set up. They’re expecting progress.

2. The ‘Step Back’ Phase

Once you actually get the project, there’s often a gap between how clear everyone thinks it is and how clear it really is.

And there’s usually pressure to get going.

I’d resist that for a bit.

Why are we doing this? What actually matters? What’s just nice to have? What happens if we don’t do it?

You’re not just being nosy. Later on you’re going to have to make trade-offs and make calls. If you don’t really understand why you’re doing the project, you’re guessing.

Sponsors don’t always love the questions either. Sometimes the answer is basically, “because the boss already said yes.”

And if you keep asking, you can start exposing bits of the idea that aren’t quite as solid as everyone thought.

Still worth doing.

Much better to have that conversation now than discover the same problem halfway through the project.

3. The ‘Reality Bites’ Phase

This is where the tech teams get a proper look at what they’re being asked to build.

And quite often the first reaction is something along the lines of: this is going to take longer than everyone thinks.

Stakeholders can find this phase frustrating. From their side, they’ve already explained what they want. Now they just want to know how long it’ll take.

The tech teams want time to dig into it before giving you a number. And they’re right to be cautious.

The problem is, everyone in tech knows what happens next. You give someone an estimate and five minutes later it’s a commitment.

Someone says “probably six weeks” and before you know it, six weeks is on a roadmap somewhere.

So give the team time to work it through. Not forever, obviously. Put some shape around it and keep the stakeholders close enough that they understand what’s happening.

Because that clock from Phase 1 is still running.

And you haven’t actually started building anything yet.

4. The ‘Lets Get This Done’ Phase

This is usually the good bit.

Things are actually getting built. Designers are designing. Developers are developing. Problems come up and people solve them. You can see progress.

Everyone is busy doing the bit of the job they’re good at.

The danger is that busy can look an awful lot like on track.

A few weeks disappear pretty quickly on a software project. So while everyone else is heads-down, you still need to keep checking that all this good work is actually getting you where you need to go.

And don’t forget the stakeholders.

Most of the interesting work is now happening somewhere they can’t really see. If you disappear for three months and then turn up with the finished thing, there’s a decent chance they’ll have developed some new opinions in the meantime.

5. The ‘Second Thoughts’ Phase

As you get closer to going live, something slightly odd can happen.

The tech team starts getting more confident that the thing is ready.

And everyone else starts getting less confident.

The change is suddenly real. People who were completely happy with it a few months ago start looking at it differently. New concerns appear. Things that didn’t seem particularly important before can suddenly become blockers.

Some of those concerns will be absolutely right. You need to listen to them.

But some won’t be.

I’ve had stakeholders raise an issue as a reason we couldn’t go live, only for us to realise the exact same problem was already in production and had been there for the best part of a year.

Should we fix it? Yep.

Should it suddenly stop this going live? Probably not.

6. The ‘T Minus’ Phase

Eventually you get to the point where the talking stops.

You’re going live.

There’ll probably still be things you’re not completely happy with. There’ll be decisions being made right up to the wire. Some of them will be yours.

And this is one of those moments where being the PM can feel a bit exposed.

If everything goes brilliantly, lots of people were involved.

If it goes badly, you may find the group of people who remember being involved gets a little smaller.

No pressure.

I’ve written separately about the credit and blame bit of the job.

7. The ‘Don’t Leave Me’ Phase

It’s live.

You can celebrate. Maybe give it a couple of days before you go completely mad.

There’ll be bugs, questions, little fixes, follow-up requests and probably a few things everyone somehow missed until real people started using it.

But there’s another problem.

Your stakeholders have probably got used to having a project team around.

For months, if they had a question, there was someone to ask. If something needed changing, there was a team looking at it. They had meetings, updates, access to people who knew the thing inside out.

And now you’re telling them everyone is moving on.

They don’t always love that.

So don’t disappear overnight. Make sure it’s clear who owns what next and where support comes from.

But don’t accidentally turn a temporary project team into permanent support either.

At some point, the thing has to stop being a project and just become part of normal life.

8. The ‘Next Time’ Phase

Once things settle down, you’ll probably have a decent list of things you’d do differently next time.

Some of them will be yours to fix. Fix them.

Some will need other people to change things. Push for those if they’re worth pushing for.

And some things probably won’t change at all, however obvious they now seem.

Then another project lands on your desk. Everyone’s very excited about it. And apparently they’d quite like to know when it’ll be finished.